DE69633205T2 - Zugriff zu Kommunikationsdateien - Google Patents

Zugriff zu Kommunikationsdateien Download PDF

Info

Publication number
DE69633205T2
DE69633205T2 DE69633205T DE69633205T DE69633205T2 DE 69633205 T2 DE69633205 T2 DE 69633205T2 DE 69633205 T DE69633205 T DE 69633205T DE 69633205 T DE69633205 T DE 69633205T DE 69633205 T2 DE69633205 T2 DE 69633205T2
Authority
DE
Germany
Prior art keywords
uri
domain name
resource
service
server
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
DE69633205T
Other languages
English (en)
Other versions
DE69633205D1 (de
Inventor
Colin Low
Andrew Franklin Seaborne
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
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
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=10789104&utm_source=***_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=DE69633205(T2) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Hewlett Packard Development Co LP filed Critical Hewlett Packard Development Co LP
Application granted granted Critical
Publication of DE69633205D1 publication Critical patent/DE69633205D1/de
Publication of DE69633205T2 publication Critical patent/DE69633205T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephone Function (AREA)
  • Application Of Or Painting With Fluid Materials (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

  • Gebiet der Erfindung
  • Die vorliegende Erfindung bezieht sich auf ein Verfahren zum Zugreifen auf Kommunikationsdaten über eine Zielentität. Die vorliegende Erfindung findet speziell Anwendung auf das Bereitstellen von IN-Diensten (IN = Intelligent Network) in einem Wähltelekommunikationssystem.
  • Wie er hierin verwendet wird, bedeutet der Ausdruck „Wähltelekommunikationssystem" ein System, das ein Trägernetzwerk aufweist, das wählt bzw. vermittelt, um einen Trägerkanal durch das Netzwerk durchzuschalten. Der Ausdruck „Wähltelekommunikationssystem" soll verwendet werden, um nicht nur die existierenden öffentlichen und privaten Telephonsysteme (unabhängig davon, ob sie analoge Telephone oder Telephone auf ISDN-Basis verwenden) zu enthalten, sondern auch Breitband-(ATM) oder andere Trägernetzwerke auf Wählbasis, die gegenwärtig implementiert werden oder in der Zukunft entstehen können. Der Bequemlichkeit halber wird der Ausdruck „Wähltelekommunikationssystem" hierin manchmal auf Telekommunikationssystem abgekürzt.
  • Eine Bezugnahme auf eine „Anrufverbindung" im Zusammenhang mit einem Wähltelekommunikationssystem ist hinsichtlich seiner Bedeutung als eine Kommunikation durch einen Trägerkanal, der über das Trägernetzwerk aufgebaut ist, zu verstehen, während Bezugnahmen auf einen Anrufverbindungs-Aufbau, eine Anrufverbindungs-Aufrechterhaltung und einen Anrufverbindungs-Abbau hinsichtlich ihrer Bedeutung als die Verfahren zum Aufbauen, Aufrechterhalten und Abbauen eines Trägerkanals durch das Trägernetzwerk zu verstehen sind. Ausdrücke wie z. B. „Anrufverbindungsverarbeitung" und „Anrufsverbindungshandhabung" sind auf ähnliche Weise zu interpretieren.
  • Der Ausdruck „Kommunikationssystem" sollte, wenn er hierin verwendet wird, als eine breitere Bedeutung als Wähltelekommunikationssystem aufweisend verstanden werden, wobei beabsichtigt ist, daß derselbe Kommunikationssysteme auf Datagrammbasis umfaßt, bei denen jedes Datenpaket unabhängig durch ein Trägernetzwerk geleitet wird, ohne einem vorbestimmten Trägerkanal zu folgen.
  • Hintergrund der Erfindung
  • Telekommunikationsfirmen, die PSTNs (Public Switched Telephone Networks) und PLMNs (Public Land Mobile Networks) unterhalten, sind in dem Geschäftsfeld des Bereitstellens von Kommunikationsdiensten und stellen dabei eine zunehmende eingebaute Intelligenz in der Form von „IN-Diensten" bereit, wie z. B. 800-Nummer-Dienste und eine Rufweiterleitung. Im Gegensatz dazu ist das World Wide Web (WWW), das in jüngerer Zeit ein explosives Wachstum erfahren hat, ein Beispiel eines globalen Netzwerks auf Internet-Basis, das komplexe Informationsdienste bereitstellt. Diese zwei Welten, die eine der großen Kommunikationsdienstleistungen und die andere der hochdynamischen Pioniergeist-WWW-Informationskultur, sind unruhige Gefährten, wobei jede plant, in den Bereich einzugreifen, der vorher durch die andere besetzt war; folglich werden Telephondienste über das WWW angeboten und Informationsdienste über die öffentliche Kommunikationsinfrastruktur.
  • Die vorliegende Erfindung schlägt Technologien für eine synergetischere Beziehung zwischen diesen zwei Welten vor, als sie gegenwärtig ins Auge gefaßt ist, wobei, um die vorliegende Erfindung in den richtigen Zusammenhang zu setzen, zunächst eine Übersicht über jede dieser zwei Welten gegeben wird.
  • Telephonnetzwerke mit IN-Diensten
  • Das Basis-PSTN. Der Basisdienst, der durch ein PSTN (Public Switched Telephone Network) bereitgestellt wird, ist die Verbindung von zwei Telephonen (d. h. Aufbauen eines Trägerkanals zwischen den Telephonen) entsprechend einer Telephonnummer eines angerufenen Teilnehmers, die am Telephon des anrufenden Teilnehmers eingegeben wird. 1 ist eine vereinfachte Darstellung eines PSTN, das einen solchen Dienst bereitstellt. Im speziellen sind Teilnehmergerätschaften, CPE 10 (CPE = customer premises equipment) (wie z. B. analoge Standardtelephone, jedoch auch in neuerer Zeit ISDN-Geräte) durch ein Zugriffnetzwerk 11 mit Schaltstellen SPs 12 (SP = Switching point) verbunden. Die SPs 12 bilden Knoten in einem Übertragungsnetzwerk 13, das aus Verbindungskanälen 14 und SPs aufgebaut ist, die durch Steuerentitäten 15 in den SPs gesteuert werden. Die Steuerung, die durch die Steuerentitäten 15 bewirkt wird, ist durch ein Signalisieren von Eingangssignalen, die von dem CPEs und anderen SPs empfangen werden, bestimmt und involviert einen Rufverbindungs-Aufbau, eine -aufrechterhaltung und einen -abbau, um den gewünschten Trägerkanal zwischen einer anrufenden CPE und einer angerufenen CPE bereitzustellen. Konzeptmäßig kann das PSTN als ein Trägernetzwerk und ein Steuernetzwerk (Signalisierungsnetzwerk) betrachtet werden, wobei die Funktion des letztgenannten darin besteht, eine Anrufverbindungssteuerung durch das Trägernetzwerk zu bewirken, nämlich die Steuerung eines Aufbauens, Aufrechterhaltens und Abbauens von Trägerkanälen durch das Trägernetzwerk; in der Praxis können das Träger- und das Signalisierungs-Netzwerk die gleichen physikalischen Schaltungen und sogar die gleichen logischen Kanäle verwenden.
  • Wenn folglich die CPE ein herkömmliches dummes Telephon ist, ist die Steuersignalisierung zwischen der CPE und ihrer lokalen SP eine In-Band-Signalisierung, d. h. die Signalisierung wird auf dem gleichen Kanal durchgeführt, der für die Sprache verwendet wird; diese Signalisierung wird an der SP 12 interpretiert und in eine Signalisierung zwischen SPs umgewandelt, die ein zweckgebundenes Gemeinsam-Kanal-Signalisierungsnetzwerk 16 verwenden (das heutzutage unter Verwendung des SS7-Protokollstapels implementiert ist). Wenn die CPE ein ISDN-Gerät ist, wird die Signalisierung in einem separaten Kanal direkt von der CPE auf einer durchgehenden Basis durchgeführt. Moderne SPs verwenden das ISUP-SS7-Protokoll (ISUP = ISDN User Part; User Part = Benutzerteil) für eine Übertragungs-Anrufverbindungs-Steuersignalisierung, ungeachtet dessen, ob die CPE ein Standardtelephon oder ein ISDN-Gerät ist.
  • Telephonnumerierungspläne – Da bestimmte Aspekte der vorliegenden Erfindung durch die Strukturierung von Telephonnummern beeinflußt werden, wird nun eine kurze Beschreibung der Strukturierung solcher Nummern gegeben. Telephonnummern bilden ein internationales hierarchisches Adressierungsschema basierend auf Gruppen von Dezimalziffern. Die oberste Ebene der Hierarchie wird durch die ITU-T verwaltet, die den geographischen Hauptzonen numerische Einzel-Ziffern-Codes zugeordnet hat (beispielsweise „1" für Nordamerika, „2" für Afrika, „3" für Europa, „4" für Europa, „5" für Südamerika und Kuba, usw.). In jeder Zone sind Ländercodes mit 2 oder 3 Stellen zugewiesen, so daß in Zone 3 Frankreich „33" ist, und in der Zone 4 UK „44" ist. Die Verwaltung des Numerierungsplans in einem Land ist einem nationalen Körper übertragen, beispielsweise dem Office of Telecommunications („Oftel") in UK. Die folgende weitere Beschreibung basiert auf dem UK-Numerierungsplan, wobei jedoch zu erkennen ist, daß das beschriebene Schema weit verbreitete Anwendbarkeit besitzt.
  • In Großbritannien (UK) ist allen nationalen Nummern ein Code von 01 bis 09 vorangestellt (wobei das Präfix '0' beim internationalen Wählen weggelassen wird). Die momentan zugewiesenen Codes sind „01" für Codes geographischer Bereiche (Geographic Area Codes), „02" für Codes zusätzlicher geographischer Bereiche (Additional Geographic Area Codes), „04" für Mobildienste (Mobile Services), „07" für persönliche Nummern (Personal Numbers) und „08" für Spezialdienste (Special Services) (gebührenfrei, Informationen). Normale Drahtleitungs-PSTN-Teilnehmer-Telephonnummern werden von dem Geographic-Area-Code-Codes zugeordnet, wobei momentan nur Codes, denen 01 vorangestellt ist, zugeordnet werden. Codes für geographische Bereiche weisen gegenwärtig drei oder vier Stellen (mit Ausnahme der vorderen '0') auf, wobei gegenwärtig 638 geographische Bereiche, von denen jeder seinen eigenen Code aufweist, existieren. Eine vollständige nationale UK-Wählnummer besitzt zwei Formen:
  • Figure 00050001
  • Der erste Fall umfaßt das Präfix '0', einen dreistelligen Bereichscode und eine siebenstellige lokale Nummer, während der zweite Fall das Präfix '0', einen vierstelligen Bereichscode und eine sechsstellige lokale Nummer besitzt. Eine weitere Interpretation der lokalen Nummer wird in der Bereichsvermittlungsstelle durchgeführt, da sogar ein sechsstelliger Adreßraum für einen einzelnen Vermittler zu groß ist, wobei für einen typischen lokalen Bereich mehrere Vermittler (Schalter) benötigt werden können, um die erforderliche Anzahl von Teilnehmerleitungen zu beherbergen. Diese Interpretation ist undurchsichtig und ist eine Aufgabe für den Bereichsdienstprovider.
  • Bei dem gegenwärtigen PSTN wird die inhärent hierarchische und geographische Interpretation der Telephonnummern durch die physikalische Architektur des Netzwerks widergespiegelt. Eine Telephonnummer ist auf eine Weise strukturiert, die es einfach macht, einen Anruf durch das Netzwerk zu leiten. Bei jedem Schritt liefert das Präfix der Nummer Informationen über den momentanen Leitschritt, während das Suffix (vielleicht undurchsichtig) Informationen über nachfolgende Leitschritte liefert; so lange ein Vermittler weiß, wie ein Präfix syntaktisch auszuwerten ist und ein Leitschritt durchzuführen ist, muß er den Inhalt des Suffix nicht verstehen, der für nachfolgende Leitschritte belassen wird. Aus diesem Grund ist die internationale und nationale Vermittlungskonfiguration ebenfalls hierarchisch organisiert.
  • Intelligente 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.
  • Das World Wide Web
  • Im Gegensatz zu dem langsamen mäßigen Fortschritt der Telephoninfrastruktur ist das WWW seit seinem Beginn 1989 exp losionsartig 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ändig qualifizierte" Name eines Hosts ist die Zeichenfolge der Knotenkennungen, von denen jede durch einen „." getrennt ist, von dem entsprechenden Blattknoten zu dem Wurzelknoten der Hierarchie, wobei dieser Letz tere durch einen abschließenden „." in dem Namen dargestellt ist. Folglich hat eine Host-Maschine „Fred" von Hewlett-Packard Laboratories in Bristol, England, einen vollständig qualifizierten Domainnamen von „fred.hpl.hp.com." (es sei bemerkt, daß, wenn ein Host-Name keinen abschließenden „." aufweist, derselbe relativ zu dem momentanen Knoten der Namensgebungshierarchie interpretiert wird).
    • – Jeder Host besitzt einen oder mehrere zugeordnete Registrierungsdatensätze (RRs).
    • – Es existiert eine Mehrzahl von DNS-Servern, von denen jeder Verantwortung für einen Teilbaum des Namenraums besitzt. Ein DNS-Server wird RRs für den gesamten oder einen Teil seines Teilbaums halten – in dem letztgenannten Fall überträgt er die Verantwortung für den Rest des Teilbaums zu einem oder mehreren weiteren DNS-Servern. Ein DNS-Server kennt die Adresse von jeglichem Server, auf den er Verantwortung übertragen hat, und ferner die Adresse des Servers, dem er die Verantwortung für den Teilbaum, den er verwaltet, gegeben hat. Die DNS-Server zeigen somit auf jeden anderen in einer Struktur, die die der Namensgebungshierarchie widerspiegelt.
    • – Eine Anwendung, die das DNS benutzen möchte, tut dies durch einen zugeordneten „Auflöser", der die Adresse von zumindest einem DNS-Server kennt. Wenn ein DNS-Server durch diesen Auflöser nach einer RR eines spezifizierten Host gefragt wird, wird er entweder den angeforderten RR oder die Adresse eines DNS-Servers zurückgeben, der hinsichtlich einer Durchquerung der Namensgebungshierarchie näher an dem Server ist, der den RR hält. Tatsächlich wird die Hierarchie der Server nach oben durchlaufen, bis ein Server erreicht ist, der auch die Verantwortung für den Domainnamen, der aufgelöst werden soll, hat; danach wird die DNS-Server-Hierarchie absteigend bis zu dem Server durchlaufen, der den RR für den Domainnamen, der aufgelöst werden soll, hält.
    • – Das DNS verwendet ein vorbestimmtes Nachrichtenformat (tatsächlich ist es dasselbe für eine Anfrage und eine Antwort) und verwendet die IP-Protokolle.
  • Diese Charakteristika des DNS können als ein „DNS-Typ"-System definierend betrachtet werden, was stets kleinere Variationen ermöglicht, wie z. B. bezüglich der Kennungssyntax, wie die Kennungen kombiniert werden (Sortierung, Separatoren), der Nachrichtenformateinzelheiten, der Entwicklungen von IP-Protokollen usw.
  • Aufgrund der hierarchischen Namensgebungsstruktur ist es möglich, die Verantwortung für die Verwaltung von Domains (Teilbäumen) des Namenraums rekursiv zu übertragen. Folglich werden die Top-Level-Domains durch InterNic verwaltet (diese Top-Level-Domains umfassen die bekannten 'com', 'edu', 'org', 'int', 'net', 'mil'-Domains, ebenso wie Top-Level-Länder-Domains, die durch Standard-Zwei-Buchstaben-Codes spezifiziert sind, wie z. B. 'us', 'uk', 'fr' usw.) Auf dem nächsten Level ist beispielsweise die Hewlett-Packard Company für alle Namen verantwortlich, die mit 'hp.com' enden, während die British Universities gemeinsam für alle Namen verantwortlich sind, die mit 'ac.uk' enden. Weiter absteigend und wiederum beispielsweise steht die Verwaltung der Domain 'hpl.hp.com' in der Verantwortung der Hewlett-Packard-Laboratories und die Verwaltung des Teilbaums (der Domain) 'newcastle.ac.uk' liegt in der Verantwortung der University of Newcastle-upon-Tyne.
  • 3 zeigt den Fortschritt einer beispielhaften Abfrage, die von innerhalb der Hewlett-Packard Laboratories durchgeführt wird. Der Host-Domainname, der aufgelöst werden soll, ist 'xy.newcastle.ac.uk', eine hypothetische Maschine an der University of Newcastle, Großbritannien. Die Abfrage wird dem DNS-Server präsentiert, der für den Teilbaum "hpl.hp.com" verantwortlich ist. Dieser Server hält nicht den angeforderten RR und antwortet somit mit der Adresse des "hp.com"-DNS-Servers; dieser Server wird dann abgefragt und antwortet mit der Adresse des 'com'-DNS-Servers, der wiederum mit der Adresse des '.'-DNS-Servers (Wurzel-DNS-Servers) antwortet. Die Abfrage schreitet dann iterativ herunter zu dem 'uk'-Zweig fort, bis der 'newcastle.ac.uk'-Server mit dem RR-Datensatz für den Namen 'xy' in seinem Teilbaum antwortet.
  • Dies sieht extrem ineffizient aus, jedoch sind die DNS-Server entworfen, um einen dynamischen Cache aufzubauen, und werden mit den Adressen mehrere Wurzel-Server initialisiert, so daß in der Praxis die meisten der iterativen Abfragen niemals stattfinden. In diesem Fall wird der 'hpl.hp.com'-DNS-Server die Adressen mehrerer Wurzel-Server kennen und wird wahrscheinlich die Adressen der 'uk'- und 'ac.uk'-Server in seinem Cache haben. Die erste Abfrage an den 'hpl.hp.com'-Server wird die Adresse des 'ac.uk'-Servers zurückgeben. Die zweite Abfrage an den 'ac.uk'-Server wird die Adresse des 'newcastle.ac.uk'-Servers zurückgeben, und die dritte Abfrage wird den fraglichen RR zurückgeben. Alle zukünftigen Abfragen mit einem 'newcastle.ac.uk'-Präfix werden direkt zu dem Newcastle-DNS-Server gehen, da diese Adresse in dem 'hpl.hp.com'-DNS-Server-Cache gehalten wird. In der Praxis werden Namen in einem lokalen Teilbaum in einer einzelnen Abfrage aufgelöst, während Namen außerhalb des lokalen Teilbaums in zwei oder drei Abfragen aufgelöst werden.
  • Anstelle dessen, daß ein Auflöser für das Durchführen der Reihe von Abfrageniterationen, die erforderlich sind, um einen Domainnamen aufzulösen, verantwortlich ist, kann der Auflöser seine erste Abfrage spezifizieren, um rekursiv zu sein, wobei in diesem Fall der empfangende DNS-Server für das Auflösen der Abfrage verantwortlich ist (wenn er den angeforderten RR nicht direkt zurückgeben kann, wird er selbst eine rekursive Abfrage zu einem 'näheren' DNS-Server ausgeben, usw.).
  • Es sei ferner bemerkt, daß in der Praxis jeder DNS-Server vervielfältigt sein wird, d. h. als ein primärer und ein oder mehrere sekundäre organisiert sein wird. Ein primärer DNS-Namenserver initialisiert sich selbst von einer Datenbank, die auf einem lokalen Dateisystem gehalten ist, während ein sekundärer sich selbst durch Übertragen von Informationen von einem primären initialisiert. Ein Teilbaum wird normalerweise einen primären Namenserver und bis zu zehn sekundäre besitzen – wobei die Begrenzung tendenziell die Zeit ist, die durch die sekundären benötigt wird, um ihre Datenbanken von den primären zu aktualisieren. Die primäre Datenbank ist die Master-Quelle von Teilbauminformationen und wird durch den Domain-DNS-Verwalter gehalten. Die sekundären sind nicht einfach Ersatzsekundäre, sondern nehmen jeweils aktiv in dem DNS teil, wobei abhängige Server auf dieselben zeigen, und nicht auf den entsprechenden primären.
  • DNS-Implementierungen, wie z. B. BIND, sind als ein Standardteil der meisten UNIX-Systeme verbreitet verfügbar und können für sich beanspruchen, unter den robustesten und am weitesten verbreiteten existierenden verteilten Anwendungen zu sein.
  • Betrieb des WWW: Bezug nehmend auf 4 der beigefügten Zeichnungen kann ein Zugriff auf das Internet durch eine direkte Verbindung mit einem Netzwerk, das selbst direkt oder indirekt mit dem Internet verbunden ist, stattfinden; eine solche Anordnung wird durch ein Endgerät 31 in 4 dargestellt (dieses Endgerät kann beispielsweise eine UNIX-Workstation oder ein PC sein). Das Besitzen einer Verbindung in das Internet dieser Form ist als das Besitzen eines 'Netzwerkzugriffs' bekannt. Jede Entität, die einen Netzwerkzugriff in das Internet besitzt, kann als ein Server im Internet wirksam sein, vorausgesetzt dieselbe besitzt eine ausreichende zugeordnete Funktionalität; in 4 ist eine Entität 32 mit einem Dateispeicher 37 als ein Server wirksam.
  • Viele Benutzer des WWW besitzen keinen Netzwerkzugriff in das Internet, sondern greifen statt dessen über einen Internet-Dienst-Provider, ISP (ISP = Internet service provider) 33, der einen Netzwerkzugriff besitzt, auf das Internet zu. In diesem Fall wird das Benutzer-Endgerät 34 allgemein mit dem ISB 33 über das öffentliche Telephonsystem unter Verwendung eines Modems und unter Verwendung von entweder SLIP (SLIP = Serial Line Interface Protocol) oder PPP (PPP = Point-to-Point Protocol) kommunizieren. Diese Protokolle ermöglichen, daß Internet-Pakete herkömmliche Telephonleitungen überqueren. Ein Zugriff auf das Internet dieser Form ist als „Einwahl-IP"-Zugriff bekannt. Bei dieser Zugriffsmethode wird dem Benutzer-Endgerät 34 während jeder Benutzersitzung temporär eine IP-Adresse zugeordnet; da sich diese IP-Adresse jedoch zwischen Sitzungen unterscheiden kann, ist es für die Entität 34 nicht zweckmäßig, als ein Server wirksam zu sein.
  • Ein Eckpfeiler des WWW ist seine Fähigkeit, spezielle Informationsressourcen durch einen URI (URI = Uniform Resource Identifier) zu adressieren, der im allgemeinen entweder ein URL (URL = Uniform Resource Locator), der eine Ressource durch ihren Ort identifiziert, oder ein URN (URN = Uniform Resource Name), der in einen URL aufgelöst werden kann, ist. Beispielsweise wird ein voller oder „absoluter" URL folgende Elemente aufweisen:
    Schema – dies ist das Zugriffsschema, das verwendet werden soll, um auf die interessierende Ressource zuzugreifen;
    Host – der Internet-Host-Domainname oder die -IP-Adresse;
    Port – der Host-Port für die (TCP)-Verbindung;
    abs-Weg – der absolute Weg der Ressource auf dem Host.
  • Tatsächlich kann 'Port' weggelassen sein, wobei in einem solchen Fall Port 80 angenommen wird.
  • 5 der beigefügten Zeichnungen zeigt einen beispielhaften URL für die Hewlett-Packard-Produkte-Willkommens-Seite. In diesem Fall sind die Elemente:
    Schema – http
    Host – www.hp.com
    Port – weggelassen (Port 80 angenommen)
    abs-Weg – Products.html
  • Das HTTP-Protokoll basiert auf einem Anforderungs/Antwort-Paradigma. Bezug nehmend wiederum auf 4 der Zeichnungen erstellt ein Client bei einem gegebenen speziellen URI, der eine Ressource 30, auf die zugegriffen werden soll, identifiziert, eine Verbindung mit dem Server 31, der dem „Host"-Element des URI entspricht und sendet eine Anforderung zu dem Server. Diese Anforderung umfaßt ein Anforderungsverfahren und den „Anforderungs-URI" (der im allgemeinen exakt der absolute Weg der Ressource auf dem Server ist, wie er durch das „abs-Weg"-Element des URI identifiziert ist); die Anforderung kann zusätzliche Datenelemente umfassen. Der Server 31 greift dann auf die Ressource 36 (die hier im Speicher 37 gehalten ist) zu und antwortet, wobei diese Antwort eine Entität eines Typs, der durch einen MIME-Typ (MIME = Multipurpose Internet Mail Extensions) identifiziert ist, der ebenfalls in der Antwort enthalten ist, umfassen kann.
  • Die zwei Hauptanforderungsverfahren sind:
    GET (Holen) – Dieses Verfahren hat die Wiedererlangung jeglicher Informationen (in der Form einer Entität) zur Folge, die durch den Anforderungs-URI identifiziert sind. Es ist wichtig, zu bemerken, daß es, wenn sich der Anforderungs-URI auf einen Datenerzeugungsprozeß bezieht, die erzeugten Daten sind, die als die Entität in der Antwort zurückgegeben werden, und nicht der Quelltext des Prozesses.
    POST (Versenden) – Dieses Verfahren wird verwendet, um anzufordern, daß der Zielserver die Entität, die in der Anforderung enthalten ist, als eine neue untergeordnete der Ressource, die durch den Anforderungs-URI identifiziert ist, akzeptiert. Das POST-Verfahren kann zur Kommentierung existierender Ressourcen, zum Liefern einer Nachricht zu einem schwarzen Brett, zum Liefern von Daten zu einem Datenhandhabungsprozeß (beispielsweise von Daten, die als das Ergebnis des Übermittelns eines Formulars erzeugt werden), und zum Erweitern einer Datenbank durch eine Beifügungs-Operation verwendet werden.
  • Zusammenfassend kann das GET-Verfahren verwendet werden, um direkt Daten wiederzugewinnen, oder um irgendeinen Prozeß auszulösen, der eine Entität zurückgeben wird (die entweder Daten oder einfach eine Anzeige des Ergebnisses des Durchführens des Prozesses sein können). Das POST-Verfahren wird verwendet, um Daten zu registrieren, wobei ein Spezifizieren dieses Verfahrens ferner wirksam ist, um einen Prozeß in dem Server auszulösen, um die versendeten Daten geeignet zu handhaben.
  • Das Weiterleiten von Informationen zu einem Prozeß, der unter Verwendung entweder des GET- oder des POST-Verfahrens ausgelöst wird, um auf einem Server zu laufen, geschieht momentan gemäß einer Schnittstelle, die als die CGI (CGI = Common Gateway Interface = gemeinsame Übergangsschnittstelle) bezeichnet wird. Der Empfangsprozeß ist häufig in einer Script-Sprache geschrieben, obwohl dies nicht essentiell ist. Typischerweise wird das Script des ausgelösten Servers verwendet, um eine Schnittstelle zu einer Datenbank herzustellen, um eine Abfrage, die in einer GET-Anforderung enthalten ist, zu behandeln. Eine weitere Verwendung, auf die bereits verwiesen wurde, besteht darin, Daten, die einer POST-Anforderung zugeordnet sind, einer Datenbank beizufügen.
  • Weitere wichtige Faktoren des Erfolgs des WWW sind die Verwendung der HTML (HTML = Hyper Text Markup Language) zum Darstellen der Konfiguration von Dokumenten, die über das WWW übertragen werden, und die Verfügbarkeit von leistungsstarken Graphik-WEB-Browsern zum Interpretieren derartiger Dokumente in einem Client-Endgerät, um dieselben einem Benutzer zu präsentieren. Grundsätzlich wird HTML verwendet, um jeden Teil eines Dokuments zu identifizieren, beispielsweise einen Titel oder eine Graphik, wobei es dann die Aufgabe des Browsers, der in dem Client-Endgerät läuft, ist, zu entscheiden, wie jeder Dokumententeil anzuzeigen ist. Jedoch ist HTML mehr als dies – sie ermöglicht ferner, daß ein URI und ein Anforderungsverfahren jedem Element eines Dokuments (beispielsweise einem speziellen Wort oder einem Bild) zugeordnet werden, so daß, wenn ein Benutzer auf dieses Element zeigt und dasselbe anklickt, auf die Ressource, die durch den URI identifiziert ist, gemäß dem Schema (Protokoll) und dem spezifizierten Anforderungsverfahren zugegriffen wird. Diese Anordnung liefert einen Hyperlink von einem Dokument zu einem anderen. Unter Verwendung derartiger Hyperlinks kann ein Benutzer an einem Client-Endgerät ohne Anstrengung von einem Dokument, das von einem Server auf einer Seite der Welt heruntergeladen wird, zu einem anderen Dokument, das sich auf einem Server auf der anderen Seite der Welt befindet, springen. Da ein Dokument, das durch einen Autor erzeugt wurde, einen Hyperlink zu einem Dokument, das durch einen anderen Author erzeugt wurde, aufweisen kann, ist ein extrem 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, Java und LiveScript (wobei die letztere eine Netscapeeigene Scriptsprache 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 ne ben weiteren Merkmalen eine eingebaute Unterstützung für Standardmedientypen und die Fähigkeit, Programme in den Client zu laden und auszuführen, liefern. Diese Browser können als Betriebssysteme für eine WWW-Interaktion betrachtet werden.
  • WWW und das Telephonnetzwerk
  • Es ist möglich, einen Telephondienst über das Internet zwischen verbundenen Endgeräten bereitzustellen, indem eine Spracheingabe digitalisiert und über das Internet in diskreten Paketen für eine Wiederzusammenstellung an dem Empfangsendgerät gesendet wird. Dies ist ein Beispiel eines Kommunikationsdienst im Internet. Im Gegensatz dazu ist es möglich, auf eine Vielzahl von Informationsdiensten, die über das Telephonsystem bereitgestellt werden, zu zeigen, wie z. B. das Minitel-System, das in Frankreich verbreitet verfügbar ist. Jedoch stellen diese Eingriffe in die traditionellen Territorien des jeweils anderen keine wirkliche Bedrohung für entweder das Internet oder das öffentliche Telephonsystem dar.
  • Interessanter sind Bereiche einer kooperativen Verwendung des Internets und des Telephonsystems. Tatsächlich existierte ein solcher Bereich für eine beträchtliche Zeit und wurde oben Bezug nehmend auf 4 umrissen, nämlich die Verwendung einer Modem-Verknüpfung über das PSTN von einem Benutzercomputer 34 zu einem Internet-Provider 33, um einen Einwahl-IP-Zugriff auf das Internet zu erhalten. Diese kooperative Verwendung ist von sehr einfacher Beschaffenheit, nämlich den Aufbau eines Trägerkanals über das PSTN für einen nachfolgend erzeugten Internetverkehr; es existiert keine wirkliche Interaktion zwischen dem Internet und dem PSTN.
  • Ein weiteres bekanntes Beispiel der kooperativen Verwendung von Internet und PSTN ist ein in jüngerer Zeit in Gang ge brachter 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.
  • Weiterer relevanter Stand der Technik umfaßt folgenden:
    • – „Internet Access via Baseband and Broadband ISDN Gateways" (Tao J. u. a., International Conference on Computers and Communications, Phoenix, S. 485–490 April 1994) – dieser Artikel beschreibt den Entwurf und die Implementierung eines ISDN-Zu-Internet-Netzübergangs unter Verwendung des TCP/IP-Protokollstapels;
    • – „Distribution of RFC 1327 Mapping Rules via the Internet DNS the INFNet distributed Gateway System" (Bonetti u. a., Computer Networks and ISDN Systems, Bd. 27, Nr. 3, Amsterdam, Dez. 1994) – dieser Artikel beschreibt ein Verfahren des Verteilens von Abbildungsregeln für die Verwendung durch Netzübergänge zwischen Mail-Protokollen X400 und RFC822/SMTP über das DNS.
    • – Prinzipien des Betriebs für die TPC.INT-Subdomain: Remote Printing-Technical Procedures" (Internet Engineering Task Force RFC 1528, Oktober 1993) – dieser RFC beschreibt eine Prozedur zum Ermitteln einer E-Mail-Adresse, an die eine Faxmitteilung über das öffentliche Internet gesendet werden kann, wobei die Empfangsentität das Fax über das lokale Telefonnetz an die Bestimmungsfaxmaschine weiterleiten soll. Diese Prozedur umfasst das syntaktische Auswerten der Bestimmungsfaxnummer in einen Domainnamen durch Behandeln jeder Ziffer als eine getrennte Domainnamenkennung. Für jeden solchen Domainnamen hält das Domainnamensystem eine Standard-MX-Ressourcenaufzeichnung, die eine entsprechende E-Mail-Adresse enthält.
  • Es ist eine Aufgabe der vorliegenden Erfindung, Internettechnologie zu verwenden, um einen Zugriff auf eine Zielentität über ein Kommunikationsnetzwerk zu ermöglichen, wenn mit einer Telefonnummer begonnen wird.
  • Zusammenfassung der Erfindung
  • Gemäß einem Aspekt der vorliegenden Erfindung ist ein Verfahren zum Zugreifen auf Kommunikationsdaten vorgesehen, die für eine Zielentität (B) relevant sind, die durch eine Zahlenzeichenfolge („B-Webtel") identifiziert wird, wobei das Verfahren folgende Schritte umfasst:
    • a) Speichern von Datensätzen in einem Datenbanksystem vom Domain-Name-System-Typ, die jeweils einem entsprechendem Domainnamen zugeordnet sind und einen Einheitsressourcenidentifizierer, URI, halten, zum Lokalisieren von Kommunikationsdaten, die dem Domainnamen zugeordnet sind, wobei jeder Domainname auf eine jeweilige Zahlenzeichenfolge („B-Webtel") bezogen ist, aus der derselbe durch einen Prozess abgeleitet werden kann, der ein syntaktisches Analysieren (120) von zumindest einem wesentlichen Abschnitt der Zahlenzeichenfolge in zumindest einen Teil des Domainnamens umfasst;
    • b) Anwenden des Prozesses auf die Zahlenzeichenfolge („B-Webtel"), die die Zielentität identifiziert, wodurch der verwandte Domainname gebildet wird;
    • c) Zuführen des Domainnamens, der in Schritt b) gebildet wird, zu dem DNS-Typ-Datenbanksystem, um den URI wiederzugewinnen, der in dem entsprechenden Datensatz gespeichert ist; und
    • d) Verwenden des URI, der in Schritt c) wiedergewonnen wird, um auf die Kommunikationsdaten zuzugreifen.
  • Gemäß einem weiteren Aspekt der Erfindung ist ein Computerprogrammprodukt vorgesehen, das für die Verwendung mit einer Rechnerressource vorgesehen ist, die eine Anschlussfähigkeit zu einem Computernetz aufweist, um einen Zugriff auf entfernt gespeicherte Kommunikationsdaten zu ermöglichen, die eine Zielentität (B) betreffen; wobei das Computerprogrammprodukt angeordnet ist, um der Rechenressource, wenn das Computerprogramm ausgeführt wird, folgendes bereitzustellen:
    • – eine erste Einrichtung zum Bilden eines Domainnamens aus einer Zahlenzeichenfolge („B-Webtel"), die die Zielentität (B) identifiziert, durch einen Prozess, der ein syntaktisches Analysieren von zumin dest einem wesentlichen Abschnitt der Zahlenzeichenfolge in zumindest einen Teil des Domainnamens umfasst;
    • – eine zweite Einrichtung, die wirksam ist, um die Netzwerkanschlussfähigkeit der Rechenressource zu verwenden, um den Domainnamen einem Datenbanksystem vom Domainnamensystem-, DNS-, Typ zuzuführen und einen Ressourcendatensatz zurückempfangen, der einen einheitlichen Ressourcenidentifizierer, URI, zum Lokalisieren von Kommunikationsdaten umfasst, die dem Domainnamen zugeordnet sind; und
    • – eine dritte Einrichtung zum Verwenden des URI zum Zugreifen auf die Kommunikationsdaten.
  • Gemäß einem dritten Aspekt der Erfindung ist ein Server eines Domainnamensystem-, DNS-, Typs eines verteilten Datenbanksystems vorgesehen, wobei der Server zumindest einen Ressourcendatensatz (RR) hält, zum Bereitstellen einer Abbildung von einem Domainnamen, der dem Datensatz zugeordnet ist, auf einen Einheitsressourcenidentifizierer, URI, der in dem Datensatz gehalten wird, und verwendet werden kann, um Kommunikationsdaten zum Kontaktieren einer Zielentität (B) zu finden, wobei zumindest ein wesentlicher Abschnitt des Domainnamens in der Form einer Zahlenzeichenfolge („B-Webtel") ist, die die Zielentität (B) identifiziert, die in mehrere Domainnamenkennungen zerlegt wurde, um dem verteilten DNS-Typ-Datenbanksystem zugeführt zu werden, für eine Wiedergewinnung des URI, der in dem entsprechenden Datensatz gehalten wird.
  • Vorteilhafterweise ist das verteilte DNS-Typ-Datenbanksystem in den vorhergehenden drei Absätzen das Domainnamensystem des Internets.
  • Kurze Beschreibung der Zeichnungen
  • Ausführungsbeispiele der vorliegenden Erfindung werden nun mittels eines nicht begrenzenden Beispiels Bezug nehmend auf die beigefügten schematischen Zeichnungen beschrieben. Es zeigen:
  • 1 ein vereinfachtes Diagramm eines Standard-PSTN;
  • 2 ein vereinfachtes Diagramm eines bekannten PSTN mit einer IN-Dienstfähigkeit;
  • 3 ein Diagramm, das eine Hostdomainnamenauflösung durch das DNS des Internets zeigt;
  • 4 ein Diagramm, das die Wirkungsweise des World Wide Web zeigt;
  • 5 ein Diagramm, das das Format eines Standard-URL zeigt;
  • 6 ein Diagramm einer ersten Anordnung, bei der Dienstressourcengegenstände auf HTTP-Servern gehalten werden, auf die sowohl das Dienststeueruntersystem eines PSTN als auch Web-Benutzer zugreifen können;
  • 7 ein Diagramm, das die Verarbeitung einer Dienstanforderung durch die SCP von 6 zeigt;
  • 8 ein Diagramm, das das Format eines Ressourcencodes zeigt, der durch die SCP von 6 verwendet wird, wenn auf einen Dienstressourcengegenstand zugegriffen wird;
  • 9 ein Diagramm, das den Prozeß des Zugreifens auf eine Dienstressource in dem Fall zeigt, in dem der Dienstcode keinen RRI-Teil umfaßt;
  • 10 ein Diagramm, das den Prozeß des Zugreifens auf eine Dienstressource in dem Fall zeigt, in dem der Dienstcode einen RRI-Teil umfaßt;
  • 11 ein Diagramm, das die Herleitung des URI einer Dienstressource durch syntaktisches Auswerten einer eingegebenen Telephonnummer gemäß der vorliegenden Erfindung zeigt;
  • 12A ein Diagramm, das einen Namenraum (den „telname-Raum") zeigt, der durch die Domainnamen, die durch ein syntaktisches Auswerten eines vorbestimmten Satzes von Telephonnummern hergeleitet werden, bildet;
  • 12B ein Diagramm, das die Eingliederung des telname-Raums ohne Fragmentierung in das DNS zeigt;
  • 12C ein Diagramm, das die Eingliederung des telname-Raums in einer fragmentierten Form in das DNS zeigt;
  • 13 ein Diagramm, das den Gesamtbetrieb der Anordnung von 6 beim Bereitstellen eines Roaming-Nummerndiensts ansprechend auf eine Telephonnummer, die an einem Standardtelephon gewählt wird, zeigt;
  • 14 ein Diagramm, das den gesamten Betrieb der Anordnung von 6 zeigt, wenn dieselbe durch einen Web-Benutzer beim Aufbauen einer Anrufverbindung durch eine Telephonschnittstelle, die in das Web-Endgerät des Benutzers integriert ist, benutzt wird;
  • 15 ein Diagramm, das den Gesamtbetrieb einer Anordnung zeigt, bei der eine Schnittstelle zwischen dem PSTN und dem Internet für einen Telephonverkehr vorgesehen ist;
  • 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ück zusenden. 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 spe ziellen 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 Telephonseiten befinden, werden die zusätzlichen Informationen ebenfalls zu dem URI-Bestimmungsblock 47 geleitet, um zu ermöglichen, daß derselbe die URI der geeigneten Telephonseite zurückgibt. Es ist auch möglich, daß sich alle Dienstressourcen, die einer Nummer zugeordnet sind, auf der gleichen Telephonseite befinden. In diesem Fall verwendet der Ressourcenzugriffsblock 46 die zusätzlichen Informationen, um einen Ressourcenidentifizierungsparameter mit seiner Zugriffsanforderung zu der betroffenen Telephonseite weiterzuleiten; es ist dann an der Funktionalität, die der Telephonseite zugeordnet ist, auf die korrekte Dienstressource zuzugreifen.
  • Folglich kann jede Dienstressource als durch einen jeweiligen Ressourcencode 54 (siehe 8), der aus einem ersten Teil UI („URI-Identifizierer"), der verwendet ist, um den URI zu identifizieren, an dem sich die Ressource in dem Internet befindet, und einem zweiten Teil RRI („relativer Ressourcenidentifizierer"), der verwendet wird, um die Ressource unter mehreren Ressourcen des gleichen URI zu identifizieren, gebildet ist, identifiziert betrachtet werden.
  • Ressourcenzugriff – Wenn sich nur eine Dienstressource 49 auf einer Telephonseite 58, die durch einen eindeutigen URI identifiziert ist, befindet, umfaßt der Ressourcencode 54 einfach den UI, allgemein entweder eine Telephonnummer allein oder eine Telephonnummer plus einen pic-Parameter (siehe 9). In diesem Fall umfaßt das Zugreifen auf eine Ressource einfach das Abbilden des gesamten Ressourcencodes 54 in den entsprechenden URI (Prozeß 55) und dann das Senden einer Anforderung 57 zu der entsprechenden Telephonseite 58, wobei diese Letztgenannte selbst die gewünschte Dienstressource 49 bildet. Das Ergebnis des Zugreifens auf die Ressource 49 wird dann in einer Antwortnachricht 59 zurückgegeben.
  • Wenn sich im Gegensatz dazu mehrere Dienstressourcen 49 auf der gleichen Telephonseite 58 befinden (10), umfaßt der Ressourcencode 54 sowohl einen UI als auch einen RRI, wobei der UI allgemein eine Telephonnummer ist und der RRI ein pic oder ein anderer Parameter zum Unterscheiden zwischen zusammen angeordneten Ressourcen ist. In diesem Fall schließt das Zugreifen auf ein Betriebsmittel das Abbilden des UI-Teils des Ressourcencodes 54 in den entsprechenden URI (Prozeß 55) und dann das Senden einer Anforderung 57 zu der entsprechenden Telephonseite (Prozeß 56) ein, wobei die Anforderung den RRI des Ressourcencodes enthält. Die Telephonseite 58 umfaßt eine Funktionalität 64 zum Zugreifen auf die erforderliche Ressource auf der Grundlage des RRI in der Anforderungsnachricht. Das Ergebnis des Zugreifens auf die erforderliche Ressource 49 wird dann in der Antwortnachricht 59 zurückgegeben.
  • Eine Alternative zu dem Verfahren von 10 zum Zugreifen auf eine Dienstressource, die sich mit anderen Orten zusammen auf einer Telephonseite befindet, bestünde darin, die gesamte Seite über das Internet zu holen, einfach unter Verwendung des URI, der von dem UI-Teil des Ressourcencodes hergeleitet wird, und nachfolgend die gewünschte Ressource auf der Grundlage des RRI zu extrahieren.
  • URI-Bestimmung aus Ressourcencode – Die Implementierung des URI-Bestimmungsblocks 47, der den Prozeß 55 durchführt, wird als nächstes betrachtet. Ein hierarchisch strukturiertes verteiltes Datenbanksystem, ähnlich wie (oder sogar Teil des) Domainnamensystems (DNS) des Internets, ist vorgesehen, um den UI-Teil eines Ressourcencodes zu einem entsprechenden URI aufzulösen. Dieser Lösungsansatz, der nachfolgend näher beschrieben wird, würde typischerweise Datenbanken umfassen, die durch jeden PSTN-Operator für seine Nummern beibehalten werden, denen URIs zugeordnet sind. Diese Datenbanken wären für alle PSTNs durch ein Netzwerk, wie zum Beispiel dem Internet, zugreifbar, wobei Auflösungsanforderungen an die entsprechende Datenbank gerichtet werden, auf ähnliche Weise wie an das Domainnamensystem. In diesem Fall wird der Block 47 durch ein geeignetes Auflösungsprogramm gebildet, das angeordnet ist, um durch die Schnittstelle 44 UI-Auflösung über das Internet anzufordern.
  • Die Hostkomponente des URI kann entweder in der Form eines Hostdomainnamens oder einer Host-IP-Adresse vorgesehen sein. Wo der Host durch einen Domainnamen identifiziert wird, wird eine weitere Auflösung des URI-Hostnamens an die IP-Adresse nachfolgend auf eine Standardweise durch die Schnittstelle 44 ausgeführt, unter Verwendung des Domainnamensystems des Internets. Diese weitere Auflösung kann vermieden werden, wenn die Hostidentität direkt als eine IP-Adresse geliefert wird.
  • Eine DNS-Typ-Nachschlagimplementierung für den URI-Bestimmungsblock 47 wird nun bis zu einer bestimmten Detailliertheit für den Fall beschrieben, bei dem der UI-Teil des Ressourcencodes eine Telephonnummer ist und keine Beschränkungen hinsichtlich des URI existieren, weshalb es erforderlich ist, daß sowohl die vollständige Host-Komponente als auch die Wegkomponente des URI durch den Nachschlag zurückgegeben wird. Ein Schlüsselteil des Gesamtprozesses ist die Bildung des Äquivalents eines Hostdomainnamen aus der interessierenden Telephonnummer; dieses Domainnamenäquivalent wird dann durch einen Nachschlagmechanismus, der bei dem vorliegenden Beispiel identisch zu dem ist, der durch das DNS verwendet wird (tatsächlich kann der Nachschlagmechanismus in das DNS eingegliedert sein, obwohl er auch unabhängig implementiert sein kann), in einen entsprechenden URI aufgelöst.
  • Die Beschaffenheit des DNS wurde bereits oben Bezug nehmend auf 3 beschrieben, wobei auch der Ausdruck „DNS-Typ"-System eingeführt wurde. Der Bequemlichkeit halber wird im folgenden ein DNS-Typ-System, das organisiert ist, um eine Telephonnummer-Zu-URI-Übersetzungsfähigkeit zu liefern, als ein „Duris"-System (was für „DNS-Typ-URI-Server"-System steht) bezeichnet.
  • Die elementaren Grundsätze, die den Betrieb eines Duris-Systems umgeben, sind:
    • – jede Telephonnummer kann in einen Hostdomainnamen umgewandelt werden (der Namenraum, der derartige Hostdomainnamen für die interessierenden Telephonnummern enthält, wird nachfolgend als der „telname-Raum" bezeichnet); und
    • – für jeden Hostdomainnamen in dem Hostdomainraum existiert eine Registrierungsdatensatz, der durch das Duris-System, das den entsprechenden URI enthält, gehalten wird.
  • Folglich wird eine eingegebene Telephonnummer, die in dem vorliegenden Fall den UI-Teil eines Ressourcencodes 54 bildet (siehe 11), zuerst syntaktisch ausgewertet, um einen Domainnamen zu bilden (Schritt 120), und wird dann zu dem Duris-System geleitet (das in 11 als durch das DNS selbst gebildet gezeigt ist), um den RR mit dem entsprechenden URI wiederzugewinnen (Schritt 121). Wenn der zurückgegebene URI seine Hostkomponente als einen Domainnamen besitzt, wird nachfolgend ausgehend von dem URI-Nachschlag als nächstes das DNS verwendet, um die Host-IP-Adresse herzuleiten (Schritt 122); dieser Schritt wird selbstverständlich nicht benötigt, wenn die Hostkomponente als eine IP- Adresse in dem RR gespeichert ist. Der URI wird dann verwendet, um eine Ressourcenanforderung an den geeigneten Server durchzuführen, wobei jeder RRI-Teil des Ressourcencodes 54 weitergeleitet wird (Schritt 123).
  • Es existiert eine Anzahl von Möglichkeiten als der obere Level, wie ein Duris-System implementiert werden könnte:
    • (a) Unabhängig von dem DNS. Bei dieser Option bildet der telname-Raum den gesamten Namenraum, der zu verwalten ist, wobei die Wurzel des telname-Raums die „."-Namenraumwurzel ist (siehe 12A, wo der telname-Raum schraffiert dargestellt ist). In diesem Fall ist das Duris-System unabhängig von dem DNS selbst. Das Duris-System könnte selbstverständlich die gleiche 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 syn taktischen 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 wiederzugewinnen und dann die Umleitungsnummer zu extrahieren (dies würde selbstverständlich eine Standardmöglichkeit zum Identifizieren der Informationen, die von der Telephonseite extrahiert werden sollen, erfordern).
  • Eine alternative und bevorzugte Anordnung zum Liefern sowohl eines Sicht- als auch eines funktionellen Zugriffs auf eine Ressource, die Erklärungsmaterial zur Betrachtung erfordert, besteht darin, einen Objekt-orientierten Lösungsansatz für einen Ressourcenentwurf zu verwenden. In diesem Fall hätte das Ressourcen-Objekt zwei unterschiedliche Zugriffsverfahren, die demselben zugeordnet sind, eines für eine rein funktionelle Verwendung der Ressource und das an dere, das eine Betrachtung des zugeordneten Erklärungsmaterials ermöglicht. Es wäre dann Aufgabe der zugreifenden Entität, unter Verwendung des geeigneten Objektverfahrens auf das Ressourcenobjekt zuzugreifen.
  • Noch eine weitere Anordnung zum Liefern sowohl einer Betrachtungs- als auch einer funktionellen Verwendung der Umleitungsnummer bestünde darin, getrennte Ressourcen bereitzustellen, die für jede Verwendung geeignet konfiguriert sind, wobei jede Ressource ihren eigenen Ressourcencode aufweist (allgemein würden beide derartigen Ressourcen auf der gleichen Telephonseite plaziert werden, wobei in diesem Fall der UI-Teil jedes Ressourcencodes identisch wäre).
  • Die Wiedergewinnung einer Telephonseite zur Verwendung durch einen menschlichen Benutzer wird im allgemeinen nicht so zeitkritisch sein wie die Wiedergewinnung für eine betriebliche Verwendung durch ein PSTN. Während für eine menschliche Verwendung das Schema, das in dem URL einer Dienstressource spezifiziert ist, HTTP sein könnte, kann es für eine betriebliche Verwendung vorteilhaft sind, ein spezielles „Telephon"-Schema (Zugriffsprotokoll) zu definieren, was zur Folge hätte, daß der Server 51 eine optimierte Zugriffsroutine verwendet, um auf die geforderte Ressource (Umleitungsnummer bei dem gegenwärtigen Beispiel) zuzugreifen und der zugreifenden Entität in der minimal möglichen Zeit zu antworten.
  • Neben Datengegenständen umfassen weitere mögliche Typen von Dienstressourcen eine Dienstlogik zur Ausführung an Ort und Stelle (im Server), wobei das Ergebnis dieser Ausführung der Entität, die auf die Ressource zugreift, zurückgegeben wird; eine Dienstlogik, die von dem Server zu der zugreifenden Entität für eine Ausführung in dieser Entität herunterladbar ist; und eine Protokollierungsressource zum Protokollieren von Informationen, die durch die zugreifende Identität zu derselben geleitet werden (oder einfach zum Protokollieren der Tatsache, daß auf sie zugegriffen wurde). Es ist klar, daß die Protokollierungsressource tatsächlich exakt ein Spezialfall einer Dienstlogik, die an Ort und Stelle ausführbar ist, ist.
  • Beispielsweise kann eine Dienstressource, die durch eine Ausführung-An-Ort-Und-Stelle-Dienstlogik gebildet ist, angeordnet sein, um eine Uhrzeit-Weiterleitung zu implementieren, wobei das Ergebnis der Ausführung der Dienstlogik darin bestünde, daß die Telephonnummer, zu der ein Anruf weitergeleitet werden soll, unter Berücksichtigung der Uhrzeit am Ort des angerufenen Teilnehmers weitergeleitet wird. Ein Beispiel einer Dienstressource, die durch eine herunterladbare Dienstlogik gebildet ist, ist eine Dienstlogik zum Steuern einer Optionsabfrage des anrufenden Teilnehmers unter Verwendung der Möglichkeiten, die durch ein IP geliefert werden. Die Protokollierungsressource kann verwendet werden, um die Anzahl von Anrufen, die hinsichtlich einer speziellen Nummer plaziert werden, aufzuzeichnen.
  • Wenn jede Ressource ihre eigene Telephonseite besitzt und die Ressource nur in ihrer ungeschmückten funktionellen Form vorliegt, kann das HTTP-Schema für einen Zugriff unter Verwendung des GET-Verfahrens sowohl für die herunterladbare Dienstlogik als auch die Ausführung-An-Ort-Und-Stelle-Dienstlogik und das POST-Verfahren für die Protokollierungsressource verwendet werden. Wenn es erwünscht ist, Erklärungsmaterial mit jeder Dienstressource bereitzustellen, kann jegliche der oben erläuterten Lösungen bezüglich Datengegenständen verwendet werden.
  • Wenn mehr als eine Dienstressource einer Nummer zugeordnet ist, kann jede solche Ressource auf einer jeweiligen Telephonseite mit ihrem eigenen URI plaziert werden. Jedoch besteht der bevorzugte Lösungsansatz darin, alle derartigen Dienstressourcen auf der gleichen Seite zu plazieren und den RRI-Teil der entsprechenden Ressourcencodes zu verwen den, um einen Zugriff auf die geeignete Ressource zu ermöglichen. Die zugegriffene Ressource wird dann entsprechend ihrer Form behandelt (ausgeführt, wenn eine Ausführen-An-Ort-Und-Stelle-Dienstlogik, zurückgegeben, wenn herunterladbare Dienst-Daten oder -Logik).
  • Wenn folglich sowohl eine Umleitungsnummer-Dienstdatenressource als auch eine Uhrzeit-Ausführung-An-Ort-Und-Stelle-Dienstlogikressource auf der gleichen Telephonseite plaziert sind, könnte der Umleitungsnummer-Ressourcencode einen RRI von „1" aufweisen, während der Uhrzeit-Ressourcencode einen RRI-Wert von „2" aufweisen könnte.
  • Wenn Optionen des anrufenden/angerufenen Teilnehmers in einer Dienstressource zur Präsentation eines solchen Teilnehmers enthalten sein sollen, kann dies, wie bereits angezeigt wurde, bequemerweise geschehen, indem die Dienstressource als eine herunterladbare Dienstlogik aufgebaut ist, wobei die ausgewählte Option möglicherweise eine Anforderung für eine nachfolgende Dienstressource initialisiert.
  • Es ist klar, daß eine Dienstressource häufig von einem komplexen Typ ist, bei dem Dienstdaten und/oder eine herunterladbare Dienstlogik und/oder eine Ausführung-An-Ort-Und-Stelle-Dienstlogik kombiniert sind. Eine speziell leistungsstarke Kombination ist die Kombination von zwei Typen einer Dienstlogik, bei der die herunterladbare Dienstlogik entworfen ist, um mit der Ausführung-An-Ort-Und-Stelle-Dienstlogik zu interagieren; unter Verwendung dieser Anordnung können dem Benutzer komplexe Client-Server-Typ-Anwendungen geboten werden.
  • Beispielverwendung einer Dienstressource
  • 13 zeigt die Operation eines Diensts, der eine Ressource auf einem Server 51 verwendet. Dieser Dienst ist äquivalent einem „Persönliche-Nummer"-Dienst, durch den durch eine einzelne, unveränderliche Nummer auf einen Benutzer zugegriffen werden kann, selbst wenn er sich zwischen Telephonen mit unterschiedlichen realen Nummern bewegt. Um dies zu erreichen, wird dem Benutzer, der diesen Dienst anfordert (Benutzer B bei dem gegenwärtigen Beispiel) eine eindeutige persönliche Nummer (die hierin als die „Webtel"-Nummer von B bezeichnet wird, aus einem Satz von Nummern zugeteilt, bei denen alle die gleiche vordere Nummernfolge besitzen, um zu ermöglichen, daß eine SSP ohne weiteres eine angerufene Nummer als eine Webtel-Nummer identifiziert. Der Benutzer B besitzt eine Dienstressource 49 auf einer zweckgebundenen Telephonseite auf dem HTTP-Server 51, wobei sich diese Telephonseite an einem URL befindet, der hier als „URL(B-Telephonseite)" identifiziert ist. B's Telephonseite gibt, wenn auf sie zugegriffen wird, die momentane Roaming-Nummer („B-telNb") zurück, unter der B erreicht werden kann. Im einfachsten Fall ist B's Telephonseite nur eine einzige Nummer, die durch B modifiziert werden kann (beispielsweise von einem Endgerät 53), wenn sich B zu einem anderen Telephon bewegt. Es ist wahrscheinlicher, daß B's Telephonseite eine Ausführung-An-Ort-Und-Stelle-Dienstlogik ist, die eine Uhrzeit-Weiterleitung liefert.
  • Bei dem vorliegenden Beispiel ist die Zuordnung zwischen B's Webtel-Nummer und dem URL von B's Telephonseite in einer Zuordnungstabelle gespeichert, auf die die SCP 43 zugreifen kann.
  • Auf den Versuch eines Benutzers A hin, den Benutzer B zu kontaktieren, indem er die Webtel-Nummer von B wählt, leitet das Telephon 40, das durch A verwendet wird, eine Anrufverbindung-Aufbauanforderung zu der SSP 41 (es sei angemerkt, daß in 13 die Trägerwege durch das Telephonnetzwerk durch die dickeren Linien 60 gezeigt sind, während die anderen starren Linien Signalisierungsflüsse anzeigen). Die SSP 41 erfaßt die gewählte Nummer als eine Webtel-Nummer und sendet eine Dienstanforderung zu der SCP 43 zu sammen 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 Teil nehmers, 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 Dienstressourcen auf den Betrieb des PSTN ab. Wenn die Dienstressource einfach einen Datengegenstand zu einer zugreifenden Entität zurückgibt, ist es möglich, daß der Operator sich nicht zu sehr um mögliche Fehler (zufällig oder beabsichtigt) beim Implementieren der Dienstressource sorgt. Jedoch wird der Operator wahrscheinlich viel besorgter um den ordnungsgemäßen Betrieb jeder Dienstlogik sein, die durch eine Ressource zurückgegeben werden kann; tatsächlich ist es möglich, daß ein Operator eine solche Dienstressource nicht erlaubt.
  • Momentan sei angenommen, daß sich ein Operator nicht um die Beschaffenheit oder Implementierung von Dienstressourcen sorgt, wobei es dann stark von der Beschaffenheit des betroffenen Servers abhängt, wie eine Ressource auf einem Server 51 plaziert wird. Wenn ein Benutzer beispielsweise einen Computer mit einem Netzwerkzugriff auf das Internet besitzt und dieser Computer als Server 51 verwendet wird, kann der Benutzer einfach eine gewünschte Ressource als eine WWW-Telephonseite für einen externen Zugriff auf den Server laden. Eine ähnliche Situation tritt auf, wenn der Server ein Organisationsserver ist, auf den der Server über ein internes LAN Zugriff hat. In beiden diesen letztgenannten Fällen erfordert das Laden der Ressource als eine WWW-Telephonseite selbst keinen Internet-Zugriff. Wenn jedoch der Server 51 einer ist, der durch einen externen Internet-Dienstprovider läuft, kann es ein Benutzer einrichten, die erforderliche Dienstressource in den zugeordneten Web-Site-Raum des Benutzers auf dem Server herunterzuladen; dies kann einen Internet-Zugriff beinhalten, muß jedoch nicht. Ein Spezialfall dieses letztgenannten Szenarios liegt vor, wenn der PSTN-Operator einen speziellen Server für Benutzer-Telephonseiten, die Dienstressourcen enthalten, bereitstellt.
  • Das Plazieren einer Dienstressource auf einem Server wird allgemein das Freischalten von einem oder mehreren Leveln eines Paßwortschutzes beinhalten, es sei denn, der eigene Computer des Benutzers wirkt als Server 51.
  • 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 wur de). 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 Tele phonseite 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 Funktio nalitä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 Telephonseite als die Nummer, die für solche Übertragungen verwendet werden soll, spezifiziert ist, zu senden. Selbstverständlich kann das Plazieren eines Anrufs von A's Endgerät über das PSTN dem Problem eines Konflikts, das bereits erläutert wurde, für eine Verwendung der Telephonleitung, wenn dies keine ISDN-Leitung ist und A einen Internetzugriff über eine SLIP/PPP-Verbindung erlangt, unterworfen sein.
  • Wie auch immer der Anruf plaziert wird, existiert eine Anzahl von Möglichkeiten, wenn B's Telephon, das der Nummer, die von A versucht wird, entspricht, belegt ist. Wenn B eine Telephonseite besitzt, die eine Umleitungsnummer spezifiziert, und B diese Dienstressource bei dem PSTN registriert hat, sollte folglich die Umleitungsnummer automatisch durch das PSTN versucht werden. Wenn jedoch die Umleitungsnummer-Ressource nicht bei dem PSTN registriert wurde, wird ein Besetzt-Signal zu A zurückgegeben. Wenn A den Anruf durch ein Standardtelephon plaziert hat, muß A nun entscheiden, wie er fortfahren will, wobei A wählen kann, entweder aufzugeben oder wiederum auf B's Telephonseite zu verweisen, um die Umleitungsnummer nachzuschlagen und eine Neuwahl unter Verwendung dieser Nummer durchzuführen. Wenn A den ursprünglichen Anruf unter Verwendung seines Endgeräts 53 plaziert hat, kann das letztgenannte programmiert sein, um die Rückgabe eines Besetzt-Signals zu erfassen und dann automatisch B's Umleitungsnummer nachzuschlagen und eine Neuwahl unter Verwendung dieser Nummer durchzuführen. Diese Funktionalität kann in einer 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 Nummer, die für B gewählt werden soll, geliefert wurde, zu A's Endgerät geleitet worden wäre).
  • Die Dienstressource, auf die auf B's Telephonseite daraufhin, daß B's Telephon besetzt ist, zugegriffen wird, kann selbstverständlich komplexer sein als nur eine Umleitungsnummer. Insbesondere kann dem Benutzer A ein Bereich von Optionen geboten werden, einschließlich beispielsweise B's Fax- oder Sprach-Mailbox-Nummer, wobei die Auswahl einer Option möglicherweise den Ablauf einer geeigneten Zugriffsoftware einleitet. Eine weitere mögliche Option für A bestünde darin, B eine Rückrufnachricht unter Verwendung eines Formulars, das von B's Telephonseite heruntergeladen wird, nachdem diese Option gewählt worden ist, zu lassen; das ausgefüllte Formular würde zu dem Server 51 zurückversendet und zur Überprüfung zu gegebener Zeit für B protokolliert werden.
  • Selbstverständlich kann der Fall auftreten, daß der Benutzer A auf B's Telephonseite zugreifen möchte, um beispielsweise B's momentane Roaming-Nummer herauszufinden, daß jedoch der Benutzer A den URI von B's Web-Site nicht kennt und nur B's Webtel-Nummer besitzt. A könnte B nur durch das PSTN anrufen, wobei in diesem Fall die Übersetzung von B's Webtel-Nummer in die Roaming-Nummer automatisch bewirkt werden würde (unter der Annahme, daß B noch für diesen Dienst registriert ist); es kann jedoch sein, daß AB nicht geradewegs anrufen möchte, sondern nur seine momentane Roaming-Nummer erfahren möchte. Um A's Problem zu lösen, sind die vorher beschriebenen Webtel-Zu-URI-Zuordnungstabellen vorzugsweise an einer bekannten Adresse (beispielsweise einer bekannten Web-Site) im Internet zugreifbar. Alles, was A nun tun muß, besteht darin, auf diese Web-Site zuzugreifen, wobei B's Webtel-Nummer weitergeleitet wird; B's Telephonseiten-URI wird dann zu A zurückgegeben, der diesen dann verwenden kann, um auf B's Telephonseite zuzugreifen. Dieser Prozeß kann selbstverständlich von dem Punkt an automatisiert werden, an dem AB'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 Aus lö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 AB 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 AB 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 Formu lar, 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-Untersystem geleitet werden.
  • „Gebührenfreie" Dienste auf WWW-Basis (800-Nummer)
  • Es ist möglich, einen „gebührenfreien" oder „800-Nummer"-Typ eines Dienstes unter Verwendung einer Kombination von WWW und PSTN zu implementieren. Wie aus der folgenden Beschreibung eines solchen Dienstes Bezug nehmend auf 17 zu sehen ist, stützt sich eine WWW/PSTN-Implementierung nicht notwendigerweise entweder auf eine Übertragung von Anrufgebühren von dem anrufenden auf den angerufenen Teilnehmer oder auf die Verwendung einer speziellen „800"-Nummer, zwei Charakteristika von üblichen „gebührenfreien" Schemata. Die WWW/PSTN-Implementierungen besitzen jedoch die allgemeinere Charakteristik des Plazierens eines anfragenden Teilnehmers und des Teilnehmers, an den die Anfrage gerichtet ist, in einen telefonischen Kontakt auf Kosten des letztgenannten Teilnehmers.
  • Bei der Anordnung von 17 besitzt ein Benutzer D, wie z. B. ein großes Warenhaus, eine Web-Site auf einem Server 51; zu Zwecken der Einfachheit wird angenommen, daß der Server unter der Steuerung eines Benutzers D ist, der einen direkten Computerzugriff auf den Server über eine Leitung 125 hat. D's Web-Site kann beispielsweise viele katalogartige Web-Seiten enthalten, die Waren zeigen, die durch D zum Verkauf angeboten werden. Darüber hinaus besitzt D eine Gebührenfrei-Seite 124 zum Handhaben von Anfragen, die auf einer gebührenfreien Basis plaziert werden; der URL dieser Seite ist einem „Gebührenfrei"-Graphikknopf 122 zugeordnet, der auf jeder der Web-Site-Katalogseiten plaziert ist.
  • Es sei angenommen, daß der Benutzer A am Endgerät 53 D's Website durchstöbert und die Katalogseiten betrachtet (Pfeil 121). Wenn A einen interessierenden Gegenstand sieht und wünscht, eine Anfrage an D über diesen Gegenstand zu stellen, aktiviert A am Endgerät 53 den Graphik-Gebührenfrei-Knopf 122, der der betreffenden Katalogseite zugeordnet ist. Diese Aktivierung bewirkt, daß der Code, der in die Katalogseite, die momentan in A's Endgerät geladen ist, eingebettet ist, den Benutzer veranlaßt, seine Telephonnummer einzugeben und optional seinen Namen, woraufhin eine HTTP-Anforderung zu D's Gebührenfrei-Seite unter Verwendung des POST-Verfahrens und beinhaltend die eingegebenen Daten gesendet wird (Pfeil 123). Auf das Empfangen dieser Anforderung hin führt D's Gebührenfrei-Seite eine Dienstlogik durch, um eine neue Anfrage (die A's Namen und Telephonnummer einschließt) in eine Anfragewarteschlange 127, die in einem Anfragesteuersystem 126 gehalten ist, einzugeben. Bei dem gegenwärtigen Beispiel ist das Anfragesteuersystem über die Leitung 125 außerhalb des Internets mit dem Server 51 verbunden; es wäre jedoch auch möglich, daß der Server 51 mit dem Anfragesteuersystem durch das Internet kommuniziert, wobei dies tatsächlich die zweckmäßigste Anordnung sein kann, wobei sich D's Website auf einem ISP-Server befindet, und nicht auf einem Server, der durch D gesteuert wird. Tatsächlich könnte der Code, der in A's Endgerät auf eine Aktivierung des Gebührenfrei-Graphikknopfs 122 hin abläuft, angeordnet sein, um die Anfrageanforderung direkt zu dem Anfragesteuersystem über das Internet weiterzuleiten, und nicht dieselbe zu dem Server 51 zurückzuleiten.
  • Das Anfragesteuersystem 126 verwaltet Anfragen, die zu demselben geleitet werden, um sicherzustellen, daß dieselben auf eine geordnete Art und Weise gehandhabt werden. Das System 126 schätzt auf den Empfang einer neuen Anfrage hin vorzugsweise ab, wie lange es dauert, bevor die Anfrage behandelt wird, wobei diese Abschätzung auf der Anzahl von gegenwärtig in der Warteschlange befindlichen Anfragen und der mittleren Zeit, die benötigt wird, um eine Anfrage zu handhaben, basiert. Diese Abschätzung einer Wartezeit wird über den Server 51 in der Antwort auf die POST-Anforderungsnachricht zu dem Benutzer A zurückgeleitet.
  • Das Anfragesteuersystem 126 schaut nach der Verteilung von Anfragen zu einer Anzahl von Vertretern, von denen jeder mit einem Telephon 40 und einer Anzeige 129 ausgestattet ist. A's Anfrage wird behandelt, sobald sie den Kopf der Warteschlange 127 erreicht und erfaßt wird, daß ein Vertreter verfügbar ist, um die Anfrage zu handhaben (beispielsweise kann das System angeordnet sein, um zu erfassen, wann das Telephon eines Vertreters aufgelegt wird). Wenn diese Bedingungen erfüllt sind, nimmt eine Verteilungs- und Aufbau-Steuereinheit 128 A's Anfrage und zeigt A's Namen und Telephonnummer auf der Anzeige 129 des verfügbaren Vertreters (der der Klarheit halber hierin als Vertreter D' bezeichnet wird) an; wenn der Benutzer D eine Datenbank von D's vergangenen Kunden oder Kreditfähigkeitsdaten hält, wird die Einheit 128 auch nach derartigen weiteren Informationen, die über A bekannt sind, suchen und dieselben anzeigen. Gleichzeitig führt die Einheit 128 eine Dritte-Partei-Anrufverbindungsaufbau-Anforderung (Pfeil 130) über das Internet zu dem Netzübergang 90 durch, mit der Bitte, eine Anrufverbindung zwischen dem Telephon des verfügbaren Vertreters D' und dem Telephon des Benutzers A aufzubauen, wobei beide Telephone durch ihre jeweiligen Nummern identifiziert sind. Wenn sowohl D' als auch A den Anruf 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 Telephon aufzubauen. Die Lösungen, die bezüglich der 11 und 13 erläutert wurden, können auch hier verwendet werden (Beendigung der Internetzsitzung; Multiplexen von Sprach- und Internet-Daten auf der gleichen Telephonleitung; und Plazieren des Anrufs über das Internet zu A's Endgerät). Bezüglich der Lösung, die auf der Beendigung der Internetsitzung basiert, könnte eine solche Beendigung verzögert werden, bis A's Anfrage an der Reihe war, um behandelt zu werden; um dies durchzuführen, wäre es jedoch notwendig, ein Feedback von dem Steuersystem 126 über das Internet zu A's Endgerät 53 zu liefern und dieses Feedback einem Code zum Bewirken der Internetsitzungsbeendigung zuzuordnen. Eine Möglichkeit, um dies zu erreichen, bestünde darin, daß die Antwortnachricht, die durch den Server 51 ansprechend auf die ursprüngliche POST-Anforderungsnachricht von A gesendet wird, einen Korrelationscode beinhaltet; jegliches nachfolgendes Feedback von dem System 126, die zu A geleitet wird, würde ebenfalls diesen Code beinhalten (wobei der Server A den Code ebenfalls zu dem Steuersystem 126 lei tet), 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 Pe rioden, zu denen eine Anfrage in einer Warteschlange ist und darauf wartet, gehandhabt zu werden, auflaufen.
  • Varianten
  • Bei dem vorhergehenden Beispielen wurden die Dienstressourcenelemente auf Server 41 platziert, die mit dem Internet verbunden sind, und auf eine gewünschte Dienstressource würde dann über das Internet durch das Dienststeuerteilsystem des PSTN und/oder durch Internetbenutzer zugegriffen, durch die Verwendung eines URI, der von einem Ressourcencode abgeleitet wird, der das gewünschte Dienstressourcenelement identifiziert. Bei der Anordnung zum Ableiten des URI von einem Ressourcencode in der Form einer Telefonnummer wird die gesamte oder ein Teil der Telefonnummer in Domainnamenform syntaktisch ausgewertet und dann in einen URI aufgelöst, unter Verwendung eines verteilten DNS-Typ-Datenbanksystems, das in der Tat in das DNS selbst integriert sein könnte (siehe 11 und 12 und verwandte Beschreibung).
  • Selbstverständlich sind viele Varianten der oben beschriebenen Anordnungen möglich und eine Anzahl dieser Varianten wird nachfolgend beschrieben.
  • Wie in 15 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.
  • Obwohl das Dienststeuerungsteilsystem des PSTN bei den vorhergehenden Beispielen als eine SCP ausgeführt wurde, ist klar, dass die Funktionalität des Dienststeuerungsteilsystems als Teil eines SSP oder in einem zugeordneten Adjunct vorgesehen sein könnte. Ferner kann das Auslösen von Dienstanforderungen durch andere Ausrüstung als SSPs bewirkt werden, beispielsweise durch Unterbrechungsblöcke, die in die SS7-Signalisierungsverbindungen eingebracht sind.
  • 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 (22)

  1. Ein Verfahren zum Zugreifen auf Kommunikationsdaten, die für eine Zielentität (B) relevant sind, die durch eine Zahlenzeichenfolge („B-Webtel") identifiziert werden, wobei das Verfahren folgende Schritte umfasst: e) Speichern von Datensätzen in einem Datenbanksystem vom Domain-Name-System-Typ, die jeweils einem entsprechendem Domainnamen zugeordnet sind und einen Einheitsressourcenidentifizierer, URI, halten, zum Lokalisieren von Kommunikationsdaten, die dem Domainnamen zugeordnet sind, wobei jeder Domainname auf eine jeweilige Zahlenzeichenfolge („B-Webtel") bezogen ist, aus der derselbe durch einen Prozess abgeleitet werden kann, der ein syntaktisches Analysieren (120) von zumindest einem wesentlichen Abschnitt der Zahlenzeichenfolge in zumindest einen Teil des Domainnamens umfasst; f) Anwenden des Prozesses (120) auf die Zahlenzeichenfolge („B-Webtel"), die die Zielentität identifiziert, wodurch der verwandte Domainname gebildet wird; g) Zuführen (121) des Domainnamens, der in Schritt b) gebildet wird, zu dem DNS-Typ-Datenbanksystem, um den URI wiederzugewinnen, der in dem entsprechenden Datensatz gespeichert ist; und h) Verwenden (123) des URI, der in Schritt c) wiedergewonnen wird, um auf die Kommunikationsdaten zuzugreifen.
  2. Ein Verfahren gemäß Anspruch 1, bei dem der URI, der in zumindest einem der Datensätze gespeichert ist, der URI für die Kommunikationsdaten selbst ist.
  3. Ein Verfahren gemäß Anspruch 1, bei dem der URI, der in zumindest einem der Datensätze gespeichert ist, von einer Funktionalität (51, 58, 64) ist, die Zugriff zu mehreren Elementen (49) von Kommunikationsdaten hat, wobei Schritt d) das Verwenden des URI umfasst, um auf die Funktionalität zuzugreifen und derselben einen Indikator (RRI) des gewünschten Elements von Kommunikationsdaten zuzuführen, wobei diese Daten dann durch die Funktionalität zurückgesendet werden.
  4. Ein Verfahren gemäß Anspruch 3, bei dem der Indikator (RRI) in dem URI enthalten ist und in dieser Form zu der Funktionalität zugeführt wird.
  5. Ein Verfahren gemäß Anspruch 3, bei dem der Indikator (RRI) als ein von dem URI getrenntes Element zu der Funktionalität zugeführt wird.
  6. Ein Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem der URI, der in der zumindest einem der Datensätze gespeichert ist, ein Einheitsressourcenlokator, URL, ist, der ein Zugriffsschema und eine Hostadresse umfasst.
  7. Ein Verfahren gemäß Anspruch 6, bei dem die Hostadresse ein Domainname ist.
  8. Ein Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem jede Zahlenzeichenfolge („B-Webtel") in Telefonnummerform ist.
  9. Ein Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem die verteilte DNS-Typ-Datenbank das Domainnamensystem des Internets (50) ist.
  10. Ein Verfahren zum Zugreifen auf eine Zielentität (B) über ein Telefonnetzwerk („PSTN"), das folgende Schritte umfasst: Zugreifen auf Kommunikationsdaten, die relevant für die Zielentität (B) sind, gemäß dem Verfahren von einem der vorhergehenden Ansprüche, wobei die Kommunikationsdaten in der Form einer Telefonnummer für die Zielentität (B) sind, und Verwenden dieser Telefonnummer zum Anrufen der Zielentität (B) über das Telefonnetz.
  11. Ein Computerprogrammprodukt, das für die Verwendung mit einer Rechnerressource (46; 53) vorgesehen ist, die eine Anschlussfähigkeit zu einem Computernetz (50) aufweist, um einen Zugriff auf entfernt gespeicherte Kommunikationsdaten zu ermöglichen, die eine Zielentität (B) betreffen; wobei das Computerprogrammprodukt angeordnet ist, um der Rechenressource, wenn das Computerprogramm ausgeführt wird, folgendes bereitzustellen: – eine erste Einrichtung (46) zum Bilden eines Domainnamens aus einer Zahlenzeichenfolge („B-Webtel"), die die Zielentität (B) identifiziert, durch einen Prozess, der ein syntaktisches Analysieren (120) von zumindest einem wesentlichen Abschnitt der Zahlenzeichenfolge in zumindest einen Teil des Domainnamens umfasst; – eine zweite Einrichtung (46), die wirksam ist, um die Netzwerkanschlussfähigkeit der Rechenressource zu verwenden, um den Domainnamen einem Datenbanksystem vom Domainnamensystem-, DNS-, Typ zuzuführen und einen Ressourcendatensatz zurückempfangen, der einen einheitlichen Ressourcenidentifizierer, URI, zum Lokalisieren von Kommunikationsdaten umfasst, die dem Domainnamen zugeordnet sind; und – eine dritte Einrichtung (46) zum Verwenden des URI zum Zugreifen auf die Kommunikationsdaten.
  12. Ein Produkt gemäß Anspruch 11, bei dem der URI der URI der Kommunikationsdaten selbst ist.
  13. Ein Produkt gemäß Anspruch 11, bei dem der URI eine Funktionalität (51, 58, 64) aufweist, die Zugriff auf mehrere Elemente (49) von Kommunikationsdaten hat, wobei die dritte Einrichtung (46) wirksam ist, um diesen URI zu verwenden, und um auf die Funktionalität zuzugreifen, und demselben einen Indikator des gewünschten Elements von Kommunikationsdaten zuzuführen, und dieses Element von der Funktionalität zurückzuempfangen.
  14. Ein Produkt gemäß Anspruch 13, bei dem die dritte Einrichtung wirksam ist, um den Indikator in den URI aufzunehmen und in dieser Form der Funktionalität (51, 58, 64) zuzuführen.
  15. Ein Produkt gemäß Anspruch 13, bei dem die dritte Einrichtung wirksam ist, um einen Indikator zu der Funktionalität (51, 58, 64) als ein von dem URI getrenntes Element zu liefern.
  16. Ein Produkt gemäß einem der Ansprüche 11 bis 15, bei dem der URI, der in zumindest einem der Datensätze gespeichert ist, ein Einheitsressourcenlokator, URL, ist, der ein Zugriffsschema und eine Hostadresse umfasst.
  17. Ein Produkt gemäß einem der Ansprüche 11 bis 16, bei dem die verteilte DNS-Typ-Datenbank das Domainnamensystem des Internets (50) ist.
  18. Ein Server eines Domainnamensystem-, DNS-, Typs eines verteilten Datenbanksystems, wobei der Server zumindest einen Ressourcendatensatz (RR) hält, zum Bereitstellen einer Abbildung von einem Domainnamen, der dem Datensatz zugeordnet ist, auf einen Einheitsressourcenidentifizierer, URI, der in dem Datensatz gehalten wird, und verwendet werden kann, um Kommunikationsdaten zum Kontaktieren einer Zielentität (B) zu finden, wobei zumindest ein wesentlicher Abschnitt des Domainnamens in der Form einer Zahlenzeichenfolge („B-Webtel") ist, die die Zielentität (B) identifiziert, die in mehrere Domainnamenetiketten zerlegt wurde, um dem verteilten DNS-Typ-Datenbanksystem zugeführt zu werden, für eine Wiedergewinnung des URI, der in dem entsprechenden Datensatz gehalten wird.
  19. Ein Server gemäß Anspruch 18, bei dem der URI ein Einheitsressourcenlokator, URL, ist, der ein Zugriffsschema und eine Hostadresse zum Zugreifen auf die Kommunikationsdaten umfasst.
  20. Ein Server gemäß Anspruch 18, bei dem die Zahlenzeichenfolge („B-Webtel") zumindest ein wesentlicher Abschnitt einer Telefonnummer ist.
  21. Ein Server gemäß Anspruch 18, bei dem der URI von einer Funktionalität (51, 58, 64) ist, die Zugriff auf mehrere Elemente (49) von Kommunikationsdaten hat.
  22. Ein Server gemäß einem der Ansprüche 18 bis 21, bei dem die verteilte DNS-Typ-Datenbank das Domainnamensystem des Internets (50) ist.
DE69633205T 1996-02-20 1996-12-11 Zugriff zu Kommunikationsdateien Expired - Lifetime DE69633205T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB9603590 1996-02-20
GBGB9603590.2A GB9603590D0 (en) 1996-02-20 1996-02-20 Method of accessing a target entity over a communciations network

Publications (2)

Publication Number Publication Date
DE69633205D1 DE69633205D1 (de) 2004-09-23
DE69633205T2 true DE69633205T2 (de) 2005-07-14

Family

ID=10789104

Family Applications (2)

Application Number Title Priority Date Filing Date
DE69633205T Expired - Lifetime DE69633205T2 (de) 1996-02-20 1996-12-11 Zugriff zu Kommunikationsdateien
DE69632495T Expired - Lifetime DE69632495T2 (de) 1996-02-20 1996-12-11 DNS-basierte Feststellung einer Telefonnummer zum Kontaktieren einer Zielstelle

Family Applications After (1)

Application Number Title Priority Date Filing Date
DE69632495T Expired - Lifetime DE69632495T2 (de) 1996-02-20 1996-12-11 DNS-basierte Feststellung einer Telefonnummer zum Kontaktieren einer Zielstelle

Country Status (10)

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

Families Citing this family (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3084681B2 (ja) * 1996-12-06 2000-09-04 財団法人流通システム開発センタ− 統合情報通信システム
US5974453A (en) * 1997-10-08 1999-10-26 Intel Corporation Method and apparatus for translating a static identifier including a telephone number into a dynamically assigned network address
DE19747583B4 (de) * 1997-10-28 2006-04-20 Telefonaktiebolaget Lm Ericsson (Publ) Kommunikationssystem und Verfahren
WO1999028979A2 (en) * 1997-12-02 1999-06-10 Alcatel Usa Sourcing, L.P. Digital phone system
WO1999029083A1 (en) * 1997-12-02 1999-06-10 Alcatel Usa Sourcing, L.P. Method and apparatus for dynamic domain names
GB2338875B (en) * 1997-12-05 2000-08-30 Distrib Syst Res Inst Integrated information communication system
US6215784B1 (en) * 1997-12-24 2001-04-10 Nortel Networks Limited Method and system for voice call completion using information retrieved from an open application on a computing machine
IL125432A (en) 1998-01-30 2010-11-30 Easynet Access Inc Personalized internet interaction
IL123129A (en) 1998-01-30 2010-12-30 Aviv Refuah Www addressing
EP0964567A3 (de) * 1998-06-12 2002-01-02 Alcatel USA Sourcing, L.P. Programmierbare Telecommunicationsschnittstelle für Kommunikation über ein Datennetzwerk
GB9815585D0 (en) * 1998-07-18 1998-09-16 Fitton Stuart J Computer network addressing system
AU3140500A (en) * 1999-03-26 2000-10-16 Nortel Networks Limited Control node with intelligent network
KR20020081049A (ko) * 1999-05-27 2002-10-26 인터넷 매니지먼트 시스템스 인코포레이티드 단일 어드레스 스트링을 이용하여 다양한 통신 응용들을통하여 통신하기 위한 시스템 및 방법
US6963928B1 (en) 1999-05-27 2005-11-08 Bagley David T Systems and methods for communicating across various communication applications using single address strings
MXPA02000287A (es) * 1999-07-09 2004-05-21 Mark J Harris Sistema y metodo para dirigir una red utilizando numeros telefonicos.
NL1012721C2 (nl) * 1999-07-28 2001-01-30 Benno Henricus Nicolaas Hijl Inrichting voor registratie, adressering, structurering en het vinden van entiteiten en gegevens, gebaseerd op identificatiecodes.
WO2001029710A2 (en) * 1999-10-15 2001-04-26 Nametree, Inc. Derivative domain names
SE517354C2 (sv) * 1999-12-01 2002-05-28 Ericsson Telefon Ab L M System och ett förfarande för privat telekommunikationsnät
SE517319C2 (sv) * 1999-12-01 2002-05-28 Ericsson Telefon Ab L M System och anordning i privata telekommunikationssystem där IP-nät används för signalering rörande förfrågnings- och svarsmeddelanden
US8548010B2 (en) 2000-01-19 2013-10-01 Sony Corporation Method and apparatus for event-based synchronization of information between communication devices
US9781257B2 (en) 2000-01-19 2017-10-03 Sony Mobile Communications Ab Technique for obtaining caller-originated alert signals in IP-based communication sessions
US8400946B2 (en) 2000-01-19 2013-03-19 Sony Corporation System and method for sharing common location-related information between communication devices
US6826403B1 (en) 2000-09-12 2004-11-30 Phonepages Of Sweden Ab Method and system for identifying a user
DE10053717B4 (de) * 2000-10-28 2004-05-19 Web.De Ag Verfahren und Vorrichtung zum Aufbau einer Telefonverbindung über eine Internet-Telefonieanwendung
US7027582B2 (en) * 2001-07-06 2006-04-11 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for resolving an entity identifier into an internet address using a domain name system (DNS) server and an entity identifier portability database
US20030074461A1 (en) * 2001-10-09 2003-04-17 I-Dns.Net International Pte. Ltd. Method of mapping names or identifiers to telecommunications network resource locations
US11341497B2 (en) * 2001-10-24 2022-05-24 Oleg Serebrennikov Method for performing transactional communication using a universal transaction account identifier assigned to a customer
WO2003060712A2 (en) * 2002-01-15 2003-07-24 Idetic, Inc. Method and system of accessing shared resources using configurable management information bases
US7161933B2 (en) 2002-09-24 2007-01-09 Intel Corporation Optimistic caching for address translations
FI20030797A0 (fi) * 2003-05-27 2003-05-27 Nokia Corp Tietokannan suorituskyvyn parantaminen nimipalvelinjärjestelmässä
US7454569B2 (en) * 2003-06-25 2008-11-18 Commvault Systems, Inc. Hierarchical system and method for performing storage operations in a computer network
US7961852B2 (en) 2003-12-19 2011-06-14 France Telecom Method and device for transmitting requests from a requesting machine to a domain name server
CN100359874C (zh) * 2004-01-12 2008-01-02 华为技术有限公司 接收方所在的多媒体业务中心获取私网地址的方法
CN1314239C (zh) * 2004-03-31 2007-05-02 中国科学院计算技术研究所 一种移动自组织网络中域名***的实现方法
CN1878164A (zh) * 2005-06-08 2006-12-13 华为技术有限公司 E.164号码域名存储和查询方法
US20070091878A1 (en) * 2005-09-30 2007-04-26 Marian Croak Method and apparatus for providing endpoint and access independent virtual numbers
EP2030418A2 (de) * 2006-05-15 2009-03-04 France Telecom Nichtstandardmässiges nummern-routingverfahren in einem standardmässigen routing-mechanismus
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
BRPI0908241A2 (pt) * 2008-02-22 2019-09-24 Sage Connex Llc portal de dados pessoais em um pstn e online home com salas e objetos virtuais
JP5753999B2 (ja) 2013-09-12 2015-07-22 メタフロンティア合同会社 端末装置、データ処理プログラム、及びデータ管理システム
CN103905581A (zh) * 2014-02-26 2014-07-02 曾宪钊 基于行为差异性的dns高速解析方案和配套的抗流量类攻击安全方案
US10673681B2 (en) * 2017-03-15 2020-06-02 Charles Lap San Chan System and method for enabling cross-domain communication over network
CN109787907A (zh) * 2017-11-14 2019-05-21 北京星河星云信息技术有限公司 一种云智能dns调度***及其用户接入和域名解析方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2173304C (en) * 1995-04-21 2003-04-29 Anthony J. Dezonno Method and system for establishing voice communications using a computer network

Also Published As

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

Similar Documents

Publication Publication Date Title
DE69633205T2 (de) Zugriff zu Kommunikationsdateien
DE69634608T2 (de) Verbindungsaufbaudurchgang für ein fernmeldesystem
DE69634854T2 (de) Verfahren zum zugreifen auf dienstmittelgegenstande für anwendung in einem fernmeldesystem
DE69635386T2 (de) Verfahren zum Bereitstellen von Telekommunikationsdiensten
DE69708266T2 (de) Verfahren zur verfügungsstellung von inhaltsbetriebmitteln für telefonnetzbenutzers
DE602005002150T2 (de) Verfahren und Vorrichtung zur Bereitstellung von universellen Fernmelderelaisdiensten
DE69838788T2 (de) Anruferidentifizierungs-verwaltungssystem in fernsprechnetzen mit telefonnummernübertragbarkeit
DE69921169T2 (de) Intelligentes netz
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
DE60117713T2 (de) Verfahren zum transferieren von teilnehmerdaten zwischen verschiedenen servern eines telekommunikationsnetzes

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

Country of ref document: EP

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