DE69634854T2 - Verfahren zum zugreifen auf dienstmittelgegenstande für anwendung in einem fernmeldesystem - Google Patents

Verfahren zum zugreifen auf dienstmittelgegenstande für anwendung in einem fernmeldesystem Download PDF

Info

Publication number
DE69634854T2
DE69634854T2 DE69634854T DE69634854T DE69634854T2 DE 69634854 T2 DE69634854 T2 DE 69634854T2 DE 69634854 T DE69634854 T DE 69634854T DE 69634854 T DE69634854 T DE 69634854T DE 69634854 T2 DE69634854 T2 DE 69634854T2
Authority
DE
Germany
Prior art keywords
service
telephone
server
uri
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
DE69634854T
Other languages
English (en)
Other versions
DE69634854D1 (de
Inventor
Colin Low
Franklin Andrew SEABORNE
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 GBGB9603582.9A external-priority patent/GB9603582D0/en
Application filed by Hewlett Packard Development Co LP filed Critical Hewlett Packard Development Co LP
Publication of DE69634854D1 publication Critical patent/DE69634854D1/de
Application granted granted Critical
Publication of DE69634854T2 publication Critical patent/DE69634854T2/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/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
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2854—Wide area networks, e.g. public data networks
    • H04L12/2856—Access arrangements, e.g. Internet access
    • 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/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
    • 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
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/487—Arrangements for providing information services, e.g. recorded voice services or time announcements
    • H04M3/493—Interactive information services, e.g. directory enquiries ; Arrangements therefor, e.g. interactive voice response [IVR] systems or voice portals
    • H04M3/4938—Interactive information services, e.g. directory enquiries ; Arrangements therefor, e.g. interactive voice response [IVR] systems or voice portals comprising a voice browser which renders and interprets, e.g. VoiceXML
    • 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
    • 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
    • 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/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/13097—Numbering, addressing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/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/13176—Common channel signaling, CCS7
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/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

  • Gebiet der Erfindung
  • Die vorliegende Erfindung bezieht sich auf ein Verfahren zum Zugreifen auf Dienstressourcenelemente, die für die Verwendung beim Einrichten von Trägerkanälen durch ein Wähltelekommunikationssystem bestimmt sind.
  • 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 typischer 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.
  • In letzter Zeit gab es Vorschläge zum Erhöhen der Flexibilität von öffentlichen IN-Systemen. Die folgenden Dokumente beschrieben eine Anzahl solcher Vorschläge:
    „Method and system for controlling the operation of a telephone exchange from a subscriber connection" WO/9423523 Nokia 13.10.94
  • Dieses Dokument beschreibt, wie eine SCP mit Befehlsmakros über eine Teilenehmerverbindung versehen werden kann.
  • „Mediation of Open Advanced Intelligent Network Interface for Public switched Telephone Network" US 5,438,568 Bellsouth Corporation 1.8.95
  • Eine Mediation-SCP überwacht alle Mitteilungen zu und von dritten Dienstlogikprogrammen, die beispielsweise auf einer dritten SCP laufen.
  • „Customers in Driver's Seat: Private Intelligent Network Control Point" M. Sevcik; R. Lueder (Siemens) 23.4.95 ISS Symposium
  • Dieses Dokument 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 als Ressource auf einem privaten TCP/IP-LAN gezeigt, zum Zugreifen auf Datenbankinformationen.
  • „Distributed intelligence and data in public and private networks" R. P. Swale & D. R. Chesterton BT Technology Journal, 13 (1995) April Nr. 2
  • Dieses Dokument erörtert die erste und dritte CTI, wobei das letztere als „privates IN" bezeichnet wird. Dann wird ein Vergleich zwischen privatem und öffentlichem IN durchgeführt, wobei angemerkt wird, dass dieselben häufig komplementär sind. Schließlich werden Möglichkeiten für eine Verbindung von privatem und öffentlichem IN erörtert, einschließlich dem Zugreifen auf eine private Datenbank durch eine Öffentliches-Netzwerk-SCP.
  • 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 desselben 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än dig 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 ei nen 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 an deren 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 leistungsstarkes 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. Beispielsweise unterstützt Netscape 2.0 HTML 3.0 Ja va und LiveScript (wobei das Letztere eine Netscape-eigene Skripting-Sprache ist).
  • 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 ei nen 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 Sprachanruf 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.
  • Aus dem vorhergehenden ist zu sehen, daß die gegenwärtige kooperative Verwendung von Internet und Telephonsystem auf einem sehr einfachen Pegel stattfindet.
  • Es ist eine Aufgabe der vorliegenden Erfindung, ein Verfahren zum Zugreifen auf ein Dienstressourcenelement über ein Kommunikationsnetzwerk zu schaffen, das die Integration des PSTN und WWW ermöglicht.
  • Zusammenfassung der Erfindung
  • Gemäß der vorliegenden Erfindung ist ein Verfahren vorgesehen, zum Zugreifen auf Dienstressourcenelemente für die Verwendung bezüglich des Einrichtens von Trägerkanälen durch ein Wähltelekommunikationssystem, wobei das Verfahren folgende Schritte umfasst:
    • (a) – Versehen zumindest eines Servers, der mit einem Computernetzwerk verbunden ist, mit einer Mehrzahl von Dienstressourcenelementen, die danach auf dem Computernetzwerk lokalisiert werden können durch entsprechende bekannte URIs, wobei sich das Computernetzwerk von dem Telekommunikationssystem logisch unterscheidet, und die Dienstressourcenelemente sich auf die Einrichtungssteuerung für Trägerkanäle durch das Telekommunikationssystem beziehen, wobei jedes der Dienstressourcenelemente einem jeweiligen vorbestimmten Code zugeordnet ist, wobei sich die vorbestimmten Codes von den URIs unterscheiden und Endpunktentitäten für die Trägerkanäle identifizieren;
    • (b) – Bereitstellen einer Abbildung zwischen jedem vorbestimmten Code und dem URI des Dienstressourcenelements, der dem vorbestimmten Code zugeordnet ist; und
    • (c) – Verwenden des vorbestimmten Codes zum Zugreifen auf ein entsprechendes Dienstressourcenelement durch Verwenden der Abbildung zum Bestimmen des URI, der diesem Ressourcenelement entspricht, und anschließend Verwenden dieses URI zum Zugreifen auf das Dienstressourcenelement über das Computernetzwerk.
  • Bei einem Ausführungsbeispiel können zumindest einige der URIs von ihren entsprechenden vorbestimmten Codes abgelei tet werden, durch Manipulation gemäß einer Funktion, die durch die Abbildung spezifiziert wird. Bei einem weiteren Ausführungsbeispiel können zumindest einige der URIs von ihren entsprechenden vorbestimmten Codes abgeleitet werden, durch Nachschlagen in einer Zuordnungstabelle, die die vorbestimmten Codes und URIs gemäß der Abbildung zuordnet. Diese Zuordnungstabelle kann vorteilhafterweise auf zumindest einem Datenbankserver gehalten werden, der mit dem Computernetzwerk verbunden ist, wobei Schritt (c) das Zugreifen auf den Datenbankserver über das Computernetzwerk umfasst, um den URI zu bestimmen, der dem vorbestimmten Code entspricht. Vorzugsweise wird der zumindest eine Datenbankserver durch ein verteiltes DNS-Typ-Datenbanksystem geliefert, in dem die URIs in Aufzeichnungen gehalten werden, die jeweiligen Namen zugeordnet sind, die hierin als Domainnamen bezeichnet werden, durch die die Aufzeichnungen wiedergewonnen werden können. In diesem Fall umfasst Schritt (c) das Übersetzen des vorbestimmten Codes in einen entsprechenden Domainnamen und das Verwenden dieses Domainnamens zum Wiedergewinnen des URI des angeforderten Dienstressourcenelements von dem verteilten DNS-Typ-Datenbanksystem.
  • Mehr als ein Dienstressourcenelement kann an dem gleichen URI angeordnet sein; in diesem Fall umfassen die vorbestimmten Codes dieser Dienstressourcenelemente jeweilige Relative-Ressourcen-Identifizierer-Werte, die an dem Server, der die Dienstressourcenelemente hält, verwendet werden können, um das angeforderte Ressourcenelement von den Dienstressourcenelementen an dem gleichen URI zu identifizieren.
  • Das Telekommunikationssystem kann ein Telefonsystem sein, wobei jeder der vorbestimmten Codes entweder die Telefonnummer der anrufenden Partei oder die Telefonnummer der angerufenen Partei ist (diese Nummern können entweder die Nummern spezifischer Telefone oder persönliche Nummern sein). Bei einem bevorzugten Ausführungsbeispiel, bei dem zumindest einige der vorbestimmten Codes Telefonnummern der angerufenen Partei sind, sind die entsprechenden Dienstressourcenelemente die aktuellen Telefonnummern der angerufenen Parteien.
  • Bezüglich der Art der Dienstressourcen können diese im Allgemeinen die folgenden Typen aufweise:
    • – eine Dienstlogik, die auf das Zugreifen hin durch den entsprechenden Server auszuführen ist, mit dem Ergebnis, dass diese Ausführung zu der zugreifenden Entität zurückgesendet wird;
    • – Herunterladbare Dienstdaten, die auf das Zugreifen hin zu der zugreifenden Entität herunterzuladen sind;
    • – Herunterladbare Dienstlogik, die auf das Zugreifen hin zu der zugreifenden Entität herunterzuladen ist, für die Ausführung durch dieselbe.
  • Wo im Vorhergehenden auf URIs verwiesen wird, sind diese URIs URLs und/oder URNs. Ferner sind die erwähnten Server vorzugsweise HTTP-Server.
  • Es ist klar, dass die obige Bezugnahme darauf, dass das Computernetzwerk von dem Telekommunikationssystem logisch getrennt ist, nicht implizieren soll, dass es eine physikalische Trennung der beiden gibt – stattdessen gibt es häufig eine gemeinsame Verwendung der gleichen physikalischen Infrastruktur. Ferner verwenden nicht nur viele Trägerkanäle, die in dem Telekommunikationssystem eingerichtet sind, das gleiche Übertragungsmedium gemeinsam, wie z. B. das Computernetzwerk, sondern ein solcher Trägerkanal kann auch als eine Leitung für Verkehr über das Computernetzwerk dienen. Die Absicht, zu erfordern, dass das Computernetzwerk logisch getrennt ist von dem Telekommunikationssystem soll Computernetzwerke ausschließen, die der Verwaltung oder Ü berwachung des Trägernetzwerks zugewiesen sind und effektiv Teil des Telekommunikationssystems selbst bilden.
  • Vorzugsweise ist das Computernetzwerk allgemein zugreifbar für Benutzer des Telekommunikationssystems, da dies für Benutzer eine Anzahl von Vorteilen schafft, die nachfolgend offensichtlich werden. Der Begriff „allgemein zugreifbar" sollte nicht bedeuten, dass alle Benutzer des Telekommunikationssystems einen solchen Zugriff zu dem Computernetzwerk haben oder einen solchen Zugriff bekommen können, sondern sollte stattdessen so gesehen werden, dass es bedeutet, dass ein wesentlicher Anteil dieser Benutzer Zugriff zu dem Computernetzwerk haben oder erhalten können.
  • Beispielsweise ist bei einem bevorzugten Ausführungsbeispiel der Erfindung das Computernetzwerk, das allgemein zugreifbar ist für Benutzer des Telekommunikationssystems, aber logisch von demselben getrennt ist, das Internet, und das Telekommunikationssystem ist ein öffentliches Fernmeldesystem. Bei einem weiteren Ausführungsbeispiel ist das Telekommunikationssystem ein privates System, das eine PABX umfasst, und das Computernetzwerk ist ein LAN.
  • 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 vorbe stimmten 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;
  • 16 ein Diagramm, das den Gesamtbetrieb einer Anordnung zeigt, bei der ein Anrufverbindungsaufbau-Netzübergang 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öglichen, 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 Telephonsei ten 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 wei tere 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 weiterer 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 bil det (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 elementare 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 Unterverzeichnis, 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 wiederzuge winnen 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 herunterladba re 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 leis tungsstarke 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 Benutzerauswahl 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 Dienst- ressourcen 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 planiert 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 Benutzer ü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 Planieren 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 (beispielsweise 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ählfunktionalitä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 Telephon seite 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 Dienstlogik, 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 Num mer, 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 au tomatisiert 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
  • 16 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.
  • 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.
  • Wenn B's Telephon besetzt war, kann ein beliebiges der vorher beschriebenen Szenarien folgen.
  • 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.
  • 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 Sprachanruf 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 Dritte-Partei-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 am Endgerät 53 präsentiert und dann zurück zu dem Server 51 versendet wird).
  • Es sei ferner 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-Üntersystem 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 Anfrage steuersystem ü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 aufnehmen, 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 Tele phon 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 Domainnamenform 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äu fig ä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 (17)

  1. Ein Verfahren zum Zugreifen auf Dienstressourcenelemente (49) für die Verwendung bezüglich des Einrichtens von Trägerkanälen (60) durch ein Wähltelekommunikationssystem, wobei das Verfahren folgende Schritte umfasst: (a) – Versehen zumindest eines Servers (51), der mit einem Computernetzwerk (50) verbunden ist, mit einer Mehrzahl von Dienstressourcenelementen (49), die danach auf dem Computernetzwerk lokalisiert werden können durch entsprechende bekannte URIs, wobei sich das Computernetzwerk von dem Telekommunikationssystem logisch unterscheidet, und die Dienstressourcenelemente (49) sich auf die Einrichtungssteuerung für Trägerkanäle (60) durch das Telekommunikationssystem beziehen, wobei jedes der Dienstressourcenelemente einem jeweiligen vorbestimmten Code (54) zugeordnet ist, wobei sich die vorbestimmten Codes von den URIs unterscheiden und Endpunktentitäten für die Trägerkanäle identifizieren; (b) – Bereitstellen einer Abbildung (55) zwischen jedem vorbestimmten Code (54) und dem URI des Dienstressourcenelements (49), der dem vorbestimmten Code zugeordnet ist; und (c) – Verwenden des vorbestimmten Codes (54) zum Zugreifen auf ein entsprechendes Dienstressourcenelement durch Verwenden der Abbildung (55) zum Bestimmen des URI, der diesem Res sourcenelement entspricht, und anschließendes Verwenden dieses URI zum Zugreifen auf das Dienstressourcenelement (49) über das Computernetzwerk (50).
  2. Ein Verfahren gemäß Anspruch 1, bei dem zumindest einige der URIs von ihren entsprechenden vorbestimmten Codes (54) abgeleitet werden können, durch Manipulation gemäß einer Funktion, die durch die Abbildung spezifiziert wird.
  3. Ein Verfahren gemäß Anspruch 1, bei dem zumindest einige der URIs von ihren entsprechenden vorbestimmten Codes (54) abgeleitet werden können, durch Nachschlagen in einer Zuordnungstabelle, die die vorbestimmten Codes und URIs gemäß der Abbildung zuordnet.
  4. Ein Verfahren gemäß Anspruch 3, bei dem die Zuordnungstabelle auf zumindest einem Datenbankserver gehalten wird, der mit dem Computernetzwerk verbunden ist, wobei Schritt (c) das Zugreifen auf den Datenbankserver über das Computernetzwerk (50) umfasst, um den URI zu bestimmen, der dem vorbestimmten Code (54) entspricht.
  5. Ein Verfahren gemäß Anspruch 4, bei dem der zumindest eine Datenbankserver durch ein verteiltes DNS-Typ-Datenbanksystem geliefert wird, indem die URIs in Aufzeichnungen gehalten werden, die jeweiligen Namen zugeordnet sind, die hierin als Domainnamen bezeichnet werden, durch die die Aufzeichnungen wiedergewonnen werden können, wobei Schritt (c) das Übersetzen des vorbestimmten Codes (54) in einen entsprechenden Domainnamen umfasst, und das Verwenden dieses Domainnamens zum Wiedergewinnen des URI des angeforderten Dienstressourcenelements (49) von dem verteilten DNS-Typ-Datenbanksystem.
  6. Ein Verfahren gemäß Anspruch 1, bei dem zumindest zwei der Dienstressourcenelemente (49) an dem gleichen URI angeordnet sind, wobei die vorbestimmten Codes (54) dieser Dienstressourcenelemente jeweilige Relative-Ressourcen-Identifizierer-Werte umfassen, die an dem Server (51), der die Dienstressourcenelemente hält, verwendet werden, um das erforderliche Ressourcenelement unter den Dienstressourcenelemente an dem gleichen URI zu identifizieren.
  7. Ein Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem das Wähltelekommunikationssystem ein Telefonsystem ist und die vorbestimmten Codes Nummern von zumindest einer der folgenden Kategorien umfassen: – die Telefonnummer der anrufenden Partei; – die Telefonnummer der angerufenen Partei.
  8. Ein Verfahren gemäß Anspruch 1, bei dem das Wähltelekommunikationssystem ein Telefonsystem ist, wobei zumindest einige der vorbestimmten Codes (54) Telefonnummern der angerufenen Partei sind und dazu dienen, Dienstressourcenelemente (49) wiederzugewinnen, die die aktuellen Telefonnummern der angerufenen Parteien sind.
  9. Ein Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem zumindest eines der Dienstressourcenelemente (49) eine Dienstlogik ist, die durch den entsprechenden Server (51) ausgeführt wird, auf das Zugreifen hin, wobei das Ergebnis dieser Ausführung zu der zugreifenden Entität zurückgesendet wird, für die Verwendung bei der Trägerkanaleinrichtungssteuerung.
  10. Ein Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem zumindest eines der Dienstressourcenelemente (49) herunterladbare Dienstdaten sind, die auf das Zugreifen hin zu der zugreifenden Entität heruntergeladen werden, für die Verwendung durch dieselbe in der Trägerkanaleinrichtungssteuerung.
  11. Ein Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem das zumindest eine Dienstressourcenelement (49) eine herunterladbare Dienstlogik ist, die auf das Zugreifen hin heruntergeladen wird zu der zugreifenden Entität für die Ausführung bei der Trägerkanaleinrichtungssteuerung.
  12. Ein Verfahren gemäß Anspruch 1, bei dem das Computernetzwerk (50) für Benutzer des Telekommunikationssystems allgemein zugreifbar ist.
  13. Ein Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem das Computernetzwerk (50) das Internet ist.
  14. Ein Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem das Wähltelekommunikationssystem ein PSTN ist.
  15. Ein Verfahren gemäß einem der Ansprüche 1 bis 13, bei dem das Telekommunikationssystem ein privates System ist, das einen PABX umfasst, dem das Dienststeuersystem (42) zugeordnet ist, und wobei das Computernetzwerk (50) ein LAN ist.
  16. Ein Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem die URIs URLs und/oder URNs sind und der Server ein HTTP-Server ist.
  17. Ein Verfahren gemäß Anspruch 6, bei dem: – der zumindest eine Server (51) ein HTTP-Server ist; – der URI, an dem die zumindest zwei Dienstressourcenelemente, die an dem gleichen URI angeordnet sind, angeordnet sind, ein URL ist; – das Telekommunikationssystem ein Telefonsystem ist; – die vorbestimmten Codes (54) persönliche Nummern sind, die einzelnen Telefonnutzern zugeordnet sind; und – die Dienstressourcenelemente (49) aktuelle Telefonnummern sind, wo die einzelnen Telefonnutzer erreicht werden können.
DE69634854T 1995-12-11 1996-12-11 Verfahren zum zugreifen auf dienstmittelgegenstande für anwendung in einem fernmeldesystem Expired - Lifetime DE69634854T2 (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
GBGB9603582.9A GB9603582D0 (en) 1996-02-20 1996-02-20 Method of accessing service resource items that are for use in a telecommunications system
GB9603582 1996-02-20
PCT/GB1996/003055 WO1997022212A1 (en) 1995-12-11 1996-12-11 Method of accessing service resource items that are for use in a telecommunications system

Publications (2)

Publication Number Publication Date
DE69634854D1 DE69634854D1 (de) 2005-07-21
DE69634854T2 true DE69634854T2 (de) 2006-06-08

Family

ID=27236966

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69634854T Expired - Lifetime DE69634854T2 (de) 1995-12-11 1996-12-11 Verfahren zum zugreifen auf dienstmittelgegenstande für anwendung in einem fernmeldesystem

Country Status (10)

Country Link
US (1) US6466570B1 (de)
EP (1) EP0867093B1 (de)
JP (1) JP2000516408A (de)
CN (1) CN1104142C (de)
AT (1) ATE298172T1 (de)
AU (1) AU704385B2 (de)
CA (1) CA2239408A1 (de)
DE (1) DE69634854T2 (de)
NO (1) NO982514L (de)
WO (1) WO1997022212A1 (de)

Families Citing this family (91)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
US5905959A (en) * 1996-07-16 1999-05-18 At&T Corp System and method for updating network routing using integrated internet/two-way paging
JP3084681B2 (ja) * 1996-12-06 2000-09-04 財団法人流通システム開発センタ− 統合情報通信システム
US5917900A (en) * 1997-02-07 1999-06-29 Mci Communications Corporation Remote data gateway
US5946684A (en) 1997-02-18 1999-08-31 Ameritech Corporation Method and system for providing computer-network related information about a calling party
US5978806A (en) * 1997-02-18 1999-11-02 Ameritech Corporation Method and apparatus for communicating information about a called party to a calling party
EP1235415A3 (de) * 1997-02-20 2006-01-04 Hewlett-Packard Company, A Delaware Corporation Bereitstellung von Diensten in einem Telekommunikationsnetz
US6278704B1 (en) * 1997-04-04 2001-08-21 International Business Machines Corporation Extended telephone services via telephone lines shared for standard telephony and internet access
NL1005982C2 (nl) * 1997-05-06 1998-11-09 Koninkl Kpn Nv Gebruikersinterface voor een telecommunicatiesysteem.
CN1152535C (zh) * 1997-06-30 2004-06-02 西门子信息通讯网络公司 通信系统
US6304566B1 (en) * 1997-06-30 2001-10-16 Siemens Telecom Networks Telecommunication system
US6385195B2 (en) 1997-07-21 2002-05-07 Telefonaktiebolaget L M Ericsson (Publ) Enhanced interworking function for interfacing digital cellular voice and fax protocols and internet protocols
WO1999005590A2 (en) * 1997-07-25 1999-02-04 Starvox, Inc. Apparatus and method for integrated voice gateway
NZ503639A (en) * 1997-10-22 2001-12-21 British Telecomm Communications network node
US6446128B1 (en) * 1997-12-01 2002-09-03 Netselector, Inc. Site access via intervening control layer
US6208642B1 (en) 1997-12-19 2001-03-27 Ericsson Inc Architecture independent application invocation over a telephony network
GB2334646B (en) * 1998-02-19 2003-02-19 Leighton Hanna King Dial on demand internet web site
US6553420B1 (en) * 1998-03-13 2003-04-22 Massachusetts Institute Of Technology Method and apparatus for distributing requests among a plurality of resources
US6430618B1 (en) 1998-03-13 2002-08-06 Massachusetts Institute Of Technology Method and apparatus for distributing requests among a plurality of resources
DE19810869A1 (de) * 1998-03-13 1999-09-16 Cit Alcatel Verfahren zur Verwaltung von Telekommunikationsdienst-Daten eines Teilnehmers sowie Server und Vermittlungsstelle hierzu
US6501750B1 (en) * 1998-06-05 2002-12-31 Siemens Information & Communication Networks, Inc. Method and device for device-to-device enablement of camp-on capability
US6411604B1 (en) 1998-06-05 2002-06-25 Inet Technologies, Inc. System and method for correlating transaction messages in a communications network
US6529594B1 (en) 1998-06-05 2003-03-04 Inet Technologies, Inc. System and method for generating quality of service statistics for an international communications network
US6778544B1 (en) * 1998-11-18 2004-08-17 Nortel Networks Limited Method and system for redirecting calls
US6560640B2 (en) 1999-01-22 2003-05-06 Openwave Systems, Inc. Remote bookmarking for wireless client devices
US6981023B1 (en) 1999-03-09 2005-12-27 Michael Hamilton Message routing
WO2000054468A2 (en) * 1999-03-10 2000-09-14 Inet Technologies, Inc. System and method for providing interoperability between circuit-switched and packet networks
US20020009071A1 (en) * 1999-05-06 2002-01-24 Erez Yaary Communication system and a method for performing telephone calls
US6963928B1 (en) * 1999-05-27 2005-11-08 Bagley David T Systems and methods for communicating across various communication applications using single address strings
US7187662B1 (en) 1999-08-11 2007-03-06 Klingman Edwin E Table driven call distribution system for local and remote agents
US7028298B1 (en) * 1999-09-10 2006-04-11 Sun Microsystems, Inc. Apparatus and methods for managing resource usage
KR100644579B1 (ko) * 1999-10-26 2006-11-13 삼성전자주식회사 인터넷에서 실시간 음성 및 영상 통신방법 및 그 통신장치
US7039722B1 (en) * 1999-11-12 2006-05-02 Fuisz Richard C Method and apparatus for translating web addresses and using numerically entered web addresses
US6615231B1 (en) * 1999-12-15 2003-09-02 Microsoft Corporation System and method for directing requests to specific processing
US6836478B1 (en) * 1999-12-30 2004-12-28 At&T Corp. Call hold with reminder and information push
US7180889B1 (en) 1999-12-30 2007-02-20 At&T Corp. Personal control of address assignment and greeting options for multiple BRG ports
US6775267B1 (en) 1999-12-30 2004-08-10 At&T Corp Method for billing IP broadband subscribers
US6937713B1 (en) 1999-12-30 2005-08-30 At&T Corp. IP call forward profile
US6826173B1 (en) 1999-12-30 2004-11-30 At&T Corp. Enhanced subscriber IP alerting
US6996072B1 (en) * 2000-01-19 2006-02-07 The Phonepages Of Sweden Ab Method and apparatus for exchange of information in a communication network
US9781257B2 (en) 2000-01-19 2017-10-03 Sony Mobile Communications Ab Technique for obtaining caller-originated alert signals in IP-based communication sessions
US8400946B2 (en) 2000-01-19 2013-03-19 Sony Corporation System and method for sharing common location-related information between communication devices
US8548010B2 (en) 2000-01-19 2013-10-01 Sony Corporation Method and apparatus for event-based synchronization of information between communication devices
WO2001059999A1 (en) * 2000-02-11 2001-08-16 Convergent Networks, Inc. Service level executable environment for integrated pstn and ip networks and call processing language therefor
US6643707B1 (en) * 2000-02-14 2003-11-04 General Instrument Corporation Method and apparatus for defining, managing and distributing broadcast names
US6731630B1 (en) * 2000-02-29 2004-05-04 3Com Corporation Flexible dial plan for a data network telephony system
US20030048883A1 (en) * 2000-03-31 2003-03-13 Warren Anthony H Integrated pstn-ip answering service
GB0008383D0 (en) * 2000-04-05 2000-05-24 Sontora Limited System and method for providing an internet audio stream to a wap mobile telephone or the like over a computer nrework
US7974277B2 (en) * 2000-05-25 2011-07-05 Cisco Technology, Inc. System and method for routing calls
JP2001339762A (ja) * 2000-05-29 2001-12-07 Mitsubishi Electric Corp 通信システム及び通信方法及び携帯電話
EP1168735A1 (de) * 2000-06-30 2002-01-02 BRITISH TELECOMMUNICATIONS public limited company Verfahren zur Feststellung der Qualität einer Sprachkommunikation über Paketnetze
US6826755B1 (en) * 2000-06-30 2004-11-30 Microsoft Corporation Systems and methods for switching internet contexts without process shutdown
GB0016756D0 (en) * 2000-07-07 2000-08-30 Hewlett Packard Co Use of local equipment by mobile entity
US6826403B1 (en) 2000-09-12 2004-11-30 Phonepages Of Sweden Ab Method and system for identifying a user
DE10053717B4 (de) * 2000-10-28 2004-05-19 Web.De Ag Verfahren und Vorrichtung zum Aufbau einer Telefonverbindung über eine Internet-Telefonieanwendung
AU2002223887A1 (en) * 2000-11-28 2002-06-11 Nortel Networks Limited A component for processing ip telephony calls
US6601065B1 (en) 2000-12-21 2003-07-29 Cisco Technology, Inc. Method and apparatus for accessing a database through a network
US6914969B2 (en) * 2001-06-18 2005-07-05 International Business Machines Corporation Service logic execution environment for telecommunications service components
US7369537B1 (en) 2001-07-18 2008-05-06 Global Ip Solutions, Inc. Adaptive Voice-over-Internet-Protocol (VoIP) testing and selecting transport including 3-way proxy, client-to-client, UDP, TCP, SSL, and recipient-connect methods
US20030093523A1 (en) * 2001-11-15 2003-05-15 Cranor Charles D. Method for associating clients with domain name servers
EP1317108A1 (de) * 2001-11-29 2003-06-04 Telefonaktiebolaget Lm Ericsson Anrufsteuerungsnetzwerk, Zugangssteuerungsserver und Anrufsteuerungsverfahren
FR2833792B1 (fr) * 2001-12-17 2004-08-27 France Telecom Procede pour realiser une interface aisement configurable entre un reseau de communication et une offre de services mettant en oeuvre un reseau de type internet
EP1550051A4 (de) * 2002-10-09 2006-06-07 Personeta Ltd Verfahren und vorrichtung für ein dienstintegrationssystem
US7237030B2 (en) * 2002-12-03 2007-06-26 Sun Microsystems, Inc. System and method for preserving post data on a server system
US6931453B2 (en) * 2003-01-03 2005-08-16 Nokia Corporation Method and apparatus for resolving protocol-agnostic schemes in an internet protocol multimedia subsystem
US7417981B2 (en) 2003-10-15 2008-08-26 Vonage Holdings Corp. Method and apparatus for enhanced Internet Telephony
US7743029B2 (en) * 2003-12-30 2010-06-22 Sap Ag Log configuration and online deployment services
US7852997B2 (en) * 2004-01-28 2010-12-14 Managed Inventions, Llc Internet telephony communications adapter for web browsers
CN1906600A (zh) * 2004-01-30 2007-01-31 国际商业机器公司 计算实用工具的分级资源管理
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
WO2005091652A1 (en) * 2004-03-20 2005-09-29 Telefonaktiebolaget Lm Ericsson (Publ) Method and network node for a call set up
US8028002B2 (en) 2004-05-27 2011-09-27 Sap Ag Naming service implementation in a clustered environment
US7721256B2 (en) * 2004-05-27 2010-05-18 Sap Ag Method and system to provide access to factories in a naming system
JP4480511B2 (ja) * 2004-08-09 2010-06-16 株式会社関西スーパーマーケット トレーサビリティ情報取得システム
JP2006127470A (ja) * 2004-09-30 2006-05-18 Oki Electric Ind Co Ltd コンポーネント間の共有情報管理プログラム、方法及び装置、記録媒体、および通信装置
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
US8918366B2 (en) 2005-02-07 2014-12-23 Mimosa Systems, Inc. Synthetic full copies of data and dynamic bulk-to-brick transformation
US8799206B2 (en) 2005-02-07 2014-08-05 Mimosa Systems, Inc. Dynamic bulk-to-brick transformation of data
US20060210036A1 (en) 2005-03-16 2006-09-21 Jeffrey Citron System for effecting a telephone call over a computer network without alphanumeric keypad operation
US8683044B2 (en) 2005-03-16 2014-03-25 Vonage Network Llc Third party call control application program interface
AU2006311417A1 (en) 2005-11-09 2007-05-18 Vonage Holdings Corp. Method and system for customized caller identification
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
EP2034694A1 (de) * 2007-09-05 2009-03-11 Nokia Siemens Networks Oy Telekommunikationsanwendungen
US8879545B2 (en) * 2007-12-31 2014-11-04 At&T Intelletual Property I, L.P. Methods and apparatus to route a communication session directly to a voicemail mailbox
CN101247442B (zh) * 2008-03-26 2011-02-02 唐东风 基于模拟电话的计算机通信方法、装置与系统
US8238538B2 (en) 2009-05-28 2012-08-07 Comcast Cable Communications, Llc Stateful home phone service
US8386340B1 (en) * 2009-12-21 2013-02-26 Amazon Technologies, Inc. Establishing communication based on item interest
US20180246965A1 (en) * 2017-02-27 2018-08-30 Ca, Inc. Terminal Emulator-Based Online Search

Family Cites Families (42)

* 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
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
FI92895C (fi) * 1993-04-06 1995-01-10 Nokia Telecommunications Oy Menetelmä ja järjestelmä puhelinkeskuksen käytön ohjaamiseksi tilaajaliittymästä käsin
JPH09501549A (ja) 1993-06-28 1997-02-10 ベルサウス コーポレイション 公衆加入電話網用開放型高度インテリジェント・ネットワーク・インタフェースの仲介
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
IE72523B1 (en) 1994-03-10 1997-04-23 Elan Med Tech Nicotine oral delivery device
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
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
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
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
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
US6014379A (en) 1996-06-26 2000-01-11 Bell Atlantic Network Services, Inc. Telecommunications custom calling services
US6021126A (en) 1996-06-26 2000-02-01 Bell Atlantic Network Services, Inc. Telecommunication number portability
US6115737A (en) 1996-07-24 2000-09-05 Telcordia Technologies, Inc. System and method for accessing customer contact services over a network
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
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
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
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
CN1104142C (zh) 2003-03-26
WO1997022212A1 (en) 1997-06-19
NO982514L (no) 1998-08-05
EP0867093B1 (de) 2005-06-15
NO982514D0 (no) 1998-06-02
AU704385B2 (en) 1999-04-22
DE69634854D1 (de) 2005-07-21
EP0867093A1 (de) 1998-09-30
CA2239408A1 (en) 1997-06-19
US6466570B1 (en) 2002-10-15
ATE298172T1 (de) 2005-07-15
JP2000516408A (ja) 2000-12-05
CN1208535A (zh) 1999-02-17
AU1104697A (en) 1997-07-03

Similar Documents

Publication Publication Date Title
DE69634854T2 (de) Verfahren zum zugreifen auf dienstmittelgegenstande für anwendung in einem fernmeldesystem
DE69635522T2 (de) Verfahren zur versorgung von fernmeldediensten
DE69633205T2 (de) Zugriff zu Kommunikationsdateien
DE69635386T2 (de) Verfahren zum Bereitstellen von Telekommunikationsdiensten
DE602005002150T2 (de) Verfahren und Vorrichtung zur Bereitstellung von universellen Fernmelderelaisdiensten
DE69921169T2 (de) Intelligentes netz
DE69838788T2 (de) Anruferidentifizierungs-verwaltungssystem in fernsprechnetzen mit telefonnummernübertragbarkeit
DE69735450T2 (de) Verfahren zum Errichten einer Verbindung über ein Rechnernetzwerk
DE60105378T2 (de) System und Verfahren zur Lieferung von Profilinformationen eines Anrufers
DE69828976T2 (de) Kommunikationssystem mit mitteln zur übertragung von internetadressen über kurzmitteilungen
DE69733762T2 (de) Fernmeldenetz mit teilnehmernummerverschiebbarkeit
DE69831650T2 (de) Verfahren und System für Sprachanruf durch Benutzung von Informationen die aus einer ausführenden Anwendung auf einem Rechnersytem abgerufen wurden
DE69735720T2 (de) Verfahren, system und vorrichtung zur überwachung von teilnehmerbetribsamkeit
DE69930963T2 (de) Verfahren und gerät zur korrelation eines einzigartigen identifizierers, wie z.b. eine pstn telefonnummer, an eine internetadresse zur kommunikation über das internet
DE69827040T2 (de) Verfahren und anordnung zum aufbau einer gesprächsverbindung in einem geschalteten telefonnetz
DE69734995T2 (de) Fernmeldenetz mit mobilteilnehmernummerübertragbarkeit
DE69435052T2 (de) Internetzsystem für persönliche Übertragungsdienste
DE69932088T2 (de) Verfahren und mittel zum bereitstellen von diensten in einem telekommunikationsnetz
DE60031103T2 (de) Verfahren und systeme zum lenken von anfragenachrichten eines anrufernamensdienstes in einem kommunikationsnetz
DE69936624T2 (de) Verfahren und Einrichtung zum automatischen Verbindungsaufbau in verschiedenen Netzen
DE69833035T2 (de) Verfahren und vorrichtung zum anbieten von netzwerkspezifischen mobilen diensten
DE60309592T2 (de) Verfahren zum Routing von Dienstanforderungen in einem Netz, mittels E.164-Nummern und DNS
DE60117713T2 (de) Verfahren zum transferieren von teilnehmerdaten zwischen verschiedenen servern eines telekommunikationsnetzes
DE69909555T2 (de) Verteiltes Anrufsystem
DE69729159T2 (de) Kompatibilität zwischen einem Fernsprechdienst mit Anbieter und einem ISDN Anruferidentifikationsdienst

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
R082 Change of representative

Ref document number: 867093

Country of ref document: EP

Representative=s name: SCHOPPE, ZIMMERMANN, STOECKELER, ZINKLER & PARTNER