DE69634608T2 - Verbindungsaufbaudurchgang für ein fernmeldesystem - Google Patents

Verbindungsaufbaudurchgang für ein fernmeldesystem Download PDF

Info

Publication number
DE69634608T2
DE69634608T2 DE69634608T DE69634608T DE69634608T2 DE 69634608 T2 DE69634608 T2 DE 69634608T2 DE 69634608 T DE69634608 T DE 69634608T DE 69634608 T DE69634608 T DE 69634608T DE 69634608 T2 DE69634608 T2 DE 69634608T2
Authority
DE
Germany
Prior art keywords
request
internet
service
call connection
resource
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE69634608T
Other languages
English (en)
Other versions
DE69634608D1 (de
Inventor
Colin Low
Nicolas Bouthors
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hewlett Packard Development Co LP
Original Assignee
Hewlett Packard Development Co LP
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
Priority claimed from GBGB9525190.6A external-priority patent/GB9525190D0/en
Priority claimed from GBGB9603591.0A external-priority patent/GB9603591D0/en
Application filed by Hewlett Packard Development Co LP filed Critical Hewlett Packard Development Co LP
Application granted granted Critical
Publication of DE69634608D1 publication Critical patent/DE69634608D1/de
Publication of DE69634608T2 publication Critical patent/DE69634608T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/10—Mapping addresses of different types
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/30—Managing network names, e.g. use of aliases or nicknames
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4557—Directories for hybrid networks, e.g. including telephone numbers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/43—Billing software details
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/56—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP for VoIP communications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/22—Arrangements for supervision, monitoring or testing
    • H04M3/2281—Call monitoring, e.g. for law enforcement purposes; Call tracing; Detection or prevention of malicious calls
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/4228—Systems providing special services or facilities to subscribers in networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/0024—Services and arrangements where telephone services are combined with data services
    • H04M7/003—Click to dial services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
    • H04M7/1205—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
    • H04M7/121—Details of network access arrangements or protocols
    • H04M7/122—Details of network access arrangements or protocols where the PSTN/ISDN access is used as an access to networks other than PSTN/ISDN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
    • H04M7/1205—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
    • H04M7/126—Interworking of session control protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
    • H04M7/1205—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
    • H04M7/128—Details of addressing, directories or routing tables
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0029—Provisions for intelligent networking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/30—Types of network names
    • H04L2101/33—Types of network names containing protocol addresses or telephone numbers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/618—Details of network addresses
    • H04L2101/65—Telephone numbers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2201/00—Electronic components, circuits, software, systems or apparatus used in telephone systems
    • H04M2201/60—Medium conversion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2203/00—Aspects of automatic or semi-automatic exchanges
    • H04M2203/10—Aspects of automatic or semi-automatic exchanges related to the purpose or context of the telephonic communication
    • H04M2203/1041—Televoting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/20—Technology dependant metering
    • H04M2215/202—VoIP; Packet switched telephony
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/22—Bandwidth or usage-sensitve billing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42136—Administration or customisation of services
    • H04M3/42153—Administration or customisation of services by subscriber
    • H04M3/42161—Administration or customisation of services by subscriber via computer interface
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42229—Personal communication services, i.e. services related to one subscriber independent of his terminal and/or location
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/4228—Systems providing special services or facilities to subscribers in networks
    • H04M3/42297—Systems providing special services or facilities to subscribers in networks with number portability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/428—Arrangements for placing incoming calls on hold
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/48—Arrangements for recalling a calling subscriber when the wanted subscriber ceases to be busy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/50—Centralised arrangements for answering calls; Centralised arrangements for recording messages for absent or busy subscribers ; Centralised arrangements for recording messages
    • H04M3/51—Centralised call answering arrangements requiring operator intervention, e.g. call or contact centers for telemarketing
    • H04M3/5183—Call or contact centers with computer-telephony arrangements
    • H04M3/5191—Call or contact centers with computer-telephony arrangements interacting with the Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/50—Centralised arrangements for answering calls; Centralised arrangements for recording messages for absent or busy subscribers ; Centralised arrangements for recording messages
    • H04M3/51—Centralised call answering arrangements requiring operator intervention, e.g. call or contact centers for telemarketing
    • H04M3/523—Centralised call answering arrangements requiring operator intervention, e.g. call or contact centers for telemarketing with call distribution or queueing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/50—Centralised arrangements for answering calls; Centralised arrangements for recording messages for absent or busy subscribers ; Centralised arrangements for recording messages
    • H04M3/53—Centralised arrangements for recording incoming messages, i.e. mailbox systems
    • H04M3/533—Voice mail systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/54—Arrangements for diverting calls for one subscriber to another predetermined subscriber
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13106—Microprocessor, CPU
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13109—Initializing, personal profile
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13141—Hunting for free outlet, circuit or channel
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13175—Graphical user interface [GUI], WWW interface, visual indication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13204—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13282—Call forward, follow-me, call diversion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13332—Broadband, CATV, dynamic bandwidth allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13345—Intelligent networks, SCP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13349—Network management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13389—LAN, internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13405—Dual frequency signaling, DTMF
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13504—Indexing scheme relating to selecting arrangements in general and for multiplex systems client/server architectures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13526—Indexing scheme relating to selecting arrangements in general and for multiplex systems resource management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13527—Indexing scheme relating to selecting arrangements in general and for multiplex systems protocols - X.25, TCAP etc.
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13528—SCP architecture
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13534—Internet - WWW, HTML, browsers etc.
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S379/00—Telephonic communications
    • Y10S379/90—Internet, e.g. Internet phone, webphone, internet-based telephony

Description

  • Die vorliegende Erfindung bezieht sich auf ein Verfahren zum Bereitstellen von Anrufverbindungs-Aufbau-Diensten in einem Wähltelekommunikationssystem.
  • Wie er hierin verwendet wird, bedeutet der Ausdruck „Wähltelekommunikationssystem" ein System, das ein Trägernetzwerk aufweist, das wählt bzw, vermittelt, um einen Trägerkanal durch das Netzwerk durchzuschalten. Der Ausdruck „Wähltelekommunikationssystem" soll verwendet werden, um nicht nur die existierenden öffentlichen und privaten Telephonsysteme (unabhängig davon, ob sie analoge Telephone oder Telephone auf ISDN-Basis verwenden) zu enthalten, sondern auch Breitband- (ATM) oder andere Trägernetzwerke auf Wählbasis, die gegenwärtig implementiert werden oder in der Zukunft entstehen können. Der Bequemlichkeit halber wird der Ausdruck „Wähltelekommunikationssystem" hierin manchmal auf Telekommunikationssystem abgekürzt.
  • Eine Bezugnahme auf eine „Anrufverbindung" im Zusammenhang mit einem Wähltelekommunikationssystem ist hinsichtlich seiner Bedeutung als eine Kommunikation durch einen Trägerkanal, der über das Trägernetzwerk aufgebaut ist, zu verstehen, während Bezugnahmen auf einen Anrufverbindungs-Aufbau, eine Anrufverbindungs-Aufrechterhaltung und einen Anrufverbindungs-Abbau hinsichtlich ihrer Bedeutung als die Verfahren zum Aufbauen, Aufrechterhalten und Abbauen eines Trägerkanals durch das Trägernetzwerk zu verstehen sind. Ausdrücke wie z. B. „Anrufverbindungsverarbeitung" und „Anrufsverbindungshandhabung" sind auf ähnliche Weise zu interpretieren.
  • Der Ausdruck „Kommunikationssystem" sollte, wenn er hierin verwendet wird, als eine breitere Bedeutung als Wähltelekommunikationssystem aufweisend verstanden werden, wobei beabsichtigt ist, daß derselbe Kommunikationssysteme auf Datagrammbasis umfaßt, bei denen jedes Datenpaket unabhängig durch ein Trägernetzwerk geleitet wird, ohne einem vorbestimmten Trägerkanal zu folgen.
  • Hintergrund der Erfindung
  • Telekommunikationsfirmen, die PSTNs (Public Switched Telephone Networks) und PLMNs (Public Land Mobile Networks) unterhalten, sind in dem Geschäftsfeld des Bereitstellens von Kommunikationsdiensten und stellen dabei eine zunehmende eingebaute Intelligenz in der Form von „IN-Diensten" bereit, wie z. B. 800-Nummer-Dienste und eine Rufweiterleitung. Im Gegensatz dazu ist das World Wide Web (WWW), das in jüngerer Zeit ein explosives Wachstum erfahren hat, ein Beispiel eines globalen Netzwerks auf Internet-Basis, das komplexe Informationsdienste bereitstellt. Diese zwei Welten, die eine der großen Kommunikationsdienstleistungen und die andere der hochdynamischen Pioniergeist-WWW-Informationskultur, sind unruhige Gefährten, wobei jede plant, in den Bereich einzugreifen, der vorher durch die andere besetzt war; folglich werden Telephondienste über das WWW angeboten und Informationsdienste über die öffentliche Kommunikationsinfrastruktur.
  • Die vorliegende Erfindung schlägt Technologien für eine synergetischere Beziehung zwischen diesen zwei Welten vor, als sie gegenwärtig ins Auge gefaßt ist, wobei, um die vorliegende Erfindung in den richtigen Zusammenhang zu setzen, zunächst eine Übersicht über jede dieser zwei Welten gegeben wird.
  • Telephonnetzwerke mit IN-Diensten
  • Das Basis-PSTN. Der Basisdienst, der durch ein PSTN (Public Switched Telephone Network) bereitgestellt wird, ist die Verbindung von zwei Telephonen (d. h. Aufbauen eines Trägerkanals zwischen den Telephonen) entsprechend einer Telephonnummer eines angerufenen Teilnehmers, die am Telephon des anrufenden Teilnehmers eingegeben wird. 1 ist eine vereinfachte Darstellung eines PSTN, das einen solchen Dienst bereitstellt. Im speziellen sind Teilnehmergerätschaften, CPE 10 (CPE = customer premises equipment) (wie z. B. analoge Standardtelephone, jedoch auch in neuerer Zeit ISDN-Geräte) durch ein Zugriffnetzwerk 11 mit Schaltstellen SPs 12 (SP = Switching point) verbunden. Die SPs 12 bilden Knoten in einem Übertragungsnetzwerk 13, das aus Verbindungskanälen 14 und SPs aufgebaut ist, die durch Steuerentitäten 15 in den SPs gesteuert werden. Die Steuerung, die durch die Steuerentitäten 15 bewirkt wird, ist durch ein Signalisieren von Eingangssignalen, die von dem CPEs und anderen SPs empfangen werden, bestimmt und involviert einen Rufverbindungs-Aufbau, eine -aufrechterhaltung und einen -abbau, um den gewünschten Trägerkanal zwischen einer anrufenden CPE und einer angerufenen CPE bereitzustellen. Konzeptmäßig kann das PSTN als ein Trägernetzwerk und ein Steuernetzwerk (Signalisierungsnetzwerk) betrachtet werden, wobei die Funktion des letztgenannten darin besteht, eine Anrufverbindungssteuerung durch das Trägernetzwerk zu bewirken, nämlich die Steuerung eines Aufbauens, Aufrechterhaltens und Abbauens von Trägerkanälen durch das Trägernetzwerk; in der Praxis können das Träger- und das Signalisierungs-Netzwerk die gleichen physikalischen Schaltungen und sogar die gleichen logischen Kanäle verwenden.
  • Wenn folglich die CPE ein herkömmliches dummes Telephon ist, ist die Steuersignalisierung zwischen der CPE und ihrer lokalen SP eine In-Band-Signalisierung, d. h. die Signalisierung wird auf dem gleichen Kanal durchgeführt, der für die Sprache verwendet wird; diese Signalisierung wird an der SP 12 interpretiert und in eine Signalisierung zwischen SPs umgewandelt, die ein zweckgebundenes Gemeinsam-Kanal-Signalisierungsnetzwerk 16 verwenden (das heutzutage unter Verwendung des SS7-Protokollstapels implementiert ist). Wenn die CPE ein ISDN-Gerät ist, wird die Signalisierung in einem separaten Kanal direkt von der CPE auf einer durchgehenden Basis durchgeführt. Moderne SPs verwenden das ISUP-SS7-Protokoll (ISUP = ISDN User Part; User Part = Benutzerteil) für eine Übertragungs-Anrufverbindungs-Steuersignalisierung, ungeachtet dessen, ob die CPE ein Standardtelephon oder ein ISDN-Gerät ist.
  • Telephonnumerierungspläne – Da bestimmte Aspekte der vorliegenden Erfindung durch die Strukturierung von Telephonnummern beeinflußt werden, wird nun eine kurze Beschreibung der Strukturierung solcher Nummern gegeben. Telephonnummern bilden ein internationales hierarchisches Adressierungsschema basierend auf Gruppen von Dezimalziffern. Die oberste Ebene der Hierarchie wird durch die ITU-T verwaltet, die den geographischen Hauptzonen numerische Einzel-Ziffern-Codes zugeordnet hat (beispielsweise „1" für Nordamerika, „2" für Afrika, „3" für Europa, „4" für Europa, „5" für Südamerika und Kuba, usw.). In jeder Zone sind Ländercodes mit 2 oder 3 Stellen zugewiesen, so daß in Zone 3 Frankreich „33" ist, und in der Zone 4 UK „44" ist. Die Verwaltung des Numerierungsplans in einem Land ist einem nationalen Körper übertragen, beispielsweise dem Office of Telecommunications („Oftel") in UK. Die folgende weitere Beschreibung basiert auf dem UK-Numerierungsplan, wobei jedoch zu erkennen ist, daß das beschriebene Schema weit verbreitete Anwendbarkeit besitzt.
  • In Großbritannien (UK) ist allen nationalen Nummern ein Code von 01 bis 09 vorangestellt (wobei das Präfix '0' beim internationalen Wählen weggelassen wird). Die momentan zugewiesenen Codes sind „01" für Codes geographischer Bereiche (Geographic Area Codes), „02" für Codes zusätzlicher geographischer Bereiche (Additional Geographic Area Codes), „04" für Mobildienste (Mobile Services), „07" für persönliche Nummern (Personal Numbers) und „08" für Spezialdienste (Special Services) (gebührenfrei, Informationen). Normale Drahtleitungs-PSTN-Teilnehmer-Telephonnummern werden von dem Geographic-Area-Code-Codes zugeordnet, wobei momentan nur Codes, denen 01 vorangestellt ist, zugeordnet werden. Codes für geographische Bereiche weisen gegenwärtig drei oder vier Stellen (mit Ausnahme der vorderen '0') auf, wobei gegenwärtig 638 geographische Bereiche, von denen jeder seinen eigenen Code aufweist, existieren. Eine vollständige nationale UK-Wählnummer besitzt zwei Formen:
    Figure 00050001
  • Der erste Fall umfaßt das Präfix '0', einen dreistelligen Bereichscode und eine siebenstellige lokale Nummer, während der zweite Fall das Präfix '0', einen vierstelligen Bereichscode und eine sechsstellige lokale Nummer besitzt. Eine weitere Interpretation der lokalen Nummer wird in der Bereichsvermittlungsstelle durchgeführt, da sogar ein sechsstelliger Adreßraum für einen einzelnen Vermittler zu groß ist, wobei für einen typischen lokalen Bereich mehrere Vermittler (Schalter) benötigt werden können, um die erforderliche Anzahl von Teilnehmerleitungen zu beherbergen. Diese Interpretation ist undurchsichtig und ist eine Aufgabe für den Bereichsdienstprovider.
  • Bei dem gegenwärtigen PSTN wird die inhärent hierarchische und geographische Interpretation der Telephonnummern durch die physikalische Architektur des Netzwerks widergespiegelt. Eine Telephonnummer ist auf eine Weise strukturiert, die es einfach macht, einen Anruf durch das Netzwerk zu leiten. Bei jedem Schritt liefert das Präfix der Nummer Informationen über den momentanen Leitschritt, während das Suffix (vielleicht undurchsichtig) Informationen über nachfolgende Leitschritte liefert; so lange ein Vermittler weiß, wie ein Präfix syntaktisch auszuwerten ist und ein Leitschritt durchzuführen ist, muß er den Inhalt des Suffix nicht verstehen, der für nachfolgende Leitschritte belassen wird. Aus diesem Grund ist die internationale und nationale Vermittlungskonfiguration ebenfalls hierarchisch organisiert.
  • Intellegente Netzwerke. Zurückkehrend nun zu einer Betrachtung der momentanen Telephonnetzwerk-Infrastruktur kann eine SP zusätzlich zu der elementaren Anrufverbindungshandhabung auch dazu dienen, IN-Dienste (IN = Intelligent Network) bereitzustellen; in diesem Fall wird die SP als eine Dienstvermittlungsstelle SSP (SSP = service switching point) bezeichnet. Eine SSP 25 ist angeordnet, um eine Anrufverbindungsverarbeitung an definierten Punkten in einer Anrufverbindung auf die Erfüllung bestimmter Kriterien hin anzuhalten und um die Fortsetzung der Anrufverbindungsverarbeitung einem Dienststeuerteilsystem zu übertragen, das eine Dienststeuerfunktion (SCF; SCF = service control function) entweder in der Form einer Dienststeuerstelle SCP 17 (siehe 2) oder eines Adjunct 18 bereitstellt. Das Adjunct 18 ist direkt einer SSP 25 zugeordnet, während die SCP 17 und die SSP 25 miteinander über ein erweitertes Gemeinsam-Kanal-Signalisierungsnetzwerk (CCS-Netzwerk; CCS = common channel singalling) 16 kommunizieren, das Signalübertragungsstellen (STP; STP = signal transfer points) 19 umfassen kann. Die SCP 17 kann mehr als einer SSP 25 zugeordnet sein. Sowohl die SCP 17 als auch das Adjunct 18 liefern eine Dienst-Logik-Ausführungsumgebung (SLEE; SLEE = service logic execution environment) 20, in der Instanzen von einem oder mehreren Dienstlogikprogrammen (SLP; SLP = service logic programs) 21 durchgeführt werden können. Die SLEE 20 und das SLP 21 liefern zusammen eine Dienststeuerfunktionalität zum Bereitstellen von Diensten zu der SSP 25.
  • Eine Dienstlogik, die in einer SCP oder einem Adjunct abläuft, wird im allgemeinen Teilnehmerinformationen verwenden, die in einer Dienstdatenfunktion (SDF; SDF = service data function) 22 gespeichert sind, die in die SCP/das Adjunct integriert oder teilweise oder vollständig getrennt von derselben bzw. demselben sein können. Die Dienstdatenfunktion (SDF) bildet wie die Dienststeuerfunktion (SCF) einen Teil des Dienststeuerteilsystem des PSTN. Es sei angemerkt, daß bestimmte oder alle der Dienststeuerfunktionen in die PSTN-Vermittler selbst eingebaut sein können.
  • Zusätzlich zu der SCP 17 und dem Adjunct 18 umfaßt das Netzwerk von 2 ein intelligentes Peripheriegerät (IP; IP = intelligent peripheral) 23. Das IP 23 liefert Ressourcen zu der SSP 25, wie z. B. Sprachansagen und DTMF-Stellen-Sammelfähigkeiten. Das Netzwerk wird ferner ein Betriebssystem (nicht gezeigt) umfassen, das eine allgemeine Ansicht des Netzwerks und seiner Dienste besitzt und Funktionen wie z. B. eine Netzwerk-Überwachung und – steuerung durchführt.
  • Wenn im Betreib die SSP 25 einen Anruf empfängt, untersucht sie die internen Auslösungszustände und, möglicherweise, Benutzerinformationen (beispielsweise gewählte Ziffern), um sicherzustellen, ob der Anruf erfordert, daß ein Dienst durch das Dienststeuerteilsystem 17, 18 bereitgestellt wird; das Überprüfen der Auslösungszustände kann an mehreren verschiedenen Punkten in der Anrufverarbeitung durchgeführt werden. Wenn die SSP 25 bestimmt, daß ein Dienst erforderlich ist, benachrichtigt sie das Dienststeuerteilsystem (entweder die SCP 17 oder das Adjunct 18), wobei der gewünschte Dienst angefordert wird und eine logische Darstellung des Anrufs bezüglich seiner Verbindbarkeit und seines Anrufverarbeitungsstatus zu demselben gesendet wird. Das Dienststeuerteilsystem stellt dann den angeforderten Dienst bereit, wobei dies entweder eine einzelne Interaktion zwischen der SSP und dem Dienststeuerteilsystem oder eine Sitzung von Interaktionen beinhalten kann. Ein typi scher Dienst ist eine Rufweiterleitung, die ein Dienst des angerufenen Teilnehmers ist, der einer so einfachen Endbenutzeranforderung wie „Wenn Du mich unter der Nummer X anrufst und es zehnmal läutet, dann versuche die Nummer Y anzurufen" Ausdruck verleiht. In diesem Fall löst die SSP, die sich bei dem angerufenen Endbenutzer befindet, ihre zugeordnete SCP (oder den Adjunct) aus, um diesen Dienst bereitzustellen. Es ist selbstverständlich klar, daß die SSP vorbereitet sein muß, um zu wissen, daß der Dienst für eine angerufene Nummer X bereitgestellt werden soll.
  • Das oben beschriebene Modell für die Bereitstellung von IN-Diensten in einem PSTN kann auch auf PLMNs (Public Land Mobile Networks) abgebildet werden, beispielsweise GSM oder andere Mobilnetzwerke. Die Steuersignalisierung in dem Fall eines mobilen Teilnehmers ist komplexer, da zusätzlich zu allen üblichen Signalisierungsanforderungen ferner ein Bedarf besteht, festzulegen, wie ein Anruf zu einem mobilen Teilnehmer geleitet werden sollte; dies ist jedoch kein von einer Anzahl von IN-Diensten eines angerufenen Teilnehmers in dem PSTN sehr unterschiedliches Problem. Folglich ist bei GSM die Dienstdatenfunktion (SDF) größtenteils in einem System angeordnet, das als HLR (HLR = Home Location Register) bezeichnet wird, angeordnet, während die Dienststeuerfunktion in einem System, das als VLR (VLR = Visitor Location Register) bezeichnet wird, das im allgemeinen auf einer Eins-Zu-Eins-Basis jeder SSP zugeordnet ist (was in GSM-Terminologie als ein MSC (MSC = Mobile Switching Centre), angeordnet ist.
  • Da Teilnehmer mobil sind, wird das Teilnehmerprofil von dem HLR zu jedem VLR transportiert, das zufällig funktional dem mobilen Teilnehmer nächstliegend ist, wobei von dort das VLR den (festgelegten) Dienst unter Verwendung des Teilnehmerprofils bedient und mit der SSP interagiert. Das HLR und das VLR bilden folglich ein Dienststeuerteilsystem ähnlich einer SCP oder eines Adjuncts mit deren zugeordneten Datenbanken.
  • Es ist selbstverständlich auch möglich, IN-Dienste in privaten Telephonsystemen bereitzustellen, wobei in diesem Fall die Dienststeuerfunktion und die Dienstdatenfunktion allgemein entweder in eine PABX (PABX = Private Automatic Branch Exchange = private automatische Zweigvermittlung) integriert sind oder durch einen lokalen Computer bereitgestellt werden. Das Dienststeuerteilsystem muß, solange vorliegend, folglich von der PABX nicht physikalisch verschieden sein.
  • Der oben beschriebene allgemeine Architekturrahmen zum Bereitstellen von IN-Diensten hat sowohl Stärken als auch Schwächen. Seine Hauptstärke besteht darin, daß er funktioniert und daß viele Dienste erfolgreich eingesetzt wurden, wie z. B. 800-Nummer-Dienste, Kreditkartenanrufe, Sprachkommunikationssysteme und verschiedene Ruf-Warte- und – Umleitungs-Dienste. Jedoch werden ungeachtet von Jahren der Standardisierung Dienste noch einzeln auf herstellerspezifischen Plattformen implementiert und lassen sich nicht gut skalieren. Der Lösungsansatz basierte auf großen fehlertoleranten Systemen, die Dienste für hunderttausende oder sogar Millionen von Teilnehmern bereitstellen und Jahre für einen Einsatz benötigen. Da ferner die Netzwerke, die verwendet werden, um diese Dienste zu unterstützen, auch die elementare Telephoninfrastruktur bilden, muß alles, was diesen Netzwerken hinzugefügt wird, rigoros auf Herz und Nieren überprüft werden. Darüber hinaus existiert die Tendenz, daß jedes Land und jeder Bediener lokale Abweichungen der sogenannten Standards besitzt, was es schwierig macht, Standardprodukte zu liefern, wodurch die Dynamik des Wettbewerbs unterbrochen wird.
  • Das World Wide Web
  • Im Gegensatz zu dem langsamen mäßigen Fortschritt der Telephoninfrastruktur ist das WWW seit seinem Beginn 1989 explosionsartig gewachsen, um der primäre elektronische Informationsverteilungsdienst bezüglich Verbreitung, Verfügbarkeit und Informationsinhaltsfülle zu werden. Jedermann kann, für bescheidene Auslagen, ein Informationsverteilungsdienst mit einer weltweiten Hörerschaft in einer stark verbundenen Informationsarchitektur werden.
  • Das WWW ist eine Client-Server-Anwendung, die über das Internet läuft und ein Client-Server-Protokoll verwendet, das nur die einfachsten Austausche zwischen Client und Server vorschreibt. Dieses Protokoll ist HTTP (Hyper Text Transfer Protocol), das für eine Verwendung über TCP/IP-Netzwerke, wie z. B. das Internet, optimiert ist; das HTTP-Protokoll kann jedoch auch über Netzwerke unter Verwendung anderer Kommunikationsprotokollstapel verwendet werden.
  • Da die Verfügbarkeit von Literatur, die das WWW betrifft, ein gleichartiges Wachstum erfahren hat, wie das WWW selbst, wird hierin keine detaillierte Beschreibung des WWWs, des HTTPs und des Internets gegeben. Jedoch erfolgt eine skizzenhafte Beschreibung, deren Augenmerk auf bestimmten Merkmalen, die für die vorliegende Erfindung relevant sind, liegt.
  • Das WWW benutzt des Internet für eine Verbindbarkeit. Das Internet ist ein System, das Netzwerke auf einer weltweiten Basis miteinander verbindet. Das Internet basiert auf dem TCP/IP-Protokollstapel und liefert eine Verbindbarkeit für Netzwerke, die ebenfalls TCP/IP verwenden. Damit eine Entität eine Präsenz im Internet haben kann, benötigt sie sowohl einen Zugriff auf ein Netzwerk, das mit dem Internet verbunden ist, als auch eine IP-Adresse. IP-Adressen sind hierarchisch strukturiert. Allgemein wird eine Entität auf der Benutzerebene durch einen Namen identifiziert, der durch das DNS (DNS = Domain Name System = Domain-Namen-System) des Internets in die entsprechende IP-Adresse aufgelöst werden kann. Da das DNS oder Anpassungen dessel ben fundamental für zumindest bestimmte Ausführungsbeispiele der nachfolgend hierin beschriebenen Erfindung sind, folgt als nächstes eine Beschreibung der allgemeinen Form und Operationen des DNS.
  • Das Domain-Namen-System (DNS) – Das DNS ist eine globale verteilte Datenbank, wobei ohne ihre Leistungsfähigkeit, Elastizität und Skalierbarkeit ein großer Teil des Internets nicht in seiner gegenwärtigen Form existieren würde. Das DNS ist ansprechend auf eine Client-Anforderung wirksam, um einen Internet-Host-Domainnamen einem oder mehreren Registrierungsdatensätzen RR (RR = Registration Records) unterschiedlicher Typen zuzuordnen, wobei die üblichsten ein Adreß-Datensatz (A-Datensatz) (wie z. B. 15.144.8.69) und Post-Austauschdatensätze (MX-Datensätze; MX = mail exchanger) (die verwendet werden, um einen Domain-Host zu identifizieren, der konfiguriert ist, um elektronische Post für eine Domain zu akzeptieren) sind. Die RRs sind über DNS-Namenserver weltweit verbreitet, wobei diese Server zusammenarbeiten, um den Domain-Namen-Übersetzungsdienst zu liefern; kein einzelner DNS-Server enthält mehr als einen kleinen Teil der globalen Datenbank, wobei jedoch jeder Server weiß, wie DNS-Server zu lokalisieren sind, die „näher" an den Daten sind als er selbst. Für gegenwärtige Zwecke sind die Hauptcharakteristika des interessierenden DNS wie folgt:
    • – Der Host-Namenraum ist als eine Baum-Struktur-Hierarchie von Knoten organisiert, wobei jeder Host einen entsprechenden Blattknoten aufweist; jeder Knoten besitzt eine Kennung (mit Ausnahme des Wurzelknotens), wobei jede Kennung mit einem alphabetischen Zeichen beginnt, dem eine Sequenz von alphabetischen Zeichen oder Ziffern folgt. Der volle, oder „vollständig qualifizierte" Name eines Hosts ist die Zeichenfolge der Knotenkennungen, von denen jede durch einen „." getrennt ist, von dem entsprechenden Blattknoten zu dem Wurzelknoten der Hierarchie, wobei dieser Letztere durch einen abschließenden „." in dem Namen dargestellt ist. Folglich hat eine Host-Maschine „Fred" von Hewlett-Packard Laboratories in Bristol, England, einen vollständig qualifizierten Domainnamen von „fred.hpl.hp.com." (es sei bemerkt, daß, wenn ein Host-Name keinen abschließenden „." aufweist, derselbe relativ zu dem momentanen Knoten der Namensgebungshierarchie interpretiert wird).
    • – Jeder Host besitzt einen oder mehrere zugeordnete Registrierungsdatensätze (RRs).
    • – Es existiert eine Mehrzahl von DNS-Servern, von denen jeder Verantwortung für einen Teilbaum des Namenraums besitzt. Ein DNS-Server wird RRs für den gesamten oder einen Teil seines Teilbaums halten – in dem letztgenannten Fall überträgt er die Verantwortung für den Rest des Teilbaums zu einem oder mehreren weiteren DNS-Servern. Ein DNS-Server kennt die Adresse von jeglichem Server, auf den er Verantwortung übertragen hat, und ferner die Adresse des Servers, dem er die Verantwortung für den Teilbaum, den er verwaltet, gegeben hat. Die DNS-Server zeigen somit auf jeden anderen in einer Struktur, die die der Namensgebungshierarchie widerspiegelt.
    • – Eine Anwendung, die das DNS benutzen möchte, tut dies durch einen zugeordneten „Auflöser", der die Adresse von zumindest einem DNS-Server kennt. Wenn ein DNS-Server durch diesen Auflöser nach einer RR eines spezifizierten Host gefragt wird, wird er entweder den angeforderten RR oder die Adresse eines DNS-Servers zurückgeben, der hinsichtlich einer Durchquerung der Namensgebungshierarchie näher an dem Server ist, der den RR hält. Tatsächlich wird die Hierarchie der Server nach oben durchlaufen, bis ein Server erreicht ist, der auch die Verantwortung für den Domainnamen, der aufgelöst werden soll, hat; danach wird die DNS-Server-Hierarchie absteigend bis zu dem Server durchlaufen, der den RR für den Domainnamen, der aufgelöst werden soll, hält.
    • – Das DNS verwendet ein vorbestimmtes Nachrichtenformat (tatsächlich ist es dasselbe für eine Anfrage und eine Antwort) und verwendet die IP-Protokolle.
  • Diese Charakteristika des DNS können als ein „DNS-Typ"-System definierend betrachtet werden, was stets kleinere Variationen ermöglicht, wie z. B. bezüglich der Kennungssyntax, wie die Kennungen kombiniert werden (Sortierung, Separatoren), der Nachrichtenformateinzelheiten, der Entwicklungen von IP-Protokollen usw.
  • Aufgrund der hierarchischen Namensgebungsstruktur ist es möglich, die Verantwortung für die Verwaltung von Domains (Teilbäumen) des Namenraums rekursiv zu übertragen. Folglich werden die Top-Level-Domains durch InterNic verwaltet (diese Top-Level-Domains umfassen die bekannten 'com', 'edu', 'org', 'int', 'net', 'mil'-Domains, ebenso wie Top-Level-Länder-Domains, die durch Standard-Zwei-Buchstaben-Codes spezifiziert sind, wie z. B. 'us', 'uk', 'fr' usw.) Auf dem nächsten Level ist beispielsweise die Hewlett-Packard Company für alle Namen verantwortlich, die mit 'hp.com' enden, während die British Universities gemeinsam für alle Namen verantwortlich sind, die mit 'ac.uk' enden. Weiter absteigend und wiederum beispielsweise steht die Verwaltung der Domain 'hpl.hp.com' in der Verantwortung der Hewlett-Packard-Laboratories und die Verwaltung des Teilbaums (der Domain) 'newcastle.ac.uk' liegt in der Verantwortung der University of Newcastle-upon-Tyne.
  • 3 zeigt den Fortschritt einer beispielhaften Abfrage, die von innerhalb der Hewlett-Packard Laboratories durchgeführt wird. Der Host-Domainname, der aufgelöst werden soll, ist 'xy.newcastle.ac.uk', eine hypothetische Maschine an der University of Newcastle, Großbritannien. Die Abfrage wird dem DNS-Server präsentiert, der für den Teilbaum "hpl.hp.com" verantwortlich ist. Dieser Server hält nicht den angeforderten RR und antwortet somit mit der Adresse des "hp.com"-DNS-Servers; dieser Server wird dann abgefragt und antwortet mit der Adresse des 'com'-DNS-Servers, der wiederum mit der Adresse des '.'-DNS-Servers (Wurzel-DNS-Servers) antwortet. Die Abfrage schreitet dann iterativ herunter zu dem 'uk'-Zweig fort, bis der 'newcastle.ac.uk'-Server mit dem RR-Datensatz für den Namen 'xy' in seinem Teilbaum antwortet.
  • Dies sieht extrem ineffizient aus, jedoch sind die DNS-Server entworfen, um einen dynamischen Cache aufzubauen, und werden mit den Adressen mehrere Wurzel-Server initialisiert, so daß in der Praxis die meisten der iterativen Abfragen niemals stattfinden. In diesem Fall wird der 'hpl.hp.com'-DNS-Server die Adressen mehrerer Wurzel-Server kennen und wird wahrscheinlich die Adressen der 'uk'- und 'ac.uk'-Server in seinem Cache haben. Die erste Abfrage an den 'hpl.hp.com'-Server wird die Adresse des 'ac.uk'-Servers zurückgeben. Die zweite Abfrage an den 'ac.uk'-Server wird die Adresse des 'newcastle.ac.uk'-Servers zurückgeben, und die dritte Abfrage wird den fraglichen RR zurückgeben. Alle zukünftigen Abfragen mit einem 'newcastle.ac.uk'-Präfix werden direkt zu dem Newcastle-DNS-Server gehen, da diese Adresse in dem 'hpl.hp.com'-DNS-Server-Cache gehalten wird. In der Praxis werden Namen in einem lokalen Teilbaum in einer einzelnen Abfrage aufgelöst, während Namen außerhalb des lokalen Teilbaums in zwei oder drei Abfragen aufgelöst werden.
  • Anstelle dessen, daß ein Auflöser für das Durchführen der Reihe von Abfrageniterationen, die erforderlich sind, um einen Domainnamen aufzulösen, verantwortlich ist, kann der Auflöser seine erste Abfrage spezifizieren, um rekursiv zu sein, wobei in diesem Fall der empfangende DNS-Server für das Auflösen der Abfrage verantwortlich ist (wenn er den angeforderten RR nicht direkt zurückgeben kann, wird er selbst eine rekursive Abfrage zu einem 'näheren' DNS-Server ausgeben, usw.).
  • Es sei ferner bemerkt, daß in der Praxis jeder DNS-Server vervielfältigt sein wird, d. h. als ein primärer und ein oder mehrere sekundäre organisiert sein wird. Ein primärer DNS-Namenserver initialisiert sich selbst von einer Datenbank, die auf einem lokalen Dateisystem gehalten ist, während ein sekundärer sich selbst durch Übertragen von Informationen von einem primären initialisiert. Ein Teilbaum wird normalerweise einen primären Namenserver und bis zu zehn sekundäre besitzen – wobei die Begrenzung tendenziell die Zeit ist, die durch die sekundären benötigt wird, um ihre Datenbanken von den primären zu aktualisieren. Die primäre Datenbank ist die Master-Quelle von Teilbauminformationen und wird durch den Domain-DNS-Verwalter gehalten. Die sekundären sind nicht einfach Ersatzsekundäre, sondern nehmen jeweils aktiv in dem DNS teil, wobei abhängige Server auf dieselben zeigen, und nicht auf den entsprechenden primären.
  • DNS-Implementierungen, wie z. B. BIND, sind als ein Standardteil der meisten UNIX-Systeme verbreitet verfügbar und können für sich beanspruchen, unter den robustesten und am weitesten verbreiteten existierenden verteilten Anwendungen zu sein.
  • Betrieb des WWW: Bezug nehmend auf 4 der beigefügten Zeichnungen kann ein Zugriff auf das Internet durch eine direkte Verbindung mit einem Netzwerk, das selbst direkt oder indirekt mit dem Internet verbunden ist, stattfinden; eine solche Anordnung wird durch ein Endgerät 31 in 4 dargestellt (dieses Endgerät kann beispielsweise eine UNIX-Workstation oder ein PC sein). Das Besitzen einer Verbindung in das Internet dieser Form ist als das Besitzen eines 'Netzwerkzugriffs' bekannt. Jede Entität, die einen Netzwerkzugriff in das Internet besitzt, kann als ein Server im Internet wirksam sein, vorausgesetzt dieselbe besitzt eine ausreichende zugeordnete Funktionalität; in 4 ist eine Entität 32 mit einem Dateispeicher 37 als ein Server wirksam.
  • Viele Benutzer des WWW besitzen keinen Netzwerkzugriff in das Internet, sondern greifen statt dessen über einen Internet-Dienst-Provider, ISP (ISP = Internet service provider) 33, der einen Netzwerkzugriff besitzt, auf das Internet zu. In diesem Fall wird das Benutzer-Endgerät 34 allgemein mit dem ISB 33 über das öffentliche Telephonsystem unter Verwendung eines Modems und unter Verwendung von entweder SLIP (SLIP = Serial Line Interface Protocol) oder PPP (PPP = Point-to-Point Protocol) kommunizieren. Diese Protokolle ermöglichen, daß Internet-Pakete herkömmliche Telephonleitungen überqueren. Ein Zugriff auf das Internet dieser Form ist als „Einwahl-IP"-Zugriff bekannt. Bei dieser Zugriffsmethode wird dem Benutzer-Endgerät 34 während jeder Benutzersitzung temporär eine IP-Adresse zugeordnet; da sich diese IP-Adresse jedoch zwischen Sitzungen unterscheiden kann, ist es für die Entität 34 nicht zweckmäßig, als ein Server wirksam zu sein.
  • Ein Eckpfeiler des WWW ist seine Fähigkeit, spezielle Informationsressourcen durch einen URI (URI = Uniform Resource Identifier) zu adressieren, der im allgemeinen entweder ein URL (URL = Uniform Resource Locator), der eine Ressource durch ihren Ort identifiziert, oder ein URN (URN = Uniform Resource Name), der in einen URL aufgelöst werden kann, ist. Beispielsweise wird ein voller oder „absoluter" URL folgende Elemente aufweisen:
    Schema – dies ist das Zugriffsschema, das verwendet werden soll, um auf die interessierende Ressource zuzugreifen;
    Host – der Internet-Host-Domainname oder die -IP-Adresse;
    Port – der Host-Port für die (TCP)-Verbindung;
    abs-Weg – der absolute Weg der Ressource auf dem Host.
  • Tatsächlich kann 'Port' weggelassen sein, wobei in einem solchen Fall Port 80 angenommen wird.
  • 5 der beigefügten Zeichnungen zeigt einen beispielhaften URL für die Hewlett-Packard-Produkte-Willkommens-Seite. In diesem Fall sind die Elemente:
    Schema – http
    Host – www.hp.com
    Port – weggelassen (Port 80 angenommen)
    abs-Weg – Products.html
  • Das HTTP-Protokoll basiert auf einem Anforderungs/Antwort-Paradigma. Bezug nehmend wiederum auf 4 der Zeichnungen erstellt ein Client bei einem gegebenen speziellen URI, der eine Ressource 30, auf die zugegriffen werden soll, identifiziert, eine Verbindung mit dem Server 31, der dem „Host"-Element des URI entspricht und sendet eine Anforderung zu dem Server. Diese Anforderung umfaßt ein Anforderungsverfahren und den „Anforderungs-URI" (der im allgemeinen exakt der absolute Weg der Ressource auf dem Server ist, wie er durch das „abs-Weg"-Element des URI identifiziert ist); die Anforderung kann zusätzliche Datenelemente umfassen. Der Server 31 greift dann auf die Ressource 36 (die hier im Speicher 37 gehalten ist) zu und antwortet, wobei diese Antwort eine Entität eines Typs, der durch einen MIME-Typ (MIME = Multipurpose Internet Mail Extensions) identifiziert ist, der ebenfalls in der Antwort enthalten ist, umfassen kann.
  • Die zwei Hauptanforderungsverfahren sind:
    GET (Holen) – Dieses Verfahren hat die Wiedererlangung jeglicher Informationen (in der Form einer Entität) zur Folge, die durch den Anforderungs-URI identifiziert sind. Es ist wichtig, zu bemerken, daß es, wenn sich der Anforderungs-URI auf einen Datenerzeugungsprozeß bezieht, die erzeugten Daten sind, die als die Entität in der Antwort zurückgegeben werden, und nicht der Quelltext des Prozesses.
    POST (Versenden) – Dieses Verfahren wird verwendet, um anzufordern, daß der Zielserver die Entität, die in der Anforderung enthalten ist, als eine neue untergeordnete der Ressource, die durch den Anforderungs-URI identifiziert ist, akzeptiert. Das POST-Verfahren kann zur Kommentierung existierender Ressourcen, zum Liefern einer Nachricht zu einem schwarzen Brett, zum Liefern von Daten zu einem Datenhandhabungsprozeß (beispielsweise von Daten, die als das Ergebnis des Übermittelns eines Formulars erzeugt werden), und zum Erweitern einer Datenbank durch eine Beifügungs-Operation verwendet werden.
  • Zusammenfassend kann das GET-Verfahren verwendet werden, um direkt Daten wiederzugewinnen, oder um irgendeinen Prozeß auszulösen, der eine Entität zurückgeben wird (die entweder Daten oder einfach eine Anzeige des Ergebnisses des Durchführens des Prozesses sein können). Das POST-Verfahren wird verwendet, um Daten zu registrieren, wobei ein Spezifizieren dieses Verfahrens ferner wirksam ist, um einen Prozeß in dem Server auszulösen, um die versendeten Daten geeignet zu handhaben.
  • Das Weiterleiten von Informationen zu einem Prozeß, der unter Verwendung entweder des GET- oder des POST-Verfahrens ausgelöst wird, um auf einem Server zu laufen, geschieht momentan gemäß einer Schnittstelle, die als die CGI (CGI = Common Gateway Interface = gemeinsame Übergangsschnittstelle) bezeichnet wird. Der Empfangsprozeß ist häufig in einer Script-Sprache geschrieben, obwohl dies nicht essentiell ist. Typischerweise wird das Script des ausgelösten Servers verwendet, um eine Schnittstelle zu einer Datenbank herzustellen, um eine Abfrage, die in einer GET-Anforderung enthalten ist, zu behandeln. Eine weitere Verwendung, auf die bereits verwiesen wurde, besteht darin, Daten, die einer POST-Anforderung zugeordnet sind, einer Datenbank beizufügen.
  • Weitere wichtige Faktoren des Erfolgs des WWW sind die Verwendung der HCML (HCML = Hyper Text Markup Language) zum Darstellen der Konfiguration von Dokumenten, die über das WWW übertragen werden, und die Verfügbarkeit von leistungsstarken Graphik-WEB-Browsern zum Interpretieren derartiger Dokumente in einem Client-Endgerät, um dieselben einem Benutzer zu präsentieren. Grundsätzlich wird HTML verwendet, um jeden Teil eines Dokuments zu identifizieren, beispielsweise einen Titel oder eine Graphik, wobei es dann die Aufgabe des Browsers, der in dem Client-Endgerät läuft, ist, zu entscheiden, wie jeder Dokumententeil anzuzeigen ist. Jedoch ist HTML mehr als dies – sie ermöglicht ferner, daß ein URI und ein Anforderungsverfahren jedem Element eines Dokuments (beispielsweise einem speziellen Wort oder einem Bild) zugeordnet werden, so daß, wenn ein Benutzer auf dieses Element zeigt und dasselbe anklickt, auf die Ressource, die durch den URI identifiziert ist, gemäß dem Schema (Protokoll) und dem spezifizierten Anforderungsverfahren zugegriffen wird. Diese Anordnung liefert einen Hyperlink von einem Dokument zu einem anderen. Unter Verwendung derartiger Hyperlinks kann ein Benutzer an einem Client-Endgerät ohne Anstrengung von einem Dokument, das von einem Server auf einer Seite der Welt heruntergeladen wird, zu einem anderen Dokument, das sich auf einem Server auf der anderen Seite der Welt befindet, springen. Da ein Dokument, das durch einen Autor erzeugt wurde, einen Hyperlink zu einem Dokument, das durch einen anderen Author erzeugt wurde, aufweisen kann, ist ein extrem leistungs starkes Dokumenten-Querverweis-System ohne eine zentrale bürokratische Kontrolle die Folge.
  • Hyperlinks sind nicht die einzige Intelligenz, die in ein HTML-Dokument eingebaut werden kann. Ein weiteres leistungsstarkes Merkmal ist die Fähigkeit, ein heruntergeladenes „Formular"-Dokument auf dem Bildschirm auszufüllen und dann einen 'Durchführungs'-Graphikknopf zu betätigen, um die eingegebenen Informationen zu einer Ressource (wie z. B. einer Datenbank), die konzipiert ist, um derartige Informationen zu sammeln, weiterleiten zu lassen. Dies wird durch ein Zuordnen des POST-Anforderungsverfahrens zu dem 'Durchführungs'-Knopf zusammen mit dem URI der Datenbankressource erreicht; das Betätigen des 'Durchführungs'-Knopfs hat zur Folge, daß die eingegebenen Informationen zu der identifizierten Ressource versandt werden, wo dieselben geeignet gehandhabt werden.
  • Eine weitere leistungsstarke Möglichkeit ist die Zuordnung eines Programmcodes (im allgemeinen Scripten, die zu interpretieren sind) zu speziellen Dokumentenelementen, wie z. B. Graphikknöpfen, wobei dieser Code auf das Betätigen des Knopfs hin ausgeführt wird. Dies eröffnet die Möglichkeit, daß Benutzer einen Programmcode von einer Ressource herunterladen und dann den Code ausführen.
  • Es ist für Fachleute zu erkennen, daß HTML nur eine von mehreren gegenwärtig verfügbaren Scriptsprachen ist, die die oben umrissene Funktionalität liefern, und daß davon ausgegangen werden kann, daß jeder seriöse WEB-Browser eine eingebaute Unterstützung für mehrere Scriptsprachen aufweist.
  • Die Wichtigkeit der Rolle des Graphik-WEB-Browsers selbst sollte nicht übersehen werden. Neben der Fähigkeit, mehrere Scriptsprachen zu unterstützen, sollte ein WEB-Browser neben weiteren Merkmalen eine eingebaute Unterstützung für Standardmedientypen und die Fähigkeit, Programme in den Client zu laden und auszuführen, liefern. Diese Browser können als Betriebssysteme für eine WWW-Interaktion betrachtet werden.
  • WWW und das Telephonnetzwerk
  • Es ist möglich, einen Telephondienst über das Internet zwischen verbundenen Endgeräten bereitzustellen, indem eine Spracheingabe digitalisiert und über das Internet in diskreten Paketen für eine Wiederzusammenstellung an dem Empfangsendgerät gesendet wird. Dies ist ein Beispiel eines Kommunikationsdienst im Internet. Im Gegensatz dazu ist es möglich, auf eine Vielzahl von Informationsdiensten, die über das Telephonsystem bereitgestellt werden, zu zeigen, wie z. B. das Minitel-System, das in Frankreich verbreitet verfügbar ist. Jedoch stellen diese Eingriffe in die traditionellen Territorien des jeweils anderen keine wirkliche Bedrohung für entweder das Internet oder das öffentliche Telephonsystem dar.
  • Interessanter sind Bereiche einer kooperativen Verwendung des Internets und des Telephonsystems. Tatsächlich existierte ein solcher Bereich für eine beträchtliche Zeit und wurde oben Bezug nehmend auf 4 umrissen, nämlich die Verwendung einer Modem-Verknüpfung über das PSTN von einem Benutzercomputer 34 zu einem Internet-Provider 33, um einen Einwahl-IP-Zugriff auf das Internet zu erhalten. Diese kooperative Verwendung ist von sehr einfacher Beschaffenheit, nämlich den Aufbau eines Trägerkanals über das PSTN für einen nachfolgend erzeugten Internetverkehr; es existiert keine wirkliche Interaktion zwischen dem Internet und dem PSTN.
  • Ein weiteres bekanntes Beispiel der kooperativen Verwendung von Internet und PSTN ist ein in jüngerer Zeit in Gang gebrachter Dienst, durch den ein Internetbenutzer mit einer Sound-Karte in ihrem/seinem Endgerätcomputer einen Sprach anruf zu einem Standardtelephon überall in der Welt durchführen kann. Dies wird erreicht, indem digitalisierte Sprache über das Internet zu einem Dienstprovider in der Nähe des Zieltelephons übertragen wird; dieser Dienstprovider stellt dann eine Verbindung in das lokale PSTN her, um auf das gewünschte Telephon zuzugreifen und überträgt den Sprachverkehr, der über das Internet empfangen wird, in das lokale PSTN. Eine Spracheingabe von dem angerufenen Telephon wird auf die umgekehrte Art und Weise gehandhabt. Der Schlüssel zu diesem Dienst ist die Fähigkeit, den bezüglich des Zieltelephons lokalen Dienstprovider zu identifizieren (hinsichtlich der Fernsprechgebühren). Obwohl diese Anordnung die Aussicht eines Wettbewerbs für die Telekommunikationsbetreiber für Ferngespräche bietet, ist sie wiederum ein einfaches Verketten von Internet und PSTN. Es ist jedoch zu bemerken, daß es in diesem Fall notwendig ist, zumindest ein Minimum an Feedback zu dem anrufenden Internet-Teilnehmer über den Fortschritt eines Verbindungsaufbaus zu dem Zieltelephon über das bezüglich dieses Telephons lokale PSTN zu liefern; dieses Feedback muß lediglich darin bestehen, ob der Anruf erfolgreich war oder nicht.
  • Der Artikel „Internet Access via Baseband and Broadband ISDN Gateways" von Tao J u. a. (International Conference on Computers and Communications, April 1994, Phoenix, S. 485 – 490) beschreibt den Entwurf und die Implementierung eines ISDN-zu-Internet-Netzübergangs unter Verwendung der TCP/IP-Protokollreihe.
  • Die EP 0 740 445 A (Rockwell International), die nach dem Prioritätsdatum der vorliegenden Anmeldung, aber vor dem Einreichdatum derselben veröffentlicht wurde, offenbart eine Einrichtung, durch die ein Internetnutzer, der das Web durchsucht, an einer Website für einen Agenten des Besitzers der Site eine Mitteilung hinterlassen kann, um den Teilnehmer anzurufen.
  • Aus dem Vorhergehenden ist ersichtlich, dass die aktuelle zusammenwirkende Verwendung des Internets und Telefonsystems auf einer sehr einfachen Ebene stattfindet.
  • Der Artikel mit dem Titel „Distributed intelligence and data in public and private networks" von R.P. Swale & D.R. Chesterton (BT Technology Journal, Bd. 13, Nr. 2, April 1995, Ipswich GB, Seiten 94 – 105) erörtert die CTI (Computer-Telefon-Integration) von Ersten und Dritten, wobei die Letzteren als „privates IN" (IN = Intelligentes Netzwerk) bezeichnet werden. Der Artikel vergleicht private und öffentliche IN, wobei angemerkt wird, dass dieselben häufig komplementär sind. Drei Möglichkeiten für die Verbindung von privaten und öffentlichen IN werden erörtert, nämlich:
    • – einfache Verbindung (d. h. eine Trägerebenenbeziehung, die das Trägersignalisierungssystem umfasst);
    • – SCP-Zugriff zu einer privaten Datenbank (die öffentliche SCP interagiert mit einer Datenbank, die in einem privaten Netzwerk gehalten wird);
    • – Hoststeuerung des öffentlichen Wählnetzes (eine private Selbstwählnebenstelle (PBX) einer Organisation wird durch das lokale öffentliche Netz ersetzt, wobei der private SCP-Host dann verbunden wird, um das lokale Wählnetz bezüglich Anrufen, die sich auf die Organisation beziehen, zu steuern).
  • Der Artikel „Customers in Driver's Seat: Private Intelligent Network Control Point" von M. Sevcik; R. Lueder (ISS '95 World Telecommunications Congress, Bd. 2, 23. April 1995, Berlin DE, Seiten 41 – 44) beschreibt eine private SCP (PSCP), die über eine TCP/IP-Verbindung mit einer Netzwerk-SCP (NSCP) verbunden ist. Die NSCP leitet übersetzte INAP-Mitteilungen direkt an die PSCP weiter. Die PSCP ist so dargestellt, dass sie als eine Ressource auf einem privaten LAN verbunden ist.
  • Es ist eine Aufgabe der vorliegenden Erfindung, ein Anrufverbindungsaufbauverfahren zum Aufbauen von Trägerkanälen durch ein Telekommunikationssystem zu liefern, das eine größere Flexibilität aufweist als diejenige, die durch aktuelle Anordnungen geboten wird.
  • Zusammenfassung der Erfindung
  • Gemäß einem Aspekt der Erfindung ist ein Verfahren zum Aufbauen eines Trägerkanals durch ein öffentliches Telefonsystem zwischen einer ersten Partei und einer zweiten Partei vorgesehen, denen ein erster vorbestimmter Code bzw. ein zweiter vorbestimmter Code zugeordnet ist, wobei das öffentliche Telefonsystem eine Schalteinrichtung zum Aufbauen von Trägerkanälen durch das öffentliche Telefonsystem und einen Anrufverbindungs-Aufbau-Netzübergang bzw. -Gateway aufweist, durch den die Schalteinrichtung von dem öffentlichen Internet gesteuert werden kann, wobei das Verfahren folgende Schritte umfasst:
    • a) Bereitstellen des zweiten vorbestimmten Codes und einer Dienstlogik zum Erzeugen und Übertragen von Anrufverbindungs-Aufbau-Anforderungen auf einem Server, der mit dem öffentlichen Internet verbunden ist;
    • b) Weiterleiten des ersten vorbestimmten Codes an den Server über das Internet von einem Anschluss, der der ersten Partei zugeordnet ist, wobei die Dienstlogik an dem Server veranlasst wird, eine Anrufverbindungs-Aufbau-Anforderung zu erzeugen und die Anforderung an den Anrufverbindungs-Aufbau-Gateway über das Internet zu übertragen, wobei die Anrufverbindungs-Aufbau-Anforderung sowohl den ersten vorbestimmten Code als auch den zweiten vorbestimmten Code umfasst; und
    • c) auf den Empfang der Anrufverbindungs-Aufbau-Anforderung an dem Anrufverbindungs-Aufbau-Gateway hin, Bewirken, dass der Anrufverbindungs-Aufbau-Gateway die Schalteinrichtung abhängig von den vorbestimmten Codes, die in der empfangenen Anrufverbindungs-Aufbau-Anforderung enthalten sind, steuert, um einen ersten und zweiten Trägerkanalabschnitt, die durch das öffentliche Telefonsystem zu der ersten bzw. der zweiten Partei verlaufen, aufzubauen und miteinander in Verbindung zu bringen.
  • Gemäß einem weiteren Aspekt der vorliegenden Erfindung ist ein Verfahren vorgesehen zum Aufbauen eines Trägerkanals durch ein öffentliches Telefonsystem zwischen einer ersten Partei und einer zweiten Partei, denen ein erster vorbestimmter Code bzw. ein zweiter vorbestimmter Code zugeordnet ist, wobei das öffentliche Telefonsystem eine Schalteinrichtung zum Aufbauen von Trägerkanälen durch das öffentliche Telefonsystem und einen Anrufverbindungs-Aufbau-Gateway aufweist, durch den die Schalteinrichtung von dem öffentlichen Internet gesteuert werden kann, wobei das Verfahren folgende Schritte umfasst:
    • a) Zugreifen auf eine Informationsressource, die auf einem Server gehalten wird und der zweiten Partei zugeordnet ist, über das Internet von einem Anschluss, der der ersten Partei zugeordnet ist, wobei die Informationsressource eine Anfrageanforderungsressource zum Erzeugen von Anfrageanforderungen umfasst;
    • b) Weiterleiten des ersten vorbestimmten Codes an die Anfrageanforderungsressource über das Internet von dem Anschluss, der der ersten Partei zugeordnet ist, um zu bewirken, dass die Anfrageanforderungsressource eine Anfrageanforderung erzeugt, die den ersten vorbestimmten Code umfasst;
    • c) Weiterleiten der Anfrageanforderung an einen Anfrageverwalter, der der zweiten Partei zugeordnet ist, wobei der Anfrageverwalter zu einem geeigneten Zeitpunkt eine Anrufverbindungs-Aufbau-Anforderung erzeugt, die über das Internet an den Anrufverbindungs-Aufbau-Gateway übertragen wird, wobei die Anrufverbindungs-Aufbau-Anforderung sowohl den ersten vorbestimmten Code als auch den zweiten vorbestimmten Code umfasst; und
    • d) auf den Empfang der Anrufverbindungs-Aufbau-Anforderung an dem Anrufverbindungs-Aufbau-Gateway hin, Bewirken, dass das Anrufverbindungs-Aufbau-Gateway die Schalteinrichtung abhängig von den vorbestimmten Codes, die in der empfangenen Anrufverbindungs-Aufbau-Anforderung enthalten sind, steuert, um einen ersten und einen zweiten Trägerkanalabschnitt, die durch das öffentliche Telefonsystem zu der ersten bzw. der zweiten Partei verlaufen, aufzubauen und miteinander in Verbindung zu bringen.
  • Die vorliegende Erfindung umfasst auch eine Anordnung zum Implementieren der obigen Verfahren.
  • Kurze Beschreibung der Zeichnungen
  • Ausführungsbeispiele der vorliegenden Erfindung werden nun mittels eines nicht begrenzenden Beispiels Bezug nehmend auf die beigefügten schematischen Zeichnungen beschrieben. Es zeigen:
  • 1 ein vereinfachtes Diagramm eines Standard-PSTN;
  • 2 ein vereinfachtes Diagramm eines bekannten PSTN mit einer IN-Dienstfähigkeit;
  • 3 ein Diagramm, das eine Hostdomainnamenauflösung durch das DNS des Internets zeigt;
  • 4 ein Diagramm, das die Wirkungsweise des World Wide Web zeigt;
  • 5 ein Diagramm, das das Format eines Standard-URL zeigt;
  • 6 ein Diagramm einer ersten Anordnung, bei der Dienstressourcengegenstände auf HTTP-Servern gehalten werden, auf die sowohl das Dienststeueruntersystem eines PSTN als auch Web-Benutzer zugreifen können;
  • 7 ein Diagramm, das die Verarbeitung einer Dienstanforderung durch die SCP von 6 zeigt;
  • 8 ein Diagramm, das das Format eines Ressourcencodes zeigt, der durch die SCP von 6 verwendet wird, wenn auf einen Dienstressourcengegenstand zugegriffen wird;
  • 9 ein Diagramm, das den Prozeß des Zugreifens auf eine Dienstressource in dem Fall zeigt, in dem der Dienstcode keinen RRI-Teil umfaßt;
  • 10 ein Diagramm, das den Prozeß des Zugreifens auf eine Dienstressource in dem Fall zeigt, in dem der Dienstcode einen RRI-Teil umfaßt;
  • 11 ein Diagramm, das die Herleitung des URI einer Dienstressource durch syntaktisches Auswerten einer eingegebenen Telephonnummer gemäß der vorliegenden Erfindung zeigt;
  • 12A ein Diagramm, das einen Namenraum (den „telname-Raum") zeigt, der durch die Domainnamen, die durch ein syntaktisches Auswerten eines vorbestimmten Satzes von Telephonnummern hergeleitet werden, bildet;
  • 12B ein Diagramm, das die Eingliederung des telname-Raums ohne Fragmentierung in das DNS zeigt;
  • 12C ein Diagramm, das die Eingliederung des telname-Raums in einer fragmentierten Form in das DNS zeigt;
  • 13 ein Diagramm, das den Gesamtbetrieb der Anordnung von 6 beim Bereitstellen eines Roaming-Nummerndiensts ansprechend auf eine Telephonnummer, die an einem Standardtelephon gewählt wird, zeigt;
  • 14 ein Diagramm, das den gesamten Betrieb der Anordnung von 6 zeigt, wenn dieselbe durch einen Web-Benutzer beim Aufbauen einer Anrufverbindung durch eine Telephonschnittstelle, die in das Web-Endgerät des Benutzers integriert ist, benutzt wird;
  • 15 ein Diagramm, das den Gesamtbetrieb einer Anordnung zeigt, bei der eine Schnittstelle zwischen dem PSTN und dem Internet für einen Telephonverkehr vorgesehen ist;
  • 16A ein Diagramm, das den Gesamtbetrieb eines ersten Ausführungsbeispiels der Erfindung darstellt, bei dem ein Anrufverbindungs-Aufbau-Gateway zwischen dem Internet und dem PSTN vorgesehen ist;
  • 16B ein Diagramm, das den Gesamtbetrieb eines zweiten Ausführungsbeispiels der Erfindung darstellt, bei dem ein Anrufverbindungs-Aufbau-Gateway zwischen dem Internet und dem PSTN vorgesehen ist;
  • 16C ein Diagramm, das den Gesamtbetrieb eines dritten Ausführungsbeispiels der Erfindung darstellt, bei dem ein Anrufverbindungs-Aufbau-Gateway zwischen dem Internet und dem PSTN vorgesehen ist;
  • 17 ein Diagramm, das den Gesamtbetrieb einer Anordnung zeigt, bei der ein Gebührenfrei-Dienst für Web-Benutzer implementiert ist; und
  • 18 ein Diagramm ähnlich zu 6, das die Bereitstellung einer verteilten Verarbeitungsumgebung für Verbindungselemente des Dienststeuer-Untersystems des PSTN zeigt.
  • Beste Art zum Durchführen der Erfindung
  • 6 zeigt eine Anordnung für das Bereitstellen von Diensten in einem PSTN, das herkömmlicherweise ein Übertragungsnetzwerk 13 (das Leitungen und Vermittlungen umfaßt, von denen zumindest einige SSPs 41 mit zugeordneten IPs sind), ein Zugriffsnetzwerk 11, das Teilnehmergerätschaften (die hier als Telephone 40 gezeigt sind) mit dem Netzwerk 13 verbindet, und ein Dienststeueruntersystem 42 umfaßt, das zumindest eine SCP zum Bereitstellen von Diensten zu den SSPs 41 auf eine Anforderung hin umfaßt. Es ist klar, daß die Darstellung in 6 eines PSTN sehr schematisch ist.
  • Die SPC 43 kann auf eine herkömmliche Art und Weise ansprechend auf Dienstanforderungen von SSPs 41 wirksam sein, um eine spezifische Dienstlogik bezüglich spezieller Daten gemäß Informationen, die in der Dienstanforderung enthalten sind, durchzuführen, und um der anfordernden SSP geeignete Befehle zum Bewirken eines Anrufverbindungsaufbaus zurückzusenden. Eine Dienstanforderung wird durch die SSP ansprechend auf vorbestimmte Auslöserzustände, die an einem Auslöserüberprüfungspunkt erfüllt sind, erzeugt, wobei ein oder mehrere derartige Überprüfungspunkte im Verlauf der Handhabung einer Anrufverbindung existieren (es sei angemerkt, daß, wenn die Auslöserbedingungen von der SCP zu der SSP heruntergeladen wurden, davon gesprochen werden könnte, daß die SSP auf eine Informationsanforderung durch die SCP anspricht, wenn die SCP daraufhin, daß die Auslöserbedingungen erfüllt sind, kontaktiert wird – jedoch wird bei der vorliegenden Beschreibung diese anfängliche Kommunikation von der SSP zu der SCP als eine „Dienstanforderung" bezeichnet).
  • Die SCP 43 ist ferner mit einer Netzwerkzugriffsschnittstelle 44 zu dem Internet 50 versehen, um bestimmte Dienstressourcengegenstände 49 (die hierin nachfolgend einfach auch als „Dienstressourcen" bezeichnet werden) während des Verlaufs der Verarbeitung zumindest bestimmter Dienstanforderungen von den SSPs 41 zu verwenden. Diese Dienstressourcen 49 werden als WWW-Seiten auf HTTP-Servern 51 gehalten (spezieller auf Dienstressourcendatenbanken 52 dieser Server 51). Die WWW-Seiten, die diese Dienstressourcen enthalten, werden nachfolgend als „Telephon"-Seiten bezeichnet. Diese Server 51 sind mit dem Internet verbunden, wobei ein Lese-Zugriff auf die Telephonseiten unter Verwendung jeweiliger URLs oder URNs erfolgen kann (der Bequemlichkeit halber wird der allgemeinere Ausdruck URI hierin nachfolgend verwendet, um auf den Internet-auflösbaren Indikator der Position einer Telephonseite hinzuweisen).
  • Die Dienstressourcen können eine Dienstlogik oder Dienstdaten sein und können durch ein sonst standardmäßiges Dienstlogikprogramm, das auf der SCP abläuft, durch eine Zugreifen auf die Telephonseite der erforderlichen Ressource unter Verwendung des geeigneten URI verwendet werden. In bestimmten Fällen können die Dienstressourcen 49 im wesentlichen die gesamte Dienststeuerung und Daten, die einem speziellen Dienst zugeordnet sind, liefern. In diesem Fall besitzt das Dienstlogikprogramm, das in der SCP 43 läuft, eine Skelettform, wobei eine Instanzbildung desselben beim Empfang einer Dienstanforderung durchgeführt wird und dasselbe dann dazu dient, einen Dienstressourcenzugriff einzuleiten und die Ergebnisse dieses Zugriffs auf die Entität, die die Dienstanforderung durchgeführt hat, zurückzugeben. Tatsächlich könnte gemäß diesem Lösungsansatz die SCP einfach als eine Plattform zum Holen und Ausführen einer Telephonseiten-Dienstlogik implementiert sein und müßte keine komplexen Bereitstellungs- und Verwaltungs-Systeme für eine solche Logik besitzen, wie es durch Standard-SCP-Plattformen gefordert wird; SCPs könnten dann allgegenwärtiger werden, wobei möglicherweise jeder SSP eine zugeordnet ist.
  • 7 ist ein Flußdiagramm, das den Fortschritt von Ereignissen in dem Fall zeigt, in dem die SCP 43 eine Dienstanforderung durch ein Zugreifen auf eine Telephonseiten-Dienstressource handhabt. Auf den Empfang einer Dienstanforderung in einer INAP-Nachricht (Schritt 100) hin, decodiert die SCP 43 die TCAP/INAP-Nachrichtenstruktur auf eine standardmäßige Art und Weise (Schritte 101 und 102), die Fachleuten bekannt ist. Als nächstes bildet die SCP 43 eine Instanz eines Dienstlogikprogramms, SLP, um die Anforderung zu handhaben (Schritt 103). Dieses SLP ist dann für das Nachschlagen des URL der erforderlichen Dienstressource verantwortlich, wie sie aus den Informationen, die in der Dienstanforderung enthalten sind, bestimmt wird (Schritt 104, 105). Wenn sich beispielsweise die Dienstanforderung auf einen Dienst eines angerufenen Teilnehmers bezieht, wird die erforderliche Ressource durch die gewählte Nummer angezeigt, wobei die Letztgenannte verwendet wird, um den URL der Ressource herzuleiten. Sobald der URL der gewünschten Dienstressource festgestellt wurde, wird eine Ressourcenanforderung (beispielsweise in der Form einer HTTP-Anforderungsnachricht) über das Internet zu dem entsprechenden Server gesendet, der die gewünschte Dienstressource hält (Schritt 106); ferner wird eine Korrelations-ID mit der Ressourcenanforderung weitergeleitet, um zu ermögli chen, daß eine Antwort von derselben mit der geeigneten SLP-Instanz verknüpft wird. Ferner wird ein Zeitgeber gestartet (Schritt 107).
  • Wenn eine Antwort von der zugegriffenen Ressource vor dem Verstreichen einer Zeitablaufperiode empfangen wird (was in Schritt 108 geprüft wird), wird eine Antwort, die üblicherweise die Form einer Bestimmungsnummer aufweist, dem geeigneten SLP, das unter Verwendung der Korrelations-ID, die mit der Antwort übermittelt wird, identifiziert ist, zugeführt (Schritt 109). Dann wird eine INAP/TCAP-Antwortnachricht vorbereitet und zu der Entität gesendet, die die ursprüngliche Dienstanforderung durchgeführt hat (Schritte 110 und 111), woraufhin die SLP-Instanz abgeschlossen wird (113).
  • Wenn in dem Schritt 108 ein Zeitablauf stattfindet, bevor eine Antwort empfangen wird, kann ein voreingestellter Antwortwert (allgemein eine voreingestellte Bestimmungsnummer) in dem Kundendatensatz nachgeschlagen, in eine INAP/TCAP-Nachricht eingebracht und zu der anfordernden Entität zurückgesendet werden (Schritte 114–116). Die SLP-Instanz wird dann abgeschlossen (113).
  • Lokalisieren von und Zugreifen auf Dienstressourcen
  • Die Funktionalität, die dem Zugreifen einer Telephonseitenressource zugeordnet ist, ist in 6 schematisch durch einen Ressourcenzugriffsblock 46 dargestellt. Der Block 46 umfaßt einen URI-Bestimmungsblock 47 zum Bestimmen des URI der Telephonseite, die die gewünschte Ressource enthält, auf der Grundlage von Parametern, die zu dem Block 46 geleitet werden. Unter Verwendung des URI, der durch den Block 47 zurückgegeben wird, greift der Ressourcenzugriffsblock 46 dann auf die Telephonseite der erforderlichen Dienstressource 49 über das Internet durch die Schnittstelle 44 zu.
  • Ressourcencodes – Es ist möglich, daß mehr als eine Dienstressource einer speziellen Telephonnummer zugeordnet ist; in diesem Fall muß der Ressourcenzugriffsblock 46 Kenntnis von zusätzlichen Informationen (wie z. B. momentaner Punkt in der Anrufverbindung, pic (pic = point-in-call)) haben, um zu ermöglichen, daß die geeignete Dienstressource identifiziert wird. Wenn sich die Dienstressourcen, die einer Nummer zugeordnet sind, auf unterschiedlichen Telephonseiten befinden, werden die zusätzlichen Informationen ebenfalls zu dem URI-Bestimmungsblock 47 geleitet, um zu ermöglichen, daß derselbe die URI der geeigneten Telephonseite zurückgibt. Es ist auch möglich, daß sich alle Dienstressourcen, die einer Nummer zugeordnet sind, auf der gleichen Telephonseite befinden. In diesem Fall verwendet der Ressourcenzugriffsblock 46 die zusätzlichen Informationen, um einen Ressourcenidentifizierungsparameter mit seiner Zugriffsanforderung zu der betroffenen Telephonseite weiterzuleiten; es ist dann an der Funktionalität, die der Telephonseite zugeordnet ist, auf die korrekte Dienstressource zuzugreifen.
  • Folglich kann jede Dienstressource als durch einen jeweiligen Ressourcencode 54 (siehe 8), der aus einem ersten Teil UI („URI-Identifizierer"), der verwendet ist, um den URI zu identifizieren, an dem sich die Ressource in dem Internet befindet, und einem zweiten Teil RRI („relativer Ressourcenidentifizierer"), der verwendet wird, um die Ressource unter mehreren Ressourcen des gleichen URI zu identifizieren, gebildet ist, identifiziert betrachtet werden.
  • Ressourcenzugriff – Wenn sich nur eine Dienstressource 49 auf einer Telephonseite 58, die durch einen eindeutigen URI identifiziert ist, befindet, umfaßt der Ressourcencode 54 einfach den UI, allgemein entweder eine Telephonnummer allein oder eine Telephonnummer plus einen pic-Parameter (siehe 9). In diesem Fall umfaßt das Zugreifen auf eine Ressource einfach das Abbilden des gesamten Ressourcencodes 54 in den entsprechenden URI (Prozeß 55) und dann das Senden einer Anforderung 57 zu der entsprechenden Telephonseite 58, wobei diese Letztgenannte selbst die gewünschte Dienstressource 49 bildet. Das Ergebnis des Zugreifens auf die Ressource 49 wird dann in einer Antwortnachricht 59 zurückgegeben.
  • Wenn sich im Gegensatz dazu mehrere Dienstressourcen 49 auf der gleichen Telephonseite 58 befinden (10), umfaßt der Ressourcencode 54 sowohl einen UI als auch einen RRI, wobei der UI allgemein eine Telephonnummer ist und der RRI ein pic oder ein anderer Parameter zum Unterscheiden zwischen zusammen angeordneten Ressourcen ist. In diesem Fall schließt das Zugreifen auf ein Betriebsmittel das Abbilden des UI-Teils des Ressourcencodes 54 in den entsprechenden URI (Prozeß 55) und dann das Senden einer Anforderung 57 zu der entsprechenden Telephonseite (Prozeß 56) ein, wobei die Anforderung den RRI des Ressourcencodes enthält. Die Telephonseite 58 umfaßt eine Funktionalität 64 zum Zugreifen auf die erforderliche Ressource auf der Grundlage des RRI in der Anforderungsnachricht. Das Ergebnis des Zugreifens auf die erforderliche Ressource 49 wird dann in der Antwortnachricht 59 zurückgegeben.
  • Eine Alternative zu dem Verfahren von 10 zum Zugreifen auf eine Dienstressource, die sich mit anderen Orten zusammen auf einer Telephonseite befindet, bestünde darin, die gesamte Seite über das Internet zu holen, einfach unter Verwendung des URI, der von dem UI-Teil des Ressourcencodes hergeleitet wird, und nachfolgend die gewünschte Ressource auf der Grundlage des RRI zu extrahieren.
  • URI-Bestimmung aus Ressourcencode – Die Implementierung des URI-Bestimmungsblocks 47, der den Prozeß 55 durchführt, wird als nächstes betrachtet. Der Block 47 kann auf eine Vielzahl von Arten implementiert sein, von denen vier nachfolgend beschrieben werden:
  • Direkte Eingabe
  • Es wäre möglich, obwohl nicht notwendigerweise bequem, für den anrufenden Teilnehmer eine Möglichkeit zu schaffen, direkt den erforderlichen URI einzugeben. Der anrufende Teilnehmer muß folglich die Host-ID-Komponente des erforderlichen URI (entweder in der Form eines Host-Domainnamen oder einer Host-IP-Adresse) plus der Wegkomponente des URI eingeben. Falls beispielsweise auf die Telephonseite eines angerufenen Teilnehmers zugegriffen werden soll, muß der anrufende Teilnehmer den URI des angerufenen Teilnehmers eingeben, wobei diese Eingabe tatsächlich die normale Eingabe einer Telephonnummer ersetzen kann. Eine vordere Eingabezeichenfolge (beispielsweise „999") kann verwendet werden, um die Eingabe als einen URI zu identifizieren. Bezüglich der Eingabeeinrichtung, wenn ein Benutzer nur ein Standard-12-Tasten-Telephon besitzt, muß die Eingabe von Host-Domainnamen und anderen URI-Elementen, die Buchstabenzeichen erfordern, unter Verwendung von einer der Standardtechniken für eine Buchstabeneingabe von einem Telephonbedienfeld erfolgen (wobei solche Techniken bereits verwendet werden, beispielsweise um einem anrufenden Teilnehmer zu ermöglichen, den Namen des angerufenen Teilnehmers zu „buchstabieren"). Es wäre ferner möglich, ein vollständiges alphanumerisches Tastenfeld für Benutzer vorzusehen, um die URI-Eingabe zu erleichtern.
  • Berechnung
  • Ein Dienstressourcenzugriff über das Internet könnte auf einen Satz von gewählten Nummern beschränkt werden, aus denen es möglich wäre, einen entsprechenden URI zu berechnen; in diesem Fall wäre der Block 47 für diese Berechnung verantwortlich.
  • Zuordnungstabellennachschlag
  • Wahrscheinlich die einfachste Implementierung für den Block 47 ist eine Zuordnungstabelle (entweder in einem Speicher oder in dem Datenbankplattenspeicher 48 gehalten), die einen URI dem UI-Teil jedes Ressourcencodes zuordnet. Ein mögliches Problem bei diesem Lösungsansatz besteht darin, daß eine Dienstressource für die Nummer eines angerufenen Teilnehmers auf der anderen Seite der Welt erforderlich sein kann, was ein rigoroses Aktualisierungsregime zwischen PSTN-Operatoren weltweit beinhaltet, um die Zuordnungstabelle auf dem laufenden zu halten. (Es sei angemerkt, daß die gleiche Beinhaltung nicht notwendigerweise hinsichtlich des Markierens der Nummer des angerufenen Teilnehmers als eine, die erforderlich sein, um eine Dienstanforderung auszulösen, gilt, da die Nummer angeordnet sein kann, um eine einer Gruppe von Nummern zu sein, die alle eine geeignete Dienstanforderung auslösen, auf eine Art und Weise ähnlich zu 800-Nummern).
  • DNS-Typ-Nachschlag
  • Eine alternative Nachschlaglösung besteht darin, ein hierarchisch strukturiertes verteiltes Datenbanksystem zu verwenden, ähnlich zu dem (oder sogar als Teil des) Domainnamensystem (DNS) des Internet, um den UI-Teil eines Ressourcencodes zu einem entsprechenden URI aufzulösen. Dieser Lösungsansatz, der detaillierter nachfolgend beschrieben wird, umfaßt typischerweise Datenbanken, die durch jeden PSTN-Operator für seine Nummern, denen URIs zugeordnet sind, gehalten werden. Auf diese Datenbanken könnten alle PSTNs in einem Netzwerk, wie z. B. dem Internet, zugreifen, wobei Auflösungsanforderungen auf eine Art und Weise ähnlich dem Domainnamensystem auf die geeignete Datenbank zeigen. In diesem Fall ist der Block 47 durch ein geeignetes Auflösungsprogramm aufgebaut, das angeordnet ist, um eine UI-Auflösung über das Internet durch die Schnittstelle 44 anzufordern.
  • Bevor eine Nachschlagimplementierung vom DNS-Typ für den URI-Bestimmungsblock 47 beschrieben wird, sind einige weitere allgemeinen Kommentare zweckmäßig. Unabhängig von dem Verfahren das verwendet wird, um den URI zu bestimmen, sind bestimmte Vereinfachungen möglich, wenn begrenzte Beschränkungen auf den erlaubten URIs plaziert werden. Insbesondere ist es in den folgenden Fällen nicht notwendig, alle Komponenten eines URI zu bestimmen:
    • (i) Ein Teil der URI-Wegkomponente kann für alle Dienstressourcen als ein Standard eingestellt werden, wobei dieser Standardteil einfach zu dem Block 47 hinzugefügt wird, sobald der Rest des URI bestimmt wurde. Wenn beispielsweise eine Roaming-Nummer nachgeschlagen werden soll, kann dieselbe durch eine Übereinkunft stets in einer Datei „Roam" in einem Unterverzeichnis „tel" eines Teilnehmerverzeichnisses auf einem speziellen Server gehalten werden. In diesem Fall werden zuerst die URI-Hostkomponente und der Teilnehmereindeutige Teil der Wegkomponente bestimmt, woraufhin der restliche Wegteil „/tel/roam" hinzugefügt wird.
    • (ii) Die URI-Wegkomponente kann angeordnet sein, um gleich einem vorbestimmten Teil des Ressourcencodes zu sein, wobei der Block 47 nur die Hostkomponente bestimmen muß und dann den Weg hinzufügen muß. Beispielsweise kann eine Vereinbarung dar über getroffen werden, daß der Weg stets mit der betroffenen Telephonnummer enden muß oder mit ausreichenden der letzten Stellen, um eine hohe Wahrscheinlichkeit einer Eindeutigkeit auf der Hostmaschine zu besitzen. Der Weg kann auch Standardkomponenten, die durch den Block 47 hinzuzufügen sind, umfassen.
    • (iii) Blöcke von Telephonnummern können ihre entsprechenden Dienstressourcen, die auf dem gleichen Hostserver angeordnet sind, aufweisen, so daß es lediglich notwendig ist, einen Teil der Telephonnummer zu verwenden, um die Hostkomponente des URI zu bestimmen; in diesem Fall kann die Wegkomponente bequemerweise jede Telephonnummer gesamt oder teilweise beinhalten. Diese Situation beinhaltet einen hohen Grad einer Steuerung durch die Telephonoperatoren und bietet dem Telephonbenutzer nicht die Freiheit, den Hostserver, auf den der Benutzer seine Telephonseite plaziert, zu wählen.
  • Ein weitere allgemeiner erwähnenswerter Punkt ist, daß, obgleich der URI bestimmt ist, die Hostkomponente des URI entweder in der Form eines Hostdomainnamen oder einer Host-IP-Adresse bereitgestellt werden kann. Wenn der Host durch einen Domainnamen identifiziert wird, wird nachfolgend eine weitere Auflösung des URI-Hostnamens in die IP-Adresse auf eine Standardweise durch die Schnittstelle 44 unter Verwendung des Domainnamensystems des Internet durchgeführt. Diese weitere Auflösung kann vermieden werden, wenn die Hostidentität direkt als eine IP-Adresse bereitgestellt wird.
  • Wenn ein Datenbanknachschlag verwendet wird, um die Nummer zu der URI-Übersetzung zu liefern, kann diese Datenbank unabhängig von einer Kundendatenbank, die andere kundenbezogene Informationen enthält, sein oder mit derselben kombiniert sein. Faktoren, die diese Wahl beeinflussen, umfassen einerseits den möglichen Wunsch, daß die Nummer-In-URI-Übersetzungsinformationen verbreitet verfügbar sind, und andererseits den möglichen Wunsch des Beschränkens eines Zugriffs auf andere kundenbezogenen Informationen.
  • URI-Nachschlag vom DNS-Typ
  • Eine DNS-Typ-Nachschlagimplementierung für den URI-Bestimmungsblock 47 wird nun bis zu einer bestimmten Detailliertheit für den Fall beschrieben, bei dem der UI-Teil des Ressourcencodes eine Telephonnummer ist und keine Beschränkungen hinsichtlich des URI existieren, weshalb es erforderlich ist, daß sowohl die vollständige Host-Komponente als auch die Wegkomponente des URI durch den Nachschlag zurückgegeben wird. Ein Schlüsselteil des Gesamtprozesses ist die Bildung des Äquivalents eines Hostdomainnamen aus der interessierenden Telephonnummer; dieses Domainnamenäquivalent wird dann durch einen Nachschlagmechanismus, der bei dem vorliegenden Beispiel identisch zu dem ist, der durch das DNS verwendet wird (tatsächlich kann der Nachschlagmechanismus in das DNS eingegliedert sein, obwohl er auch unabhängig implementiert sein kann), in einen entsprechenden URI aufgelöst.
  • Die Beschaffenheit des DNS wurde bereits oben Bezug nehmend auf 3 beschrieben, wobei auch der Ausdruck „DNS-Typ"-System eingeführt wurde. Der Bequemlichkeit halber wird im folgenden ein DNS-Typ-System, das organisiert ist, um eine Telephonnummer-Zu-URI-Übersetzungsfähigkeit zu liefern, als ein „Duris"-System (was für „DNS-Typ-URI-Server"-System steht) bezeichnet.
  • Die elementaren Grundsätze, die den Betrieb eines Duris-Systems umgeben, sind:
    • – jede Telephonnummer kann in einen Hostdomainnamen umgewandelt werden (der Namenraum, der derartige Hostdomainnamen für die interessierenden Telephonnummern enthält, wird nachfolgend als der „telname-Raum" bezeichnet); und
    • – für jeden Hostdomainnamen in dem Hostdomainraum existiert eine Registrierungsdatensatz, der durch das Duris-System, das den entsprechenden URI enthält, gehalten wird.
  • Folglich wird eine eingegebene Telephonnummer, die in dem vorliegenden Fall den UI-Teil eines Ressourcencodes 54 bildet (siehe 11), zuerst syntaktisch ausgewertet, um einen Domainnamen zu bilden (Schritt 120), und wird dann zu dem Duris-System geleitet (das in 11 als durch das DNS selbst gebildet gezeigt ist), um den RR mit dem entsprechenden URI wiederzugewinnen (Schritt 121). Wenn der zurückgegebene URI seine Hostkomponente als einen Domainnamen besitzt, wird nachfolgend ausgehend von dem URI-Nachschlag als nächstes das DNS verwendet, um die Host-IP-Adresse herzuleiten (Schritt 122); dieser Schritt wird selbstverständlich nicht benötigt, wenn die Hostkomponente als eine IP-Adresse in dem RR gespeichert ist. Der URI wird dann verwendet, um eine Ressourcenanforderung an den geeigneten Server durchzuführen, wobei jeder RRI-Teil des Ressourcencodes 54 weitergeleitet wird (Schritt 123).
  • Es existiert eine Anzahl von Möglichkeiten als der obere Level, wie ein Duris-System implementiert werden könnte:
    • (a) Unabhängig von dem DNS. Bei dieser Option bildet der telname-Raum den gesamten Namenraum, der zu verwalten ist, wobei die Wurzel des telname-Raums die „."-Namenraumwurzel ist (siehe 12A, wo der telname-Raum schraffiert dargestellt ist). In diesem Fall ist das Duris-System unabhängig von dem DNS selbst. Das Duris-System könnte selbstverständlich die gleiche e lementare Infrastruktur wie das DNS verwenden (d. h. das Internet) oder ein völlig getrenntes Netzwerk. Wenn der telname-Raum alle Domainnamen, die allen öffentlichen Telephonnummern weltweit entsprechen, enthält, wird das syntaktische Auswerten einer vollständigen internationalen Telephonnummer einen vollständig qualifizierten Domainnamen ergeben. Selbstverständlich könnte der telname-Raum ein viel kleinerer Satz von Namen sein, wie z. B. diejenigen, die von internen Erweiterungsnummern in einer Firma, die weltweite Operationen umfaßt, hergeleitet werden.
    • (b) Ein unfragmentierter telname-Raum in dem DNS. Bei dieser Option ist der telname-Raum ein Bereich des DNS-Namenraum und das Duris-System wird durch das DNS selbst geliefert. Wenn folglich der telname-Raum alle Domainnamen umfaßt, die von öffentlichen Telephonnummern weltweit hergeleitet werden, könnte der telname-Raum in der Domain der ITU, in einer speziellen Unterdomain „tel" plaziert werden, wobei dann die Wurzel des telname-Raums „tel.itu.int." ist (siehe 12B, wobei wiederum der schraffierte Bereich den telname-Raum darstellt). Die Verantwortlichkeit zum Verwalten der Domain „tel.itu.int." würde dann bei der ITU liegen. Bei diesem letztgenannten Beispiel wird, um einen vollständig qualifizierten Domainnamen aus einer eingegebenen Telephonnummer zu bilden, der Endzusatz „tel.itu.int." hinzugefügt. Der vollständig qualifizierte Domainnamen wird dann dem DNS zugeführt, wobei der entsprechende RR-Datensatz, der den erforderlichen URI hält, wiedergewonnen wird. Als ein weiteres Beispiel könnte der telname-Raum alle Namen beinhalten, die von internen Erweiterungsnummern innerhalb Hewlett-Packard hergeleitet werden, wobei in diesem Fall die Wurzel des telname-Raums „tel.hp.com." lauten würde und Hewlett-Packard für das Verwalten dieser Domain vollständig verantwortlich wäre.
    • (c) Fragmentierter telname-Raum in dem DNS. Bei dieser Option ist der telname-Raum zwischen mehreren Domains des DNS-Namenraums aufgeteilt, und das Duris-System wird durch das DNS selbst geliefert. Wenn folglich der telname-Raum alle Domainnamen, die von öffentlichen Telephonnummern weltweit hergeleitet werden, aufweist, könnte der telname-Raum zwischen jeweiligen „tel"-Unterdomains jeder Landesdomain aufgeteilt sein; folglich hätte, wie in 12C gezeigt ist, der Teil des telname-Raums, der französischen Telephonnummern entspricht, eine Wurzel „tel.fr.", während der Teil des telname-Raums, der UK-Telephonnummern entspricht, eine Wurzel „tel.uk." hätte. Die Verantwortlichkeit zum Verwalten jeder „tel"-Teildomain würde dann in jedem Land liegen. Um bei diesem letztgenannten Beispiel einen vollständig qualifizierten Domainnamen aus einer eingegebenen Telephonnummer zu bilden, wird der Teil der Telephonnummer, der dem Landescode folgt, syntaktisch ausgewertet, um den Teil des Domainnamens in einer Länder-'tel'-Unterdomain zu bilden, wobei dann ein Hostdomainname-Endzusatz geeignet für das betroffene Land hinzugefügt wird. Folglich wird für eine französische Telephonnummer der Ländercode „33" vor dem syntaktischen Auswerten von der Nummer entfernt und verwendet, um einen Endzusatz „tel.fr." hinzuzufügen. Der Endzusatz, der für jedes Land geeignet ist, kann in einer lokalen Nachschlagtabelle gespeichert sein. Als weiteres Beispiel können zwei kommerzielle Organisationen (Firma X und Firma Y) mit jeweiligen DNS-Domains von „xco.com." und „yco.com." übereinkommen, um ein gemeinsames Duris-System mit einem telname-Raum, der zwischen „tel.xco.com." und „tel.yco.com." unterteilt ist, zu betreiben. In diesem Fall wird jegliche Telephonnummer der Firma Y, die von der Firma X eingegeben wird, in einen vollständig qualifizierten Domainnamen, der mit „tel.yco.com" endet, syntaktisch ausgewertet und umgekehrt.
  • Als nächstes wird das syntaktische Auswerten einer Telephonnummer in einen Domainnamen betrachtet – in anderen Worten, wo die „."-Zeichen in die Nummer einzufügen sind, um die Strukturierung eines Domainnamens zu liefern. Selbstverständlich sind, wie bereits erklärt wurde, Telephonnummern entsprechend dem Numerierungsplan jedes Lands hierarchisch strukturiert. Folglich bestünde ein Lösungsansatz darin, dieser Numerierungsplanstrukturierung beim Unterteilen einer Telephonnummer, um einen Domainnamen zu bilden, zu folgen. Beispielsweise könnte die Telephonnummer „441447456987", die eine UK-Nummer (Ländercode „44") ist, mit einem vierstelligen Bereichscode („1447") und einer sechsstelligen lokalen Nummer („456987") unterteilt werden, um einen Domainnamen von 456987.1447.44 zu bilden (man bemerke die Umkehr der Kennungsreihenfolge, die aufgrund der Tatsache angetroffen wird, daß die niederstwertigen DNS-Kennungen zuerst angeordnet werden). Wenn der telname-Raum eine Unterdomain des DNS mit einer Plazierung, wie sie in 12B gezeigt ist, ist, würde der vollständig qualifizierte Domainnamen, der von der Telephonnummer hergeleitet wird, lauten:
    456987.1447.44.tel.itu.int.
  • Es existieren jedoch von Natur aus bei dem Versuch, an die Numerierungsplanhierarchie anzupassen, wenn eine Telephonnummer in einen Hostnamen syntaktisch ausgewertet wird, Schwierigkeiten. Um eine internationale Nummer korrekt syntaktisch auszuwerten wäre es für jede Entität, die mit dieser Operation betraut wird, zuerst notwendig, die Strukturierung des Numerierungsplans jedes Landes zu kennen, wobei es, wenn, wie in UK, Bereichscodes eine unterschiedliche Länge aufweisen können, notwendig sein kann, daß das erforderliche Wissen die Form einer Nachschlagtabelle besitzt. Obwohl dies keine komplizierte Rechenaufgabe ist, ist es eine Hauptverwaltungsunannehmlichkeit, da es bedeutet, daß jedes Land alle anderen über seinen Numerierungsplan und jegliche Aktualisierungen informieren muß.
  • Das zweite Problem besteht darin, daß eine sechs- oder sieben-stellige lokale Nummer eine sehr große Domain ist; es wäre aus Verhaltens- und Skalierungs-Gründen bevorzugt, Unterdomains zu erzeugen, wobei jedoch keine offensichtliche Art existiert, dies durchzuführen.
  • Diese Probleme können überwunden werden, indem die Beschränkung dahingehend, daß das syntaktische Auswerten der Telephonnummer in einen Domainnamen mit der Strukturierung nationaler Numerierungspläne übereinstimmen sollte, aufgegeben wird. Tatsächlich existiert kein starker Grund, um einem solchen Schema zu folgen, da DNS-Server nichts über die Bedeutung des Namenraums wissen. Es ist daher möglich, Telephonnummern unter Verwendung eines deterministischen Algorithmusses syntaktisch auszuwerten, wobei z. B. vier Stellen gleichzeitig verwendet werden, um die Größe jeder Unterdomain zu begrenzen und es möglich zu machen, 'die Punkte einzufügen', ohne den betroffenen Numerierungsplan zu kennen. Solange die DNS-Domains und -Zonen, die durch die DNS-Server bedient werden, korrekt erzeugt werden, wird alles funktionieren.
  • Für internationale Nummern scheint es noch geeignet zu sein, die Ländercodes abzutrennen, so daß ein hybrides Schema zur syntaktischen Auswertung darin bestünde, den anfänglichen Teil einer gewählten Nummer entsprechend bekannter Ländercodes syntaktisch auszuwerten und danach ein deterministisches Schema (beispielsweise 3,7 oder 4,6 oder 3,3,4) zu verwenden, um die Stellen zu trennen. Wenn ein fragmentierter telname-Raum verwendet wird, wie in 12C gezeigt ist, wird selbstverständlich der Ländercode verwendet, um den Hostnamen-Endzusatz nachzuschlagen, wobei es lediglich der nationale Teil der Nummer sein wird, der syntaktisch ausgewertet werden würde.
  • Schließlich kann bezüglich der Einzelheiten, wie ein DNS-Server aufgebaut sein kann, um RR-Datensätze mit URIs zu halten, beispielsweise auf „DNS and BIND", Paul Albitz und Criket Liu, O'Reilly & Associates, 1992, verwiesen werden, wo beschrieben ist, wie ein DNS-Server unter Verwendung der Unix-BIND-Implementierung aufgebaut wird. Die RR-Datensätze können beispielsweise ein Text-Typ sein.
  • Es sollte angemerkt werden, daß DNS-Kennungen in der Theorie nicht mit einer Ziffer beginnen sollten. Wenn diese Übereinkunft im Gedächtnis gehalten wird, ist es selbstverständlich eine triviale Übung, wenn eine Telephonnummer syntaktisch ausgewertet wird, ein Standardzeichen als das erste Zeichen jeder Kennung einzufügen. Folglich würde eine vierstellige Kennung von 2826 zu „t2826" werden, wobei „t" als das Standardanfangszeichen verwendet wird.
  • Es ist klar, daß wie bei Domainnamen, wenn eine eingegebene Telephonnummer nicht die vollständige Nummer ist (beispielsweise erfordert ein lokaler Anruf kein internationales oder Bereichs-Code-Präfix), dieselbe in einem Domainnamen in dem lokalen Domain syntaktisch ausgewertet wird.
  • Die vorhergehende Erörterung der Duris-System-Implementierung erfolgte hinsichtlich des Übersetzens einer Telephonnummer in einen URI, wobei die Telephonnummer den vollständigen UI eines Ressourcencodes bildet und das Duris-System einen vollständigen URI zurückgibt. Es ist klar, daß die beschriebene Duris-Implementierung ohne weiteres angepaßt werden kann, um die verschiedenen Modifikationen, die oben bezüglich der Form des UI erläutert wurden, und bezüglich dessen, welche Teile des URI nachgeschlagen werden müssen, angepaßt werden kann. Wenn beispielsweise eine Nummer von verschiedenen Dienstressourcen, die einem Teilnehmer jede in ihrer eigenen Datei zugeordnet sind, existiert und die erforderliche Ressource durch einen pic-Teil des Ressourcencodes identifiziert ist, wird die eingegebene Telephonnummer verwendet, um nicht den vollständigen URI nachzuschlagen, sondern die Hostkomponente und den Teil der Wegkomponente bis zu dem relevanten Unter verzeichnis, wobei der pic-Teil des UI angehängt wird, um die erforderliche Ressourcendatei zu identifizieren.
  • Für kleine lokale Duris-Implementierungen kann es möglich sein, einen einzelnen Server zu besitzen; eine Implementierung sollte jedoch noch als von einem DNS-Typ betrachtet werden, vorausgesetzt, die anderen relevanten Merkmale liegen vor.
  • Beschaffenheit der Dienstressourcen
  • Sich nun einer Betrachtung der Dienstressourcen 49 zuwendend wird vollständiger nachfolgend beschrieben, wie diese Dienstressourcen auf den Servern 51 bereitgestellt werden können, wobei jedoch hinsichtlich des vorliegenden Beispiels die Dienstressource oder die -ressourcen, die einem bestimmten PSTN-Benutzer (einem einzelnen oder einer Organisation, unabhängig davon, ob ein anrufender oder ein angerufener Teilnehmer) zugeordnet ist bzw. sind, über das Internet von einem Benutzerendgerät 53 auf einer oder mehreren WWW-Seiten auf einem Server 51 plaziert werden kann bzw. können.
  • Es sei der einfache Fall betrachtet, bei dem die Dienstressource ein Dienstdatengegenstand ist, wie z. B. eine Telephonnummer (beispielsweise eine alternative Nummer, die versucht werden soll, wenn das Telephon des Benutzers, das der durch einen anrufenden Teilnehmer gewählten Nummer zugeordnet ist, belegt ist). Diese Umleitungsnummer könnte als die einzige Dienstressource einer Telephonseite des Benutzers hergestellt sein. Der Telephonseiten-URI könnte ein URL mit einem Schema sein, das auf HTTP eingestellt ist, wobei in diesem Fall das GET-Verfahren verwendet werden könnte, um die Umleitungsnummer wiederzugewinnen. Eine solche Anordnung ist geeignet, wenn die Telephonseite nur für eine funktionelle Wiedergewinnung der Umleitungsnummer verwendet werden soll. Wenn die Umleitungsnummer jedoch an einem Benutzerendgerät 53 visuell dargestellt werden soll, kann es erwünscht sein, die Nummer mit erklärendem Material begleitend zu versehen (dies wird häufig nicht notwendig sein, da die Umleitungsnummer angeordnet sein kann, um in eine existierende angezeigte Seite, die bereits Zusammenhangsinformationen liefert, zurückgegeben zu werden). Wenn jedoch die Telephonseite neben der Umleitungsnummer Erklärungsmaterial beinhaltet, könnte eine Entität, die lediglich eine funktionelle Verwendung der Telephonseite machen möchte, angeordnet sein, um die Telephonseite wiederzugewinnen und dann die Umleitungsnummer zu extrahieren (dies würde selbstverständlich eine Standardmöglichkeit zum Identifizieren der Informationen, die von der Telephonseite extrahiert werden sollen, erfordern).
  • Eine alternative und bevorzugte Anordnung zum Liefern sowohl eines Sicht- als auch eines funktionellen Zugriffs auf eine Ressource, die Erklärungsmaterial zur Betrachtung erfordert, besteht darin, einen Objekt-orientierten Lösungsansatz für einen Ressourcenentwurf zu verwenden. In diesem Fall hätte das Ressourcen-Objekt zwei unterschiedliche Zugriffsverfahren, die demselben zugeordnet sind, eines für eine rein funktionelle Verwendung der Ressource und das andere, das eine Betrachtung des zugeordneten Erklärungsmaterials ermöglicht. Es wäre dann Aufgabe der zugreifenden Entität, unter Verwendung des geeigneten Objektverfahrens auf das Ressourcenobjekt zuzugreifen.
  • Noch eine weitere Anordnung zum Liefern sowohl einer Betrachtungs- als auch einer funktionellen Verwendung der Umleitungsnummer bestünde darin, getrennte Ressourcen bereitzustellen, die für jede Verwendung geeignet konfiguriert sind, wobei jede Ressource ihren eigenen Ressourcencode aufweist (allgemein würden beide derartigen Ressourcen auf der gleichen Telephonseite plaziert werden, wobei in diesem Fall der UI-Teil jedes Ressourcencodes identisch wäre).
  • Die Wiedergewinnung einer Telephonseite zur Verwendung durch einen menschlichen Benutzer wird im allgemeinen nicht so zeitkritisch sein wie die Wiedergewinnung für eine betriebliche Verwendung durch ein PSTN. Während für eine menschliche Verwendung das Schema, das in dem URL einer Dienstressource spezifiziert ist, HTTP sein könnte, kann es für eine betriebliche Verwendung vorteilhaft sind, ein spezielles „Telephon"-Schema (Zugriffsprotokoll) zu definieren, was zur Folge hätte, daß der Server 51 eine optimierte Zugriffsroutine verwendet, um auf die geforderte Ressource (Umleitungsnummer bei dem gegenwärtigen Beispiel) zuzugreifen und der zugreifenden Entität in der minimal möglichen Zeit zu antworten.
  • Neben Datengegenständen umfassen weitere mögliche Typen von Dienstressourcen eine Dienstlogik zur Ausführung an Ort und Stelle (im Server), wobei das Ergebnis dieser Ausführung der Entität, die auf die Ressource zugreift, zurückgegeben wird; eine Dienstlogik, die von dem Server zu der zugreifenden Entität für eine Ausführung in dieser Entität herunterladbar ist; und eine Protokollierungsressource zum Protokollieren von Informationen, die durch die zugreifende Identität zu derselben geleitet werden (oder einfach zum Protokollieren der Tatsache, daß auf sie zugegriffen wurde). Es ist klar, daß die Protokollierungsressource tatsächlich exakt ein Spezialfall einer Dienstlogik, die an Ort und Stelle ausführbar ist, ist.
  • Beispielsweise kann eine Dienstressource, die durch eine Ausführung-An-Ort-Und-Stelle-Dienstlogik gebildet ist, angeordnet sein, um eine Uhrzeit-Weiterleitung zu implementieren, wobei das Ergebnis der Ausführung der Dienstlogik darin bestünde, daß die Telephonnummer, zu der ein Anruf weitergeleitet werden soll, unter Berücksichtigung der Uhrzeit am Ort des angerufenen Teilnehmers weitergeleitet wird. Ein Beispiel einer Dienstressource, die durch eine herunterladbare Dienstlogik gebildet ist, ist eine Dienstlogik zum Steuern einer Optionsabfrage des anrufenden Teilnehmers unter Verwendung der Möglichkeiten, die durch ein IP geliefert werden. Die Protokollierungsressource kann verwendet werden, um die Anzahl von Anrufen, die hinsichtlich einer speziellen Nummer plaziert werden, aufzuzeichnen.
  • Wenn jede Ressource ihre eigene Telephonseite besitzt und die Ressource nur in ihrer ungeschmückten funktionellen Form vorliegt, kann das HTTP-Schema für einen Zugriff unter Verwendung des GET-Verfahrens sowohl für die herunterladbare Dienstlogik als auch die Ausführung-An-Ort-Und-Stelle-Dienstlogik und das POST-Verfahren für die Protokollierungsressource verwendet werden. Wenn es erwünscht ist, Erklärungsmaterial mit jeder Dienstressource bereitzustellen, kann jegliche der oben erläuterten Lösungen bezüglich Datengegenständen verwendet werden.
  • Wenn mehr als eine Dienstressource einer Nummer zugeordnet ist, kann jede solche Ressource auf einer jeweiligen Telephonseite mit ihrem eigenen URI plaziert werden. Jedoch besteht der bevorzugte Lösungsansatz darin, alle derartigen Dienstressourcen auf der gleichen Seite zu plazieren und den RRI-Teil der entsprechenden Ressourcencodes zu verwenden, um einen Zugriff auf die geeignete Ressource zu ermöglichen. Die zugegriffene Ressource wird dann entsprechend ihrer Form behandelt (ausgeführt, wenn eine Ausführen-An-Ort-Und-Stelle-Dienstlogik, zurückgegeben, wenn herunterladbare Dienst-Daten oder -Logik).
  • Wenn folglich sowohl eine Umleitungsnummer-Dienstdatenressource als auch eine Uhrzeit-Ausführung-An-Ort-Und-Stelle-Dienstlogikressource auf der gleichen Telephonseite plaziert sind, könnte der Umleitungsnummer-Ressourcencode einen RRI von „1" aufweisen, während der Uhrzeit-Ressourcencode einen RRI-Wert von „2" aufweisen könnte.
  • Wenn Optionen des anrufenden/angerufenen Teilnehmers in einer Dienstressource zur Präsentation eines solchen Teilnehmers enthalten sein sollen, kann dies, wie bereits angezeigt wurde, bequemerweise geschehen, indem die Dienstressource als eine herunterladbare Dienstlogik aufgebaut ist, wobei die ausgewählte Option möglicherweise eine Anforderung für eine nachfolgende Dienstressource initialisiert.
  • Es ist klar, daß eine Dienstressource häufig von einem komplexen Typ ist, bei dem Dienstdaten und/oder eine herunterladbare Dienstlogik und/oder eine Ausführung-An-Ort-Und-Stelle-Dienstlogik kombiniert sind. Eine speziell leistungsstarke Kombination ist die Kombination von zwei Typen einer Dienstlogik, bei der die herunterladbare Dienstlogik entworfen ist, um mit der Ausführung-An-Ort-Und-Stelle-Dienstlogik zu interagieren; unter Verwendung dieser Anordnung können dem Benutzer komplexe Client-Server-Typ-Anwendungen geboten werden.
  • Beispielverwendung einer Dienstressource
  • 13 zeigt die Operation eines Diensts, der eine Ressource auf einem Server 51 verwendet. Dieser Dienst ist äquivalent einem „Persönliche-Nummer"-Dienst, durch den durch eine einzelne, unveränderliche Nummer auf einen Benutzer zugegriffen werden kann, selbst wenn er sich zwischen Telephonen mit unterschiedlichen realen Nummern bewegt. Um dies zu erreichen, wird dem Benutzer, der diesen Dienst anfordert (Benutzer B bei dem gegenwärtigen Beispiel) eine eindeutige persönliche Nummer (die hierin als die „Webtel"-Nummer von B bezeichnet wird, aus einem Satz von Nummern zugeteilt, bei denen alle die gleiche vordere Nummernfolge besitzen, um zu ermöglichen, daß eine SSP ohne weiteres eine angerufene Nummer als eine Webtel-Nummer identifiziert. Der Benutzer B besitzt eine Dienstressource 49 auf einer zweckgebundenen Telephonseite auf dem HTTP-Server 51, wobei sich diese Telephonseite an einem URL befindet, der hier als „URL(B-Telephonseite)" identifiziert ist. B's Telephonseite gibt, wenn auf sie zugegriffen wird, die momentane Roaming-Nummer („B-telNb") zurück, unter der B erreicht werden kann. Im einfachsten Fall ist B's Telephonseite nur eine einzige Nummer, die durch B modifiziert werden kann (beispielsweise von einem Endgerät 53), wenn sich B zu einem anderen Telephon bewegt. Es ist wahrscheinlicher, daß B's Telephonseite eine Ausführung-An-Ort-Und-Stelle-Dienstlogik ist, die eine Uhrzeit-Weiterleitung liefert.
  • Bei dem vorliegenden Beispiel ist die Zuordnung zwischen B's Webtel-Nummer und dem URL von B's Telephonseite in einer Zuordnungstabelle gespeichert, auf die die SCP 43 zugreifen kann.
  • Auf den Versuch eines Benutzers A hin, den Benutzer B zu kontaktieren, indem er die Webtel-Nummer von B wählt, leitet das Telephon 40, das durch A verwendet wird, eine Anrufverbindung-Aufbauanforderung zu der SSP 41 (es sei angemerkt, daß in 13 die Trägerwege durch das Telephonnetzwerk durch die dickeren Linien 60 gezeigt sind, während die anderen starren Linien Signalisierungsflüsse anzeigen). Die SSP 41 erfaßt die gewählte Nummer als eine Webtel-Nummer und sendet eine Dienstanforderung zu der SCP 43 zusammen mit B's Webtel-Nummer. Die SCP 43 leitet auf das Empfangen dieser Dienstanforderung hin ein Dienstlogikprogramm zum Steuern der Übersetzung von B's Webtel-Nummer in eine momentane Roaming-Nummer für B ein; tatsächlich fordert in dem vorliegenden Fall dieses Programm einfach den Ressourcenzugriffsblock 46 auf, auf die Dienstressource, die durch B's Webtel-Nummer identifiziert ist, (d. h. B's Telephonseite 49) zuzugreifen und das Ergebnis dieses Zugriffs zurückzugeben. Zu diesem Zweck übersetzt der Block 46 zuerst B's Webtel-Nummer in den URL von B's Telephonseite und verwendet dann diesen URL, um über das Internet auf B's Telephonseite zuzugreifen (beispielsweise unter Verwendung 'Telephon'-Schemas, auf das bereits mit einem Verfahren, das dem HTTP-GET-Verfahren entspricht, verwiesen wurde). Diese Ergebnisse hinsichtlich B's momentaner Roaming-Nummer B-telNb werden zu dem Block 46 zurückgeleitet, wobei rechtzeitig diese Nummer zu der SSP 41 zurückgegeben wird, die dann den Abschluß des Anrufsverbindungsaufbaus zu dem Telephon 40, das B-telNb entspricht, einleitet.
  • Das Beispiel von 13 bezieht sich auf einen Dienst des angerufenen Teilnehmers; es ist selbstverständlich klar, daß der Grundsatz des Zugreifens auf Dienstressourcen über das Internet auf alle Diensttypen angewendet werden kann, einschließlich sowohl Diensten des anrufenden Teilnehmers als auch des angerufenen Teilnehmers sowie Hybriden. Somit können Standard-800-Nummer-Dienste mit der gewählten 800-Nummer implementiert werden, was einen Zugriff auf eine Telephonseiten-Ressource, die durch eine Ausführung-An-Ort-Und-Stelle-Dienstlogik gebildet ist, die die geeignetste Nummer zum Steuern einer Vorwärtsrufumleitung zurückgibt, zur Folge hat.
  • Obwohl bei dem Beispiel von 13 die Dienstanforderung von der SSP durch eine führende Nummernfolge einer gewählten Nummer ausgelöst wurde, ist es klar, daß eine Dienstanforderung durch eine Vielzahl von Auslösern ausgelöst werden kann, einschließlich der Nummer eines anrufenden Teilnehmers, der Nummer eines angerufenen Teilnehmers oder irgend einer anderen Benutzereingabe, wobei derartige Auslöser möglicherweise durch den Anrufverbindungs-Aufbaufortschritt qualifiziert werden (beispielsweise die Nummer eines angerufenen Teilnehmers, die durch einen Besetzt-Status oder durch ein Klingeln für eine längere als eine vorbestimmte Zeit qualifiziert ist).
  • Eine mögliche Anwendung bezüglich der oben genannten Protokollierungsdienstressource ist bei einer Telephonabstimmung. In diesem Fall bewirkt das Wählen der Abstimmungsnummer, daß die SSP den Anruf aufnimmt, um eine Dienstanforderung zu der SCP 43 zu leiten, die dann die geeignete Protokollierungsressource über das Internet kontaktiert, um eine Abstimmung zu registrieren, nachdem der Anruf abgeschlossen ist. Um Flaschenhälse zu minimieren, könnte eine Protokollierungsressource mit einem unterschiedlichen URL für jede SCP vorgesehen sein, wobei es eine einfachere Sache ist, eine Abstimmung von allen diesen Protokollierungsressourcen über das Internet zu sammeln und zusammenzustellen. Wenn eine SCP mit Internet-Zugriff an jeder SSP vorgesehen ist, ist das Risiko einer Überfüllung stark reduziert.
  • Wie bereits angemerkt wurde, kann die Telephonseite eines Benutzers mehrere Dienstressourcen halten, wobei in diesem Fall die Zugriffsanforderung von der zugreifenden SCP einen geeigneten RRI, der die erforderliche Ressource identifiziert, enthalten muß.
  • Falls eine SCP sowohl einen herkömmlichen IN-Dienst zu bestimmten Benutzern als auch einen äquivalenten Dienst unter Verwendung einer über Internet zugegriffenen Dienstressource zu anderen Benutzern liefern muß, kann es notwendig sein, eine Nachschlagtabelle in der SCP vorzusehen, um sicherzustellen, daß eine Dienstanforderung geeignet gehandhabt wird; eine solche Nachschlagtabelle kann bequemerweise mit der Kunden-Datensatzdatenbank kombiniert werden.
  • Sobald ein Benutzer, wie z. B. der Benutzer B, eine oder mehrere Telephonseiten, die seine gewünschten Dienstressourcen (eine spezielle Dienstlogik, die personalisierte Dienste definiert) spezifizieren, aufgebaut hat, ist es für den Benutzer B klarerweise logisch, daß er möchte, daß jeder PSTN-Operator, den er verwenden möchte, auf solche Dienstressourcen zugreift und diese benutzt. Dies ist möglich, wenn die Webtel-Zu-URI-Datenbanken für alle Operatoren verfügbar sind. Diese mehrere Operatoren könnten eingestellt sein, um auf B's Telephon-Seite oder -Seiten zuzugreifen. Wenn es ein Operator ablehnt, B's Telephonseiten zu verwenden, kann B offensichtlich wählen, diesen Operator nicht zu verwenden (zumindest wenn dieser Operator einen langen schleppenden Trägerdienst, der einer Benutzer auswahl unterworfen ist, liefert). Daher entsteht die Möglichkeit, daß eine Dienstbereitstellung aufhört, eine Zugabe von Operatoren zu befehlen, sondern vielmehr wird das Bereitstellen einer Telephonseitenbenutzung durch einen Operator ein notwendiges elementares Merkmal des PSTN-Betriebs.
  • Bereitstellen und Aktualisieren von Dienstressourcen
  • Als nächstes wird betrachtet, wie die Dienstressourcen 49 den Servern 51 bereitgestellt und nachfolgend aktualisiert werden.
  • Soweit das Bereitstellen betroffen ist, sind zwei elementare Aktionen erforderlich: erstens muß die Dienstressource auf einem Server 51 plaziert werden und zweitens muß der URI der Dienstressource dem PSTN-Operator zusammen mit den Auslöserbedingungen (Nummer plus jegliche andere Bedingung, beispielsweise Punkt-Im-Anruf), die nach einem Zugriff auf die Ressource streben, mitgeteilt werden; wenn mehrere Ressourcen an dem gleichen URI vorgesehen sind, müssen ferner die RRI-Werte, die benötigt werden, um die geeignete Ressource für eine spezielle Auslöserbedingung wiederzugewinnen, ebenfalls mitgeteilt werden. Dieser Mitteilungsprozeß wird hierin nachfolgend als 'Registrieren' der Dienstressource bei dem PSTN-Operator bezeichnet; eine Registrierung ist selbstverständlich notwendig, um zu ermöglichen, daß die Zuordnungstabellen, die durch die SCP 43 verwendet werden, aufgebaut werden und daß die Auslöserbedingungen in den SSPs 43 eingestellt werden. Für bestimmte Dienste, beispielsweise den, der oben Bezug nehmend auf 13 beschrieben wurde, ist es nicht der Benutzer, der die Auslösenummer liefert (die Webtel-Nummer bei dem Beispiel von 13); statt dessen weist der PSTN-Operator dem Benutzer eine geeignete Nummer als Teil des Registrierungsprozesses zu.
  • Wie der Prozeß des Plazierens einer Dienstressource auf einem Server 51 ausgeführt wird, hängt von dem Verhalten des PSTN-Operators auf die möglichen Wirkungen solcher Dienstressourcen auf den Betrieb des PSTN ab. Wenn die Dienstressource einfach einen Datengegenstand zu einer zugreifenden Entität zurückgibt, ist es möglich, daß der Operator sich nicht zu sehr um mögliche Fehler (zufällig oder beabsichtigt) beim Implementieren der Dienstressource sorgt. Jedoch wird der Operator wahrscheinlich viel besorgter um den ordnungsgemäßen Betrieb jeder Dienstlogik sein, die durch eine Ressource zurückgegeben werden kann; tatsächlich ist es möglich, daß ein Operator eine solche Dienstressource nicht erlaubt.
  • Momentan sei angenommen, daß sich ein Operator nicht um die Beschaffenheit oder Implementierung von Dienstressourcen sorgt, wobei es dann stark von der Beschaffenheit des betroffenen Servers abhängt, wie eine Ressource auf einem Server 51 plaziert wird. Wenn ein Benutzer beispielsweise einen Computer mit einem Netzwerkzugriff auf das Internet besitzt und dieser Computer als Server 51 verwendet wird, kann der Benutzer einfach eine gewünschte Ressource als eine WWW-Telephonseite für einen externen Zugriff auf den Server laden. Eine ähnliche Situation tritt auf, wenn der Server ein Organisationsserver ist, auf den der Server über ein internes LAN Zugriff hat. In beiden diesen letztgenannten Fällen erfordert das Laden der Ressource als eine WWW-Telephonseite selbst keinen Internet-Zugriff. Wenn jedoch der Server 51 einer ist, der durch einen externen Internet-Dienstprovider läuft, kann es ein Benutzer einrichten, die erforderliche Dienstressource in den zugeordneten Web-Site-Raum des Benutzers auf dem Server herunterzuladen; dies kann einen Internet-Zugriff beinhalten, muß jedoch nicht. Ein Spezialfall dieses letztgenannten Szenarios liegt vor, wenn der PSTN-Operator einen speziellen Server für Benutzer-Telephonseiten, die Dienstressourcen enthalten, bereitstellt.
  • Das Plazieren einer Dienstressource auf einem Server wird allgemein das Freischalten von einem oder mehreren Leveln eines Paßwortschutzes beinhalten.
  • Hinsichtlich des Ursprungs der Dienstressource, die durch einen Benutzer auf den Server 51 geladen wird, kann diese durch den Benutzer erzeugt werden oder, speziell wenn die Ressource eine Dienstlogik umfaßt, durch eine dritte Partei (einschließlich des PSTN-Operators) erzeugt werden.
  • Wenn der PSTN-Operator Kontrolle über die Dienstressourcen 49 haben möchte, um jegliche nachteiligen Wirkungen auf den Betrieb des PSTN zu vermeiden, sind zwei Lösungsansätze möglich. Zuerst könnte der Operator fordern, daß jede Ressource (oder möglicherweise ein bestimmter Teilsatz) vor der Verwendung einem Verifikationsprozeß unterworfen werden mußte, wobei dann geeignete Maßnahmen unternommen werden, um eine nachfolgende Änderung der Ressource durch den Benutzer zu vermeiden (möglicherweise mit Ausnahme spezieller Datengegenstände); diesbezüglich könnte der Operator fordern, daß die Ressource unter der Steuerung des Operators auf einem Server plaziert wird, auf den der Benutzer keinen Schreibzugriff hatte (mit Ausnahme der Möglichkeit zum Ändern spezieller Datengegenstände, wie oben angezeigt wurde). Ein zweiter, attraktiverer Lösungsansatz, um nachteilige Wirkungen durch die Dienstressourcen 49 zu minimieren, für den Operator besteht darin, Standarddienstressourcen bereitzustellen, zu denen ein Benutzer die eigenen Daten des Benutzers hinzufügen könnte (und möglicherweise begrenzte funktionelle Auswahlen durchführen kann, falls die Ressource eine Dienstlogik umfaßte); die kundenspezifische Ressource würde dann unter der Steuerung durch den Operator auf einen Server 51 geladen werden. Dieser Prozeß kann bequemerweise für eine spezielle Ressource unter Verwendung eines HTML-„Formulars" implementiert werden, das ein Benutzer über das WWW von dem Operator-gesteuerten Server herunterladen könnte. Nach dem Vervollständigen des Formulars und dem Aktivieren eines 'Bestätigen'-Graphikknopfs des Formulars würden die eingegebenen Informationen zurück zu dem Server 'versendet' werden, wo die Informationen verwendet werden würden, um eine kundenspezifische Dienstressource zu erzeugen, die danach für einen Zugriff über das Internet auf dem Server plaziert wird. Ein Vorteil dieses Lösungsansatzes besteht darin, daß eine Registrierung der Dienstressource mit dem Operator gleichzeitig bewirkt wird. (Es mag angemerkt werden, daß, wenn eine Registrierung als eine vom Laden einer Dienstressource auf einen Server separate Handlung durchgeführt werden muß, die Verwendung eines HTML-Formulars eine sehr bequeme Weise ist, um diesen Registrierungsprozeß zu implementieren).
  • Aus dem vorhergehenden ist zu sehen, daß, während der Bereitstellungsprozeß nicht notwendigerweise erfordert, daß Informationen über das Internet geleitet werden, dies in vielen Fällen die beste Lösung sein wird, speziell, wenn ein HTML-Formular, das über das WWW ausgetauscht wird, verwendet werden kann, um eine kundenspezifische Dienstressource zu erzeugen. Es sollte bemerkt werden, daß das Erzeugen einer kundenspezifischen Dienstressource unter Verwendung eines HTML-Formulars nicht auf Fälle begrenzt ist, bei denen der PSTN-Operator den Server steuert.
  • Bezüglich der Aktualisierung von Dienstressourcen existiert die Wahrscheinlichkeit, daß ein Bedarf besteht, bestimmte Datengegenstände auf einer ziemlich häufigen Basis zu aktualisieren (beispielsweise eine Roaming-Nummer). Wenn der PSTN-Operator keinerlei Kontrollen hinsichtlich der Dienstressourcen 49 plaziert, ist ein Aktualisieren eine relativ einfache Sache, die nur einen Schreibzugriff auf den betroffenen Server erfordert (wie bereits angezeigt wurde, wir dies im allgemeinen einen oder mehrere Level eines Paßwortschutzes beinhalten). Wenn jedoch der PSTN-Operator eine Kontrolle über die Dienstressourcen ausführt, indem beispielsweise nur kundenspezifische Anpassungen von Standarddienstressourcen erlaubt werden, wobei solche kundenspezifischen Ressourcen gesteuert durch den Operator auf Server geladen werden, kann es sein, daß ein Schreibzugriff auf die Dienstressource streng kontrolliert wird. Wiederum kann bequemerweise ein HTML-Formular in solchen Fällen als das Medium zum Modifizieren eines Datengegenstands verwendet werden; für den Operator hat dies den Vorteil des Begrenzens der möglichen Modifikationen, während für den Benutzer eine Formularschnittstelle einen einfachen Weg für eine Ressourcenmodifikation liefern sollte.
  • Für komplexere Aktualisierungen kann es notwendig sein, einen Prozeß zu durchlaufen, der ähnlich zu dem ist, der für eine anfängliche Bereitstellung erforderlich ist.
  • Speziell wenn die Dienstressourcen auf einem Server 51, der durch den PSTN-Operator gesteuert wird, gehalten werden, wird eine Ressourcenaktualisierung allgemein eine Kommunikation über das Internet beinhalten.
  • Web-Benutzer-Interaktion
  • Als nächstes werden andere mögliche Verwendungen der Dienstressourcen, die auf Telephonseiten auf den Servern 51 gehalten sind, betrachtet. Wenn beispielsweise die Telephonseite eines Benutzers B eine Umleitungsnummer enthält, kann, unter der Voraussetzung, daß ein Endgerät 53 eines Benutzers A einen Lesezugriff über das Internet auf diese Telephonseite durchführen kann, der Benutzer A einen graphischen Web-Browser, der auf dem Endgerät 53 läuft, verwenden, um B's Telephonseite zu betrachten und B's Umleitungsnummer zu entdecken. Wie vorher erläutert wurde, kann die Umleitungsnummer für eine Anzeige in einem existierenden visuellen Kontext, der der Nummer eine Bedeutung gibt, zu dem Benutzer A geleitet werden, oder kann mit einem begleitenden Erklärungstext zu dem Benutzer A geleitet werden.
  • Ein nützlicheres Beispiel ist ein Momentan-Roaming-Nummer-Dienst für den Benutzer B. Es sei angenommen, daß B's Telephonseite 49 auf dem Server 51 (siehe 14) wirksam ist, um, wenn auf dieselbe zugegriffen wird, eine momentane Roaming-Nummer, unter der B erreicht werden kann, zurückzugeben. Ferner sei angenommen, daß der Benutzer B eine Web-Site mit mehreren Web-Seiten, die in HTML geschrieben sind, besitzt, wobei jede Seite einen graphischen 'Telephon'-Knopf enthält, der, wenn er aktiviert wird, das GET-Verfahren verwendet, um durch ihren URL auf B's Telephonseite zuzugreifen. Wenn nun der Benutzer A während des Durchstöberns (Pfeil 66) von B's Web-Site über das WWW von dem Endgerät 53 des Benutzers A entscheidet, daß er den Benutzer B anrufen möchte, um bestimmte interessierende Gegenstände zu diskutieren, aktiviert der Benutzer A einfach den Telephonknopf 65 auf der momentan betrachteten Seite von B. Dies bewirkt, daß B's Telephonseite unter Verwendung der HTTP-Anforderung „GET URL (B-Telephonseite)" zugegriffen wird – siehe Pfeil 67.
  • Danach wird B's momentane Nummer, die angerufen werden soll, bestimmt und zu dem Endgerät 53 des Benutzers A geleitet (siehe Pfeil 68), wo dieselbe angezeigt wird. Ein erklärender Text, der die Nummer enthält, wird allgemein ebenfalls angezeigt; beispielsweise könnte der Text „bitte rufe mich unter der folgenden Nummer an:" angezeigt werden, wobei dieser Text entweder durch das HTML-Skript, das dem Telephonknopf zugeordnet ist, oder von der Telephonseite, wenn sie die momentane Nummer zurückgibt, bereitgestellt wird. Tatsächlich wäre es wahrscheinlich hilfreicher, dem Benutzer A nicht nur die momentane Nummer zum Erreichen des Benutzers B zur Verfügung zu stellen, sondern ferner alle Nummern, unter denen B erreicht werden könnte, zusammen mit den Zeiten, zu denen B am wahrscheinlichsten unter jeder Nummer zu erreichen ist. Da es wahrscheinlich ist, daß diese zusätzlichen Informationen häufigen Änderungen unterworfen sind, besteht die einzige vernünftige Möglichkeit, die Informationen bereitzustellen, von der Telephonseite. Somit liefert B's Telephonseite nicht nur die momentane Nummer zum Erreichen von B, sondern ferner einen Text, der Nummern und Seiten, die einer Änderung unterworfen sind, enthält; das Schreiben von B's Telephonseite geschieht selbstverständlich auf eine Weise, die sicherstellt, daß veränderliche Daten nur an einer Stelle geändert werden müssen.
  • Bei einem weiteren Beispiel könnte B's Telephonseite einer herunterladbare Dienstlogik zur Ausführung am Endgerät des Benutzers A beinhalten. Dies ist nützlich, wenn einem Benutzer Auswahlen präsentiert werden sollen, wobei jede Auswahl eine nachfolgende Aktion, wie z. B. das Holen einer weiteren Telephonseite, erzeugt. Beispielsweise könnte die Telephonseite, auf die zuerst zugegriffen wurde, eine Familientelephonseite sein, die die allgemeine Telephonnummer für eine Familie angibt, die dem Benutzer jedoch auch die Möglichkeit gibt, weitere Telephoninformationen bezüglich jedes Familienmitglieds auszuwählen, beispielsweise eine uhrzeitabhängige Nummer; in diesem Fall besitzt jedes Familienmitglied seine eigene Nachfolge-Telephonseite.
  • Bei den obigen Szenarien wurde dem Benutzer A eine anzurufende Nummer über das PSTN dargeboten. Der Benutzer A kann nun sein Standardtelephon abheben und die angegebene Nummer wählen. Tatsächlich tritt eine Komplikation auf, wenn A nur über eine SLIP/PPP-Verbindung über eine herkömmliche Nicht-ISDN-, PSTN-Leitung Zugriff auf das Internet hat, da in diesem Fall A's Telephonleitung bereits durch das Durchführen des Internetzugriffs besetzt ist, wenn der Netzübergang 90 versucht, eine Anrufverbindung zu A's Telephon aufzubauen; bei einer ISDN-Verbindung sind zwei Kanäle verfügbar, so daß dieses Problem nicht auftritt. Eine Möglichkeit, dieses Problem zu überwinden, bestünde darin, daß A's Endgerät 53 nach dem Erhalten der Nummer für den Anruf von B's Telephonseite seine Internetsitzung durch Speichern jeglicher erforderlicher Zustandsinformationen (beispiels weise des momentanen WWW-URL, auf den zugegriffen wird) automatisch unterbricht und seine SLIP/PPP-Verbindung beendet, um dadurch die Telephonleitung freizumachen. A kann dann B anrufen. Am Ende dieses Anrufs kann A die unterbrochene Internetsitzung wieder aufnehmen, unter Verwendung der gespeicherten Zustandsinformationen, um zu dem Punkt, an dem A abgebrochen hat, um B anzurufen, zurückzukehren. Ein alternativer Lösungsansatz besteht darin, ein geeignetes Multiplex-Modulationsschema auf der Telephonleitung zu A durchzuführen, was ermöglicht, daß Sprache und Daten gleichzeitig übertragen werden. Eine Anzahl derartiger Schemata existiert bereits. Das PSTN müßte dann die kombinierten Daten- und Sprach-Ströme, die von A kommen, an einem bestimmten Punkt trennen und jeden zu seinem geeigneten Ziel leiten (die Internet-Daten werden zu der ISP, die die SLIP/PPP-Verbindung für den Benutzer A liefert, weitergeleitet, während der Sprachstrom zu B geleitet wird); selbstverständlich würde auch der Daten- und Sprach-Verkehr in der umgekehrten Richtung eine Kombination an einem bestimmten Punkt für ein Senden über den letzten Schenkel zu A's Endgerät benötigen.
  • Statt des manuellen Anrufens von B durch A unter Verwendung eines Standardtelephons besteht eine weitere Möglichkeit darin, daß das Endgerät des Benutzers A mit einer Funktionalität versehen ist, die ermöglicht, daß A einen Anruf über das PSTN von seinem Endgerät durchführt; diese Funktionalität umfaßt allgemein eine Hardwareschnittstelle 70 (14) zu einer Telephonleitung und einer Telephon-Treibersoftware 71 zum Treiben der Schnittstelle 70 ansprechend auf eine Eingabe von einer Anwendungssoftware, beispielsweise dem Web-Browser 73. A könnte seine Telephonsoftware aufrufen und die erforderliche Nummer eingeben oder A muß vorzugsweise nur die Nummer, die von B's Telephonseite zurückgegeben wird, auf dem Bildschirm „auswählen" und dann in A's Telephonsoftware leiten. Tatsächlich wäre es unter der Voraussetzung, daß der Benutzer B die Softwareschnittstelle zu der Software 71, die die Wählfunk tionalität auf A's Endgerät liefert, kannte, für B's Telephonseite möglich, zu A's Endgerät einen Programmcode zurückzugeben, um auf A's Bestätigung, daß er mit einer Anrufplazierung fortsetzen möchte, hin automatisch B's Nummer zu wählen. Als eine Alternative zum Plazieren eines Sprachanrufs könnte, wenn A's Endgerät mit einem geeigneten Modem und einer Steuersoftware ausgerüstet ist, A statt dessen wählen, ein Fax oder Daten durch das PSTN entweder zu B' s üblicher Nummer oder zu einer Nummer, die auf B' s Telephonseite als die Nummer, die für solche Übertragungen verwendet werden soll, spezifiziert ist, zu senden. Selbstverständlich kann das Plazieren eines Anrufs von A's Endgerät über das PSTN dem Problem eines Konflikts, das bereits erläutert wurde, für eine Verwendung der Telephonleitung, wenn dies keine ISDN-Leitung ist und A einen Internetzugriff über eine SLIP/PPP-Verbindung erlangt, unterworfen sein.
  • Wie auch immer der Anruf plaziert wird, existiert eine Anzahl von Möglichkeiten, wenn B's Telephon, das der Nummer, die von A versucht wird, entspricht, belegt ist. Wenn B eine Telephonseite besitzt, die eine Umleitungsnummer spezifiziert, und B diese Dienstressource bei dem PSTN registriert hat, sollte folglich die Umleitungsnummer automatisch durch das PSTN versucht werden. Wenn jedoch die Umleitungsnummer-Ressource nicht bei dem PSTN registriert wurde, wird ein Besetzt-Signal zu A zurückgegeben. Wenn A den Anruf durch ein Standardtelephon plaziert hat, muß A nun entscheiden, wie er fortfahren will, wobei A wählen kann, entweder aufzugeben oder wiederum auf B's Telephonseite zu verweisen, um die Umleitungsnummer nachzuschlagen und eine Neuwahl unter Verwendung dieser Nummer durchzuführen. Wenn A den ursprünglichen Anruf unter Verwendung seines Endgeräts 53 plaziert hat, kann das letztgenannte programmiert sein, um die Rückgabe eines Besetzt-Signals zu erfassen und dann automatisch B's Umleitungsnummer nachzuschlagen und eine Neuwahl unter Verwendung dieser Nummer durchzuführen. Diese Funktionalität kann in einer Dienstlo gik, die von B's Telephonseite heruntergeladen wird und auf A's Endgerät abläuft, enthalten sein.
  • Wenn A seine Internetsitzung beenden mußte, um die Telephonleitung für eine Sprachverwendung freizumachen, erfordert eine erneute Bezugnahme auf B's Telephonseite, daß eine neue Internetsitzung begonnen wird (tatsächlich könnte diese Unbequemlichkeit vermieden werden, wenn B's Umleitungsnummer zu dem Zeitpunkt, zu dem die ursprüngliche Nummer, die für B gewählt werden soll, geliefert wurde, zu A's Endgerät geleitet worden wäre).
  • Die Dienstressource, auf die auf B's Telephonseite daraufhin, daß B's Telephon besetzt ist, zugegriffen wird, kann selbstverständlich komplexer sein als nur eine Umleitungsnummer. Insbesondere kann dem Benutzer A ein Bereich von Optionen geboten werden, einschließlich beispielsweise B's Fax- oder Sprach-Mailbox-Nummer, wobei die Auswahl einer Option möglicherweise den Ablauf einer geeigneten Zugriffsoftware einleitet. Eine weitere mögliche Option für A bestünde darin, B eine Rückrufnachricht unter Verwendung eines Formulars, das von B's Telephonseite heruntergeladen wird, nachdem diese Option gewählt worden ist, zu lassen; das ausgefüllte Formular würde zu dem Server 51 zurückversendet und zur Überprüfung zu gegebener Zeit für B protokolliert werden.
  • Selbstverständlich kann der Fall auftreten, daß der Benutzer A auf B's Telephonseite zugreifen möchte, um beispielsweise B's momentane Roaming-Nummer herauszufinden, daß jedoch der Benutzer A den URI von B's Web-Site nicht kennt und nur B's Webtel-Nummer besitzt. A könnte B nur durch das PSTN anrufen, wobei in diesem Fall die Übersetzung von B's Webtel-Nummer in die Roaming-Nummer automatisch bewirkt werden würde (unter der Annahme, daß B noch für diesen Dienst registriert ist); es kann jedoch sein, daß A B nicht geradewegs anrufen möchte, sondern nur seine momentane Roaming-Nummer erfahren möchte. Um A's Problem zu lösen, sind die vorher beschriebenen Webtel-Zu-URI-Zuordnungstabellen vorzugsweise an einer bekannten Adresse (beispielsweise einer bekannten Web-Site) im Internet zugreifbar. Alles, was A nun tun muß, besteht darin, auf diese Web-Site zuzugreifen, wobei B's Webtel-Nummer weitergeleitet wird; B's Telephonseiten-URI wird dann zu A zurückgegeben, der diesen dann verwenden kann, um auf B's Telephonseite zuzugreifen. Dieser Prozeß kann selbstverständlich von dem Punkt an automatisiert werden, an dem A B's Webtel-Nummer zu der Zuordnungstabellen-Web-Site sendet.
  • Internet/PSTN-Anrufschnittstelle
  • Bei dem Szenario von 14 fand A's Zugriff auf das PSTN durch eine Standardtelephonschnittstelle statt, selbst wenn sich die tatsächliche Form von A's Telephon vom Standard dadurch unterschieden hat, daß dasselbe in A's Computerendgerät 53 integriert ist. 15 zeigt eine Situation, bei der A, nachdem ihm B's momentane Roaming-Nummer wie bei dem Fall von 14 bereitgestellt wurde, B über einen Weg anruft, der über das Internet beginnt und dann über eine Benutzernetzwerkschnittstelle 80 in das PSTN weitergeht. Die Schnittstelle 80 ist angeordnet, um eine Umwandlung zwischen einer ISDN-Typ-Telephonsignalisierung auf dem PSTN und entsprechenden Signalisierungsanzeigen, die in IP-Paketen über das Internet übertragen werden, durchzuführen; zusätzlich überträgt die Schnittstelle 80 Sprachdaten von IP-Paketen auf den Kanal 60 und umgekehrt.
  • Daraufhin, daß A einen Anruf zu B einleitet, sendet eine Internet-Telephonsoftware 81 in A's Endgerät eine Anrufverbindungs-Einleitungssignalisierung über das Internet zu der Schnittstelle 80, deren Adresse A's Endgerät bereits bekannt ist. An der Schnittstelle 80 wird die Signalisierung in eine ISDN-Typ-Signalisierung umgewandelt und zu der SSP 41 geleitet. Der Anrufverbindungsaufbau setzt sich dann auf die normale Weise fort und eine Rückgabesignalisierung wird durch die Schnittstelle 80 über das Internet zu der Software 81 in A's Endgerät zurückübertragen. Diese Software leitet Anrufverbindungs-Aufbaufortschrittsinformationen für eine Anzeige für A zu dem WWW-Browser 73 weiter. Nachdem die Anrufverbindung eingerichtet wurde, kann A mit B über sein Telephon sprechen, wobei A's Spracheingabe zuerst in einer Telephonhardwareschnittstelle 83 digitalisiert und dann durch die Software 81 in IP-Pakete eingefügt wird, um das Internet über die Schnittstelle 80 (siehe Pfeil 84) zu überqueren; ein Sprachverkehr von B folgt dem umgekehrten Weg.
  • IN-Dienste können für diesen Anruf durch die SCP ansprechend auf eine Dienstanforderung von einer SSP 41 vorgesehen sein. Wenn folglich B's Telephon besetzt ist und B für eine Anrufumleitung registriert ist, wird die SCP 42 beim Empfang einer Dienstanforderung auf B's geeignete Telephonseite für eine Anrufumleitung zugreifen und die Umleitungsnummer wiedergewinnen. Wenn die SSP 41 nicht eingestellt ist, um eine Dienstanforderung daraufhin, daß B's Telephon besetzt ist, einzuleiten, wird die Besetzt-Anzeige zu A's Endgerät zurückgegeben, wo dieselbe auf die Art und Weise, die bereits Bezug nehmend auf 14 beschrieben wurde, gehandhabt werden kann.
  • Tatsächlich kann die Schnittstelle 80 mit einer Funktionalität versehen sein, die ähnlich zu einer SSP ist, um Auslöserbedingungen einzustellen und eine Dienstanforderung zu der SCP 43 zu erzeugen, wenn diese Bedingungen erfüllt sind.
  • Dritte-Partei-Anrufverbindungsaufbau-Netzübergang
  • 16A zeigt eine weitere Anordnung, durch die A B anrufen kann, nachdem B's momentane Roaming-Nummer empfangen wurde. In diesem Fall ist ein Dritte-Partei- Anrufverbindungsaufbau-Netzübergang 90 vorgesehen, der eine Schnittstelle sowohl mit dem Internet als auch einer SSP 41 liefert. Geeigneterweise kann sich der Übergang 90 am gleichen Ort wie die SCP 43 befinden (obwohl dies nicht essentiell ist). Der Übergang 90 besitzt die Fähigkeit, die SSP 41 anzuweisen, eine Anrufverbindung zwischen spezifizierten Telephonen aufzubauen (verschiedene Befehlssätze und Protokolle zum Anweisen von SSPs sind in der Technik bereits bekannt). Der Netzübergang wird als „Dritte-Partei-" Netzübergang bezeichnet, da derselbe von beiden beabsichtigten Kommunikationsentitäten A und B getrennt ist.
  • Wenn A B anrufen möchte, wird somit eine Dritte-Partei-Anrufverbindungsaufbau-Anforderung von A's Endgerät über das Internet zu dem Netzübergang 90 gesendet (siehe Pfeil 91). Diese Aufbauanforderung umfaßt A's Telephonnummer und B's momentane Roaming-Nummer. Der Netzübergang 90 versucht zuerst, die Anrufverbindung zu A's Telephon aufzubauen (was allgemein erfolgreich sein sollte) und danach, die Anrufverbindung zu B's identifiziertem Telephon aufzubauen. Sobald die Anrufverbindung aufgebaut ist, kommunizieren A und B auf herkömmliche Weise über das PSTN.
  • Es sei angemerkt, daß die Anrufverbindungsaufbau-Anforderung, die durch A's Endgerät zu dem Netzübergang 90 durchgeführt wird, gleichermaßen durch eine Dienstlogik, die in B's Telephonseite gehalten und durch den Server 51 ausgeführt wird, durchgeführt hätte werden können (eine solche Anordnung würde selbstverständlich erfordern, daß A's Telephonnummer zu B's Telephonseiten-Dienstlogik geleitet wird, wobei es eingerichtet werden könnte, daß dies entweder automatisch stattfindet oder durch ein Formular, das dem Benutzer A an dem Endgerät A präsentiert und dann zurück zu dem Server 51 versendet wird).
  • Der Aufbaunetzübergang 90 kann über das Internet 50 zugreifbar sein unter Verwendung jedes geeigneten Protokolls hoher Ebene; da jedoch allgemein A's Anschluss 53 und der Server 51 bereits das HTTP-Protokoll betreiben, kann dieses letztere Protokoll praktischerweise auch verwendet werden, um auf den Netzübergang 90 zuzugreifen.
  • Anstatt dass der Anschluss 53 des Benutzers A oder die Dienstlogik von B auf dem Server 51 nach einem Austausch zwischen dem Anschluss 53 und dem Server 51 auf den Netzübergang 90 zugreifen, kann der Benutzer A direkt auf den Netzübergang zugreifen, um eine Anrufverbindung aufzubauen, und ein solcher Zugriff wird durch Implementieren der Internetschnittstelle des Netzübergangs 90 als ein HTTP-Server ermöglicht. Genauer gesagt, die Internetschnittstelle des Netzübergangs könnte CGI-Skripte speichern, um einen Anrufverbindungsaufbau zu bewirken, und der Benutzer A könnte ein geeignetes Skript von dem Anschluss 53 aktivieren. Beim Arbeiten auf diese Weise liefert der Benutzer A seine eigene Telefonnummer und die Telefonnummer von B an den Netzübergang, wobei die Nummer von B entweder die tatsächliche Nummer zum Anrufen für B oder seine Webtel-Nummer sein kann. Im letzteren Fall greift der Netzübergang 90 auf B's Telefonseite 59 auf dem Server 51 zu, um B's aktuelle Roamingnummer auf die bereits beschriebene Weise zu erlangen; dieses Zugreifen auf B's Telefonseite kann entweder direkt durch den Netzübergang 90 durchgeführt werden oder durch den Netzübergang, der eine Dienstanforderung an die SCP 43 weiterleitet (wobei das Letztere nur eine Möglichkeit ist, wo eine solche SCP mit Internetverbindbarkeit vorgesehen ist, wie es in 16A dargestellt ist).
  • Der Netzübergang 90 kann auch angeordnet sein, um Dienstanforderungen zu der SCP 43 durchzuführen, wenn vorbestimmte Auslöserbedingungen erfüllt sind. Folglich könnte der Netzübergang 90 eingestellt sein, um den Besetzt-Zustand von B's Telephon aufzunehmen und eine Dienstanforderung nach einer Umleitungsnummer zu der SCP 43 einzuleiten. Jedoch ist das Leiten der Besetzt-Anzeige zurück zu A's Endgerät über den Netzübergang 90 aufgrund der Flexibilität, die dies A bezüglich einer weiteren Aktion gibt, bevorzugt.
  • Andere Anordnungen von Dritte-Partei-Anrufverbindungsaufbaunetzübergängen, die sich von demjenigen, das in 16A gezeigt ist, unterscheiden, sind ebenfalls möglich. Somit kann der Netzübergang angeordnet sein, um eine Anrufverbindungsaufbausteuerung über SCP 43 zu bewirken, anstatt direkt mit dem Schalter 41 eine Schnittstelle zu bilden. Alternativ kann der Netzübergang einen speziellen Schalter 94 steuern, der zweckgebunden ist, um einen Anrufverbindungsaufbau unter der Steuerung des Netzübergangs zu bewirken (siehe 16B). Eine weitere Möglichkeit ist das Bereitstellen eines Schalters 95 an der äußeren Grenze des PSTN (siehe 16C), die dazu dient, eine Anrufverbindung zwischen dem Benutzer A und dem Benutzer B aufzubauen, durch Aufbauen jeweiliger Anrufverbindungen durch das PSTN an die Benutzer A und B und dann Verbinden der Anrufverbindungen untereinander. In diesem Fall kann der Netzübergang zusammen mit dem Schalter 95 angeordnet sein oder mit demselben verbunden sein, durch jeden geeigneten Kommunikationskanal, wie z. B. LAN oder in der Tat über das Internet.
  • Wie bereits allgemein bezüglich 14 erörtert wurde, entsteht eine Komplikation, wenn A einen Internetzugriff lediglich über eine SLIP/PPP-Verbindung über eine übliche, Nicht-ISDN, PSTN-Leitung besitzt, da in diesem Fall A's Telephonleitung bereits durch das Erzeugen des Internetzugriffs besetzt ist, wenn der Netzübergang 90 versucht, eine Anrufverbindung zu A's Telephon aufzubauen. Die Lösungen, die bezüglich 14 erörtert wurden (ab Beendigung der Internetsitzung; Multiplexen von Sprach- und Internet-Daten über die gleiche Telephonleitung) können auch hier verwendet werden. Ein alternativer Lösungsansatz sowohl für das Szenario von 14 als auch das von 16 ist möglich, wenn das Endgerät des Benutzers A einen Sprachan ruf als digitalisierte Sprache, die über das Internet geleitet wird, handhaben kann. In diesem Fall kann der Sprachanruf durch eine Schnittstelle 80 der Form von 15 plaziert werden, wobei der Sprach-Verkehr und die Internet-Kommunikation mit B's Telephonseite und/oder dem Netzübergang 90 beide in Internet-Paketen durchgeführt werden, die über die SLIP/PPP-Verbindung zu/von A's Endgerät 53 geleitet werden, jedoch als logisch unterschiedliche Flüsse, die durch getrennte Anwendungen, die auf dem Endgerät 53 laufen, übertragen werden.
  • Es sei angemerkt, daß die Schnittstelle 80 von 15 und der Netzübergang 90 von 16 Beispiele liefern, wie Dienstanforderungen durch andere Entitäten als die SSPs 41 zu dem Dienststeuer-Untersystem geleitet werden.
  • „Gebührenfreie" Dienste auf WWW-Basis (800-Nummer)
  • Es ist möglich, einen „gebührenfreien" oder „800-Nummer"-Typ eines Dienstes unter Verwendung einer Kombination von WWW und PSTN zu implementieren. Wie aus der folgenden Beschreibung eines solchen Dienstes Bezug nehmend auf 17 zu sehen ist, stützt sich eine WWW/PSTN-Implementierung nicht notwendigerweise entweder auf eine Übertragung von Anrufgebühren von dem anrufenden auf den angerufenen Teilnehmer oder auf die Verwendung einer speziellen „800"-Nummer, zwei Charakteristika von üblichen „gebührenfreien" Schemata. Die WWW/PSTN-Implementierungen besitzen jedoch die allgemeinere Charakteristik des Plazierens eines anfragenden Teilnehmers und des Teilnehmers, an den die Anfrage gerichtet ist, in einen telefonischen Kontakt auf Kosten des letztgenannten Teilnehmers.
  • Bei der Anordnung von 17 besitzt ein Benutzer D, wie z. B. ein großes Warenhaus, eine Web-Site auf einem Server 51; zu Zwecken der Einfachheit wird angenommen, daß der Server unter der Steuerung eines Benutzers D ist, der einen direkten Computerzugriff auf den Server über eine Leitung 125 hat. D's Web-Site kann beispielsweise viele katalogartige Web-Seiten enthalten, die Waren zeigen, die durch D zum Verkauf angeboten werden. Darüber hinaus besitzt D eine Gebührenfrei-Seite 124 zum Handhaben von Anfragen, die auf einer gebührenfreien Basis plaziert werden; der URL dieser Seite ist einem „Gebührenfrei"-Graphikknopf 122 zugeordnet, der auf jeder der Web-Site-Katalogseiten plaziert ist.
  • Es sei angenommen, daß der Benutzer A am Endgerät 53 D's Website durchstöbert und die Katalogseiten betrachtet (Pfeil 121). Wenn A einen interessierenden Gegenstand sieht und wünscht, eine Anfrage an D über diesen Gegenstand zu stellen, aktiviert A am Endgerät 53 den Graphik-Gebührenfrei-Knopf 122, der der betreffenden Katalogseite zugeordnet ist. Diese Aktivierung bewirkt, daß der Code, der in die Katalogseite, die momentan in A's Endgerät geladen ist, eingebettet ist, den Benutzer veranlaßt, seine Telephonnummer einzugeben und optional seinen Namen, woraufhin eine HTTP-Anforderung zu D's Gebührenfrei-Seite unter Verwendung des POST-Verfahrens und beinhaltend die eingegebenen Daten gesendet wird (Pfeil 123). Auf das Empfangen dieser Anforderung hin führt D's Gebührenfrei-Seite eine Dienstlogik durch, um eine neue Anfrage (die A's Namen und Telephonnummer einschließt) in eine Anfragewarteschlange 127, die in einem Anfragesteuersystem 126 gehalten ist, einzugeben. Bei dem gegenwärtigen Beispiel ist das Anfragesteuersystem über die Leitung 125 außerhalb des Internets mit dem Server 51 verbunden; es wäre jedoch auch möglich, daß der Server 51 mit dem Anfragesteuersystem durch das Internet kommuniziert, wobei dies tatsächlich die zweckmäßigste Anordnung sein kann, wobei sich D's Website auf einem ISP-Server befindet, und nicht auf einem Server, der durch D gesteuert wird. Tatsächlich könnte der Code, der in A's Endgerät auf eine Aktivierung des Gebührenfrei-Graphikknopfs 122 hin abläuft, angeordnet sein, um die Anfrageanforderung direkt zu dem Anfragesteuersystem über das Internet weiterzuleiten, und nicht dieselbe zu dem Server 51 zurückzuleiten.
  • Das Anfragesteuersystem 126 verwaltet Anfragen, die zu demselben geleitet werden, um sicherzustellen, daß dieselben auf eine geordnete Art und Weise gehandhabt werden. Das System 126 schätzt auf den Empfang einer neuen Anfrage hin vorzugsweise ab, wie lange es dauert, bevor die Anfrage behandelt wird, wobei diese Abschätzung auf der Anzahl von gegenwärtig in der Warteschlange befindlichen Anfragen und der mittleren Zeit, die benötigt wird, um eine Anfrage zu handhaben, basiert. Diese Abschätzung einer Wartezeit wird über den Server 51 in der Antwort auf die POST-Anforderungsnachricht zu dem Benutzer A zurückgeleitet.
  • Das Anfragesteuersystem 126 schaut nach der Verteilung von Anfragen zu einer Anzahl von Vertretern, von denen jeder mit einem Telephon 40 und einer Anzeige 129 ausgestattet ist. A's Anfrage wird behandelt, sobald sie den Kopf der Warteschlange 127 erreicht und erfaßt wird, daß ein Vertreter verfügbar ist, um die Anfrage zu handhaben (beispielsweise kann das System angeordnet sein, um zu erfassen, wann das Telephon eines Vertreters aufgelegt wird). Wenn diese Bedingungen erfüllt sind, nimmt eine Verteilungs- und Aufbau-Steuereinheit 128 A's Anfrage und zeigt A's Namen und Telephonnummer auf der Anzeige 129 des verfügbaren Vertreters (der der Klarheit halber hierin als Vertreter D' bezeichnet wird) an; wenn der Benutzer D eine Datenbank von D's vergangenen Kunden oder Kreditfähigkeitsdaten hält, wird die Einheit 128 auch nach derartigen weiteren Informationen, die über A bekannt sind, suchen und dieselben anzeigen. Gleichzeitig führt die Einheit 128 eine Dritte-Partei-Anrufverbindungsaufbau-Anforderung (Pfeil 130) über das Internet zu dem Netzübergang 90 durch, mit der Bitte, eine Anrufverbindung zwischen dem Telephon des verfügbaren Vertreters D' und dem Telephon des Benutzers A aufzubauen, wobei beide Telephone durch ihre jeweiligen Nummern identifiziert sind. Wenn sowohl D' als auch A den Anruf aufneh men, setzt sich die Anfrage fort, wobei die Kosten der Anrufverbindung durch D gezahlt werden, da es D ist, von dem die Anrufverbindung über das PSTN ausgeht. Wenn jedoch, aus welchem Grund auch immer, der Anruf für eine vorbestimmte Zeitablaufperiode unvollständig bleibt (da er beispielsweise durch A nicht beantwortet wird), kann die Einheit 128 angeordnet sein, um automatisch die nächste Anfrage zu dem Kopf der Warteschlange 127 zu leiten.
  • Es wäre selbstverständlich möglich, darauf zu verzichten, daß die Einheit 128 einen Anrufverbindungsaufbau durch den Netzübergang 90 anfordert, und dafür den Vertreter D' A's Nummer manuell wählen zu lassen oder die Einheit 126 ein automatisches Wählen der Telephonnummer von D' einleiten zu lassen (wobei der Vertreter D' beispielsweise ein Computerintegriertes Telephon ähnlich dem von A in 14 aufweist). Der Vorteil dieser Lösungsansätze besteht darin, daß das existierende PSTN ohne Anpassung und ohne irgendeine Dienstinstallation beim Implementieren des Gebührenfrei-Dienstes auf WWW-Basis verwendet werden könnte.
  • Wie bezüglich der 11 und 13 erläutert wurde, entsteht eine Komplikation beim Plazieren eines Anrufs zu A, wenn A lediglich einen Internetzugriff über eine SLIP/PPP-Verbindung über eine übliche, Nicht-ISDN, PSTN-Leitung besitzt, da in diesem Fall A's Telephonleitung bereits durch das Durchführen eines Internetzugriffs besetzt ist, wenn der Benutzer D versucht, eine Anrufverbindung zu A's Telephon aufzubauen. Die Lösungen, die bezüglich der 11 und 13 erläutert wurden, können auch hier verwendet werden (Beendigung der Internetzsitzung; Multiplexen von Sprach- und Internet-Daten auf der gleichen Telephonleitung; und Plazieren des Anrufs über das Internet zu A's Endgerät). Bezüglich der Lösung, die auf der Beendigung der Internetsitzung basiert, könnte eine solche Beendigung verzögert werden, bis A's Anfrage an der Reihe war, um behandelt zu werden; um dies durchzuführen, wäre es jedoch notwendig, ein Feedback von dem Steuersystem 126 über das Internet zu A's Endgerät 53 zu liefern und dieses Feedback einem Code zum Bewirken der Internetsitzungsbeendigung zuzuordnen. Eine Möglichkeit, um dies zu erreichen, bestünde darin, daß die Antwortnachricht, die durch den Server 51 ansprechend auf die ursprüngliche POST-Anforderungsnachricht von A gesendet wird, einen Korrelationscode beinhaltet; jegliches nachfolgendes Feedback von dem System 126, die zu A geleitet wird, würde ebenfalls diesen Code beinhalten (wobei der Server A den Code ebenfalls zu dem Steuersystem 126 leitet), wodurch ermöglicht wird, daß A's Endgerät dieses Feedback korrekt identifiziert. Tatsächlich könnte der gleiche Mechanismus verwendet werden, um dem Benutzer A Aktualisierungen zu liefern, wie lange der Benutzer A wahrscheinlich noch warten muß, bis er zurückgerufen wird, wobei dieser Mechanismus unabhängig davon verwendbar ist, ob ein Konfliktproblem für die Verwendung von A's Telephonleitung existierte oder nicht.
  • Wenn der Benutzer A nur ein Telephon 40 und kein Endgerät 53 besitzt, ist es immer noch möglich, die grundlegende Struktur von 17 zu verwenden, um einen Gebührenfrei-Dienst für den Benutzer A zu liefern, ohne auf die Komplexität einer Anrufverbindungs-Rechnungsstellungsübertragung zurückgreifen zu müssen. Spezieller würde A eine Spezialnummer für den Gebührenfrei-Dienst des Benutzers D (typischerweise eine 800-Nummer) wählen, wobei die SSP 41 diese Spezialnummer auf eine Standardweise erkennen würde und eine Dienstanforderung an die SCP 43 einschließlich sowohl dieser Spezialnummer als auch A's Nummer durchführen würde. Die SCP 43 würde dann D's Gebührenfrei-Seite-URL durch das Durchführen einer Nummer-Zu-URL-Übersetzung sicherstellen und unter Verwendung einer POST-Verfahren-HTTP-Anforderung ähnlich zu der Anforderung 123 auf D's Gebührenfrei-Seite zugreifen. Sobald diese Anforderung als eine Anfrage durch D's Gebührenfrei-Seite 124 registriert wurde, könnte die Letztgenannte eine Antwort zu der SCP 43 senden, die dieselbe auffordert, eine Ansage abzuspielen, wie z. B. „Ihre Gebührenfrei-Anfrage wurde registriert; bitte hängen sie auf und sie werden in Kürze kontaktiert". Diese Ansage könnte für A durch eine IP auf eine Standardweise abgespielt werden. A würde dann aufhängen und wäre bereit, einen Anruf von D zu empfangen.
  • Ein signifikanter Vorteil der obigen Gebührenfrei-Schemata unter Verwendung des WWW besteht darin, daß für den Benutzer D keine Kosten für die Verwendung des PSTN während Perioden, zu denen eine Anfrage in einer Warteschlange ist und darauf wartet, gehandhabt zu werden, auflaufen.
  • Varianten
  • Selbstverständlich sind viele Varianten bezüglich der oben beschriebenen Anordnungen möglich, wobei eine Anzahl dieser Varianten nachfolgend beschrieben wird.
  • Verteilte Verarbeitungsumgebung. Wie in 18 gezeigt ist, kann die SCP 43 auf die HTTP-Server 51 durch eine verteilte Verarbeitungsumgebung, DPE 98 (DPE = distributed processing environment), die zumindest logisch vom Internet getrennt ist, zugreifen. Vorzugsweise werden in diesem Fall die Server 51 durch PSTN-Operatoren kontrolliert und sind somit zahlenmäßig beschränkt.
  • Dienstressourcen auf DNS-Typ-Servern. Bei den vorher genannten Beispielen wurden die Dienstressourcengegenstände auf Servern 51 plaziert, die mit dem Internet verbunden sind, wobei durch das Dienststeuerungsteilsystem des PSTN und/oder durch Internet-Benutzer durch die Verwendung eines URI, der von einem Ressourcencode, der den gewünschten Dienstressourcengegenstand identifiziert, hergeleitet wird, über das Internet auf eine gewünschte Dienstressource zugegriffen wurde. Bei einer bevorzugten Anordnung zum Herleiten des URI von einem Ressourcencode in der Form einer Telephonnummer wurde die gesamte oder ein Teil der betroffenen Telephonnummer syntaktisch in eine Domainnamen form ausgewertet und dann unter Verwendung eines verteilten Datenbanksystems vom DNS-Typ, das tatsächlich in das DNS selbst integriert sein könnte (siehe 11 und 12 und zugehörige Beschreibung), in einen URI aufgelöst. Tatsächlich wäre es möglich, Dienstressourcengegenstände direkt in Registrierungsdatensätzen (RRs), die durch ein verteiltes Datenbanksystem vom DNS-Typ gehalten werden, zu plazieren, so daß statt der syntaktisch ausgewerteten Telephonnummer, die in einen URI aufgelöst wird, der dann verwendet wird, um auf die erforderliche Ressource zuzugreifen, die syntaktisch ausgewertete Telephonnummer direkt in den erforderlichen Dienstressourcengegenstand aufgelöst wird. Der Mechanismus, der bei diesem Prozeß verwendet wird, entspricht exakt dem bereits zum Auflösen einer syntaktisch ausgewerteten Telephonnummer in eine URI beschriebenen. Das verteilte Datenbanksystem vom DNS-Typ, das hierzu verwendet wird, wäre vorzugsweise ein solches, auf das über das Internet oder das DNS selbst zugegriffen werden kann, um einen Zugriff auf die Dienstressourcengegenstände für Internet-Benutzer und für das Dienststeuer-Untersystem des PSTN zu liefern (auf die gleiche Weise, wie sie oben Bezug nehmend auf 18 beschrieben wurde, wobei durch ein anderes Netzwerk als das Internet auf die DNS-Typ-Server, die die Dienstressourcengegenstände halten, zugegriffen werden kann). Obwohl das Plazieren der Dienstressourcengegenstände in RRs, die in DNS-Typ-Servern gehalten sind, nicht für alle Typen von Dienstressourcengegenständen geeignet sein muß, ist es für Gegenstände, wie z. B. Telephonnummern, die sich nicht häufig ändern, geeignet. Folglich besteht eine geeignete Verwendung darin, eine Nummernübertragbarkeit vorzusehen; in diesem Fall löst eine gewählte persönliche Nummer einen Nachschlag in dem DNS-Typ-System mit der gesamten oder einem Teil der persönlichen Nummer, die zuerst syntaktisch ausgewertet wird und dann auf das DNS-Typ-System angewendet wird, um eine momentane Nummer für eine Anrufumleitung zurückzugeben, aus. Alle gewählten Nummern könnten als persönliche Nummern oder einfach als ein Untersatz solcher Nummern behandelt werden, wobei dieser Untersatz Nummern aufweist, die ohne weiteres beispielsweise durch einen lokalen Nachschlag an einer SSP oder das Vorliegen einer vorbestimmten vorderen Ziffernfolge als persönliche Nummern identifizierbar sind. Das allgemeine Konzept des syntaktischen Auswertens einer Telephonnummer (oder einer ähnlichen Nummer) insgesamt oder teilweise, um einen Domainnamen für eine Auflösung in einem verteilten Datenbanksystem vom DNS-Typ kann zur Wiedergewinnung anderer Informationsgegenstände neben URIs und Dienstressourcengegenständen verwendet werden.
  • Feedbackmechanismus. Bei der Erörterung der Gebührenfrei-Anordnung auf WWW-Basis von 17 wurde erwähnt, daß dem Benutzer A ein Feedback bezüglich der wahrscheinlichen Dauer der Wartezeit, bevor A zurückgerufen wird, geliefert werden könnte. Dies ist ein Beispiel der Verwendung des Internets, um einen Feedbackweg für einen potentiellen oder tatsächlichen Telephonbenutzer zu liefern. Ein anderes Beispiel wurde bezüglich 16 angegeben, wo der Fortschritt eines Anrufverbindungsaufbaus durch den Anrufverbindungsaufbau-Netzübergang dem Endgerät des Benutzers A zurückberichtet wurde. Tatsächlich ergibt sich allgemein dort, wo bekannt ist, daß ein Benutzer ein Endgerät, das im Internet aktiv ist, verwendet, die Gelegenheit, dem Benutzer ein Feedback bezüglich des Fortschritts eines Anrufverbindungsaufbaus durch das Telephonsystem zu liefern. Um dies durchzuführen, ist es selbstverständlich notwendig sicherzustellen, daß das Feedback zu der geeigneten Anwendung geleitet werden kann, die auf dem Endgerät A abläuft, wobei dies allgemein erfordert, daß die Anwendung geeignete Verknüpfungsinformationen verfügbar gemacht hat. Ebenso wie Anrufverbindungsaufbau-Fortschrittsinformationen können auch andere Informationen, beispielsweise während einer Anrufverbindungshalteperiode, zurückgegeben werden. Beispielsweise kann somit ein spezieller Server im Internet vorgesehen sein, der Multimedia-Clips oder sogar Videos hält, die während einer Anrufhalteperiode zu dem Benutzer A ausgegeben werden könnten.
  • Bei den beschriebenen Anordnungen hielten die Server 51 Dienstressourcengegenstände, die primär eine Anrufverbindungsaufbausteuerung betrafen. Es sei angemerkt, daß in einer etwas unterschiedlichen Anwendung Internet-Server angeordnet sein könnten, um Daten zu halten, auf die von dem Telephonsystem ansprechend auf eine von einem Benutzer eingeleitete Telephonanforderung zugegriffen werden könnte und die zu diesen Telephonbenutzer zurückgegeben werden könnten. Ein solcher Dienst würde beispielsweise ansprechend auf eine SSP-Auslösung einer Dienstanforderung auf das Eingeben einer speziellen Telephonnummer hin geliefert werden, wobei die Dienstanforderung eine SCP veranlaßt, zu bewirken, daß ein intelligentes Peripheriegerät auf einen speziellen Internet-Server (nicht notwendigerweise einen HTTP-Server) zugreift und die erforderlichen Daten für eine Zurückgabe zu dem anrufenden Teilnehmer wiedergewinnt. Das intelligente Peripheriegerät kann einen Text-Zu-Sprach-Wandler zum vokalen Wiedergeben der Daten zu dem Benutzer umfassen.
  • Ein weiterer Feedback-Prozeß ist ebenfalls erwähnenswert, in diesem Fall in Bezug auf Dienstressourcengegenstände selbst. Beispielsweise kann ein Telephonbenutzer G an einem Dienst teilnehmen, durch den Anrufe, die zu G's Telephon durchgeleitet werden, um ein Minimum von X Minuten getrennt werden, wobei X Benutzer-einstellbar ist. Um diesen Dienst zu implementieren, besitzt G eine Telephonseite auf einem Server 51, die eine „Belegt"-Statusanzeige umfaßt. Auf eine Beendigung einer erfolgreichen Anrufverbindung zu G hin löst G's lokale SSP das Übersenden einer Nachricht durch die zugeordnete SCP über das Internet zu G's Telephonseite aus. Diese Nachricht bewirkt, daß G's Belegt-Anzeige gesetzt wird, um anzuzeigen, daß G belegt ist; Diese Nachricht startet ferner einen Zeitgeber, der nach einer Periode X abläuft und bewirkt, daß die Belegt-Status-Anzeige rückgesetzt wird. Ein Anrufversuch zu G wird entweder an G's SSP zurückgewiesen, da G's Leitung tatsächlich belegt ist, oder wird auslösen, daß die SSP über die SCP anfragt, ob G's Telephonseiten-Belegt-Status-Anzeige gesetzt ist. Wenn die Belegt-Status-Anzeige gesetzt ist (was sie während der Periode X nach der Beendigung einer erfolgreichen Anrufverbindung sein wird), wird der Anrufversuch zurückgewiesen, wohingegen, wenn die Belegt-Status-Anzeige in ihrem rückgesetzten Zustand ist, erlaubt wird, daß der Anrufversuch fortgesetzt wird. Indem der Belegt-Status-Anzeigemechanismus auf G's Telephonseite plaziert wird, ist es möglich, es einzurichten, daß G einfach in der Lage ist, den Wert von X zu ändern.
  • Allgemeinere Varianten. Obwohl das Dienststeuer-Untersystem des PSTN bei den vorhergehenden Beispielen als eine SCP verkörpert war, ist es klar, daß die Funktionalität des Dienststeuer-Untersystem als Teil einer SSP oder eines zugeordneten Adjunct geliefert werden könnte. Ferner kann das Auslösen von Dienstanforderungen durch eine andere Ausrüstung als SSPs bewirkt werden, beispielsweise durch Unterbrechungsblöcke, die in die SS7-Signalisierungsverbindungen eingebracht sind.
  • Es ist klar, daß der Ausdruck „Internet" so zu verstehen ist, daß er nicht nur die momentane Spezifikation der TCP/IP-Protokolle, die für das Internet verwendet werden, und das momentane Adressierungsschema umfaßt, sondern auch Entwicklungen dieser Merkmale, wie sie z. B. zur Behandlung isochroner Medien benötigt werden können. Ferner sollten Bezugnahmen auf das WWW und das HTTP-Protokoll in gleicher Weise so verstanden werden, daß sie sich entwickelnde Abkömmlinge derselben beinhalten.
  • Die vorliegende Erfindung kann auch auf andere Telephonsysteme als PSTNs angewendet werden, beispielsweise PLMNs oder andere mobile Netzwerke, sowie auf private Systeme unter Verwendung von PABXs. In diesem letztgenannten Fall wird ein LAN oder ein geländeweites Computernetzwerk, das allgemein die gleichen internen Benutzer wie das PABX bedient, die Rolle des Internet bei den beschriebenen Ausführungsbeispielen einnehmen.
  • Darüber hinaus hat die vorliegende Erfindung dort Anwendung, wo beliebige Vermittlungstelekommunikationssysteme (beispielsweise ein Breitband-ATM-System) eine Dienststeuerung erfordern, wobei ein Computernetzwerk für die Bereitstellung von Dienstressourcen zu dem Dienststeuer-Untersystem des Telekommunikationssystems verwendet werden kann.

Claims (8)

  1. Ein Verfahren zum Aufbauen eines Trägerkanals (60) durch ein öffentliches Telefonsystem zwischen einer ersten Partei (A) und einer zweiten Partei (B), denen ein erster vorbestimmter Code (A-telnb) beziehungsweise ein zweiter vorbestimmter Code (B-telnb) zugeordnet ist, wobei das öffentliche Telefonsystem eine Schalteinrichtung (41) zum Aufbauen von Trägerkanälen (60) durch das öffentliche Telefonsystem und einen Anrufverbindungs-Aufbau-Gateway (90) aufweist, durch den die Schalteinrichtung (41) von dem öffentlichen Internet (50) gesteuert werden kann, wobei das Verfahren folgende Schritte umfasst: a) Bereitstellen des zweiten vorbestimmten Codes (B-telnb) und einer Dienstlogik zum Erzeugen und Übertragen von Anrufverbindungs-Aufbau-Anforderungen auf einem Server (51), der mit dem öffentlichen Internet (50) verbunden ist; b) Weiterleiten des ersten vorbestimmten Codes (A-telnb) an den Server (51) über das Internet (50) von einem Anschluss (53), der der ersten Partei (A) zugeordnet ist, wobei die Dienstlogik an dem Server (51) veranlasst wird, eine Anrufverbindungs-Aufbau-Anforderung zu erzeugen und die Anforderung an den Anrufverbindungs-Aufbau-Gateway (90) über das Internet zu übertragen, wobei die Anrufverbindungs-Aufbau-Anforderung sowohl den ersten vorbestimmten Code (A-telnb) als auch den zweiten vorbestimmten Code (B-telnb) umfasst; und c) auf den Empfang der Anrufverbindungs-Aufbau-Anforderung an dem Anrufverbindungs-Aufbau- Gateway (90) hin, Bewirken, dass der Anrufverbindungs-Aufbau-Gateway die Schalteinrichtung (41) abhängig von den vorbestimmten Codes (A-telnb, B-telnb), die in der empfangenen Anrufverbindungs-Aufbau-Anforderung enthalten sind, steuert, um einen ersten und zweiten Trägerkanalabschnitt, die durch das öffentliche Telefonsystem zu der ersten beziehungsweise der zweiten Partei (A, B) verlaufen, aufzubauen und miteinander in Verbindung zu bringen.
  2. Ein Verfahren gemäß Anspruch 1, bei dem die Anrufverbindungs-Aufbau-Anforderung eine HTTP-Mitteilung ist.
  3. Ein Verfahren gemäß Anspruch 1, bei dem die Dienstlogik nach dem Empfang des ersten vorbestimmten Codes (A-telnb), aber vor dem Erzeugen der Anrufverbindungs-Aufbau-Anforderung einen bestimmten Wert des zweiten vorbestimmten Codes (B-telnb) von einer Anzahl von möglichen Werten auswählt, wobei dieser ausgewählte bestimmte Wert dann der Wert des zweiten vorbestimmten Codes ist, der in der Anrufverbindungs-Aufbau-Anforderung verwendet wird.
  4. Ein Verfahren gemäß Anspruch 1, bei dem der Trägerkanal durch das öffentliche Telefonsystem zu einer der Parteien (A) hin an einer Schnittstelle (80) zu dem Internet (50) und zu der anderen Partei (B) hin an Teilnehmergerätschaften (40) dieser Partei endet; wobei das Verfahren den Schritt des Aufbauens eines Trägerkanalabschnitts (84) über das Internet (50) zwischen der einen Partei (A) und der Schnittstelle (80), und des Kommunizierens dieses Trägerkanalabschnitts (84) mit dem Trägerkanal umfasst, der von dieser Schnittstelle durch das Telefonnetzwerk verläuft.
  5. Ein Verfahren zum Aufbauen eines Trägerkanals (60) durch ein öffentliches Telefonsystem zwischen einer ersten Partei (A) und einer zweiten Partei (D), denen ein erster vorbestimmter Code (A-telnb) beziehungsweise ein zweiter vorbestimmter Code (D'-telnb) zugeordnet ist, wobei das öffentliche Telefonsystem eine Schalteinrichtung (41) zum Aufbauen von Trägerkanälen (60) durch das öffentliche Telefonsystem und einen Anrufverbindungs-Aufbau-Gateway (90) aufweist, durch den die Schalteinrichtung (41) von dem öffentlichen Internet (50) gesteuert werden kann, wobei das Verfahren folgende Schritte umfasst: a) Zugreifen auf eine Informationsressource (124), die auf einem Servier (51) gehalten wird und der zweiten Partei (D) zugeordnet ist, über das Internet (50) von einem Anschluss (53), der der ersten Partei (A) zugeordnet ist, wobei die Informationsressource (124) eine Anfrageanforderungsressource zum Erzeugen von Anfrageanforderungen umfasst; b) Weiterleiten des ersten vorbestimmten Codes (A-telnb) an die Anfrageanforderungsressource über das Internet (50) von dem Anschluss (53), der der ersten Partei (A) zugeordnet ist, um zu bewirken, dass die Anfrageanforderungsressource eine Anfrageanforderung erzeugt, die den ersten vorbestimmten Code (A-telnb) umfasst; c) Weiterleiten der Anfrageanforderung an einen Anfrageverwalter (126), der der zweiten Partei (D) zugeordnet ist, wobei der Anfrageverwalter (126) zu einem geeigneten Zeitpunkt eine Anrufverbindungs-Aufbau-Anforderung erzeugt, die über das Internet (50) an den Anrufverbindungs-Aufbau-Gateway (90) übertragen wird, wobei die Anrufverbindungs-Aufbau-Anforderung sowohl den ersten vorbestimmten Code (A-telnb) als auch den zweiten vorbestimmten Code (D'-telnb) umfasst; und d) auf den Empfang der Anrufverbindungs-Aufbau-Anforderung an dem Anrufverbindungs-Aufbau-Gateway (90) hin, Bewirken, dass das Anrufverbindungs-Aufbau-Gateway die Schalteinrichtung (41) abhängig von den vorbestimmten Codes (A-telnb, D'-telnb), die in der empfangenen Anrufverbindungs-Aufbau-Anforderung enthalten sind, steuert, um einen ersten und zweiten Trägerkanalabschnitt, die durch das öffentliche Telefonsystem zu der ersten beziehungsweise der zweiten Partei (A, D) verlaufen, aufzubauen und miteinander in Verbindung zu bringen.
  6. Ein Verfahren gemäß Anspruch 5, bei dem die Anrufverbindungs-Aufbau-Anforderung eine HTTP-Mitteilung ist.
  7. Ein Verfahren gemäß Anspruch 5, bei dem der Trägerkanal (60) durch das öffentliche Telefonsystem zu der ersten Partei (A) hin an einer Schnittstelle (80) zu dem Internet (50) und zu der zweiten Partei (D) hin an Teilnehmergerätschaften (40) dieser Partei endet; wobei das Verfahren den Schritt des Aufbauens eines Trägerkanalabschnitts (84) über das Internet (50) zwischen der ersten Partei (A) und der Schnittstelle (80), und des Kommunizierens dieses Trägerkanalabschnitts mit dem Trägerkanal umfasst, der von dieser Schnittstelle durch das Telefonnetzwerk verläuft.
  8. Eine Anordnung zum Implementieren aller Schritte des Verfahrens gemäß einem der vorhergehenden Ansprüche.
DE69634608T 1995-12-11 1996-12-11 Verbindungsaufbaudurchgang für ein fernmeldesystem Expired - Lifetime DE69634608T2 (de)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
GB9525190 1995-12-11
GBGB9525190.6A GB9525190D0 (en) 1995-12-11 1995-12-11 Method and system for providing telecommunication services
EP95410148 1995-12-22
EP95410148 1995-12-22
GB9603591 1996-02-20
GBGB9603591.0A GB9603591D0 (en) 1996-02-20 1996-02-20 Method of providing telecommunication services
PCT/GB1996/003049 WO1997022210A2 (en) 1995-12-11 1996-12-11 Call setup gateway for telecommunications system

Publications (2)

Publication Number Publication Date
DE69634608D1 DE69634608D1 (de) 2005-05-19
DE69634608T2 true DE69634608T2 (de) 2006-03-02

Family

ID=27236968

Family Applications (2)

Application Number Title Priority Date Filing Date
DE69634608T Expired - Lifetime DE69634608T2 (de) 1995-12-11 1996-12-11 Verbindungsaufbaudurchgang für ein fernmeldesystem
DE69635522T Expired - Lifetime DE69635522T2 (de) 1995-12-11 1996-12-11 Verfahren zur versorgung von fernmeldediensten

Family Applications After (1)

Application Number Title Priority Date Filing Date
DE69635522T Expired - Lifetime DE69635522T2 (de) 1995-12-11 1996-12-11 Verfahren zur versorgung von fernmeldediensten

Country Status (11)

Country Link
US (2) US6282281B1 (de)
EP (3) EP0867091B1 (de)
JP (1) JP3742108B2 (de)
CN (1) CN1208536A (de)
AT (2) ATE293338T1 (de)
AU (2) AU704503B2 (de)
CA (2) CA2238501A1 (de)
DE (2) DE69634608T2 (de)
NO (2) NO982510L (de)
NZ (1) NZ324340A (de)
WO (2) WO1997022209A1 (de)

Families Citing this family (205)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6021428A (en) * 1997-09-15 2000-02-01 Genesys Telecommunications Laboratories, Inc. Apparatus and method in improving e-mail routing in an internet protocol network telephony call-in-center
GB9603582D0 (en) 1996-02-20 1996-04-17 Hewlett Packard Co Method of accessing service resource items that are for use in a telecommunications system
US6154445A (en) 1996-04-18 2000-11-28 Bell Atlantic Network Services, Inc. Telephony communication via varied redundant networks
US6069890A (en) 1996-06-26 2000-05-30 Bell Atlantic Network Services, Inc. Internet telephone service
US6385191B1 (en) 1996-11-14 2002-05-07 Avaya Technology Corp. Extending internet calls to a telephony call center
US6078582A (en) 1996-12-18 2000-06-20 Bell Atlantic Network Services, Inc. Internet long distance telephone service
US7031442B1 (en) 1997-02-10 2006-04-18 Genesys Telecommunications Laboratories, Inc. Methods and apparatus for personal routing in computer-simulated telephony
US6480600B1 (en) 1997-02-10 2002-11-12 Genesys Telecommunications Laboratories, Inc. Call and data correspondence in a call-in center employing virtual restructuring for computer telephony integrated functionality
US6104802A (en) 1997-02-10 2000-08-15 Genesys Telecommunications Laboratories, Inc. In-band signaling for routing
US5978806A (en) * 1997-02-18 1999-11-02 Ameritech Corporation Method and apparatus for communicating information about a called party to a calling party
US5946684A (en) 1997-02-18 1999-08-31 Ameritech Corporation Method and system for providing computer-network related information about a calling party
US6137869A (en) 1997-09-16 2000-10-24 Bell Atlantic Network Services, Inc. Network session management
US6574216B1 (en) 1997-03-11 2003-06-03 Verizon Services Corp. Packet data network voice call quality monitoring
US6292479B1 (en) 1997-03-19 2001-09-18 Bell Atlantic Network Services, Inc. Transport of caller identification information through diverse communication networks
US6870827B1 (en) 1997-03-19 2005-03-22 Verizon Services Corp. Voice call alternative routing through PSTN and internet networks
US6404736B1 (en) * 1997-06-20 2002-06-11 Telefonaktiebolaget L M Ericsson (Publ) Call-routing efficiency with a network access server
DE19734622A1 (de) 1997-08-09 1999-02-11 Alsthom Cge Alcatel Endgerät, Berechtigungskarte und Telekommunikationsnetz für einen Teilnehmer sowie Verfahren zum Ändern eines dem Teilnehmer zugeordneten Diensteprofils
US6748054B1 (en) 1997-09-08 2004-06-08 Worldcom, Inc. Single telephone number access to multiple communications services
US6631402B1 (en) 1997-09-26 2003-10-07 Worldcom, Inc. Integrated proxy interface for web based report requester tool set
US6711611B2 (en) 1998-09-11 2004-03-23 Genesis Telecommunications Laboratories, Inc. Method and apparatus for data-linking a mobile knowledge worker to home communication-center infrastructure
US6985943B2 (en) 1998-09-11 2006-01-10 Genesys Telecommunications Laboratories, Inc. Method and apparatus for extended management of state and interaction of a remote knowledge worker from a contact center
USRE46528E1 (en) 1997-11-14 2017-08-29 Genesys Telecommunications Laboratories, Inc. Implementation of call-center outbound dialing capability at a telephony network level
DE19752838A1 (de) 1997-11-28 1999-06-02 Cit Alcatel Verfahren zur Übermittlung einer Teilnehmernummer eines gewünschten Teilnehmers, sowie Telefonauskunftseinrichtung und Endgerät hierfür
NO975518L (no) * 1997-12-01 1999-06-02 Ericsson Telefon Ab L M FremgangsmÕte for forbedring av oppsettingen av telefon-til-telefon-anrop
US6618366B1 (en) * 1997-12-05 2003-09-09 The Distribution Systems Research Institute Integrated information communication system
US6829236B1 (en) * 1997-12-10 2004-12-07 Mci Communications Corporation System and method for providing automated directory assistance via the internet and corresponding call completion within a telecommunications system
US6185194B1 (en) * 1997-12-12 2001-02-06 Zip2 System and method for initiating a telephone call utilizing internet initiation
US6757274B1 (en) 1997-12-16 2004-06-29 Bellsouth Intellectual Property Corporation Method and apparatus for allowing selective disposition of an incoming telephone call during an internet session
FI105383B (fi) * 1997-12-22 2000-07-31 Nokia Networks Oy Menetelmä prosessien väliseen tiedonsiirtoon
US6097804A (en) * 1997-12-23 2000-08-01 Bell Canada Method and system for completing a voice connection between first and second voice terminals in a switched telephone network
DE59807682D1 (de) * 1997-12-23 2003-04-30 Siemens Ag Wählvermittlungssystem mit zugang zu seinen ressourcen durch das internet
EP0926908A1 (de) * 1997-12-24 1999-06-30 TELEFONAKTIEBOLAGET L M ERICSSON (publ) Verarbeitung von Zeitüberschreitungen in einer Dineststeuereinrichtung
DE19801498A1 (de) * 1998-01-16 1999-07-22 Siemens Ag Verfahren zum Aufbau einer Telekommunikationsverbindung und Telekommunikationssystem hierfür
US7907598B2 (en) 1998-02-17 2011-03-15 Genesys Telecommunication Laboratories, Inc. Method for implementing and executing communication center routing strategies represented in extensible markup language
US6332154B2 (en) 1998-09-11 2001-12-18 Genesys Telecommunications Laboratories, Inc. Method and apparatus for providing media-independent self-help modules within a multimedia communication-center customer interface
DE19809799A1 (de) * 1998-03-09 1999-09-16 Cit Alcatel Verfahren zur Übermittlung von Zustandsdaten, Server-Rechner und Dienststeuereinheit
DE19810869A1 (de) * 1998-03-13 1999-09-16 Cit Alcatel Verfahren zur Verwaltung von Telekommunikationsdienst-Daten eines Teilnehmers sowie Server und Vermittlungsstelle hierzu
DE19818006A1 (de) * 1998-04-22 1999-10-28 Siemens Ag Durchführung von Diensten eines Intelligenten Netzes unter Nutzung eines Datennetzes
US6236722B1 (en) * 1998-05-01 2001-05-22 Bell Canada Method and system for using TCAP signaling for improved call setup from a virtual switching point
US7171463B1 (en) * 1998-05-20 2007-01-30 Lucent Technologies Inc. System and method for denoting and communicating with computer network mobile sites
US6421338B1 (en) * 1998-06-05 2002-07-16 Lucent Technologies Inc. Network resource server
WO2000003550A1 (en) * 1998-07-08 2000-01-20 Ericsson Inc. Hypertext transport protocol interface in an intelligent network node
US6415027B1 (en) * 1998-08-12 2002-07-02 Bellsouth Intellectual Property Corporation Networks, systems and methods for intelligently routing traffic within a telephone network
USRE46153E1 (en) 1998-09-11 2016-09-20 Genesys Telecommunications Laboratories, Inc. Method and apparatus enabling voice-based management of state and interaction of a remote knowledge worker in a contact center environment
US20040193512A1 (en) * 1998-09-24 2004-09-30 Parmeshwar Gobin Web based integrated customer interface for invoice reporting
US6876632B1 (en) * 1998-09-25 2005-04-05 Hitachi, Ltd. Intelligent network with an internet call waiting function
GB2342529B (en) 1998-10-05 2003-06-04 Hewlett Packard Co Call Centre
FR2785123A1 (fr) * 1998-10-22 2000-04-28 Cit Alcatel Passerelle entre un reseau de donnees et un reseau de services
NO312739B1 (no) * 1998-11-23 2002-06-24 Ericsson Telefon Ab L M Anordning for forbedring av styringen av supplement¶re tjenester i en fast terminal
US6930998B1 (en) * 1998-12-07 2005-08-16 Nortel Networks Limited Hybrid TDM and ATM voice switching central office and method of completing inter-office calls using same
DE69942735D1 (de) * 1998-12-10 2010-10-21 Lucent Technologies Inc PABX-Verwaltung
FI982725A (fi) * 1998-12-16 2000-06-17 Nokia Networks Oy Menetelmä ja järjestelmä tietoliikennejärjestelmässä
JP3328208B2 (ja) * 1998-12-28 2002-09-24 富士通株式会社 インテリジェントネットワークシステム
US6940847B1 (en) * 1999-01-15 2005-09-06 Telefonaktiebolaget Lm Ericsson (Publ) System and method for providing access to service nodes from entities disposed in an integrated telecommunications network
US6614784B1 (en) * 1999-01-15 2003-09-02 Telefonaktiebolaget L M Ericsson (Publ) System and method for providing supplementary services (SS) in an integrated telecommunications network
CN1339213A (zh) 1999-02-04 2002-03-06 爱培恩通信有限公司 通信网关
US20030033382A1 (en) * 1999-02-05 2003-02-13 Bogolea Steven C. Interactive communication system
FI108266B (fi) 1999-03-01 2001-12-14 Tecnomen Oy Menetelmä ja järjestelmä puhelun ohjaamiseksi verkkoon kytkettyä tietokonetta käyttäen
US6738824B1 (en) * 1999-03-30 2004-05-18 Cisco Technology, Inc. Dial-out link selection via static route redistribution
US6839324B1 (en) * 1999-03-30 2005-01-04 Cisco Technology, Inc. Method and apparatus providing dial on demand scaling
US6816481B1 (en) * 1999-04-09 2004-11-09 Sbc Technology Resources, Inc. Internet caller identification system and method
CA2273657C (en) * 1999-05-05 2010-09-21 Nortel Networks Corporation Telephony and data network services at a telephone
US7068641B1 (en) * 1999-05-05 2006-06-27 Nortel Networks Limited Telephony and data network services at a telephone
US6535506B1 (en) * 1999-05-11 2003-03-18 Click Interconnect, Inc. Method and apparatus for establishing communications with a remote node on a switched network based on hypertext calling received from a packet network
US6411697B1 (en) * 1999-05-20 2002-06-25 International Business Machines Corp. System and method for providing customer personalized and modifiable subscriber services
US6963928B1 (en) * 1999-05-27 2005-11-08 Bagley David T Systems and methods for communicating across various communication applications using single address strings
US6393274B1 (en) 1999-06-08 2002-05-21 Nokia Mobile Phones, Ltd. Wireless telecommunication system having subscriber advanced personal service
US6842447B1 (en) 1999-06-14 2005-01-11 Mci, Inc. Internet protocol transport of PSTN-to-PSTN telephony services
FI108979B (fi) * 1999-06-14 2002-04-30 Nokia Corp Ohjaavan palvelun käynnistäminen
US6546392B1 (en) * 1999-06-25 2003-04-08 Mediaone Group, Inc. Self service gateway
ES2204140T3 (es) * 1999-06-30 2004-04-16 Nokia Corporation Red de telecomunicaciones y metodo de encaminamiento.
NL1012552C2 (nl) * 1999-07-09 2001-01-10 Koninkl Kpn Nv User interface voor telecommunicatie-abonnees.
US6453034B1 (en) 1999-07-29 2002-09-17 Mci Worldcom, Inc. Method of and system for extending internet telephony over virtual private network direct access lines
US6735209B1 (en) * 1999-07-29 2004-05-11 Worldcom, Inc. Address definition for IP telephony services
US7062265B1 (en) 1999-08-12 2006-06-13 Lucent Technologies Inc. Architecture to support service features for wireless calls in a wireless telecommunication system
US7388953B2 (en) * 1999-09-24 2008-06-17 Verizon Business Global Llc Method and system for providing intelligent network control services in IP telephony
US6636596B1 (en) * 1999-09-24 2003-10-21 Worldcom, Inc. Method of and system for providing intelligent network control services in IP telephony
US7272649B1 (en) 1999-09-30 2007-09-18 Cisco Technology, Inc. Automatic hardware failure detection and recovery for distributed max sessions server
CA2317283A1 (en) * 1999-10-08 2001-04-08 Nortel Networks Corporation Multimedia music on hold
US6970451B1 (en) * 1999-10-12 2005-11-29 At&T Corp. Smart routers-simple optics: network architecture for IP over WDM
US20030123636A1 (en) * 1999-10-22 2003-07-03 Bigelow Tim A. Method of routing telecommunications and data traffic
DE19954224A1 (de) * 1999-11-05 2001-05-10 Deutsche Telekom Ag Verfahren zur Erweiterung der Funktionalität eines Telekommunikationsnetzes und Telekommunikationssystem zur Durchführung des Verfahrens
US6480588B1 (en) 1999-11-08 2002-11-12 Worldcom, Inc. Methods for providing prepaid telephony service via an internet protocol network system
US6615236B2 (en) 1999-11-08 2003-09-02 Worldcom, Inc. SIP-based feature control
US9281996B1 (en) 1999-11-08 2016-03-08 Verizon Patent And Licensing Inc. Method and system for dynamic gateway selection in an IP telephony network
US6434143B1 (en) 1999-11-08 2002-08-13 Mci Worldcom, Inc. Internet protocol telephony voice/video message deposit and retrieval
US7929978B2 (en) 1999-12-01 2011-04-19 Genesys Telecommunications Laboratories, Inc. Method and apparatus for providing enhanced communication capability for mobile devices on a virtual private network
US6615231B1 (en) * 1999-12-15 2003-09-02 Microsoft Corporation System and method for directing requests to specific processing
CA2328008A1 (en) * 1999-12-20 2001-06-20 Nortel Networks Limited Private reuse of the public switched telephone network dial plan
US6687242B1 (en) * 1999-12-22 2004-02-03 Bellsouth Intellectual Property Corporation Method and system for providing additional information to a subscriber based on a universal resource locator
US6519228B1 (en) * 1999-12-22 2003-02-11 International Business Machines Corp. System and method of operation for verifying and validating public switch telephone networks (PSTN) to (IP) network services
EP1111506A1 (de) * 1999-12-23 2001-06-27 Alcatel Verfahren und Vorrichtung zur Bestimmung einer Verarbeitungsumgebung
US20070237320A1 (en) * 2000-01-19 2007-10-11 Sony Ericsson Mobile Communications Ab Nya Vattentornet Technique for providing caller-originated alert signalsin circuit-switched communications
US7934206B2 (en) * 2000-02-11 2011-04-26 Convergent Networks, Inc. Service level executable environment for integrated PSTN and IP networks and call processing language therefor
US6977917B2 (en) * 2000-03-10 2005-12-20 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for mapping an IP address to an MSISDN number within a service network
US6711156B1 (en) * 2000-03-20 2004-03-23 Telefonaktiebolaget L M Ericsson (Publ) System and method for providing enhanced user-service interaction in an integrated telecommunications network
EP1137295A1 (de) * 2000-03-20 2001-09-26 BRITISH TELECOMMUNICATIONS public limited company Kommunikationsnetzwerk
DE10019727A1 (de) 2000-04-20 2001-10-25 Alcatel Sa Netzwerkserver
JP2001339762A (ja) * 2000-05-29 2001-12-07 Mitsubishi Electric Corp 通信システム及び通信方法及び携帯電話
FI111594B (fi) * 2000-06-05 2003-08-15 Nokia Corp Tilaajatietojen hallinta matkaviestinjärjestelmässä
US7116657B1 (en) 2000-08-22 2006-10-03 Internet Operator (Asia) Pte. Ltd. System and method for establishing long distance call connections using a desktop application
DE60018446T2 (de) * 2000-09-01 2006-02-09 Nokia Corp. Architektur für dienstscriptenausführung und -verwaltung
US7177867B2 (en) * 2000-10-23 2007-02-13 Sri International Method and apparatus for providing scalable resource discovery
US6879678B1 (en) 2000-11-13 2005-04-12 Softalk, Inc. System and method for establishing long distance call connections using a personal communication assistant
DE10064999A1 (de) * 2000-12-23 2002-07-11 Alcatel Sa Verfahren zum Aufbau einer Telekommunikationsverbindung, sowie Diensterechner und Programmmodule hierfür
US7286524B1 (en) * 2001-02-02 2007-10-23 Qwest Communications International, Inc. System and method for high capacity/failure tolerance telecommunications in a signaling network gateway
JP4113336B2 (ja) * 2001-03-15 2008-07-09 富士通株式会社 通話サービス提供システム
US20020138427A1 (en) * 2001-03-20 2002-09-26 Trivedi Prakash A. Systems and methods for communicating from an integration platform to a billing unit
US7054866B2 (en) 2001-03-20 2006-05-30 Mci, Inc. Systems and methods for communicating from an integration platform to a provisioning server
US7043480B2 (en) * 2001-03-20 2006-05-09 Mci, Inc. Systems and methods for communicating from an integration platform to a lightweight directory access protocol based database
US8660017B2 (en) 2001-03-20 2014-02-25 Verizon Business Global Llc Systems and methods for updating IP communication service attributes using an LDAP
US8195738B2 (en) * 2001-03-20 2012-06-05 Verizon Business Global Llc Systems and methods for communicating from an integration platform to a profile management server
US7039041B2 (en) 2001-03-20 2006-05-02 Robohm Kurt W Operational support system for telecommunication services
US20020138603A1 (en) * 2001-03-20 2002-09-26 Robohm Kurt W. Systems and methods for updating IP communication service attributes
US8417632B2 (en) * 2001-03-20 2013-04-09 Verizon Business Global Llc Systems and methods for interfacing with a billing and account management unit
US7047417B2 (en) * 2001-03-20 2006-05-16 Leskuski Walter J Systems and methods for accessing reporting services
US6788774B1 (en) * 2001-05-23 2004-09-07 Bellsouth Intellectual Property Corporation System and method of providing a per-use, auto-generation, personalized web page service
US6879672B2 (en) * 2001-09-13 2005-04-12 International Business Machines Corporation Telecommunications service extensions
WO2003028357A1 (en) * 2001-09-27 2003-04-03 British Telecommunications Public Limited Company Computer telephony integration using email address to establish voice connection
CN100384192C (zh) * 2001-09-28 2008-04-23 华为技术有限公司 一种宽带智能上网业务的实现方法
EP1303097A3 (de) 2001-10-16 2005-11-30 Microsoft Corporation Virtuelles verteiltes Sicherheitsystem
US7194553B2 (en) 2001-10-16 2007-03-20 Microsoft Corporation Resolving virtual network names
US7676540B2 (en) 2001-10-16 2010-03-09 Microsoft Corporation Scoped referral statements
US8015204B2 (en) 2001-10-16 2011-09-06 Microsoft Corporation Scoped access control metadata element
US7469299B2 (en) * 2001-10-25 2008-12-23 Verizon Business Global Llc Bridging user agent and a proxy server for supporting network services
US7899047B2 (en) 2001-11-27 2011-03-01 Microsoft Corporation Virtual network with adaptive dispatcher
US20030135595A1 (en) * 2002-01-03 2003-07-17 Segelstein David J. Method of providing auto-registration of an IP telephony end-point
US20030156565A1 (en) * 2002-02-18 2003-08-21 Taisto Gregory T. Method of transmitting data
US7529249B1 (en) * 2002-03-22 2009-05-05 Cisco Technology, Inc Voice and dial service level agreement enforcement on universal gateway
US7590740B1 (en) 2002-03-22 2009-09-15 Cisco Technology, Inc. Expediting port release in distributed networks
US7376742B1 (en) 2002-03-22 2008-05-20 Cisco Technology, Inc. Resource and AAA service device
US7237026B1 (en) 2002-03-22 2007-06-26 Cisco Technology, Inc. Sharing gateway resources across multi-pop networks
US6968050B1 (en) * 2002-03-27 2005-11-22 Verizon Services Corp. Methods and apparatus for authenticating and authorizing ENUM registrants
JP2004005435A (ja) * 2002-03-28 2004-01-08 Seiko Epson Corp ダウンロード管理システム
US20040148340A1 (en) * 2003-01-29 2004-07-29 Web.De Ag Web site having a zone layout
US20040015563A1 (en) * 2002-07-22 2004-01-22 Web. De Ag Communications environment having web sites on a portal
EP1395028A1 (de) * 2002-08-27 2004-03-03 Web. De AG Websitegesteuerter Aufbau von Telefonverbindung
EP1398945A1 (de) * 2002-09-11 2004-03-17 Web. De AG Websitegesteuerter Aufbau von Telefonverbindung
DE10392561B4 (de) * 2002-04-30 2006-07-06 Combots Product Gmbh & Co. Kg Websitegesteuerter Aufbau von Telefonverbindung
US20040013132A1 (en) * 2002-07-22 2004-01-22 Web.De Ag Multiprotocol communications environment
EP1502412A2 (de) * 2002-04-30 2005-02-02 Web.De AG Website mit einem erzeugungselemenht
US20050182824A1 (en) * 2002-04-30 2005-08-18 Pierre-Alain Cotte Communications web site
US20040148392A1 (en) * 2003-01-29 2004-07-29 Web.De Ag Website having an event identification element
US20040148341A1 (en) * 2003-01-29 2004-07-29 Web.De Ag Web site having an individual event settings element
AU2003229760A1 (en) * 2002-04-30 2003-11-17 Web.De Ag Web site having an event identification element
EP1514403A2 (de) * 2002-04-30 2005-03-16 Web.De AG Verfahren zur verwaltung der kommunikation
US20040148351A1 (en) * 2003-01-29 2004-07-29 Web.De Ag Communications web site
US20040221297A1 (en) * 2003-04-30 2004-11-04 Web.De Ag Event-related screensaver
AU2003236846A1 (en) * 2002-04-30 2003-11-17 Web.De Ag Method for establishing a communications link
US20040015588A1 (en) * 2002-07-22 2004-01-22 Web.De Ag Communications environment having multiple web sites
EP1504584B1 (de) * 2002-04-30 2007-01-17 Combots Product GmbH & Co.KG Kommunikationsumgebung mit mehreren web-sites
US20040013258A1 (en) * 2002-07-22 2004-01-22 Web. De Ag Communications environment having a connection device
EP1502414A2 (de) * 2002-04-30 2005-02-02 Web.De AG Kommunikationsumgebung mit webseiten auf einem portal
US20040019629A1 (en) * 2002-07-23 2004-01-29 Web.De Ag Communications environment
US20040221064A1 (en) * 2003-04-30 2004-11-04 Web.De Ag Multinet session management
US20040215783A1 (en) * 2003-04-25 2004-10-28 Web.De Ag Method for establishing a communications link
EP1395027A1 (de) * 2002-08-27 2004-03-03 Web. De AG Kommunikationsverbindungen über eine Telekommunikations-Web-Site
KR100876780B1 (ko) * 2002-06-05 2009-01-07 삼성전자주식회사 로컬 네트워크를 위한 인터넷 액세스 게이트웨이에서네트워크 어드레스 변환 없이 단일의 인터넷 프로토콜어드레스를 공유하기 위한 방법 및 장치
US7216287B2 (en) * 2002-08-02 2007-05-08 International Business Machines Corporation Personal voice portal service
US7133506B1 (en) 2002-08-12 2006-11-07 Bellsouth Intellectual Property Corp. Message delivery systems and methods
US6882718B1 (en) * 2002-09-06 2005-04-19 Bellsouth Intellectual Property Corp. Real time customer service data manipulation to allow multiple services per trigger type
US7240068B2 (en) * 2002-09-06 2007-07-03 Truetel Communications, Inc. Service logic execution environment (SLEE) that is running on a device, supporting a plurality of services and that is compliant with a telecommunications computing standard for SLEES
US7308091B1 (en) 2002-09-06 2007-12-11 At&T Bls Intellectual Property, Inc. Web-based data manipulation for advanced intelligent network service control point services
US7139382B1 (en) 2002-09-09 2006-11-21 Bellsouth Intellectual Property Corp. System and method for restricting incoming calls
US7162254B1 (en) 2002-09-09 2007-01-09 Bellsouth Intellectual Property Corp: Methods and systems for delivering travel-related information
US7480915B2 (en) * 2002-10-03 2009-01-20 Nokia Corporation WV-IMS relay and interoperability methods
US7734745B2 (en) * 2002-10-24 2010-06-08 International Business Machines Corporation Method and apparatus for maintaining internet domain name data
EP1420572B1 (de) * 2002-11-14 2005-01-19 Alcatel Verfahren zum Aufbau einer Verbindung
JP2004172782A (ja) * 2002-11-19 2004-06-17 Fujitsu Ltd サービス制御ネットワークシステム
US7529839B2 (en) 2003-03-24 2009-05-05 Nokia Corporation Request redirection handling in IMC
US7079632B2 (en) * 2003-08-28 2006-07-18 International Business Machines Corporation Voice mail profiles for dynamic voice mail response
US7460658B2 (en) * 2003-09-16 2008-12-02 Alcatel Lucent Apparatus, and an associated method, for selectably and automatically redirecting a telephonic call to a secondary location
US7417981B2 (en) * 2003-10-15 2008-08-26 Vonage Holdings Corp. Method and apparatus for enhanced Internet Telephony
US7586901B2 (en) * 2003-10-17 2009-09-08 International Business Machines Corporation Data instance routing with configurable user profile
US7418091B1 (en) 2003-10-24 2008-08-26 Nortel Networks Limited Selective call waiting caller ID
JP4576840B2 (ja) * 2003-12-26 2010-11-10 パナソニック株式会社 通信システム及びｉｐ通信装置
US7386111B2 (en) 2004-02-10 2008-06-10 Vonage Network Inc. Method and apparatus for placing a long distance call based on a virtual phone number
US20050198099A1 (en) * 2004-02-24 2005-09-08 Covelight Systems, Inc. Methods, systems and computer program products for monitoring protocol responses for a server application
JP4392336B2 (ja) * 2004-03-25 2009-12-24 パナソニック株式会社 強誘電体容量素子の製造方法
US7860228B1 (en) 2004-03-25 2010-12-28 American Express Travel Related Services Company, Inc. System and method for provisioning telephony services
US20060067505A1 (en) * 2004-09-24 2006-03-30 Wayne Heinmiller Methods and apparatus to control distribution of call information
GB0422275D0 (en) * 2004-10-07 2004-11-10 Nokia Corp Callback services in a communication system
US8275749B2 (en) * 2005-02-07 2012-09-25 Mimosa Systems, Inc. Enterprise server version migration through identity preservation
US8812433B2 (en) 2005-02-07 2014-08-19 Mimosa Systems, Inc. Dynamic bulk-to-brick transformation of data
US8799206B2 (en) 2005-02-07 2014-08-05 Mimosa Systems, Inc. Dynamic bulk-to-brick transformation of data
US8918366B2 (en) 2005-02-07 2014-12-23 Mimosa Systems, Inc. Synthetic full copies of data and dynamic bulk-to-brick transformation
EP1696645A1 (de) * 2005-02-25 2006-08-30 Sony Ericsson Mobile Communications AB Übergabe von Anruferinformation
US8683044B2 (en) 2005-03-16 2014-03-25 Vonage Network Llc Third party call control application program interface
US20060210036A1 (en) 2005-03-16 2006-09-21 Jeffrey Citron System for effecting a telephone call over a computer network without alphanumeric keypad operation
US9450959B2 (en) * 2005-04-13 2016-09-20 Loc-Aid Technologies, Inc. Method and system for utilizing a location-based internetwork gateway
CA2544804A1 (en) * 2005-04-27 2006-10-27 At&T Corp. System and method for eliminating hold time in a telecommunications network
US8254278B2 (en) * 2005-05-23 2012-08-28 Xconnect Global Networks Ltd Efficient address caching for packet telephony services
WO2007010541A2 (en) * 2005-07-20 2007-01-25 Backvon Ltd. Method and system for secure redirection of incoming and outgoing multimedia sessions over a data network
US8798253B2 (en) * 2005-07-29 2014-08-05 Verizon Patent And Licensing Inc. Network routing
CN101361356A (zh) * 2005-11-09 2009-02-04 沃纳格控股公司 用于定制主叫标识的方法和系统
US9008075B2 (en) 2005-12-22 2015-04-14 Genesys Telecommunications Laboratories, Inc. System and methods for improving interaction routing performance
US8917717B2 (en) 2007-02-13 2014-12-23 Vonage Network Llc Method and system for multi-modal communications
EP1989823B1 (de) 2006-02-27 2012-11-07 Vonage Network LLC Verfahren und system für bidrektionalen datentransfer
GB0612433D0 (en) * 2006-06-23 2006-08-02 Ibm Method and system for defining a hierarchical structure
US7599936B2 (en) * 2006-12-22 2009-10-06 Verizon Services Organization Inc. Publication service using web pages and web search engines
US8774165B2 (en) * 2008-05-29 2014-07-08 Michael Socaciu End-to-end internet connections establishment
US8077704B2 (en) * 2009-01-06 2011-12-13 Oracle International Corporation Web service assisted real-time session peering between enterprise VoIP networks via internet
US8238538B2 (en) 2009-05-28 2012-08-07 Comcast Cable Communications, Llc Stateful home phone service
TWI427994B (zh) * 2010-08-23 2014-02-21 Hon Hai Prec Ind Co Ltd 資料模型物件刪除識別裝置及其使用方法
US9124700B1 (en) * 2012-01-30 2015-09-01 Jpmorgan Chase Bank, N.A. System and method for unified calling

Family Cites Families (50)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4659877A (en) 1983-11-16 1987-04-21 Speech Plus, Inc. Verbal computer terminal system
US5351276A (en) 1991-02-11 1994-09-27 Simpact Associates, Inc. Digital/audio interactive communication network
US5247571A (en) * 1992-02-28 1993-09-21 Bell Atlantic Network Services, Inc. Area wide centrex
US5452350A (en) 1992-03-09 1995-09-19 Advantis Subscriber call routing processing system
US5982870A (en) 1992-05-26 1999-11-09 Bell Atlantic Network Services, Inc. Method for concurrently establishing switch redirection for multiple lines of the public telephone network
US5436957A (en) * 1992-12-24 1995-07-25 Bell Atlantic Network Services, Inc. Subscriber control of access restrictions on a plurality of the subscriber's telephone lines
FI92895C (fi) * 1993-04-06 1995-01-10 Nokia Telecommunications Oy Menetelmä ja järjestelmä puhelinkeskuksen käytön ohjaamiseksi tilaajaliittymästä käsin
NZ269342A (en) 1993-06-28 1998-05-27 Bellsouth Corp Mediating message traffic across advanced intelligent network interfaces
US5703940A (en) 1993-11-12 1997-12-30 Intervoice, Inc. Method and apparatus for delivering calling services
US5509060A (en) 1993-11-19 1996-04-16 At&T Corp. Network-accessible intelligent telephone service
US5423003A (en) 1994-03-03 1995-06-06 Geonet Limited L.P. System for managing network computer applications
US5602846A (en) * 1994-04-08 1997-02-11 Paradyne Corporation Simultaneous voice and data call establishment using a simultaneous voice and data modem pool and private branch exchange facilities
US5742905A (en) * 1994-09-19 1998-04-21 Bell Communications Research, Inc. Personal communications internetworking
CA2139081C (en) 1994-12-23 1999-02-02 Alastair Gordon Unified messaging system and method
ES2194038T3 (es) 1994-12-29 2003-11-16 Siemens Ag Procedimiento y dispositivo para la utilizacion de diferentes redes de comunicaciones a traves de un abonado.
US5873077A (en) 1995-01-13 1999-02-16 Ricoh Corporation Method and apparatus for searching for and retrieving documents using a facsimile machine
US5546452A (en) 1995-03-02 1996-08-13 Geotel Communications Corp. Communications system using a central controller to control at least one network and agent system
US5635980A (en) * 1995-04-04 1997-06-03 Bell Communications Research, Inc. System and method for customer premises broadband interface with on-hook alerting
CA2173304C (en) 1995-04-21 2003-04-29 Anthony J. Dezonno Method and system for establishing voice communications using a computer network
FI104869B (fi) 1995-05-24 2000-04-14 Ericsson Telefon Ab L M Menetelmä verkkojen välisen puheyhteyden muodostamiseksi ja älyverkkopalvelu
US5708780A (en) 1995-06-07 1998-01-13 Open Market, Inc. Internet server access control and monitoring systems
US5818836A (en) * 1995-08-09 1998-10-06 Duval; Stephen C. Method and apparatus for anonymous voice communication using an online data service
US5943399A (en) * 1995-09-29 1999-08-24 Northern Telecom Limited Methods and apparatus for providing communications to telecommunications terminals
FI955093A0 (fi) 1995-10-25 1995-10-25 Finland Telecom Oy Datornaetelettelefonsystem och foerfarande foer styrning av det
US5799317A (en) 1995-11-08 1998-08-25 Mci Communications Corporation Data management system for a telecommunications signaling system 7(SS#7)
US5812656A (en) 1995-11-15 1998-09-22 Lucent Technologies, Inc. System for providing prioritized connections in a public switched network
US5802146A (en) 1995-11-22 1998-09-01 Bell Atlantic Network Services, Inc. Maintenance operations console for an advanced intelligent network
US5805587A (en) 1995-11-27 1998-09-08 At&T Corp. Call notification feature for a telephone line connected to the internet
US5838682A (en) 1995-11-28 1998-11-17 Bell Atlantic Network Services, Inc. Method and apparatus for establishing communications with a remote node on a switched network based on hypertext dialing information received from a packet network
PT875110E (pt) 1996-01-15 2002-11-29 Interactive Telecom Inc Metodo para proporcionar mensagens de notificacao e de controlo de chamadas de voz atraves de um caminho de dados
US5751961A (en) 1996-01-31 1998-05-12 Bell Communications Research, Inc. Integrated internet system for translating logical addresses of internet documents to physical addresses using integrated service control point
US5953392A (en) 1996-03-01 1999-09-14 Netphonic Communications, Inc. Method and apparatus for telephonically accessing and navigating the internet
US6125113A (en) 1996-04-18 2000-09-26 Bell Atlantic Network Services, Inc. Internet telephone service
US6021126A (en) 1996-06-26 2000-02-01 Bell Atlantic Network Services, Inc. Telecommunication number portability
US6014379A (en) 1996-06-26 2000-01-11 Bell Atlantic Network Services, Inc. Telecommunications custom calling services
US6115737A (en) 1996-07-24 2000-09-05 Telcordia Technologies, Inc. System and method for accessing customer contact services over a network
US5799063A (en) 1996-08-15 1998-08-25 Talk Web Inc. Communication system and method of providing access to pre-recorded audio messages via the Internet
US5838768A (en) 1996-10-03 1998-11-17 Telefonaktiebolaget L M Ericsson System and method for controlled media conversion in an intelligent network
US5917817A (en) * 1996-12-06 1999-06-29 International Business Machines Corporation User invocation of services in public switched telephone network via parallel data networks
US6014437A (en) 1997-02-03 2000-01-11 International Business Machines Corporation Multi service platform architecture for telephone networks
US5870454A (en) 1997-04-01 1999-02-09 Telefonaktiebolaget L M Ericsson Telecommunications speech/text conversion and message delivery system
US6067516A (en) 1997-05-09 2000-05-23 Siemens Information Speech and text messaging system with distributed speech recognition and speaker database transfers
US5958016A (en) * 1997-07-13 1999-09-28 Bell Atlantic Network Services, Inc. Internet-web link for access to intelligent network service control
US6084956A (en) 1997-09-19 2000-07-04 Nortel Networks Corporation SS7 mediation for data network call setup and services interworking
US6029203A (en) 1997-09-26 2000-02-22 3Com Corporation Apparatus and methods for use therein for an ISDN LAN modem that provides enhanced network activity
US6023724A (en) 1997-09-26 2000-02-08 3Com Corporation Apparatus and methods for use therein for an ISDN LAN modem that displays fault information to local hosts through interception of host DNS request messages
US5966427A (en) 1997-09-30 1999-10-12 Siemens Information Apparatus and method for troubleshooting internet protocol telephony networks
US6026441A (en) 1997-12-16 2000-02-15 At&T Corporation Method for establishing communication on the internet with a client having a dynamically assigned IP address
US6097804A (en) 1997-12-23 2000-08-01 Bell Canada Method and system for completing a voice connection between first and second voice terminals in a switched telephone network
US6141413A (en) 1999-03-15 2000-10-31 American Tel-A-System, Inc. Telephone number/Web page look-up apparatus and method

Also Published As

Publication number Publication date
AU704503B2 (en) 1999-04-22
DE69635522T2 (de) 2006-07-06
NZ324340A (en) 1998-11-25
WO1997022210A2 (en) 1997-06-19
WO1997022210A3 (en) 1997-07-17
CN1208536A (zh) 1999-02-17
EP0867091B1 (de) 2005-04-13
ATE311728T1 (de) 2005-12-15
AU704569B2 (en) 1999-04-29
CA2238501A1 (en) 1997-06-19
EP1519593A2 (de) 2005-03-30
JP2000516406A (ja) 2000-12-05
NO982512L (no) 1998-08-05
DE69635522D1 (de) 2006-01-05
WO1997022209A1 (en) 1997-06-19
NO982510D0 (no) 1998-06-02
NO982510L (no) 1998-08-05
US6798771B1 (en) 2004-09-28
JP3742108B2 (ja) 2006-02-01
EP1519593A3 (de) 2005-11-23
ATE293338T1 (de) 2005-04-15
US6282281B1 (en) 2001-08-28
CA2239493A1 (en) 1997-06-19
AU1104097A (en) 1997-07-03
DE69634608D1 (de) 2005-05-19
NO982512D0 (no) 1998-06-02
AU1181397A (en) 1997-07-03
EP0867091A2 (de) 1998-09-30
EP0867094A1 (de) 1998-09-30
EP0867094B1 (de) 2005-11-30

Similar Documents

Publication Publication Date Title
DE69634608T2 (de) Verbindungsaufbaudurchgang für ein fernmeldesystem
DE69634854T2 (de) Verfahren zum zugreifen auf dienstmittelgegenstande für anwendung in einem fernmeldesystem
DE69633205T2 (de) Zugriff zu Kommunikationsdateien
DE69635386T2 (de) Verfahren zum Bereitstellen von Telekommunikationsdiensten
DE69921169T2 (de) Intelligentes netz
DE602005002150T2 (de) Verfahren und Vorrichtung zur Bereitstellung von universellen Fernmelderelaisdiensten
DE69735355T2 (de) Nichtgeographische telefonnummerübertragbarkeit von intelligenten netzwerkdiensten
DE60105378T2 (de) System und Verfahren zur Lieferung von Profilinformationen eines Anrufers
DE69735450T2 (de) Verfahren zum Errichten einer Verbindung über ein Rechnernetzwerk
DE69733762T2 (de) Fernmeldenetz mit teilnehmernummerverschiebbarkeit
DE69435052T2 (de) Internetzsystem für persönliche Übertragungsdienste
DE69633230T2 (de) Verfahren und system zur herstellung einer sprachverbindung in verschiedenen netzen
DE69833035T2 (de) Verfahren und vorrichtung zum anbieten von netzwerkspezifischen mobilen diensten
DE69828976T2 (de) Kommunikationssystem mit mitteln zur übertragung von internetadressen über kurzmitteilungen
DE69831650T2 (de) Verfahren und System für Sprachanruf durch Benutzung von Informationen die aus einer ausführenden Anwendung auf einem Rechnersytem abgerufen wurden
DE69827040T2 (de) Verfahren und anordnung zum aufbau einer gesprächsverbindung in einem geschalteten telefonnetz
DE69735720T2 (de) Verfahren, system und vorrichtung zur überwachung von teilnehmerbetribsamkeit
DE69932088T2 (de) Verfahren und mittel zum bereitstellen von diensten in einem telekommunikationsnetz
US8204046B2 (en) Method and apparatus for accessing service resource items that are for use in a telecommunications system
DE60034329T2 (de) Verfahren und system zur leitweglenkung von mit portierten teilnehmern assozierten signalisierungsnachrichten in einem kommunikationsnetzwerk
DE60117713T2 (de) Verfahren zum transferieren von teilnehmerdaten zwischen verschiedenen servern eines telekommunikationsnetzes
DE60023207T2 (de) Vorrichtung und Verfahren zur Umleitung von Anrufen zu einem Internet Service Provider über den nächsten Zugangspunkt in einem Telefonnetzwerk
DE69729159T2 (de) Kompatibilität zwischen einem Fernsprechdienst mit Anbieter und einem ISDN Anruferidentifikationsdienst
DE60119849T2 (de) Telekommunikationssystem un Verfahren zur Herstelung von mindestens einem neuen Numerierungsplan
DE69834576T2 (de) Fernumfragedienste für ein fortgeschrittenes intelligentes netz

Legal Events

Date Code Title Description
8327 Change in the person/name/address of the patent owner

Owner name: HEWLETT-PACKARD DEVELOPMENT CO., L.P., HOUSTON, TE

8364 No opposition during term of opposition