DE60112982T2 - Einrichtung zur Bereitstellung von Server-Inhalten - Google Patents

Einrichtung zur Bereitstellung von Server-Inhalten Download PDF

Info

Publication number
DE60112982T2
DE60112982T2 DE60112982T DE60112982T DE60112982T2 DE 60112982 T2 DE60112982 T2 DE 60112982T2 DE 60112982 T DE60112982 T DE 60112982T DE 60112982 T DE60112982 T DE 60112982T DE 60112982 T2 DE60112982 T2 DE 60112982T2
Authority
DE
Germany
Prior art keywords
content
content data
connection method
retrieval request
location information
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 - Fee Related
Application number
DE60112982T
Other languages
English (en)
Other versions
DE60112982D1 (de
Inventor
Takuya Neyagawa-shi Kobayashi
Seiji Osaka-shi URA
Hiromi Neyagawa-shi Wada
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.)
Panasonic Holdings Corp
Original Assignee
Matsushita Electric Industrial Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Matsushita Electric Industrial Co Ltd filed Critical Matsushita Electric Industrial Co Ltd
Publication of DE60112982D1 publication Critical patent/DE60112982D1/de
Application granted granted Critical
Publication of DE60112982T2 publication Critical patent/DE60112982T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/957—Browsing optimisation, e.g. caching or content distillation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols

Description

  • HINTERGRUND DER ERFINDUNG
  • Gebiet der Erfindung
  • Die vorliegende Erfindung bezieht sich auf eine Inhalteabrufvorrichtung, und genauer auf eine Inhalteabrufvorrichtung, die konstruiert ist, die Verwendung einer Vielzahl an Verbindungsverfahren zu verwenden und Inhaltsdaten von einem Server über ein Kommunikationsnetzwerk unter einem optimalen Verbindungsverfahren abzurufen.
  • Beschreibung des Standes der Technik
  • In den vergangenen Jahren hat das Browsen von Homepages (Webseiten) und Austauschen von Emails in dem Internet große Beliebtheit erreicht. Um auf das Internet zuzugreifen, bedient der Verwender eine Inhalteabrufvorrichtung, versinnbildlicht durch ein Mobiltelefon. Die Inhalteabrufvorrichtung baut zuerst eine Verbindung zu einem Netzwerk, das der Verwender abboniert hat (z.B. ein mobiles Kommunikationsnetzwerk), zum Zugriff auf das Internet auf. Die Inhalteabrufvorrichtung greift dann auf einem Server auf dem Internet zu und ruft gemäß der Bedienung durch den Verwender über das Netzwerk Inhaltsdaten ab, versinnbildlicht durch eine Homepage oder eine Email.
  • Üblicherweise haben, teilweise wegen einer niedrigen Übertragungsrate in einem Netzwerk, Server hauptsächlich Inhaltsdaten geringer Größe, wie Textdateien und Stillbilderdateien, gehandhabt. Mit den technologischen Fortschritten in letzter Zeit jedoch, in welchen die Inhalteabrufvorrichtungen verbesserte Leistungen erreicht haben und die Übertragungsrate in einem Netzwerk sich dramatisch verbessert hat. Dementsprechend sind Server nun in der Lage, Inhaltsdaten großer Größe zu handhaben, wie Bewegtbilddateien und Audiodateien.
  • Herkömmliche Inhalteabrufvorrichtungen greifen auf ein Netzwerk zu unter einer der beiden Verbindungsverfahren, leitungsvermittelter Verbindung und paketvermittelter Verbindung. In der leitungsvermittelten Verbindung wird ein physischer Kommunikationspfad zwischen einem Anrufer und einem Anrufsempfänger etabliert. Da der Anrufer und der Anrufsempfänger einen Kommunikationspfad von dem Beginn eines Rufs bis zum Ende desselben in der leitungsvermittelten Verbindung belegen, ist die Datenkommunikation zwischen dem Anrufer und dem Anrufsempfänger frei von Einfluss auf andere Datenkommunikation. Das heißt, die Kommunikationsverzögerung, welche Zeit bedeutet, die benötigt wird, um Daten von einem Sender zu einem Empfänger zu liefern, kann im Wesentlichen konstant gemacht werden, und daher ist es einfach, eine Übertragungsrate sicherzustellen. Mit dieser Eigenschaft ist die leitungsvermittelte Verbindung geeignet für Anlässe des Übertragens von Inhaltsdaten großer Größe zu dem gleichen Empfänger, wie Multimedia-Telefone und Verbreitung von Bewegtbildern.
  • In der paketvermittelten Verbindung ist ein Kommunikationspfad nicht durch einen Anruf belegt, sondern wird mit anderen Anrufen geteilt, im Gegensatz zu der leitungsvermittelten Verbindung. Auf dem geteilten Kommunikationspfad werden Daten in Pakete unterteilt und zusammen mit anderen Paketen für andere Anrufaustäusche übertragen. Die paketvermittelte Verbindung erlaubt daher effektive Verwendung von Kommunikationspfadressourcen und daher Reduktion der Kommunikationskosten. Jedoch erzeugt die paketvermittelte Verbindung Schwierigkeiten, wie Paketverlust und Umkehr der Ordnung des Ankommens von Paketen, und versagt daher, konstante Kommunikationsverzögerung zu erzielen, anders als die leitungsvermittelte Verbindung. Das heißt, in der paketvermittelten Verbindung ist es nicht einfach, eine Übertragungsrate sicherzustellen. Da Pakete für einen Anrufaustausch von denjenigen für andere Anrufaustausche unterschieden werden müssen, enthält zudem jedes Paket Identifikatoren, welche den Sender und den Empfänger repräsentieren, zusätzlich zu den zu übertragenden Daten. Die effektive Übertragungsrate ist daher in der paketvermittelten Verbindung niedriger als in der leitungsvermittelten Verbindung. Die effektive Übertragungsrate, wie sie hierin verwendet wird, bezieht sich auf die Übertragungsrate allein für Daten, wobei sie Kontrollinformation, wie Identifikatoren, ausschließt. Angesichts des Obigen ist die paketvermittelte Verbindung geeignet für Anlässe, wo Kommunikationsverzögerung kein signifikantes Problem darstellt, oder wo Datenkommunikation nicht immer aktiv ist über die Anrufsperiode, wie Austäusche von Emails.
  • Auf herkömmliche Weise haben die Inhalteabrufvorrichtungen nur eine der leitungsvermittelten Verbindung oder paketvermittelten Verbindung verwendet. In jüngerer Zeit wurde eine Inhalteabrufvorrichtung entwickelt, welche selektiv entweder die leitungsvermittelte Verbindung oder die paketvermittelte Verbindung verwenden kann. Als Beispiel solch einer Inhalteabrufvorrichtung ist eine Inter-LAN-Verbindungsvorrichtung im japanischen Patentblatt Nr. 2625388 offenbart. Die Inter-LAN-Verbindungsvorrichtung ist angewandt auf Systeme, welche Datenkommunikation über ISDN (Integrated Services Digital Network) ausführen. Die Inter-LAN-Verbindungsvorrichtung überwacht die Datentransfermenge auf einem Kommunikationspfad, und wählt entweder die leitungsvermittelte Verbindung oder die paketvermittelte Verbindung, basierend auf der Datenübertragungsmenge und der Kommunikationsverkehrsmenge, welche Kommunikationsdichte von Daten auf einem Kommunikationspfad bedeuten, für jede Transaktion.
  • Die Inter-LAN-Verbindungsvorrichtung überwacht Datenkommunikation, die gegenwärtig ausgeführt wird, und wählt entweder die leitungsvermittelte Verbindung oder die paketvermittelte Verbindung basierend auf dem Status der überwachten Datenkommunikation. Daher ist es schwierig für die Vorrichtung, das für kommende Datenkommunikation geeignete Verbindungsverfahren auszuwählen. Die Inter-LAN-Verbindungsvorrichtung hat ein anderes Problem wie folgt. Das Verbindungsverfahren kann geschaltet werden abhängig von dem Status der Datenkommunikation. Bei solch einem Ereignis wird eine Kommunikationsverzögerung verursacht durch die Zeit, die benötigt wird, um das Umschalten von einem Verbindungsverfahren auf das andere zu vervollständigen, wenn kontinuierliche Datenkommunikation ohne Unterbrechung benötigt wird, z.B. wenn eine Bewegtbilddatei übertragen wird. Angesichts des Obigen ist die Inter-LAN-Verbindungsvorrichtung nicht geeignet für Daten, die eine Natur haben, dass Kommunikationsverzögerung und Unterbrechung von Datenkommunikation fatal sind.
  • Um die obigen Probleme zu lösen, ist die Inter-LAN-Verbindungsvorrichtung mit einem Transaktionsinformationssetzabschnitt versehen, welcher ein Attribut an Daten, die für jede Transaktion ausgetaucht werden, als Transaktionsinformation setzt. Durch Bezugnahme auf den Transaktionsinformationssetzabschnitt werden kommende auszutauschende Daten vorhergesagt und ein geeignetes Verbindungsverfahren für die Daten wird ausgewählt. Jedoch sind auf dem Internet verschiedene Arten an Daten, wie Textdateien, Bewegtbilddateien und Audiodateien, verfügbar. Daher ist es für die Inter-LAN-Verbindungsvorrichtung schwierig, kommende auszutauschende Daten korrekt vorherzusagen.
  • Andere solche Systeme, die Gebrauch machen, sind offenbart in US 5,838,682 und WO 99/66747. Die US 5,838,682 offenbart ein Internet-Zugangstypsystem, das einen Autodialer enthält zum Etablieren einer Verbindung über ein Wählnetz, während es die Anschlussfähigkeit ans Internet über ein Paketdatennetzwerk aufrecht erhält, worin der Autodialer zwischen der Internetsession und der Wählanschlussfähigkeit koordiniert, worin in dem Terminal abgewechselt wird zwischen Empfangen von Adressinformation über das Paketnetzwerk und Empfangen von Inhaltsdaten über ein Wählnetz. WO 99/66747 betrifft einen Broadcast-Informationsservice, in welchem eine kurze Schlagzeile oder Zusammenfassung eines Themas in einem Broadcast-Informationsservice kommuniziert wird, wobei es dem Verwender erlaubt wird, nach Auswahl, den gesamten Text für das ausgewählte Thema anzufordern, welcher zu einer Zieladresse gesendet wird, z.B. eine Faxnummer, worin das Kommunikationsverfahren zum Herunterladen der detaillierten Information durch dessen Größe bestimmt wird.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Daher ist es eine Aufgabe der vorliegenden Erfindung, eine Inhalteabrufvorrichtung bereitzustellen, welche ein geeignetes Verbindungsverfahren vor dem Datenempfang auswählt.
  • Diese und andere Aufgaben werden gelöst durch eine Inhalteabrufvorrichtung, wie im unabhängigen Anspruch 1 definiert, einem Inhalteabrufverfahren, wie im unabhängigen Anspruch 6 definiert, einem Aufzeichnungsmedium mit darin auf gezeichnetem Programm, wie im unabhängigen Anspruch 11 definiert, und einem Programm zum Abrufen von Inhaltsdaten, wie im unabhängigen Anspruch 16 definiert. Weitere bevorzugte Ausführungsformen sind Gegenstand der abhängigen Ansprüche 2 bis 5, 7 bis 10, 12 bis 15 und 17 bis 20.
  • Ein Aspekt der vorliegenden Erfindung ist gerichtet auf eine Inhalteabrufvorrichtung zum Abrufen von Inhaltsdaten von einem Server über ein Kommunikationsnetzwerk, wobei die Inhalteabrufvorrichtung umfasst: einen Browserabschnitt zum Erzeugen einer Abrufanforderung, welche Ortsangabeninformation von Inhaltsdaten, die gegenwärtig abgerufen sind, spezifiziert; einen Protokollkontrollabschnitt zum Auswählen eines geeigneten Verbindungsverfahrens für die dabei spezifizierten Inhaltsdaten aus entweder einem paketvermittelten Verbindungsverfahren oder einem leitungsvermittelten Verbindungsverfahren, die in einer Multicall-Funktion verwendet werden; und einen Kommunikationskontrollabschnitt zum Empfangen der Inhaltsdaten, die durch den Browserabschnitt spezifiziert sind, von dem Server unter entweder dem paketvermittelten Verbindungsverfahren und dem leitungsvermittelten Verbindungsverfahren, das durch den Protokollkontrollabschnitt ausgewählt ist; worin der Protokollkontrollabschnitt das geeignete Verbindungsverfahren basierend auf Information auswählt, die enthalten ist in oder beigefügt ist zu der Ortsangabeninformation, spezifiziert in der Abrufanfrage, erzeugt durch den Browserabschnitt vor dem Empfang der Inhaltsdaten.
  • Diese und andere Aufgaben, Merkmale, Aspekte und Vorteile der vorliegenden Erfindung werden ersichtlicher werden aus der folgenden detaillierten Beschreibung der vorliegenden Erfindung, wenn in Zusammenhang mit der beigefügten Zeichnung genommen.
  • KURZE BESCHREIBUNG DER ZEICHNUNG
  • 1 ist ein funktionelles Blockdiagramm einer Inhalteabrufvorrichtung 1a.
  • 2A und 2B sind Ansichten der Datenstruktur der Antwortdaten Drep, die durch einen Inhalteserver 3 in 1 erzeugt werden, bzw. einer internen Informationstabelle Tconn1.
  • 3A und 3B sind Ansichten, welche die Beziehung zwischen Hauptinhaltsdaten Dmc und Unterinhaltsdaten Dsc zeigen.
  • 4 ist ein Blockdiagramm einer mobilen Kommunikationseinheit U-comm1 bis Ucomm4.
  • 5 ist ein Flussdiagramm des Betriebs der mobilen Kommunikationseinheit Ucomm1.
  • 6 ist ein funktionales Blockdiagramm einer Inhalteabrufvorrichtung 1b.
  • 7A und 7B sind Ansichten einer Verbindungsinformationstabelle Tconn2 bzw. einer internen Informationstabelle Tctyp.
  • 8 ist ein Flussdiagramm des Betriebs der mobilen Kommunikationseinheit Ucomm2.
  • 9 ist ein funktionales Blockdiagramm einer Inhalteabrufvorrichtung 1c.
  • 10 ist eine Ansicht einer Verbindungsinformationstabelle Tconn3.
  • 11 ist ein Flussdiagramm des Betriebs der mobilen Kommunikationseinheit Ucomm3.
  • 12 ist ein funktionales Blockdiagramm einer Inhalteabrufvorrichtung 1d.
  • 13 ist ein Flussdiagramm des Betriebs der mobilen Kommunikationseinheit Ucomm4.
  • BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
  • 1 ist ein funktionales Blockdiagramm einer Inhalteabrufvorrichtung 1a einer ersten Ausführungsform der vorliegenden Erfindung. 1 zeigt auch ein Kommunikationsnetzwerk 2 und einen Inhalteserver 3 in Zusammenhang mit der Inhalteabrufvorrichtung 1a. Die Inhalteabrufvorrichtung 1a hat eine Multicall-Funktion, welche das Abrufen von Inhaltsdaten Dc von dem Inhalteserver 3 durch jedes der Verbindungsverfahren, die paketvermittelte Verbindung und die leitungsvermittelte Verbindung, erlaubt. Die Inhalteabrufvorrichtung 1a greift auf den Inhalteserver 3 über einen ersten Kommunikationspfad 4pkt zu, während der paketvermittelten Verbindung, während sie auf dem Inhalteserver 3 über einen zweiten Kommunikationspfad 4tel während der leitungsvermittelten Verbindung zugreift. Um die oben beschriebene Datenkommunikation zu verwirklichen, enthält die Inhalteabrufvorrichtung 1a einen Browserabschnitt Pbw, einen Protokollkontrollabschnitt Ppc, einen ersten Kommunikationskontrollabschnitt Pcc1 und einen zweiten Kommunikationskontrollabschnitt Pcc2.
  • Der Inhalteserver 3 speichert einige Inhaltsdaten Dc, von denen jede typischerweise eine Textdatei ist, beschrieben in einer Markup-Sprache, versinnbildlicht durch Hypertext Markup Language (HTML), eine Audiodatei, eine Stillbilddatei oder eine Bewegtbilddatei. HTML erlaubt das Verlinken von einem Inhaltsdatum Dc zu einem anderen Inhaltsdatum Dc (so genannter Hyperlink). In dieser Ausführungsform wird sich hiernach auf die Inhaltsdaten Dc, worin ein Link seinen Ursprung hat, als Hauptinhaltsdaten Dmc bezogen, und auf die Inhaltsdaten Dc als ein verlinktes Ziel wird sich hiernach als Unterinhaltsdaten Dsc bezogen.
  • Um Hyperlink zu erreichen, enthalten die Hauptinhaltsdaten Dmc ein Anker-Tag Tanc, welches Ortsangabeninformation Iur1 (d.h. URL (uniform resource locator), spezifiziert als url1 oder url2 in 1) speichert, welche den Speicherort von Unterinhaltsdaten Dsc anzeigt. In dieser Ausführungsform enthält der Anker-Tag Tanc als einen Attributwert Verbindungsverfahrensinformation Iconn1 (Verbindungsverfahrensinformation Iconn11 oder Iconn12 ist in 1 veranschaulicht). Die Verbindungsverfahrensinformation Iconnl zeigt ein geeignetes Verbindungsverfahren an, unter welchem die Inhalteabrufvorrichtung 1a geeigneterweise die Unterinhaltsdaten Dsc abruft. In dieser Ausführungsform sind zwei Arten von Verbindungsverfahrensinformation Iconn1 definiert: die Verbindungsverfahrensinformation Iconn11, welche anzeigt, dass das geeignete Verbindungsverfahren die paketvermittelte Verbindung ist, beschrieben als cc = Paket, und die Verbindungsverfahrensinformation Iconn12, welche anzeigt, dass das geeignete Verbindungsverfahren die leitungsvermittelte Verbindung ist, beschrieben cc = tel.
  • 1 exemplifiziert ein Hauptinhaltsdatum Dmc und zwei Unterinhaltsdaten Dsc1 und Dsc2 als die Unterinhaltsdaten Dsc. Als die Ortsangabeinformation Iur1 der Hauptinhaltsdaten Dc ist url0 zugewiesen, welche eine Form hat wie http://www.xxx.co.jp/main.html. Es sei angenommen, dass das Unterinhaltsdaten Dsc1 eine Textdatei oder eine Stillbilddatei ist, für welche Kommunikationsverzögerung und Unterbrechung von Datenkommunikation nicht fatal sind, d.h., eine Datei, die geeigneterweise unter der paketvermittelten Verbindung abrufbar ist. Im Gegensatz dazu sei angenommen, dass das Unterinhaltsdatum Dsc2 eine Audiodatei oder eine Bewegtbilddatei ist, für welche Kommunikationsverzögerung und Unterbrechung von Datentransfer fatal sind, d.h., eine Datei, die geeigneterweise unter der leitungsvermittelten Verbindung abrufbar ist. Es sei auch angenommen, dass die Ortsangabeinformation Iur1 des Unterinhaltsdatums Dsc1 url1 ist und diejenige des Unterinhaltsdatums Dsc2 url2 ist. Unter den obigen Annahmen hat das Hauptinhaltsdatum Dmc Beschreibungen von zwei Anker-Tags Tanc1 und Tanc2. Das Anker-Tag Tanc1 enthält Beschreibungen von „href = url1" und „cc = Paket", während das Anker-Tag Tanc2 Beschreibungen von „href = url2" und „cc = tel" hat.
  • Hiernach wird der Betrieb der Inhalteabrufvorrichtung 1b beschrieben werden. Der Protokollkontrollabschnitt Ppc empfängt eine Inhalteabrufanforderung Dcreq von dem Browserabschnitt Pbw. Es sei angenommen, dass die vorliegende Inhalteabrufanforderung Dcreq in Antwort auf eine Eingabe durch den Verwender der Inhalteabrufvorrichtung 1a erzeugt wird und die Ortsangabeinformation Iur1 des Hauptinhaltsdatums Dmc (d.h. url0) enthält. Der Protokollkontrollabschnitt Ppc gibt die empfangene Abrufanforderung Dcreq zu dem ersten Kommunikationskontrollabschnitt Pcc1 weiter, wobei er anweist, das Hauptinhaltsdatum Dmc abzurufen. In Antwort auf diese Anweisung baut der erste Kommunikationskontrollabschnitt Pcc1 zuerst den ersten Kommunikationspfad 4pkt zu dem Inhalteserver 3 gemäß den paketvermittelten Verbindungsanforderungen auf, falls die Verbindung nicht aufgebaut wurde, und überträgt dann die Abrufanforderung Dcreq an den Inhalteserver 3.
  • Der erste Kommunikationspfad 4pkt wird zum Abrufen des Hauptinhaltsdatums Dmc, wie oben beschrieben, verwendet. Dies daher, weil das Hauptinhaltsdatum Dmc eine Datei ist, in welcher ein Link seinen Urspung hat, wobei das für diesen Abruf geeignete Verbindungsverfahren nicht in dem Anker-Tag Tanc spezifiziert ist. Zusätzlich sind die Kommunikationskosten im Allgemeinen niedriger in der paketvermittelten Verbindung als in der leitungsvermittelten Verbindung, da viele Verwender den ersten Kommunikationspfad 4pkt teilen.
  • Der Inhalteserver 3 liest die Inhaltsdaten Dc basierend auf der Ortsangabeinformation Iur1 in der empfangenen Abrufanforderung Dcreq und erzeugt einen Antwort-Header Hc und Antwortdaten Drep. Das gegenwärtig gelesene Inhaltsdatum Dc ist das Hauptinhaltsdatum Dmc. Der Antwort-Header Hc, der gegenwärtig erzeugt wird, ist ein Antwort-Header Hmc für das Hauptinhaltsdatum Dmc, der einen Protokollidentifikator IDprt, einen Antwortergebnis-Code Crep, einen Inhaltstyp Ictyp und eine Inhaltsdatenlänge Ic1g enthält, wie in 2A gezeigt. Der Protokollidentifikator IDprt spezifiziert das Protokoll für die gegenwärtige Datenkommunikation. Der Antwortergebnis-Code Crep spezifiziert das Antwortergebnis für die gegenwärtige Abrufanforderung Dcreq. Der Inhaltstyp Ictyp zeigt den Typ des gegenwärtig gelesenen Inhaltsdatums Dmc an. Hier sei angenommen, dass der gegenwärtige Inhaltstyp Ictyp anzeigt, dass das Inhaltsdatum Dmc in HTML beschrieben ist. Die Inhaltsdatenlänge Ic1g zeigt die Größe des gegenwärtig gelesenen Inhaltsdatums Dmc an. Die gegenwärtig vorbereiteten Antwortdaten Drep sind Antwortdaten Drep1 für das Hauptinhaltsdatum Dmc. Die Antwortdaten Drep1, welche das Hauptinhaltsdatum Dmc und den oben beschriebenen Antwort-Header Hmc, zu dem Inhaltsdatum Dmc hinzugefügt, enthält, werden zu der Inhalteabrufvorrichtung 1a über den ersten Kommunikationspfad 4pkt übertragen.
  • In der Inhalteabrufvorrichtung 1a empfängt der erste Kommunikationskontrollabschnitt Pcc1 die Antwortdaten Drep1 über den ersten Kommunikationspfad 4pkt und gibt die Daten an den Protokollkontrollabschnitt Ppc so wie sie sind weiter. Der Protokollkontrollabschnitt Ppc identifiziert die Art der Inhaltsdaten Dc von dem vorhergehenden Inhaltstyp Ictyp in den empfangenen Antwortdaten Drep1, Wenn der Inhaltetyp Ictyp HTML anzeigt, gibt der Protokollkontrollabschnitt Ppc die empfangenen Antwortdaten Drep1 zu einem Sprachanalyseteil (nicht gezeigt) des Browserabschnitts Pbw weiter, wobei er anweist, das Hauptinhaltsdatum Dmc in den Antwortdaten Drep1 zu analysieren.
  • In Antwort auf die Anweisung analysiert der Browserabschnitt Pbw die Struktur und Anordnung des Textes, der durch die Inhaltsdaten Pmc repräsentiert ist, und führt dann Anzeigeverarbeitung für den Text aus. Zusätzlich extrahiert der Browserabschnitt Pbw, als interne Information, eine Menge der Ortsangabeinformnation Iur1 und der Verbindungsverfahrensinformation Iconn1 von jedem der Anker-Tags Tanc1 und Tanc2. Und der Browserabschnitt Pbw beschreibt die extrahierte Information in einer internen Informationstabelle Tconn1, die darin gehalten wird. Wie in 2B gezeigt, ist die interne Informationstabelle Tconn1 konstruiert, Beschreibung von Mengen der Ortsangabeinformation Iur1 und der Verbindungsverfahrensinformation Iconn1 darin zu erlauben. Mit dieser Tabelle ist es möglich, anzuzeigen, welches Verbindungsverfahren, die paketvermittelte Verbindung oder die leitungsvermittelte Verbindung, geeignet ist beim Abrufen der Unterinhaltsdaten Dsc. In dieser Ausführungsform zeigt das Anker-Tag Tanc1 die Menge von „href = url1" und „cc = Paket", wie in der Verbindungsverfahrensinformation Iconn11, und das Anker-Tag Tanc2 enthält die Menge von „href = url2" und „cc = tel" als die Verbindungsverfahrensinformation Iconn12, wie in 1 gezeigt. Daher sind in der internen Informationstabelle Tconn1 die Menge von url1 und Paket und die Menge von url2 und tel wie in 2B gezeigt beschrieben. Daher wird angezeigt, dass die paketvermittelte Verbindung geeignet ist zum Abrufen des Unterinhaltsdatums Dsc1, während die leitungsvermittelte Verbindung geeignet ist zum Abrufen des Unterinhaltsdatums Dsc2.
  • Wenn das Unterinhaltsdatum Dsc1 abzurufen ist, empfangt der Protokollkontrollabschnitt Ppc eine Abrufanforderung Dcreq, welche die Ortsangabeinformation Iur1 enthält. Diese Abrufanforderung Dcreq wird automatisch durch den Browserabschnitt Pbw erzeugt. Die Abrufanforderung Dcreq wird automatisch erzeugt, wenn das Unterinhaltsdatum Dsc1 in dem Hauptinhaltsdatum Dmc eingebettet ist. Ein Beispiel dieser eingebetteten Daten ist in 3A gezeigt, wo ein Stillbild, repräsentiert durch das Unterinhaltsdatum Dsc1, dem Text eingefügt ist, dargestellt durch das Hauptinhaltsdatum Dmc. Der Protokollkontrollabschnitt Ppc ext rahiert die Ortangabeninformation Iur1 von der empfangenen Abrufanforderung Dcreq und extrahiert die Verbindungsverfahrensinformation Iconn1, die mit dieser Ortsangabeninformation Iur1 gepaart ist (Verbindungsverfahrensinformation Iconn11 in diesem Fall) von der internen Informationstabelle Tconn1 (siehe 2B). Der Protokollkontrollabschnitt Ppc bestimmt, welches Verbindungsverfahren, die paketvermittelte Verbindung oder die leitungsvermittelte Verbindung, angewandt werden soll für die gegenwärtigen Unterinhaltsdaten Dsc gemäß der extrahierten Verbindungsverfahrensinformation Iconn1. Da in diesem Fall die Verbindungsverfahrensinformation Iconn11 extrahiert wurde, wird die Paketvermittlungsverbindung als geeignet bestimmt.
  • Basierend auf der obigen Bestimmung, gibt der Protokollkontrollabschnitt Ppc die empfangene Abrufanforderung Dcreq an den ersten Kommunikationskontrollabschnitt Pcc1 weiter, wobei er anweist, die Unterinhaltsdaten Dsc1 abzurufen. In Antwort auf diese Anweisung überträgt der erste Kommunikationskontrollabschnitt Pcc1 die gegenwärtige Abrufanforderung Dcreq an den Inhalteserver 3 über den ersten Kommunikationspfad 4pkt, falls der erste Kommunikationspfad 4pkt aufgebaut wurde. Falls noch nicht aufgebaut, baut der erste Kommunikationskontrollabschnitt Pcc1 zuerst den ersten Kommunikationspfad 4pkt an den Inhalteserver 3 auf und überträgt dann dazu die gegenwärtige Abrufanforderung Dcreq.
  • Basierend auf der Ortsangabeninformation Iur1 in der empfangenen Abrufanforderung Dcreq liest der Inhalteserver 3 die Inhaltsdaten Dc und erzeugt einen Antwort-Header Hc und Antwortdaten Drep. Die Inhaltsdaten Dc, die gegenwärtig gelesen werden, sind Unterinhaltsdaten Dsc1. Der Inhalteserver 3 erzeugt einen Antwort-Header Hsc1 für die Unterinhaltsdaten Dsc1. Der Antwort-Header Hsc ist, wie in 2A gezeigt, aufgebaut, wo der Inhaltetyp Ictyp und die Inhaltsdatenlänge Ic1g den Typ bzw. die Größe der gegenwärtig gelesenen Unterinhaltsdaten Dsc1 anzeigen. In dieser Ausführungsform ist der Typ der Unterinhaltsdaten Dsc1 ein Stillbild, wie in 3A gezeigt, und daher ist der durch den Inhaltetyp Ictyp spezifizierte Typ Stillbild. Der Inhalteserver 3 erzeugt Antwortdaten Drep2 durch Hinzufügen des Antwort-Headers Hsc1 zu den Unterinhaltsdaten Dsc1 und sendet die Antwortdaten Drep2 zu dem ersten Kommunikationspfad 4pkt.
  • Der erste Kommunikationskontrollabschnitt Pcc1 der Inhalteabrufvorrichtung 1a empfängt die Antwortdaten Drep2 von dem ersten Kommunikationspfad 4pkt und gibt die Daten an den Protokollkontrollabschnitt Ppc so wie sie sind weiter. Der Protokollkontrollabschnitt Ppc identifiziert den Typ der Inhaltsdaten Dsc1 von dem vorhergehenden Inhaltetyp Ictyp in den empfangenen Antwortdaten Drep2. Sobald der Protokollkontrollabschnitt Ppc bestimmt, dass der Inhaltetyp Ictyp Stillbild anzeigt, gibt er die empfangenen Antwortdaten Drep2 zu einem Stillbild-Anzeigeverarbeitungsabschnitt (nicht gezeigt) des Browserabschnitts Pbw weiter, wobei er anweist, Verarbeitung zur Anzeige der Unterinhaltsdaten Dsc1 in den Antwortdaten Drep2 auszuführen. In Antwort auf die Anweisung führt der Browserabschnitt Pbw Stillbild-Anzeigeverarbeitung der Unterinhaltsdaten Dsc1 durch. Als ein Ergebnis fügt der Browserabschnitt Pbw das Stillbild, das durch die Unterinhaltsdaten Dsc1 repräsentiert wird, in den durch die Hauptinhaltsdaten Dmc repräsentierten Text ein.
  • Als Nächstes wird das Abrufen des Unterinhaltsdatums Dsc2 beschrieben werden. Es sei angenommen, dass das Unterinhaltsdatum Dsc2 eine Audiodatei ist und eingebettet in den Hauptinhaltsdaten Dmc. Genauer, wie in 3A gezeigt, wird Audio, das durch die Unterinhaltsdaten Dsc2 repräsentiert wird, während der Anzeige des Textes gespielt, der durch die Hauptinhaltsdaten Dmc repräsentiert wird. Beim Abrufen der Unterinhaltsdaten Dmc2 empfängt der Protokollkontrollabschnitt Ppc von dem Browserabschnitt Pbw eine Abrufanforderung Dcreq, welche die Ortsangabeinformation Iur1 (d.h. url2) einschließt. Der Protokollkontrollabschnitt Ppc extrahiert die Ortsangabeninformation Iur1 von der empfangenen Abrufanforderung Dcreq und extrahiert dann die Verbindungsverfahrensinformation Iconn1, welche gepaart ist mit dieser Ortsangabeninformation Iur1 (in diesem Fall Verbindungsverfahrensinformation Iconn12) von der internen Informationstabelle Tconn1. Der Protokollkontrollabschnitt Ppc bestimmt das Verbindungsverfahren, das gegenwärtig angewandt werden soll (in diesem Fall die leitungsvermittelte Verbindung) gemäß der extrahierten Verbindungsverfahrensinformation Iconn1.
  • Basierend auf der obigen Bestimmung gibt der Protokollkontrollabschnitt Ppc die empfangene Abrufanforderung Dcreq an den zweiten Kommunikationskontrollabschnitt Pcc2 weiter, wobei er anweist, die Unterinhaltsdaten Dsc2 abzurufen. In Antwort auf diese Anweisung überträgt der zweite Kommunikationskontrollabschnitt Pcc2 die gegenwärtige Abrufanforderung Dcreq an den Inhalteserwer 3 über den zweiten Kommunikationspfad 4tel, falls der zweite Kommunikationspfad 4tel aufgebaut wurde. Falls nicht aufgebaut, baut der zweite Kommunikationskontrollabschnitt Pcc2 zuerst den zweiten Kommunikationspfad 4tel zu dem Inhalteserver 3 auf und überträgt dann dazu die gegenwärtige Abrufanforderung Dcrq.
  • Basierend auf der Ortsangabeninformation Iur1, die in der empfangenen Abrufanforderung Dcreq spezifiziert ist, liest der Server 3 die Unterinhaltsdaten Dsc2 und erzeugt auch einen Antwort-Header Hsc2 (2A) für die gegenwärtigen Unterinhaltsdaten Dsc2. Der Inhalteserver 3 erzeugt Antwortdaten Drep3 durch Hinzufügen des Antwort-Headers Hsc2 zu den Unterinhaltsdaten Dsc2 und sendet die Antwortdaten Drep3 an den zweiten Kommunikationspfad 4tel.
  • Der zweite Kommunikationskontrollabschnitt Pcc2 der Inhalteabrufvorrichtung 1a empfängt die Antwortdaten Drep3 von dem zweiten Kommunikationspfad 4tel und gibt die Daten, so wie sie sind, an den Protokollkontrollabschnitt Ppc weiter. Der Protokollkontrollabschnitt Ppc identifiziert den Typ der Unterinhaltsdaten Dsc2 von dem Inhaltetyp Ictyp in den empfangenen Antwortdaten Drep3. Sobald der Protokollkontrollabschnitt Ppc bestimmt, dass der Inhaltetyp Ictyp eine Audiodatei anzeigt, gibt er die empfangenen Antwortdaten Drep3 an einen Audiowiedergabe-Verarbeitungsabschnitt (nicht gezeigt) des Browserabschnitts Pbw weiter, wobei er anweist, durch die Unterinhaltsdaten Dsc2 repräsentiertes Audio wiederzugeben. In Antwort auf die Anweisung führt der Browserabschnitt Pbw Wiedergabeverarbeitung durch. Als ein Ergebnis gibt ein Ausgabeabschnitt (nicht gezeigt) das Audio zusammen mit der Schirmanzeige, wie in 3A gezeigt, aus.
  • Wie oben beschrieben, enthalten die Hauptinhaltsdaten Dmc die Verbindungsverfahrensinformation Iconn11 und Iconn12, geeignet zum Abrufen der Unterinhaltsdaten Dsc1 und Dsc2. Durch Analysieren der Hauptinhaltsdaten Dmc ist daher die Inhalteabrufvorrichtung 1a informiert über das zum Abrufen der Inhaltsdaten Dsc1 und Dsc2 geeignete Verbindungsverfahren vor dem Abrufen der Unterinhaltsdaten Dsc1 und Dsc2. Mit anderen Worten kann die Inhalteabrufvorrichtung 1a die leitungsvermittelte Verbindung auswählen vor dem Abrufen der Unterinhaltsdaten Dsc2 und ruft daher eine Audiodatei oder eine Bewegtbilddatei ohne Kommunikationsverzögerung oder Unterbrechung von Datenkommunikation ab. In ähnlicher Weise kann die Inhalteabrufvorrichtung 1a die paketvermittelte Verbindung auswählen, vor dem Abrufen der Unterinhaltsdaten Dsc1 und daher eine Datei wie eine Email abrufen, welche keine Berücksichtigung hinsichtlich Kommunikationsverzögerung und Unterbrechung benötigt, bei relativ niedrigen Kommunikationskosten.
  • In der ersten Ausführungsform ist das geeignete Verbindungsverfahren durch en Attributwert in dem Anker-Tag Tanc spezifiziert. Alternativ kann ein neues Anker-Tag separat von dem nominalen Anker-Tag Tanc definiert werden, um das geeignete Verbindungsverfahren zu spezifizieren.
  • In der obigen Ausführungsform sind die Unterinhaltsdaten Dsc1 und Dsc2 in den Hauptinhaltsdaten Dmc eingebettet (siehe 3A). Alternativ können die Unterinhaltsdaten Dsc1 und Dsc2 zu den Hauptinhaltsdaten Dmc verknüpft sein, während sie Inhalte repräsentieren, die unabhängig von den Hauptinhaltsdaten Dmc sind. Genauer, wie in 3B gezeigt, werden die Inhalte, die durch die Hauptinhaltsdaten Dmc repräsentiert sind, zuerst angezeigt. Sobald der Verwender die Anker-Tags Tanc1 oder Tanc2 in dem Kontext der angezeigten Inhalte auswählt, ruft die Inhalteabrufvorrichtung 1a die Unterinhaltsdaten Dsc1 oder Dsc2 ab. Als ein Ergebnis werden die anzeigten Inhalte zu den Inhalten umgeschaltet, welche durch die Unterinhaltsdaten Dsc1 oder Dsc2 repräsentiert werden.
  • Ein Implementierungsbeispiel der Inhalteabrufvorrichtung 1a, die oben beschrieben ist, wird beschrieben werden. 4 ist ein Blockdiagramm einer mobilen Kommunikationseinheit Ucomm1, welche die Inhalteabrufvorrichtung 1a umfasst. Mit Bezug auf 4 enthält die mobile Kommunikationseinheit Ucomm1 CPU 11, ROM 12, ein RAM 13, den ersten Kommunikationskontrollabschnitt Pcc1, den zweiten Kommunikationskontrollabschnitt Pcc2, eine Eingabevorrichtung 14, eine Ausgabevorrichtung 15, einen Multiplexer/Demultiplexer 16 und einen Sender/Empfänger 17. Die CPU 11 führt ein Programm aus, das im Voraus in dem ROM 12 gespeichert ist. Während Ausführung des Programms verwendet die CPU 11 das RAM 13 als einen Arbeitsbereich. Die CPU 11 bildet in Kombination mit dem ROM 12 und dem RAM 13 den Browserabschnitt Pbw und den Protokollkontrollabschnitt Ppc (siehe 1), der oben beschrieben ist. Der erste Kommunikationskontrollabschnitt Pcc1 führt Datenkommunikation unter der paketvermittelten Verbindung unter der Kontrolle der CPU 11 aus. Ähnlich führt der zweite Kommunikationskontrollabschnitt Pcc2 Datenkommunikation unter der leitungsvermittelten Verbindung unter der Kontrolle der CPU 11 aus. Die CPU 11, das ROM 12, das RAM 13, der erste Kommunikationskontrollabschnitt Pcc1 und der zweite Kommunikationskontrollabschnitt Pcc2 bilden die Inhalteabrufvorrichtung 1a.
  • Die Eingabevorrichtung 14 umfasst typischerweise Tasten, Knöpfe und ein Jog-Dial, die durch einen Verwender bedient werden. Die Ausgabevorrichtung 15, welche eine Flüssigkristallanzeige und einen Lautsprecher umfasst, führt Ausgabeverarbeitung für Ausgabedaten Dout aus, die durch die CPU 11 generiert werden, und präsentiert die Inhalte, die durch die Ausgabedaten Dout repräsentiert werden, dem Verwender. Der Multiplexer/Demultiplexer 16 multiplext die Abrufanforderung Dcreq, empfangen von dem ersten Kommunikationskontrollabschnitt Pcc1 und dem zweiten Kommunikationskontrollabschnitt Pcc2 und demultiplext auch die Inhaltsdaten Dc, empfangen von dem Sender/Empfänger 17. Genauer, da Inhaltsdaten Dc gerichtet an andere mobile Kommunikationseinheiten Ucomm1 auch von dem Sender/Empfänger 17 gesendet werden, demultiplext der Multiplexer/Demultiplexer 16 die Inhaltsdaten Dc, die an ihn selbst gerichtet sind, von den Inhaltsdaten Dc, die an andere Einheiten gerichtet sind. Der Sender/Empfänger 17 sendet die Abrufanforderung Dcreq gemultiplext durch den Multiplexer/Demultiplexer 16 an das Kommunikationsnetzwerk 2. Zusätzlich empfängt der Sender/Empfänger 17 die Inhaltsdaten Dc, die über das Kommunikationsnetzwerk 2 übertragen werden, und gibt die Daten an den Multiplexer/Demultiplexer 16 weiter.
  • Die Operation der mobilen Kommunikationseinheit Ucomm1 wird beschrieben werden mit Bezug auf das Flussdiagramm von 5. Die CPU 11 führt ein Programm, das in dem ROM 12 gespeichert ist, aus. Der Verwender gibt Ortsangabeninformation Iur1 von Inhaltsdaten Dc ein, die er oder sie dieses Mal abzurufen wünscht, durch die Eingabevorrichtung 14. Es sei angenommen, dass die Ortsangabeninformation, die gegenwärtig eingegeben wird, die Ortsangabeninformation Iur1 der Hauptinhaltsdaten Dmc (d.h. Url0) ist. Die CPU 11 arbeitet zuerst als der Browserabschnitt Pbw, um eine Abrufanforderung zu erzeugen (Schritt S101). Genauer, in Schritt S101, erzeugt die CPU 11 eine Abrufanforderung Dcreq, welche die Ortsangabeninformation Iur1, die von der Eingabevorrichtung 14 gesendet ist, enthält.
  • Die CPU 11 arbeitet dann als der Protokollkontrollabschnitt Ppe, um zu bestimmen, ob die Verbindung aufgebaut wurde oder nicht (Schritt S102). Genauer, in Schritt S102, bestimmt die CPU 11, ob ein Zugriff auf den Server 3 (siehe 1) möglich ist unter entweder der paketvermittelten Verbindung oder der leitungsvermittelten Verbindung oder nicht. Falls die Verbindung nicht aufgebaut wurde, gibt die CPU 11 die gegenwärtige Abrufanforderung Dcreq an den ersten Kommunikationskontrollabschnitt Pcc1 weiter, wobei sie anweist, die Hauptinhaltsda ten Dmc abzurufen (Schritt S103). Die obige Reihe von Verarbeitung bis zu Schritt S103 sind diejenigen, die durch den Protokollkontrollabschnitt Ppc ausgeführt werden.
  • In Antwort auf die Anweisung von der CPU 11 baut der erste Kommunikationskontrollabschnitt Pcc1 den ersten Kommunikationspfad 4pkt an den Inhalteserver 3 auf (Schritt S104). Sobald der erste Kommunikationspfad 4pkt aufgebaut wurde, gibt der erste Kommunikationskontrollabschnitt Pcc1 die Abrufanforderung Dcreq an den Multiplexer/Demultiplexer 16 weiter. Der Multiplexer/Demultiplexer 16 multiplext dann die empfangene Abrufanforderung Dcreq und gibt die gemultiplexte Abrufanforderung Dcreq an den Sender/Empfänger 17 weiter, welcher die gemultiplexte Abrufanforderung Dcreq an den ersten Kommunikationspfad 4pkt sendet. Auf diese Weise wird die gegenwärtig erzeugte Abrufanforderung Dcreq an den ersten Kommunikationspfad 4pkt gesendet (Schritt S105). Der Server 3 empfängt die Abrufanforderung Dcreq und in Antwort auf die empfangene Abrufanforderung Dcreq erzeugt er Antwortdaten Drep1 (siehe 1A), welche zu dem ersten Kommunikationspfad 4pkt gesendet werden.
  • In der mobilen Kommunikationseinheit Ucomm1 empfängt der Sender/Empfänger 17 die Antwortdaten Drep1 von dem ersten Kommunikationspfad 4pkt und gibt die Daten an den Multiplexer/Demultiplexer 16 weiter. Der Multiplexer/Demultiplexer 16 demultiplext die Antwortdaten Drep1, die an ihn selbst gerichtet sind von denen, die an andere Einheiten gerichtet sind und gibt die Daten an den ersten Kommunikationskontrollabschnitt Pcc1 weiter. Der erste Kommunikationskontrollabschnitt Pcc1 gibt die empfangenen Antwortdaten Drep1 so wie sie sind weiter und speichert sie in dem RAM 13. Auf diese Weise werden die Antwortdaten Drep1 durch die mobile Kommunikationseinheit Ucomm1 empfangen (Schritt S106). Sobald die Antwortdaten Drep1 in dem RAM 13 gespeichert sind, arbeitet die CPU 11 als der Protokollkontrollabschnitt Ppc, um den Typ der Hauptinhaltsdaten Dmc von dem vorhergehenden Inhaltstyp Ictyp in den empfangenen Antwortdaten Drep1 zu bestimmen (Schritt S107). Genauer bestimmt die CPU 11, ob die Hauptinhaltsdaten Dmc in HTML geschrieben sind oder nicht. In diesem Fall zeigt der Inhaltstyp Ictyp in den Antwortdaten Drep1 HTML an. Daher schreitet die CPU 11 zum Schritt S108 fort.
  • Die CPU 11 arbeitet dann als der Browserabschnitt Pbw, um die Hauptinhaltsdaten Dmc zu analysieren und Mengen der Ortsangabeninformation Iur1 und der Verbindungsverfahrensinformation Iconn1 von den Anker-Tags Tanc1 und Tanc2 als interne Information zu extrahieren. Die CPU 11 beschreibt die extrahierten Mengen der Ortsangabeninformation Iur1 und der Verbindungsverfahrensinformation Iconn1 in der internen Informationstabelle Tconn1. Auf diese Weise wird die interne Informationstabelle Tconn1 erzeugt (Schritt S108). Die CPU 11 analysiert auch die Struktur und Anordnung des Textes, der durch die Hauptinhaltsdaten Dmc dargestellt wird, und erzeugt Ausgabedaten Dout in dem RAM 13 (Schritt S109). Die Ausgabedaten Dout werden zu der Ausgabevorrichtung 15 übertragen, welche Ausgabeverarbeitung gemäß den Ausgabedaten Dout ausführt.
  • Wenn die Unterinhaltsdaten Dsc1 oder Dsc2 durch die mobile Kommunikationseinheit Ucomm1 abzurufen sind, erzeugt die CPU 11 eine Inhalteabrufanforderung Dcreq (Schritt S101). Dieses Mal wird die Abrufanforderung Dcreq automatisch durch die CPU 11 erzeugt und enthält die Ortsangabeninformation Iur1 (d.h. url1 oder ur12). Die CPU 11 bestimmt, ob die Verbindung aufgebaut wurde oder nicht (Schritt S102). Dieses Mal ist der erste Kommunikationspfad 4pkt zur Datenkommunikation verfügbar. Die CPU 11 bestimmt daher, dass die Verbindung aufgebaut ist. Die CPU 11 bestimmt dann, ob die Inhaltsdaten Dc, welche gegenwärtig abzurufen sind, Unterinhaltsdaten Dsc sind oder nicht (Schritt S1010). Genauer bestimmt die CPU 11, ob die Verbindungsverfahrensinformation Iconn1, welche gepaart ist mit der Ortsangabeninformation Iur1, in der gegenwärtig präparierten Abrufanforderung Dcreq in der internen Informationstabelle Tconn1 (siehe 2B), die in Schritt S108 erzeugt wurde, gefunden wird.
  • Falls die Verbindungsverfahrensinformation Iconn1 nicht in der Tabelle gefunden wird, müssen die derzeit abzurufenden Inhaltsdaten Dc Hauptinhaltsdaten Dmc sein. Die CPU 11 geht daher zum Schritt S105, um die nachfolgenden Verarbeitugsschritte auszuführen. Wenn die Verbindungsverfahrensinformation Iconn1 in der Tabelle gefunden wird, werden die derzeit abzurufenden Inhaltsdaten Dc als Unterinhaltsdaten Dsc betrachtet. Die CPU 11 extrahiert dann die Verbindungsverfahrensinformation Iconn1 (die Verbindungsverfahrensinformation Iconn11 oder Iconn12), welche gepaart ist mit der Ortsangabeninformation Iur1 von der internen Informationstabelle Tconn1 (Schritt S1011). Danach bestimmt die CPU 11, ob die extrahierte Verbindungsverfahrensinformation Iconn1 den zweiten Kommunikationspfad 4tel anzeigt oder nicht (Schritt S1012).
  • Wenn die gegenwärtige Abrufanforderung Dcreq url1 als die Ortsangabeninformation Iur1 enthält, wurde die Verbindungsverfahrensinformation Iconn11 im Schritt S1011 extrahiert. In diesem Fall bestimmt die CPU 11, dass die extrahierte Verbindungsverfahrensinformation Iconn1 den zweiten Kommunikationspfad 4tel nicht anzeigt. Das heißt, die CPU 11 bestimmt Abruf der Unterinhaltsdaten Dsc1 durch den ersten Kommunikationspfad 4pkt wie in den Hauptinhaltsdaten Dmc.
  • Wenn die gegenwärtige Abrufanforderung Dcreq url2 als die Ortsangabeninformation Iur1 enthält, wurde die Verbindungsverfahrensinformation Iconn12 im Schritt S1011 extrahiert. In diesem Fall bestimmt die CPU 11, dass die extrahierte Verbindungsverfahrensinformation Iconn1 den zweiten Kommunikationspfad 4te1 anzeigt. Das hießt, die CPU 11 bestimmt Abruf der Unterinhaltsdaten Dsc2 unter der leitungsvermittelten Verbindung. Die CPU 11 schreitet dann zu Schritt S1013 fort und weist zuerst den ersten Kommunikationskontrollabschnitt Pcc1 an, die Verbindung zu trennen (den ersten Kommunikationspfad 4pkt zu trennen). Die CPU 11 gibt dann die gegenwärtig erzeugte Abrufanforderung Dcreq an den zweiten Kommunikationskontrollabschnitt Pcc2 weiter, wobei sie anweist, die Unterinhaltsdaten Dsc2 abzurufen (Schritt S1013). Die obige Reihe an Verarbei tung von den Schritten S1010 bis S1013 sind auch diejenigen, die durch den Protokollkontrollabschnitt Ppc ausgeführt werden.
  • In Antwort auf die Anweisung von der CPU 11 trennt der erste Kommunikationskontrollabschnitt Pcc1 die Verbindung zu dem ersten Kommunikationspfad 4pkt, der als Pfad zu dem Inhalteserver 3 aufgebaut worden ist. Auch baut, in Antwort auf die Anweisung von der CPU 11, der zweite Kommunikationskontrollabschnitt Pcc2 den zweiten Kommunikationspfad 4tel zu dem Inhalteserwer 3 gemäß den leitungsvermittelten Verbindungsanforderungen auf (Schritt S1014). Sobald der zweite Kommunikationspfad 4tel aufgebaut wurde, gibt der zweite Kommunikationskontrollabschnitt Pcc2 die Abrufanforderung Dcreq an den Multiplexer/Demultiplexer 16 weiter. Der Multiplexer/Demultiuplexer 16 multiplext dann die empfangene Abrufanforderung Dcreq und gibt die gemultiplexte Abrufanforderung Dreq an den Sender/Empfänger 17 weiter, welcher die gemultiplexte Abrufanforderung Dcreq an den zweiten Kommunikationspfad 4tel sendet. Auf diese Weise wird die gegenwärtig erzeugte Abrufanforderung Dcreq an den zweiten Kommunikationspfad 4tel gesendet (Schritt S105). Als ein Ergebnis werden die Unterinhaltsdaten Dsc2 über den zweiten Kommunikationspfad 4tel abgerufen, anders als die Hauptinhaltsdaten Dmc.
  • Wie oben mit Bezug auf 3A beschrieben, repräsentieren die Unterinhaltsdaten Dsc1 und Dsc2 Stillbild und Audio und sind daher nicht in HTML im engeren Sinne beschrieben. Daher ist im Prinzip die Bestimmung durch die CPU 11 im Schritt S107 NEIN. In diesem Fall überspringt die CPU 11 den Schritt des Extrahierens von interner Information von den Unterinhaltsdaten Dsc1 und Dsc2. Die CPU 11 erzeugt dann die Ausgabedaten Dout basierend auf den Unterinhaltsdaten Dsc1 und Dsc2 und transferiert die Ausgabedaten Dout an die Ausgabevorrichtung 15 (Schritt S109). Die Ausgabevorrichtung 15 führt Stillbild-Anzeigeverarbeitung und Audio-Wiedergabeverarbeitung gemäß den empfangenen Unterinhaltsdaten Dsc1 und Dsc2 durch.
  • 6 ist ein funktionelles Blockdiagramm einer Inhalteabrufvorrichtung 1b einer zweiten Ausführungsform der vorliegenden Erfindung. 6 zeigt auch ein Kommunikationsnetzwerk 2 und einen Inhalteserver 3 in Verbindung mit der Inhalteabrufvorrichtung 1b. Wie die Inhalteabrufvorrichtung 1a hat die Inhalteabrufvorrichtung 1b eine Multicall-Funktion, welche Zugriff auf den Inhalteserver 3 über einen ersten Kommunikationspfad 4pkt während der paketvermittelten Verbindung und Zugriff auf den Inhalteserver 3 über einen zweiten Kommunikationspfad 4tel während der leitungsvermittelten Verbindung erlaubt. Die Inhalteabrufvorrichtung 1b unterscheidet sich von der Inhalteabrufvorrichtung 1a darin, dass ein Verbindungsinformationsverwaltungsabschnitt Pconn1 zusätzlich bereitgestellt ist, um die oben beschriebene Datenkommunikation zu verwirklichen. Der andere Aufbau der Inhalteabrufvorrichtung 1b ist derselbe wie derjenige der Inhalteabrufvorrichtung 1a. In 6 sind daher dieselben Komponenten wie diejenigen in 1 mit denselben Bezugszeichen bezeichnet.
  • Der Verbindungsinformationsverwaltungsabschnitt Pconn1 hält im Voraus und verwaltet eine Verbindungsinformationstabelle Tconn2, wie in 7A gezeigt. Die Verbindungsinformationstabelle Tconn2 enthält im Voraus Mengen der Inhaltstypen Ictyp und der Verbindungsverfahrensinformation Iconn1, welche dieselbe ist wie in der ersten Ausführungsform. Der Inhaltstyp Ictyp zeigt den Typ jeder Inhaltsdaten Dc an. Diese Tabelle zeigt daher, welches Verbindungsverfahren, die paketvermittelte Verbindung oder die leitungsvermittelte Verbindung, geeignet ist für jeden Inhaltstyp Ictyp der Inhaltsdaten Dc. In dieser Ausführungsform ist der Inhaltstyp Ictyp von text/html einer HTML-Datei zugeteilt, während der Inhaltstyp Ictyp von video/mpeg einer Bewegtbilddatei zugeordnet ist. Da Kommunikationsverzögerung und Unterbrechung von Datenkommunikation nicht fatal sind für die HTML-Datei, ist text/html vorzugsweise mit der Verbindungsverfahrensinformation Iconn11 (paketvermittelte Verbindung) gepaßt. Auch ist, da Kommunikationsverzögerung und Unterbrechung fatal für die Bewegtbilddatei ist, video/mpeg vorzugsweise mit der Verbindungsverfahrensinformation Iconn12 (leitungsvermittelte Verbindung) gepaart.
  • Der Inhalteserver 3 speichert einige Inhaltsdaten Dc wie in der ersten Ausführungsform. In der ersten Ausführungsform ist das geeignete Verbindungsverfahren selbst (Verbindungsverfahrensinformation Iconn1) in den Hauptinhaltsdaten Dmc als der Attributwert des Anker-Tags Tanc beschrieben. In der zweiten Ausführungsform ist jedoch als der Attributwert des Anker-Tags Tanc der Inhaltstyp Ictpyp, welcher den Typ der Unterinhaltsdaten Dsc anzeigt, beschrieben. In dieser Ausführungsform sind zwei Inhaltstypen Ictyp vorbereitet: Inhaltstyp Ictyp1, welcher anzeigt, dass die Unterinhaltsdaten Dsc, die durch den Anker-Tag Tanc spezifiert sind, eine HTML-Datei ist, beschrieben als Typ = text/html, und Inhaltstyp Ictyp2, welcher anzeigt, dass die Unterinhaltsdaten Dsc, welche durch den Anker-Tag Tanc spezifiziert sind, eine Bewegbilddatei ist, beschrieben als Typ = video/html.
  • 6 exemplifiziert ein Hauptinhaltsdatum Dmc und zwei Unterinhaltsdaten Dsc1 und Dsc2 als die Unterinhaltsdaten Dsc. Die Ortsangabeninformation Iur1 des Hauptinhaltsdatums Dmc ist url0. Es sei angenommen, dass das Unterinhaltsdatum Dsc1 eine HTML-Datei ist, auf welche Kommunikationsverzögerung und Unterbrechung von Datenkommunikation nicht fatal sind, und dass das Unterinhaltsdatum Dsc2 eine Bewegtbilddatei ist, für welche Kommunikationsverzögerung und/oder Unterbrechung fatal sind, wie oben beschrieben. Es sei auch angenommen, dass die Ortsangabeninformation Iur1 der Unterinhaltsdaten Dsc1 und Dsc2 url1 bzw. url2 sind. Unter der obigen Annahme hat das Hauptinhaltsdatum Dsc Beschreibungen von zwei Anker-Tags Tanc1 und Tanc2. Das Anker-Tag Tanc1 enthält Beschreibungen von „href = url1" und „type = text/html", während der Anker-Tag Tanc2 Beschreibungen von „href = url2" und „type = video/mpeg" enthält.
  • Die Operation der Inhalteabrufvorrichtung 1b, welche den obigen Aufbau hat, wird beschrieben werden. Die Inhalteabrufvorrichtung 1b ruft das Hauptinhaltsdatum Dmc von dem Inhalteserwer 3 in im Wesentlichen derselben Weise ab wie die Inhalteabrufvorrichtung 1a der ersten Ausführungsform. Das heißt, der Protokollkontrollabschnitt Ppc gibt das Hauptinhaltsdatum Dmc an den Browserabschnitt Pbw weiter, wobei er anweist, die Daten zu analysieren. In Antwort auf diese Anweisung analysiert der Browserabschnitt Pbw die Struktur und Anordnung des Textes, welcher durch die Inhaltsdaten Dmc repräsentiert ist, um Ausgabedaten Dout zu erzeugen, welche den Text repräsentieren. Zusätzlich extrahiert der Browserabschnitt Pbw Mengen der Ortsangabeninformation Iur1 und der Inhaltstypen Ictyp von den Anker-Tags Tanc1 und Tanc2 des gegenwärtig empfangenen Inhaltsdatums Dmc als interne Information und beschreibt und hält die interne Information in der internen Informationstabelle Tctyp. Wie in 7B gezeigt, ist die interne Informationstabelle Tctyp im Voraus aufgebaut, um Beschreibung der Mengen von Ortsangabeninformation Iur1 und des Inhaltstyps Ictyp darin zu erlauben, so dass der Inhaltstyp Ictyp von jedem Unterinhaltsdatum Dsc aus dieser Tabelle identifiziert wird. In dem veranschaulichten Beispiel enthält der Anker-Tag Tanc1 die Menge von „href = url1" und „type = text/html", und der Anker-Tag Tanc2 enthält die Menge von „href = url12" und „type = video/mpeg" , wie in 6 gezeigt. Daher sind in der internen Informationstabelle Tctyp die Menge von url1 und text/html und die Menge von url2 und video/mpeg beschrieben.
  • Wenn das Unterinhaltsdatum Dsc1 abzurufen ist, empfängt der Protokollkontrollabschnitt Ppc eine Abrufanforderung Dcreq, welche url1 als die Ortsangabeninformation Iur1 enthält, von dem Browserabschnitt Pbw. Der Protokollkontrollabschnitt Ppc extrahiert die Ortsangabeninformation Iur1 von der empfangenen Abrufanforderung Dcreq und extrahiert den Inhaltstyp Ictyp (text/html in diesem Fall), der gepaart ist mit der gegenwärtigen Ortsangabeninformation Iur1 von der internen Informationstabelle Tctyp (siehe 7B) des Browserabschnitts Pbw. Der Protokollkontrollabschnitt Ppc bestimmt dann, welches Verbindungsverfahren, die paketvermittelte Verbindung oder die leitungsvermittelte Verbindung, angewandt werden soll für die Unterinhaltsdaten Dsc, die gegenwärtig abzurufen sind. Zu diesem Zweck fragt der Protokollkontrollabschnitt Ppc von dem Verbindungsinformationsverwaltungsabschnitt Pconn1 ab, ob die Verbindungsinformati onstabelle Pconn2 einen Inhaltstyp enthält, welcher zu dem Inhaltstyp Ictyp passt, der von der internen Informationstabelle Tctyp extrahiert wurde oder nicht. Wenn die Verbindungsinformationstabelle Tconn2 einen Inhaltstyp enthält, welcher zu dem abgefragten Inhaltstyp Ictyp passt, gibt der Verbindungsinformationsverwaltungsabschnitt Tconn1 die Verbindungsverfahrensinformation Iconn1 (Verbindungsverfahrensinformation Iconn11 (Paket) in diesem Fall) zurück, welche gepaart ist mit dem fraglichen Inhaltstyp Ictyp an den Protokollkontrollabschnitt Ppc. Der Protokollkontrollabschnitt Ppc bestimmt, welches Verbindungsverfahren, die paketvermittelte Verbindung oder die leitungsvermittelte Verbindung, angewandt werden soll für die gegenwärtig anzurufenden Unterinhaltsdaten Dsc1 gemäß der Verbindungsverfahrensinformation Iconn1, die von dem Verbindungsinformationsverwaltungsabschnitt Pconn1 geholt wurde. In diesem Falle, da die Verbindungsverfahrensinformation Iconn11 geholt wurde, wird die paketvermittelte Verbindung als geeignet bestimmt. Die nachfolgende Operation ist im Wesentlichen dieselbe wie diejenige der ersten Ausführungsform und daher wird die Beschreibung davon hier unterlassen.
  • Wenn das Unterinhaltsdatum Dsc2 abzurufen ist, empfängt der Protokollkontrollabschnitt Ppc eine Abrufanforderung Dcreq, welche url2 als die Ortsangabeninformation Iur1 enthält. Von der empfangenen Abrufanforderung Dcreq extrahiert der Protokollkontrollabschnitt Ppc den Inhaltstyp Ictyp (video/mpeg in diesem Fall), der gepaart ist mit der Ortsangabeninformation Iur1 von der internen Informationstabelle Tctyp des Browserabschnitts Pbw. Der Protokollkontrollabschnitt Ppc fragt dann bei dem Verbindungsinformationsverwaltungsabschnitt Pconn1 nach, ob die Verbindungsinformationstabelle Tconn2 einen Inhaltstyp enthält, welcher zu dem Inhaltstyp Ictyp passt, der von der internen Informationstabelle Tctyp extrahiert wurde. Falls die Verbindungsverfahrensinformation Iconn1 den passenden Inhaltstyp enthält, gibt der Verbindungsinformationsverwaltungsabschnitt Pconn1 die Verbindungsverfahrensinformation Iconn1 (Verbindungsverfahrensinformation Iconn12 (tel) in diesem Fall), gepaart mit dem fraglichen Inhaltstyp Ictyp, zu dem Protokollkontrollabschnitt Ppc zurück. Der Protokollkon trollabschnitt Ppc bestimmt, welches Verbindungsverfahren, die paketvermittelte Verbindung oder die leitungsvermittelte Verbindung, angewandt werden soll für das Unterinhaltsdatum Dsc2, das gegenwärtig abzurufen ist, gemäß der Verbindungsverfahrensinformation Iconn1, die von dem Verbindungsinformationsverwaltungsabschnitt Tconn1 geholt wurde. In diesem Falle, da die Verbindungsverfahrensinformation Iconn12 geholt wurde, wird die leitungsvermittelte Verbindung als geeignet bestimmt. Die nachfolgende Operation ist im Wesentlichen die4selbe wie diejenige der ersten Ausführungsform und daher wird Beschreibung derselben hier unterlassen.
  • Wie oben beschrieben, enthält das Hauptinhaltsdatum Dmc den Inhaltstyp Ictyp von jedem der Unterinhaltsdaten Dsc1 und Dsc2. Auch hält die Inhalteabrufvorrichtung 1b die Verbindungsverfahrensinformation Iconn2, in welcher Mengen von dem Inhaltstyp Ictyp und der Verbindungsverfahrensinformation Iconn1 im Voraus beschrieben sind. Die Inhalteabrufvorrichtung 1b analysiert das Hauptinhaltsdatum Dmc und beschreibt Mengen der Ortsangabeninformation Iur1 und des- Inhaltstyps Ictyp in der internen Informationstabelle Tctyp. Indem man sich auf die interne Informationstabelle Tctyp und die Verbindungsinformationstabelle Tconn2 bezieht, ist die Inhalteabrufvorrichtung 1b über das geeignete Verbindungsverfahren zum Abrufen der Unterinhaltsdaten Dsc vor Abruf der Unterinhaltsdaten Dsc informiert.
  • In der zweiten Ausführungsform ist der Inhaltstyp Ictyp in den Inhaltsdaten Dc beschrieben und der Verbindungsinformationsverwaltungsabschnitt Tconn1 verwaltete die Verbindungsverfahrensinformation Iconn1 im Zusammenhang mit dem Inhaltstyp Ictyp. Alternativ kann die Verbindungsverfahrensinformation Iconn1 in Zusammenhang mit einem Attribut der Inhaltsdaten Dc verwaltet werden, wenn das Attribut in den Inhaltsdaten Dc beschrieben ist. Ein typisches Beispiel des Attributs der Inhaltsdaten Dc enthält den Dateinamen, die Dateierweiterung und die Inhaltslänge Ic1g. Insbesondere, falls die Inhaltslänge Ic1g in den Inhaltsdaten Dc beschrieben ist und der Verbindungsinformationsverwaltungsab schnitt Pconn1 die Verbindungsverfahrensinformation Iconn1 in Zusammenhang mit der Inhaltslänge Ic1g verwaltet, wird die zu holende Verbindungsverfahrensin-formation Iconn1 bestimmt durch Vergleichen der Länge lc1g der Inhaltsdaten Dc, die abzurufen sind, mit der Inhaltslänge Ic1g, verwaltet durch den Verbindungsinformationsverwaltungsabschnitt Pconn1.
  • In der zweiten Ausführungsform ist der Inhaltstyp Ictyp in den Inhaltsdaten Dc beschrieben. Alternativ kann die Inhalteabrufvorrichtung 1b einen Teil der Unterinhaltsdaten Dsc im Voraus abrufen und den Teil der Daten analysieren, um das Datenformat (d.h. den Inhaltstyp Ictyp) der gegenwärtigen Inhaltsdaten Dsc zu spezifizieren. Die Inhalteabrufvorrichtung 1b holt dann die Verbindungsverfahrensinformation Iconn1 basierend auf dem spezifizierten Inhaltstyp Ictyp.
  • Hiernach wird eine mobile Kommunikationseinheit Ucomm2, welche die Inhalteabrufvorrichtung 1b, die oben beschrieben wurde, enthält, beschrieben werden. Die mobile Kommunikationseinheit Ucomm2 hat im Wesentlichen denselben Aufbau wie die mobile Kommunikationseinheit Ucomm1. Daher wird sich in der folgenden Beschreibung auf 4 bezogen werden. Die Operation der mobilen Kommunikationseinheit Ucomm2 wird beschrieben werden mit Bezug auf das Flussdiagramm von 8. Das Flussdiagramm von 8 ist dasselbe wie das Flussdiagramm von 5, ausgenommen dass Schritte S108, S1010 und S1011 mit Schritten S201, S202 und S203 ersetzt sind. In 8 sind daher Schritte, welche den Schritten in 5 entsprechen, mit denselben Bezugszeichen bezeichnet und die Beschreibung davon ist hier unterlassen.
  • Wenn die mobile Kommunikationseinheit Ucomm2 die Inhaltsdaten Dc abzurufen hat, liest die CPU 11 zuerst ein Programm aus dem ROM 12 in das RAM 13. Das Programm in dieser Ausführungsform hält die Verbindungsinformationstabelle Tconn2, die in 7A gezeigt ist, vor. Die Verbindungsinformationstabelle Tconn2 wird während des Lesens des Programms in das RAM 13 gelesen. Die mobile Kommunikationseinheit Ucomm2 führt Schritte S101 bis S107 zum Abru fen der Hauptinhaltsdaten Dmc aus. Da der Inhaltstyp Ictyp der Antwortdaten Drep1 (siehe 2A) HTML anzeigt, schreitet die CPU 11 vom Schritt S107 zum Schritt 201 fort, wo die CPU 11 die Hauptinhaltsdaten Dmc analysiert, um die Mengen der Ortsangabeninformation Iur1 und der Verbindungsverfahrensinformation Iconn1 aus den Anker-Tags Tanc1 und Tanc2 als interne Information zu extrahieren. Die CPU 11 speichert die extrahierte interne Information in dem RAM 13 und beschreibt die interne Informationstabelle Tctyp, die in 7B gezeigt ist (Schritt S201). Die CPU 11 schreitet dann zum Schritt S109 fort.
  • Wenn die mobile Kommunikationseinheit Ucomm2 die Unterinhaltsdaten Dsc1 oder Dsc2 abzurufen hat, führt die CPU 11 die Schritte S101 und S102 aus und schreitet dann zu Schritt S202 fort, wo die CPU 11 bestimmt, ob das gegenwärtig abzurufende Inhaltsdatum Dc das Unterinhaltsdatum Dsc ist (Schritt S202). Genauer bestimmt die CPU 11, ob dieselbe Ortangabeninformation wie die Ortsangabeninformation Iur1, die in der gegenwärtig erzeugten Abrufanforderung Dcreq enthalten ist, in der internen Informationstabelle Tctyp (siehe 7B) gefunden wird, beschrieben in Schritt S201.
  • Wenn dieselbe Ortsangabeninformation Iur1 nicht in der Tabelle gefunden wird, ist das gegenwärtig abzurufende Inhaltsdatum Dc Hauptinhaltsdaten Dmc. Die CPU 11 geht daher zu Schritt S105. Wenn dieselbe Ortsangabeninformation Iur1 in der Tabelle gefunden wird, wird das gegenwärtig abzurufende Inhaltsdatum Dc als Unterhaltsdaten Dc betrachtet. Die CPU 11 schreitet dann zu Schritt S203 fort, wo die CPU 11 den Inhaltstyp Ictyp (text/html oder video/mpeg) extrahiert, die gepaart ist mit der extrahierten Ortsangabeninformation Iur1 von der internen Informationstabelle Tctyp. Danach greift die CPU 11 auf die Verbindungsinformationstabelle Tconn2 zu, die zusammen mit dem Programm in das RAM 13 gelesen wurde, um die Verbindungsverfahrensinformation Iconn1 (Paket oder tel) zu entnehmen, die gepaart ist mit dem extrahierten Inhaltstyp Ictyp. Die CPU 11 schreitet dann zu Schritt S1012 fort. Die nachfolgende Verarbeitung ist dieselbe wie die der ersten Ausführugsform und daher ist die Beschreibung davon hier unterlassen.
  • 9 ist ein funktionelles Blockdiagramm einer Inhalteabrufvorrichtung 1c einer dritten Ausführungsform der vorliegenden Erfindung. 9 zeigt auch ein Kommunikationsnetzwerk 2 und einen Inhalteserver 3 in Zusammenhang mit der Inhalteabrufvorrichtung 1c. Wie die Inhalteabrufvorrichtung 1a hat die Inhalteabrufvorrichtung 1c eine Multicall-Funktion, welche Zugriff auf den Inhalteserver 3 erlaubt über einen ersten Kommunikationspfad 4pkt während der paketvermittelten Verbindung und Zugriff auf den Inhalteserver 3 über einen zweiten Kommunikationspfad 4tel während der leitungsvermittelten Verbindung. Die Inhalteabrufvorrichtug 1c unterscheidet sich von der Inhalteabrufvorrichtung 1a darin, dass ein Verbindungsinformationsverwaltungsabschnitt Pconn2 zusätzlich bereitgestellt ist, um die oben beschriebene Datenkommunikation zu verwirklichen. Der andere Aufbau der Inhalteabrufvorrichtung 1c ist derselbe wie der der Inhalteabrufvorrichtung 1a. In 9 sind daher dieselben Bestandteile wie diejenigen in 1 durch dieselben Bezugszeichen bezeichnet.
  • Der Verbindungsinformationsverwaltungsabschnitt Pconn2 verwaltet eine Verbindungsinformationstabelle Tconn3, die in 10 gezeigt ist, welche im Voraus Mengen enthält von einem Teil, welcher ein Merkmal der Ortsangabeninformation Iur1 repräsentiert, und der Verbindungsverfahrensinformation Iconn1, welche dieselbe ist wie in der ersten Ausführungsform. Die Ortsangabeninformation Iur1 (d.h. url) ist jedem Inhaltsdatum Dc eindeutig zugeordnet, wobei es den Speicherort der Inhaltsdaten Dc anzeigt. Ein Teil der Ortsangabeninformation Iur1 repräsentiert ein Merkmal der Inhaltsdaten Dc. Genauer enthält die Ortsangabeninformation Iur1 als ein Suffix eine Erweiterung, welche ein Merkmal der Inhaltsdaten Dc repräsentiert. Durch Bezugnahme auf die Menge von dem Merkmal der Ortsangabeninformation Iur1 der Verbindungsverfahrensinformation Iconn1 wird daher identifiziert, welches Verbindungsverfahren, die paketvermittelte Verbindung oder die leitungsvermittelte Verbindung, geeignet ist für jedes Merkmal (Erweite rung) der Ortsangabeninformation Iur1. Im Allgemeinen wird Ortsangabeninformation Iur1, welche eine Form hat wie http://www.xxx.co.jp/yyy.html, einer HTML-Datei zugeordnet, wo die Erweiterung .html ist. Kommunikationsverzögerung und Unterbrechung von Datenkommunikation sind der HTML-Datei nicht fatal. Daher ist .html vorzugsweise mit der Verbindungsverfahrensinformation Iconn11 (paketvermittelte Verbindung) gepaart. Ähnlich ist Ortsangabeninformation Iur1, welche eine Form hat wie http://www.xxx.co.jp./zzz.mpg einer Bewegtbilddatei zugeordnet, wenn die Datei gemäß MPEG (Motion Picture Experts Group) erzeugt ist, wo die Erweiterung .mpg ist. Kommunikationsverzögerung und Unterbrechung sind fatal für die Bewegtbilddatei. Daher ist .mpg vorzugsweise mit der Verbindungsverfahrensinformation Iconn12 (leitungsvermittelte Verbindung) gepaart.
  • Der Inhalteserver 3 speichert einige Inhaltsdaten Dc (drei in der veranschaulichten Ausführungsform) wie in der ersten Ausführungsform. Die oben beschriebene 0rtsangabeninformation Iur1 wird jedem Inhaltsdatum Dc zugeordnet. In der ersten Ausführungsform ist das geeignete Verbindungsverfahren selbst in den Hauptinhaltsdaten Dmc als Attributwert des Anker-Tags Tanc beschrieben. In der dritten Ausführungsform hat das Anker-Tag Tanc nichts mit der Natur der Inhalteabrufvorrichtung 1c zu tun und wird daher in dieser Ausführungsform nicht gezeigt.
  • Die Operation der Inhalteabrufvorrichtung 1c, welche den obigen Aufbau hat, wird beschrieben werden. Der Protokollkontrollabschnitt Ppc empfängt eine Inhalteabrufanforderug Dcreq, welche die Ortsangabeninformation Iur1 der Inhaltsdaten Dc enthält. In Antwort auf die empfangene Abrufanforderung Dcreq bestimmt der Protokollkontrollabschnitt Ppc das Verbindungsverfahren, das geeignet zum Abrufen der gegenwärtigen Inhaltsdaten Dc. Genauer extrahiert zuerst der Protokollkontrollabschnitt Ppc das Merkmal, d.h. die Erweiterung, der Ortsangabeninformation Iur1 von der empfangenen Abrufanforderung Dcreq. Der Protokollkontrollabschnitt Ppc fragt dann bei dem Verbindungsinformationsverwal tungsabschnitt Pconn2 nach, ob das Merkmal, das zu dem gegenwärtig aus der Ortsangabeninformation Iur1 extrahierten Merkmal passt, in der Verbindungsinformationstabelle Tconn3 gefunden wird. Wenn die Verbindungsinformationstabelle Tconn3 das Merkmal enthält, das zu dem abgefragten Merkmal der Ortsangabeninformation Iur1 passt, gibt der Verbindungsinformationsverwaltungsabschnitt Pconn2 die Verbindungsverfahrensinformation Iconn1 an den Protokollkontrollabschnitt Ppc zurück, die gepaart ist mit diesem Merkmal der Ortsangabeninformation Iur1. Der Protokollkontrollabschnitt Ppc bestimmt gemäß der empfangenen Verbindungsverfahrensinformation Iconn1, welches Verbindungsverfahren, die paketvermittelte Verbindung oder die leitungsvermittelte Verbindung, für die derzeit abzurufenden Inhaltsdaten Dc angewandt werden soll. Die nachfolgende Operation ist im Wesentlichen dieselbe wie die ersten Ausführungsform und daher wird die Beschreibung hier unterlassen.
  • Wie oben beschrieben, hat jedes Inhaltsdatum Dc Ortsangabeninformation Iur1 dazu zugeordnet, welche das Merkmal der Inhaltsdaten Dc repräsentiert. Die Inhalteabrufvorrichtung 1c hält im Voraus die Verbindungsinformationstabelle Tconn3, welche Beschreibung der Verbindungsverfahrensinformation Iconn1 in Zusammenhang mit dem Merkmal der Ortsangabeninformation Iur1 enthält. Die Inhalteabrufvorrichtung 1c extrahiert das Merkmal der Ortsangabeninformation Iur1 von der Abrufanforderung Dcreq und durch Verwenden des extrahierten Merkmals der Ortsangabeninformation Iur1 und durch Bezugnahme auf die Verbindungsinformationstabelle Tconn3 ist die Inhalteabrufvorrichtung 1c vor dem zum Abruf der Inhaltsdaten Dc geeigneten Verbindungsverfahren vor- dem Abrufen der Inhaltsdaten Dc informiert.
  • In der dritten Ausführungsform ist die Verbindungsverfahrensinformation Iconn1 in der Verbindungsinformationstabelle Tconn3 in Zusammenhang mit der Erweiterung beschrieben, so dass der Protokollkontrollabschnitt Ppc die Verbindungsverfahrensinformation Iconn1 basierend auf der Erweiterung der Ortsangabeninformation Iur1 der abzurufenden Inhaltsdaten Dc extrahiert. Alternativ können andere Teile der Ortsangabeninformation Iur1 als die Erweiterung, wie der Host-Name, ein Teil oder das Gesamte des Pfades, das Schema oder die Portnummer, in der Verbindungsinformationstabelle Tconn3 beschrieben werden. Der Protokollkontrollabschnitt Ppc extrahiert dann die Verbindungsverfahrensinformation, welche der Information (der Host-Name, ein Teil oder das Gesamte des Pfades, das Schema oder die Portnummer) entspricht, die in Verbindungsinformationstabelle Tconn3 beschrieben sind, unter Verwendung der Ortsangabeninformation Iur1 der abzurufenden Inhaltsdaten Dc.
  • Hiernach wird eine mobile Kommunikationseinheit Ucomm3, welche die Inhalteabrufvorrichtung 1c, die oben beschrieben ist, umfasst, beschrieben werden. Die mobile Kommunikationseinheit Ucomm3 hat im Wesentlichen denselben Aufbau wie die mobile Kommunikationseinheit Ucomm1. Daher wird sich auf 4 in der folgenden Beschreibung bezogen werden. Die Operation der mobilen Kommunikationseinheit Ucomm3 wird mit Bezug auf das Flussdiagramm von 11 beschrieben werden.
  • Wenn die mobile Kommunikationseinheit Ucomm3 die Inhaltsdaten Dc abzurufen hat, liest die CPU 11 zuerst ein Programm aus dem ROM 12 in das RAM 13. Das Programm in dieser Ausführungsform enthält die in 10 gezeigte Verbindungsinformationstabelle im Voraus. Die Verbindungsinformationstabelle Tconn3 wird während des Lesens des Programms in das RAM 13 gelesen. Wenn die Inhaltsdaten Dc durch die mobile Kommunikationseinheit Ucomm3 abzurufen sind, arbeitet die CPU 11 zuerst als der Browserabschnitt Pbw, um eine Abrufanforderung zu erzeugen (Schritt S301). Genauer erzeugt, in Schritt S301, die CPU 11 eine Abrufanforderung Dcreq, welche die von der Eingabevorrichtung 14 empfangene Ortsangabeninformation Iur1 enthält.
  • Danach arbeitet die CPU 11 als der Protokollkontrollabschnitt Ppc, um eine Erweiterung aus der gegenwärtig extrahierten Ortsangabeninformation Iur1 zu extrahieren, welche das Merkmal der Inhaltsdaten Dc anzeigt, die gegenwärtig abzuru fen sind (Schritt S302). Die CPU 11 extrahiert dann die Verbindungsinformation Iconn1, welche gepaart ist mit dem gegenwärtigen extrahierten Merkmal der Ortsangabeninformation Iur1 aus der Verbindungsinformationstabelle Tconn3 in dem RAM 13 (Schritt S303). Die GPU 11 bestimmt, ob die gegenwärtigen Inhaltsdaten Dc unter der paketvermittelten Verbindung oder der leitungsvermittelten Verbindung abgerufen werden sollen (Schritt S304) gemäß der extrahierten Verbindungsverfahrensinformation Iconn1. Wenn die extrahierte Information die Verbindungsverfahrensinformation Iconn11 ist, wird die paketvermittelte Verbindung geeignet für den gegenwärtigen Abruf der Inhaltsdaten Dc bestimmt. Wenn die extrahierte Information Verbindungsverfahrensinformation Tconn12 ist, wird die leitungsvermittelte Verbindung als geeignet für den gegenwärtigen Abruf der Inhaltsdaten Dc bestimmt.
  • Nachfolgend bestimmt die CPU 11, ob die Verbindung zu dem Inhalteserver 3 aufgebaut wurde oder nicht (Schritt S305). Genauer bestimmt die CPU 11, ob Zugriff auf den Server 3 (siehe 9) unter entweder der paketvermittelten Verbindung oder der leitungsvermittelten Verbindung möglich ist. Wenn die Vebindung nicht aufgebaut ist, gibt die CPU 11 die gegenwärtig erzeugte Abrufanforderung Dcreq entweder zu dem ersten Kommunikationskontrollabschnitt Pcc1 oder dem zweiten Kommunikationskontrollabschnitt Pcc2 weiter, wobei sie anweist, die Inhaltsdaten Dc abzurufen (Schritt S306). Bei diesem Schritt, wenn die paketvermittelte Verbindung in Schritt S304 als geeignet bestimmt wurde, wird die gegenwärtig erzeugte Abrufanforderung Dcreq an den ersten Kommunikationskontrollabschnitt Pcc1 weitergegeben. Im Gegensatz dazu, falls die leitungsvermittelte Verbindung als geeignet bestimmt wurde, wird die gegenwärtige Abrufanforderung Dcreq an den zweiten Kommunikationskontrollabschnitt Pcc2 weitergegeben. Die obigen Verarbeitungsreihen bis zu Schritt S306 sind diejenigen, die durch den Protokollkontrollabschnitt Ppc ausgeführt werden.
  • Der erste oder zweite Kommunikationskontrollabschnitt Pcc1 oder Pcc2 baut den ersten oder zweiten Kommunikationspfad 4pkt bzw. 4tel zu dem Inhalteserver 3 nur auf, wenn durch die CPU 11 angewiesen (Schritt S307). Sobald der erste oder zweite Kommunikationspfad 4pkt oder 4tel aufgebaut worden ist, gibt der erste oder zweite Kommunikationskontrollabschnitt Pcc1 oder Pcc2 die Abrufanforderung Dcreq an den ersten oder zweiten Kommunikationspfad 4pkt oder 4tel über den Multiplexer/Demultiplexer 16 und den Sender/Empfänger 17 weiter. Auf diese Weise wird die Abrufanforderung Dcreq zu dem ersten oder zweiten Kommunikationspfad 4pkt oder 4tel ausgegeben (Schritt S308). Der Server 3 empfängt die Abrufanforderung Dcreq, erzeugt Antwortdaten Drep1, wie in 2A gezeigt, in Antwort auf die Anforderung und sendet die Antwort an den ersten oder zweiten Kommunikationspfad 4pkt oder 4tel, welcher auch immer gegenwärtig als der Pfad zu der mobilen Komminikationseinheit Ucomm3 aufgebaut worden ist.
  • In der mobilen Kommunikationseinheit Ucomm3 empfängt der erste oder zweite Kommunikationskontrollabschnitt Pcc1 oder Pcc2 die Antwortdaten Drep, welche an ihn selbst gerichtet sind, über den ersten oder zweiten Kommunikationspfad 4pkt oder 4tel, den Sender/Empfänger 17 und den Multiplexer/Demultiplexer 16. Der erste oder zweite Kommunikationskontrollabschnitt Pcc1 oder Pcc2 speichert die empfangenen Antwortdaten Drep in dem RAM 13 so wie sie sind. Auf diese Weise empfangt die CPU 11 die Antwortdaten Drep. In dem nachfolgenden Schritt arbeitet die CPU 11 als der Protokollkontrollabschnitt Ppc, um die Antwortdaten Drep in dem RAM 13 zu analysieren (Schritt S309). Danach arbeitet die CPU 11 als der Browserabschnitt Pbw, um Ausgabedaten Dout in dem RAM 13 gemäß den Inhaltsdaten Dc zu erzeugen (Schritt S3010). Die Ausgabedaten Dout werden an die Ausgabevorrichtung 15 zur Ausgabeverarbeitung transferiert.
  • In einigen Fällen erzeugt die Inhalteabrufvorrichtung 1c eine Inhalteabrufanforderung Dcreq nach Aufbau der Verbindung. In solchen Fällen bestimmt die CPU 11 in Schritt S305, dass die Verbindung aufgebaut ist. Die CPU 11 bestimmt dann, ob ein Umschalten der Verbindung notwendig ist oder nicht (Schritt S311). Genauer bestimmt die CPU 11, ob der Kommunikationspfad 4 (der erste Kommunikationspfad 4pkt oder der zweite Kommunikationspfad 4tel), der gegenwärtig zur Datenkommunikation mit dem Inhalteserver 3 verwendet wird, zu dem Kommunikationspfad 4 passt, der in Schritt 304 bestimmt wurde. Falls er passt, wird kein neuer Verbindungsaufbau benötigt, und daher geht die CPU 11 zu Schritt S307. Wenn der Kommunikationspfad, der in Schritt S304 bestimmt wurde, unterschiedlich ist von dem gegenwärtig verwendeten, schreitet die CPU 11 zu Schritt S312 fort, wo die CPU 11 zuerst den ersten oder zweiten Kommunikationskontrollabschnitt Pcc1 oder Pcc2, der gegenwärtig zur Datenkommunikation verwendet wird, anweist die Verbindung zu trennen (den ersten oder zweiten Kommunikationspfad 4pkt oder 4tel zu trennen). Die CPU 11 gibt dann die gegenwärtig erzeugte Abrufanforderung Dcreq an den ersten oder zweiten Kommunikationskontrollabschnitt Pcc1 oder Pcc2 weiter, der in Schritt S304 bestimmt wurde, wobei sie anweist, die Inhaltsdaten Dc abzurufen (Schritt S312). Danach führt die Inhalteabrufvorrichtung 1c den Schritt S308 aus.
  • 12 ist ein funktionales Blockdiagramm einer Inhalteabrufvorrichtung 1d einer vierten Ausführungsform der vorliegenden Erfindung. 12 zeigt auch ein Kommunikationsnetzwerk 2 und einen Inhalteserver 3 in Zusammenhang mit der Inhalteabrufvorrichtung 1d. Die Inhalteabrufvorrichtung 1d hat denselben Aufbau wie die Inhalteabrufvorrichtung 1b und daher wird die Beschreibung davon hier unterlassen. Der Inhalteserver 3 speichert einige Inhaltsdaten Dc (drei in dem veranschaulichten Beispiel) wie in der dritten Ausführungsform.
  • Die Operation der Inhalteabrufvorrichtung 1d, welche den obigen Aufbau hat, wird beschrieben werden. Der Protokollkontrollabschnitt Ppc empfängt eine Inhalteabrufanforderung Dcreq, die durch den Browserabschnitt Pbw erzeugt wurde. Die Inhalteabrufanforderung Dcreq enthält die Ortsangabeninformation Iur1 der Inhaltsdaten Dc, die gegenwärtig abzurufen sind, wie in den obigen Ausführungsformen. In Antwort auf Empfang der Abrufanforderung Dcreq erzeugt der Protokollkontrollabschnitt Ppc eine Header-Abrufanforderung Dcreq, welches Daten sind, die den Inhalteserver 3 auffordern, nur einen Antwort-Header Hc für die Inhaltsdaten Dc, die gegenwärtig abzurufen sind, zu übertragen. Die Abrufanfor derrng Dhreq enthält die Ortsangabeninformation Iur1, welche die Inhaltsdaten Dc spezifiziert. Wenn Datenkommunikation mit dem Inhalteserver 3 bereits ausgeführt wurde, gibt der Protokollkontrollabschnitt Ppc die erzeugte Abrufanforderung Dhreq an den ersten oder zweiten Kommunikationskontrollabschnitt Pcc1 oder Pcc2 weiter, welcher derzeit Datenkommunikation ausführt, wobei sie anweist, den Antwort-Header Hc abzurufen. Der erste oder zweite Kommunikationskontrollabschnitt Pcc1 oder Pcc2 überträgt die Abrufanforderung Dhreq an den Inhalteserver 3 über den ersten oder zweiten Kommunikationspfad 4pkt oder 4tel nur, wenn durch den Protokollkontrollabschnitt Ppc angewiesen.
  • Wenn mit dem Inhalteserver 3 noch keine Datenkommunikation ausgeführt wurde, gibt der Protokollkontrollabschnitt Ppc die erzeugte Abrufanforderung Dhreq vorzugsweise an den ersten Kommunikationskontrollabschnitt Pcc1 weiter, wobei er anweist, den Antwort-Header Hc abzurufen. Der erste Kommunikationskontrollabschnitt Pcc1 wird ausgewählt, da der erste Kommunikationspfad 4pkt in Kommunikationskosten weniger teuer ist. In Antwort auf die Anweisung von dem Protokollkontrollabschnitt Ppc überträgt der erste Kommunikationskontrollabschnitt Pcc1 die Abrufanforderung Dhreq an den Inhalteserver 3 über den ersten Übertragungspfad 4pkt.
  • Der Inhalteserver 3 erstellt den Antwort-Header Hc für die Inhaltsdaten Dc basierend auf der Ortsangabeninformation Iur1, die in der empfangenen Abrufanforderung Dhreq spezifiziert ist. Das Format des Antwort-Headers Hc ist wie in 2A gezeigt. Der erstellte Antwort-Header Hc wird von dem Inhalteserver 3 an die Inhalteabrufvorrichtung 1d über den ersten oder zweiten Kommunikationspfad 4pkt oder 4tel übertragen.
  • In der Inhalteabrufvorrichtung 1d empfängt der erste oder zweite Kommunikationskontrollabschnitt Pcc1 oder Pcc2 den Antwort-Header Hc über den ersten oder zweiten Kommunikationspfad 4pkt oder 4tel, und gibt den Antwort-Header Hc an den Protokollkontrollabschnitt Ppc so wie er ist weiter. Der Protokollkontrollab schnitt Ppc extrahiert den Inhaltetyp Ictyp von dem empfangenen Antwort-Header Hc und extrahiert die Verbindungsverfahrensinformation Iconn1, die gepaart ist mit dem extrahierten Inhaltetyp Ictyp von der Verbindungsinformationstabelle Tconn2 (siehe 7A) in dem Verbindungsinformationsverwaltungsabschnitt Pconn1. Der Protokollkontrollabschnitt Ppc bestimmt gemäß der extrahierten Verbindungsverfahrensinformation Iconn1, ob die gegenwärtigen Inhaltsdaten Dc unter der paketvermittelten Verbindung oder der leitungsvermittelten Verbindung abgerufen werden sollen. Wenn die Verbindungsverfahrensinformation Iconn11 extrahiert wird, wird die paketvermittelte Verbindung als geeignet bestimmt. Im Gegensatz dazu wird, wenn die Verbindungsverfahrensinformation Iconn12 extrahiert wird, die leitungsvermittelte Verbindung als geeignet bestimmt.
  • Falls der Kommunikationspfad 4 (der erste Kommunikationspfad 4pkt oder der zweite Kommunikationspfad 4tel), welcher durch die extrahierte Verbindungsverfahrensinformation Iconnn1 spezifiziert ist, derselbe ist wie der Kommunikationspfad 4 ist, der für die Übertragung der Header-Abrufanforderung Dhreq verwendet wurde, gibt der Protokollkontrollabschnitt Ppc die Abrufanforderung Dcreq, die von dem Browserabschnitt Pbw empfangen wurde, an den ersten oder zweiten Kommunikationskontrollabschnitt Pcc1 oder Pcc2, der gegenwärtig Datenkommunikation ausführt, weiter, wobei er anweist, die Inhaltsdaten Dc abzurufen. Der erste oder zweite Kommunikationskontrollabschnitt Pcc1 oder Pcc2 überträgt die Abrufanforderung Dcreq an den Inhalteserver 3 über den ersten oder zweiten Kommunikationspfad 4pkt oder 4tel nur, wenn durch den Protokollkontrollabschnitt Ppc angewiesen.
  • Wenn im Gegensatz dazu der durch die extrahierte Verbindungsverfahrensinformation Iconn1 spezifizierte Kommunikationspfad 4 sich von dem zur Übertragung der Header-Abrufanforderung Dhreq verwendeten Kommunikationspfad 4 unterscheidet, weist der Protokollkontrollabschnitt Ppc den ersten oder zweiten Kommunikationskontrollabschnitt Pcc1 oder Pcc2, der gegenwärtig Datenkommunikation ausführt, an, die Verbindung zu trennen. Der Protokollkontrollab schnitt Ppc gibt dann die Abrufanforderung Dcreq, die von dem Browserabschnitt Pbw empfangen wurde, an den ersten oder zweiten Kommunikationskontrollabschnitt Pcc1 oder Pcc2, welcher gegenwärtig keine Datenkommunikation ausführt, weiter, wobei er anweist, die Inhaltsdaten Dc abzurufen. Der erste oder zweite Kommunikationskontrollabschnitt Pcc1 oder Pcc2 trennt den ersten oder zweiten Kommunikationspfad 4pkt oder 4tel, der gegenwärtig als der Pfad zu dem Inhalteserver 3 aufgebaut ist, nur wenn er durch den Protokollkontrollabschnitt Ppc angewiesen wird, die Verbindung zu trennen. Der erste oder zweite Kommunikationskontrollabschnitt Pcc1 oder Pcc2 stellt den ersten oder zweiten Kommunikationspfad 4pkt oder 4tel nur her, wenn durch den Protokollkontrollabschnitt Ppc angewiesen, die Inhaltsdaten Dc abzurufen, und überträgt die Abrufanforderung Dcreq an den Inhalteserver 3.
  • Falls der für die Übertragung der Header-Abrufanforderung Dcreq verwendete Kommunikationspfad 4 getrennt wird, gibt der Protokollkontrollabschnitt Ppc die Abrufanforderung Dcreq, die von dem Browserabschnitt Pbw empfangen wurde, an den ersten oder zweiten Kommunikationskontrollabschnitt Pcc1 oder Pcc2 weiter, welcher durch die extrahierte Verbindungverfahrensinformation Iconn11 spezifiziert ist, wobei er anweist, die Inhaltsdaten Dc abzurufen. Der erste oder zweite Kommunikationskontrollabschnitt Pcc1 oder Pcc2 baut den ersten oder zweiten Kommunikationspfad 4pkt oder 4tel als den Pfad zu dem Inhalteserver 3 nur auf wenn durch den Protokollkontrollabschnitt Ppc angewiesen, und überträgt die Abrufanforderung Dcreq an den Inhalteserver 3. Der Inhalteserver 3 liest die Inhaltsdaten Dc, basierend auf der Ortsangabe Iur1, die in der empfangenen Abrufanforderung Dcreq spezifiziert ist und überträgt die gelesenen Inhaltsdaten Dc an die Inhalteabrufvorrichtung 1d über den ersten oder zweiten Kommunikationspfad 4pkt oder 4tel, der gegenwärtig zur Datenkommunikation verwendet wird.
  • Wie oben beschrieben, ruft die Inhalteabrufvorrichtung 1d den Antwort-Header Hc von Inhaltsdaten Dc vor dem Abrufen der Inhaltsdaten Dc ab und ist über eine zum Abrufen der gegenwärtigen Inhaltsdaten Dc geeignetes Verbindungsverfah ren informiert durch Bezugnahme auf den Inhaltstyp Ictyp, der in dem abgerufenen Antwort-Header Hc enthalten ist, und der Verbindungsinformationstabelle Tconn2.
  • In der vierten Ausführungsform wird der Inhaltstyp Ictyp aus dem Antwort-Header Hc extrahiert und der Verbindungsinformationsverwaltungsabschnitt Pconn1 verwaltete die Verbindungsverfahrensinformation Iconn1 in Zusammenhang mit dem Inhaltetyp Ictyp. Alternativ kann ein Attribut der Inhaltsdaten Dc, das in dem Antwort-Header Hc enthalten ist (z.B. die Inhaltslänge Ic1g), extrahiert werden und der Verbindungsinformationsverwaltungsabschnitt Pconn1 kann die Verbindungsverfahrensinformation Iconn1 in Zusammenhang mit diesem Attribut der Inhaltsdaten Dc verwalten. Insbesondere bestimmt, wenn das Attribut der Inhaltsdaten Dc die Inhaltslänge Ic1g ist, die Inhalteabrufvorrichtung 1d die zu extrahierende Verbindungsverfahrensinformation Iconn1 durch Vergleichen der Länge Ic1g der gegenwärtig abzurufenden Inhaltsdaten Dc mit der Inhaltslänge Ic1g, die durch den Verbindungsinformationsverwaltungsabschnitt Pconn1 verwaltet wird.
  • Hiernach wird eine mobile Kommunikationseinheit Ucomm4, welche die Inhalteabrufvorrichtung 1d, die oben beschrieben ist, enthält, beschrieben werden. Die mobile Kommunikationseinheit Ucomm4 hat im Wesentlichen denselben Aufbau wie die mobile Kommunikationseinheit Ucomm1. Daher wird sich in der folgenden Beschreibung auf 4 bezogen werden. Die Operation der mobilen Kommunikationseinheit Ucomm4 wird mit Bezug auf das Flussdiagramm von 13 beschrieben werden. 13 ist dieselbe wie 11, außer dass die Schritte S302 bis S304 mit den Schritten S401 bis S405 ersetzt sind. In 13 sind daher Schritte, die den Schritten in 11 entsprechen, mit denselben Bezugzeichen bezeichnet und die Beschreibung davon ist hier unterlassen.
  • Wenn die mobile Kommunikationseinheit Ucomm4 die Inhaltsdaten Dc abzurufen hat, liest die CPU 11 zuerst ein Programm aus dem ROM 12 in das RAM 13. Das Programm in dieser Ausführungsform enthält die Verbindungsinformationstabelle Tconn2, die in 7A gezeigt ist, im Voraus. Die Verbindungsinformationstabelle Tconn2 wird während des Lesens des Programms in das RAM 13 gelesen. Danach erzeugt die CPU 11 eine Abrufanforderung (Schritt S301). Die CPU 11 arbeitet dann als Protokollkontrollabschnitt Ppc, um eine Header-Abrufanforderung Dhreq zu erzeugen (Schritt S402).
  • Die CPU 11 gibt die erzeugte Abrufanforderung Dhreq an entweder den ersten Kommunikationskontrollabschnitt Pcc1 oder den zweiten Kommunikationskontrollabschnitt Pcc2 weiter. Wenn Datenkommunikation mit dem Inhalteserver 3 bereits ausgeführt wurde, gibt die CPU 11 die erzeugte Abrufanforderung Dhreq an den Kommunikationskontrollabschnitt weiter, der gegenwärtig Datenkommunikation ausführt, wobei sie anweist, den Antwort-Header Hc abzurufen. In Antwort auf die Anweisung von der CPU 11 überträgt der erste oder zweite Kommunikationskontrollabschnitt Pcc1 oder Pcc2 die Abrufanforderung Dhreq an den Inhalteserver 3 über den Multiplexer/Demultiplexer 16, den Sender/Empfänger 17 und den ersten oder zweiten Kommunikationspfad 4pkt oder 4tel. Im Gegensatz dazu, falls noch keine Datenkommunikation bereits ausgeführt wurde, gibt die CPU 11 die erzeugte Abrufanforderung Dhreq an den ersten Kommunikationskontrollabschnitt Pcc1. In Antwort überträgt der erste Kommunikationskontrollabschnitt Pcc1 die Abrufanforderung Dhreq an den Inhalteserver 3 über den Multiplexer/Demultiplexer 16, den Sender/Empfänger 17 und den ersten Kommunikationspfad 4pkt. Auf diese Weise wird die Header-Abrufanforderung Dhreq an den Inhalteserver 3 übertragen (Schritt S402).
  • Der Inhalteserver 3 erzeugt den Antwort-Header Hc und gibt den Antwort-Header Hc an die mobile Kommunikationseinheit Ucomm4 über den ersten oder zweiten Kommunikationspfad 4pkt oder 4tel zurück. In der mobilen Kommunikationseinheit Ucomm4 empfängt der erste oder zweite Kommunikationskontrollabschnitt Pcc1 oder Pcc2 den Antwort-Header Hc über den ersten oder zweiten Kommunikationspfad 4pkt oder 4tel, den Sender/Empfänger 17 und den Multiple xer/Demultiplexer 16 und speichert den Antwort-Header Hc so wie er ist in dem RAM 13. Auf diese Weise empfängt die CPU 11 den Antwort-Header Hc (Schritt S403). Die CPU 11 extrahiert die Verbindungsverfahrensinformation Iconn1, welche gepaart ist mit dem Inhaltetyp Ictyp in dem empfangenen Antwort-Header Hc aus der Verbindungsinformationstabelle Tconn2 (siehe 7A) in dem RAM 13. Die CPU 11 bestimmt, ob die Inhaltsdaten Dc unter der paketvermittelten Verbindung oder der leitungsvermittelten Verbindung abgerufen werden sollen gemäß der extrahierten Verbindungsverfahrensinformation Iconn1 (Schritt S405). Nachfolgend führt die mobile Kommunikationseinheit Ucomm4 Schritte S305 bis S312 aus, die im Wesentlichen dieselben sind wie die in 11 gezeigten. Es sollte jedoch bemerkt werden, dass der Inhalteserver 3 nur die Inhaltsdaten Dc an die mobile Kommunikationseinheit Ucomm4 übertragen mag in Antwort auf die Inhalteabrufanforderung Dcreq. Ubertragung des Antwort-Headers Hc ist nicht notwendigerweise erforderlich.
  • In den ersten bis vierten Ausführungsformen, die oben beschrieben sind, wurde HTML als die Markup-Sprache verwendet. Die Inhalteabrufvorrichtungen 1a bis 1d der vorliegenden Erfindung können die oben beschriebene Verarbeitung auch für Inhaltsdaten Dc ausführen, die in XML (eXtension Markup Language) beschrieben sind.
  • Während die Erfindung im Detail beschrieben wurde, ist die vorhergehende Beschreibung in allen Aspekten illustrativ und nicht beschränkend. Es wird verstanden werden, dass zahlreiche andere Modifikationen und Variationen erdacht werden können, ohne den Bereich der Erfindung zu verlassen.

Claims (20)

  1. Inhalteabrufvorrichtung (1a bis 1d) zum Abrufen von Inhaltsdaten von einem Server über ein Kommununikationsnetzwerk, wobei die Inhalteabrufvorrichtung umfasst: einen Browserabschnitt (Pbw) zum Erzeugen einer Abrufanfrage, welche Ortsangabeninformation von derzeit abzurufenden Inhaltsdaten spezifiziert; einen Protokollkontrollabschnitt (Ppc) zum Auswählen einer geeigneten Verbindungsverfahren für die dadurch spezifizierten Inhaltsdaten aus einem aus entweder einem paketvermittelten Verbindungsverfahren oder einem leitungsvermittelten Verbindungsverfahren, die in einer Multi-Ruf-Funktion verwendet werden; und einen Kommunikationskontrollabschnitt (Pcc1, Pcc2) zum Empfangen der durch den Browserabschnitt spezifizierten Inhaltsdaten von dem Server in entweder dem paketvermittelten Verbindungsverfahren oder dem leitungsvermittelten Verbindungsverfahren, das durch den Protokollkontrollabschnitt ausgewählt wurde; dadurch gekennzeichnet, dass der Protokollkontrollabschnitt (Ppc) angepasst ist, das geeignete Verbindungsverfahren basierend auf Information auszuwählen, die in der Ortsangabeninformation, die in der Abrufanfrage, die durch den Browserabschnitt vor Empfang der Inhaltsdaten spezifiziert wurde, enthalten ist oder dieser beigefügt ist.
  2. Inhalteabrufvorrichtung nach Anspruch 1, worin der Browserabschnitt eingerichtet ist, die empfangenen Inhaltsdaten zu analysieren, um daraus Ortsangabeninformation jeder Unterinhaltsdaten zu extrahieren, die mit den Inhaltsdaten verknüpft sind, und Verbindungsverfahreninformation, welche ein geeignetes Verbindungsverfahren für jede der Unterinhaltsdaten anzeigt, und dann eine Abrufanfrage zu erzeugen, welche die Ortsangabeninformation von derzeit abzurufenden Unterinhaltsdaten angibt, und der Protokollkontrollabschnitt angepasst ist, basierend auf der durch den Browserabschnitt extrahierten Verbindungsverfahrensinformation, ein geeignetes Verbindungsverfahren auszuwählen zum Empfangen der Unterinhaltsdaten, die durch den Browserabschnitt spezifiziert wurden, aus entweder einem paketvermittelten Verbindungsverfahren oder einem leitungsvermittelten Verbindungsverfahren, die in einer Multi-Ruf-Funktion verwendet werden.
  3. Inhalteabrufvorrichtung nach Anspruch 1, worin die Inhalteabrufvorrichtung weiterhin einen Verbindungsinformationsverwaltungsabschnitt (Pconn1) umfasst zum Verwalten einer Verbindungsinformationstabelle, welche Beschreibung eines geeigneten Verbindungsverfahrens in Verbindung mit dem Datei-Attribut der Inhaltsdaten enthält, der Browserabschnitt eingerichtet ist, die empfangenen Inhaltsdaten zu analysieren, um daraus eine Menge der Ortsangabeninformation und des Datei-Attributs jeder der Unterinhaltsdaten zu extrahieren, die mit den Inhaltsdaten verknüpft sind, und die Menge als interne Information zu halten, und dann eine Abrufanfrage zu erzeugen, welche die Ortsangabeninformation der derzeit abzurufenden Unterinhaltsdaten spezifiziert, und der Protokollkontrollabschnitt eingerichtet ist, nach Empfang der durch den Browserabschnitt erzeugten Abrufanfrage, entweder das paketvermittelte Verbindungsverfahren oder das leitungsvermittelte Verbindungsverfahren als ein geeignetes Verbindungsverfahren auszuwählen durch Emp fangen des Datei-Attributs, das gepaart ist mit der Ortsangabeinformation, spezifiziert in der Abrufanfrage von dem Browserabschnitt, und dann Extrahieren des geeigneten Verbindungsverfahrens, das gepaart ist mit dem Datei-Attribut, das von dem Browserabschnitt empfangen wurde, von dem Verbindungsinformationsverwaltungsabschnitt.
  4. Inhalteabrufvorrichtung nach Anspruch 1, worin die Inhalteabrufvorrichtung weiterhin einen Verbindungsinformationsverwaltungsabschnitt (Pconn2) umfasst zum Verwalten einer Verbindungsinformationstabelle, welche Beschreibung eines geeigneten Verbindungsverfahrens in Verbindung mit einer Eigenschaft der Inhaltsdaten enthält, und der Browserabschnitt zum Erzeugen einer Abrufanfrage, welche Ortsangabeninformation spezifiziert, welche den Inhaltsdaten zugewiesen ist zum Anzeigen eines Speicherorts der Inhaltsdaten in dem Server, wobei ein Teil der Ortsangabeninformation eine Eigenschaft der Inhaltsdaten darstellt, wobei der Protokollkontrollabschnitt eingerichtet ist, ein geeignetes Verbindungsverfahren zu bestimmen durch, nach Empfang der durch den Browserabschnitt erzeugten Abrufanfrage, Empfangen des geeigneten Verbindungsverfahrens, das gepaart ist mit dem Teil der Ortsangabeninformation, die in der Abrufanfrage enthalten ist, von dem Verbindungsinformationsverwaltungsabschnitt.
  5. Inhalteabrufvorrichtung nach Anspruch 1, worin die Inhalteabrufvorrichtung weiterhin einen Verbindungsinformationsverwaltungsabschnitt (Pconn1) umfasst zum Verwalten einer Verbindungsinformationstabelle, welche Beschreibung eines geeigneten Verbindungsverfahrens in Verbindung mit dem Datei-Attribut der Inhaltsdaten enthält, der Browserabschnitt eingerichtet ist, eine erste Abrufanfrage zu erzeugen, welche Ortsangabeninformation von derzeit abzurufenden Inhaltsdaten spezifiziert, nach Empfang der ersten Abrufanfrage, die durch den Browserabschnitt erzeugt wurde, der Protokollkontrollabschnitt eingerichtet ist, eine zweite Abrufanfrage zu erzeugen zu Abrufen eines Inhalt-Headers der Inhaltsdaten, die in der ersten Abrufanfrage spezifiziert wurden, der Kommunikationskontrollabschnitt eingerichtet ist, von dem Server einen Inhalt-Header zu empfangen, der ein Datei-Attribut von Inhaltsdaten enthält, spezifiziert in der zweiten Abrufanfrage, die durch den Protokollkontrollabschnitt erzeugt wurde, und der Protokollkontrollabschnitt eingerichtet ist, ein geeignetes Verbindungsverfahren zu bestimmen durch Extrahieren des geeigneten Verbindungsverfahrens, das gepaart ist mit dem Datei-Attribut, das in dem Inhalt-Header enthalten ist, der durch den Kommunikationskontrollabschnitt empfangen wurde, aus dem Verbindungsinformationsverwaltungsabschnitt.
  6. Inhalteabrufverfahren zum Abrufen von Inhaltsdaten von einem Server über ein Kommunikationsnetzwerk, wobei das Verfahren die Schritte umfasst des: Erzeugens einer Inhaltsabrufanfrage, welche Ortsangabeninformation von derzeit abzurufenden Inhaltsdaten spezifiziert (S101); Auswählens eines geeigneten Verbindungsverfahrens für die Inhaltsdaten, welche durch den Schritt des Erzeugens einer Inhaltsabrufanfrage spezifiziert wurden, aus entweder einem paketvermittelten Verbindungsverfahren oder einem leitungsvermittelten Verbindungsverfahren, die in einer Multi-Ruf-Funktion verwendet werden (S1012, S304, S405); und Empfangens der Inhaltsdaten, welche durch den Schritt des Erzeugens einer Inhaltsabrufanfrage spezifiziert wurden, von dem Server in entweder dem paketvermittelten Verbindungsverfahren oder dem leitungsvermittel ten Verbindungsverfahren, das durch den Schritt des Bestimmens eines geeigneten Verbindungsverfahrens ausgewählt wurde (S106, S309); dadurch gekennzeichnet, dass in dem Schritt des Auswählens das geeignete Verbindungsverfahren ausgewählt wird basierend auf Information, welche in der Ortsangabeninformation, die in der durch den Browserabschnitt erzeugten Abrufanfrage spezifiziert ist, enthalten ist oder dieser beigefügt ist, vor dem Empfang der Inhaltsdaten.
  7. Inhalteabrufverfahren nach Anspruch 6, worin Inhaltsdaten Ortsangabeninformation enthalten für jede von Unterinhaltsdaten, die mit den Inhaltsdaten verknüpft sind, und ein Verbindungsverfahren geeignet für jede der Unterinhaltsdaten, der Schritt des Erzeugens einer Inhaltsabrufanfrage, die Ortsangabeninformation und die Verbindungsverfahrensinformation jeder der Unterinhaltsdaten extrahiert durch Analysieren der empfangenen Inhaltsdaten, und dann eine Inhaltsabrufanfrage erzeugt, welche die Ortsangabeninformation von derzeit abzurufenden Inhaltsdaten spezifiziert, und der Schritt des Auswählens, basierend auf der Verbindungsverfahrensinformation, die durch den Schritt des Erzeugens einer Inhaltsabrufanfrage spezifiziert werden, eines geeigneten Verbindungsverfahrens zum Empfang der Unterinhaltsdaten, die durch den Schritt des Erzeugens der Inhaltsabrufanfrage spezifiziert werden, auswählt aus entweder einem paketvermittelten Verbindungsverfahren oder einem leitungsvermittelten Verbindungsverfahren, die in einer Multi-Ruf-Funktion verwendet werden.
  8. Inhalteabrufverfahren nach Anspruch 6, worin die Inhaltsdaten Ortsangabeninformation und ein Datei-Attribut von jeder von Unterinhaltsdaten enthalten, die mit den Inhaltsdaten verknüpft sind, der Schritt des Erzeugens einer Inhaltsabrufanfrage eine Menge der Ortsangabeninformation und des Datei-Attributs von jeder der Unterinhaltsda ten extrahiert durch Analysieren der empfangenen Inhaltsdaten und die Menge als interne Information hält, und dann eine Inhaltsabrufanfrage erzeugt, welche die Ortsangabeninformation von derzeit zu empfangenden Unterinhaltsdaten spezifiziert, und der Schritt des Bestimmens eines geeigneten Verbindungsverfahrens ein geeignetes Verbindungsverfahren bestimmt durch, nach Empfang der durch den Schritt des Erzeugens einer Inhaltsabrufanfrage erzeugten Inhaltsabrufanfrage, Empfang des Datei-Attributs, das mit der Ortsangabeninformation gepaart ist, die in der Inhaltsabrufanfrage spezifiziert ist, von dem Schritt des Erzeugens einer Inhaltsabrufanfrage, und dann Extrahieren des geeigneten Verbindungsverfahrens, gepaart mit dem Datei-Attribut, das von dem Schritt des Erzeugens einer Inhaltsabrufanfrage empfangen wurde, aus einer Verbindungsinformationstabelle, die im Voraus erzeugt wurde, welche Beschreibung eines geeigneten Verbindungsverfahrens in Verbindung mit dem Datei-Attribut der Inhaltsdaten enthält.
  9. Inhalteabrufverfahren nach Anspruch 6, worin Ortsangabeninformation zugewiesen wird an Inhaltsdaten zum Anzeigen eines Speicherorts der Inhaltsdaten in dem Server, wobei ein Teil der Ortsangabeninformation eine Eigenschaft der Inhaltsdaten repräsentiert, der Schritt des Bestimmens eines geeigneten Verbindungsverfahrens ein geeignetes Verbindungsverfahren bestimmt nach Empfang der durch den Schritt des Erzeugens einer Inhaltsabrufanfrage erzeugten Inhaltsabrufanfrage, Extrahieren des geeigneten Verbindungsverfahrens, das mit dem Teil der Ortsangabeninformation gepaart ist, das in der Inhaltsabrufanfrage enthalten ist, aus einer Verbindungsinformationstabelle, die im Voraus erzeugt wurde, welche Beschreibung eines geeigneten Verbindungsverfahrens in Verbindung mit der Eigenschaft der Inhaltsdaten enthält.
  10. Inhalteabrufverfahren nach Anspruch 6, worin der Server in der Lage ist, einen Inhalt-Header zu übertragen, der ein Datei-Attribut von Inhaltsdaten enthält, sowie die Inhaltsdaten, das Verfahren weiter die Schritte umfasst des: nach Empfang der Inhaltsabrufanfrage, die durch den Schritt des Erzeugens einer Inhaltsabrufanfrage erzeugt wurde, Erzeugens einer Header-Abrufanfrage zum Abrufen eines Inhalt-Headers der Inhaltsdaten, die in der Inhaltsabrufanfrage spezifiziert sind; und Empfangens des Inhalt-Headers, der in der Header-Abrufanfrage spezifiziert ist, die durch den Schritt des Erzeugens einer Header-Abrufanfrage erzeugt wurde, von dem Server, und der Schritt des Bestimmens eines geeigneten Verbindungsverfahrens ein geeignetes Verbindungsverfahren bestimmt durch Extrahieren des geeigneten Verbindungsverfahrens, das gepaart ist mit dem Datei-Attribut, das in dem Inhalt-Header enthalten ist, der durch den Schritt des Empfangs des Inhalt-Headers empfangen wurde, aus einer Verbindungsinformationstabelle, die im Voraus erzeugt wurde, welche Beschreibung eines geeigneten Verbindungsverfahrens enthält in Verbindung mit der Eigenschaft der Inhaltsdaten, die im Voraus verwaltet wird.
  11. Aufzeichnungsmedium mit einem darauf aufgezeichneten Programm, auf welches ein Programm zum Abrufen von Inhaltsdaten von einem Server über ein Kommunikationsnetzwerk aufgezeichnet ist, wobei das Programm die Schritte umfasst des: Erzeugens einer Inhaltsabrufanfrage, welche Ortsangabeninformation von derzeit abzurufenden Inhaltsdaten spezifiziert (S101); Auswählens eines geeigneten Verbindungsverfahrens für die Inhaltsdaten, welche durch den Schritt des Erzeugens einer Inhaltsabrufanfrage spezifiziert wurden, aus entweder einem paketvermittelten Verbindungsverfahren oder einem leitungsvermittelten Verbindungsverfahren, die in einer Multi-Ruf-Funktion verwendet werden (S1012, S304, S405); und Empfangens der Inhaltsdaten, welche durch den Schritt des Erzeugens einer Inhaltsabrufanfrage spezifiziert wurden, von dem Server unter entweder dem paketvermittelten Veibindungsverfahren oder dem leitungsvermittelten Verbindungsverfahren, das durch den Schritt des Bestimmens eines geeigneten Verbindungsverfahrens ausgewählt wurde (S106, S309); dadurch gekennzeichnet, dass in dem Schritt des Auswählens das geeignete Verbindungsverfahren ausgewählt wird basierend auf Information, welche in der Ortsangabeninformation, die in der durch den Browserabschnitt erzeugten Abrufanfrage spezifiziert ist, enthalten ist oder dieser beigefügt ist, vor dem Empfang der Inhaltsdaten.
  12. Aufzeichnungsmedium mit darauf aufgezeichnetem Programm nach Anspruch 11, worin Inhaltsdaten Ortsangabeninformation von jeder von Unterinhaltsdaten enthält, die mit den Inhaltsdaten verknüpft sind, und ein Verbindungsverfahren, das für jede der Unterinhaltsdaten geeignet ist, der Schritt des Erzeugens einer Inhaltsabrufanfrage die Ortsangabeninformation und die Verbindungsverfahrensinformation von jeder der Unterinhaltsdaten extrahiert durch Analysieren der empfangenen Inhaltsdaten, und dann eine Inhaltsabrufanfrage erzeugt, welche Ortsangabeninformation von derzeit abzurufenden Unterinhaltsdaten spezifiziert, und der Schritt des Auswählens, basierend auf der Verbindungsverfahrensinformation, die durch den Schritt des Erzeugens einer Inhaltsabrufanfrage spezifiziert wurden, eines geeigneten Verbindungsverfahrens ein geeignetes Verbindungsverfahren zum Empfang der Unterinhaltsdaten, die durch den Schritt des Erzeugens der Inhaltsabrufanfrage spezifiziert wurde, bestimmt aus entweder einem paketvermittelten Verbindungsverfahren oder einem leitungsvermittelten Verbindungsverfahren, die in einer Multi-Ruf-Funktion verwendet werden.
  13. Aufzeichnungsmedium mit darauf aufgezeichnetem Programm nach Anspruch 11, worin die Inhaltsdaten Ortangabeninformation und ein Datei-Attribut von jeder der Unterhaltsdaten enthält, die mit den Inhaltsdaten verknüpft sind, der Schritt des Erzeugens einer Inhaltsabrufanfrage eine Menge der Ortsangabeninformation und des Datei-Attributs von jeder der Unterinhaltsdaten extrahiert durch Analysieren der empfangenen Inhaltsdaten und die Menge als interne Information hält, und dann eine Inhaltsabrufanfrage erzeugt, welche die Ortsangabeninformation von derzeit abzurufenden Unterinhaltsdaten spezifiziert, und der Schritt des Bestimmens eines geeigneten Verbindungsverfahrens ein geeignetes Verbindungsverfahren bestimmt durch, nach Empfang der durch den Schritt des Erzeugens einer Inhaltsabrufanfrage erzeugten Inhaltsabrufanfrage, Empfang des Datei-Attributs, das mit der Ortsangabeninformation gepaart ist, die in der Inhaltsabrufanfrage spezifiziert ist, von dem Schritt des Erzeugens einer Inhaltsabrufanfrage, und dann Extrahieren des geeigneten Verbindungsverfahrens, gepaart mit dem Datei-Attribut, das von dem Schritt des Erzeugens einer Inhaltsabrufanfrage empfangen wurde, aus einer Verbindungsinformationstabelle, die im Voraus erzeugt wurde, welche Beschreibung eines geeigneten Verbindungsverfahrens in Verbindung mit dem Datei-Attribut der Inhaltsdaten enthält.
  14. Aufzeichnungsmedium mit darauf aufgezeichnetem Programm nach Anspruch 11, worin Ortsangabeninformation Inhaltsdaten zugeordnet ist zum Anzeigen eines Speicherorts der Inhaltsdaten in dem Server, wobei ein Teil der Ortsangabeninformation eine Eigenschaft der Inhaltsdaten darstellt, der Schritt des Bestimmens eines geeigneten Verbindungsverfahrens ein geeignetes Verbindungsverfahren bestimmt, nach Empfang der durch den Schritt des Erzeugens einer Inhaltsabrufanfrage erzeugten Inhaltsabrufanfrage, durch Extrahieren des geeigneten Verbindungsverfahrens, das mit dem Teil der Ortsangabeninformation gepaart ist, das in der Inhaltsabrufanfrage enthalten ist, aus einer Verbindungsinformationstabelle, die im Voraus erzeugt wurde, welche Beschreibung eines geeigneten Verbindungsverfahrens in Verbindung mit dem Datei-Attribut der Inhaltsdaten enthält.
  15. Aufzeichnungsmedium mit darauf aufgezeichnetem Programm nach Anspruch 11, worin der Server in der Lage ist, einen Inhalt-Header zu übertragen, der ein Datei-Attribut von Inhaltsdaten enthält, sowie die Inhaltsdaten, wobei das Verfahren weiterhin die Schritte umfasst des: nach Empfang der Inhaltsabrufanfrage, die durch den Schritt des Erzeugens einer Inhaltsabrufanfrage erzeugt wurde, Erzeugens einer Header-Abrufanfrage zum Abrufen eines Inhalt-Headers der Inhaltsdaten, die in der Inhaltsabrufanfrage spezifiziert sind; und Empfangens des Inhalt-Headers, der in der Header-Abrufanfrage spezifiziert ist, die durch den Schritt des Erzeugens einer Header-Abrufanfrage erzeugt wurde, von dem Server, und der Schritt des Bestimmens eines geeigneten Verbindungsverfahrens ein geeignetes Verbindungsverfahren bestimmt durch Extrahieren des geeigneten Verbindungsverfahrens, das gepaart ist mit dem Datei-Attribut, das in dem Inhalt-Header enthalten ist, der durch den Schritt des Empfangs des Inhalt-Headers empfangen wurde, aus einer Verbindungsinformationstabelle, die im Voraus erzeugt wurde, welche Beschreibung eines geeigneten Verbindungsverfahrens enthält in Verbindung mit der Eigenschaft der Inhaltsdaten, die im Voraus verwaltet wird.
  16. Programm zum Abrufen von Inhaltsdaten von einem Server über ein Kommunikationsnetzwerk, wobei das Programm die Schritt umfasst des: Erzeugens einer Inhaltsabrufanfrage, welche Ortsangabeninformation von derzeit abzurufenden Inhaltsdaten spezifiziert (S101); Auswählens eines geeigneten Verbindungsverfahrens für die Inhaltsdaten, welche durch den Schritt des Erzeugens einer Inhaltsabrufanfrage spezifiziert wurden, aus entweder einem paketvermittelten Verbindungsverfahren oder einem leitungsvermittelten Verbindungsverfahren, die von einer Multi-Ruf-Funktion verwendet werden (S1012, S304, S405); und Empfangens der Inhaltsdaten, welche durch den Schritt des Erzeugens einer Inhaltsabrufanfrage spezifiziert wurden, von dem Server unter dem paketvermittelten Verbindungsverfahren oder dem leitungsvermittelten Verbindungsverfahren, das durch den Schritt des Bestimmens eines geeigneten Verbindungsverfahrens ausgewählt wurde (S106, S309); dadurch gekennzeichnet, dass in dem Schritt des Auswählens das geeignete Verbindungsverfahren ausgewählt wird basierend auf Information, welche in der Ortsangabeninformation, die in der durch den Browserabschnitt erzeugten Abrufanfrage spezifiziert ist, enthalten ist oder dieser beigefügt ist, vor dem Empfang der Inhaltsdaten.
  17. Programm nach Anspruch 16, worin Inhaltsdaten Ortsangabeninformation von jeder der Unterinhaltsdaten enthält, die mit den Inhaltsdaten verknüpft sind, und ein Verbindungsverfahren, das geeignet ist für jede der Unterinhaltsdaten, der Schritt des Erzeugens einer Inhaltsabrufanfrage extrahiert die Ortsangabeninformation und die Verbindungsverfahrensinformation von jeder der Unterinhaltsdaten durch Analysieren der empfangenen Inhaltsdaten und erzeugt dann eine Inhaltsabrufanfrage, welche Ortsangabeninformation von derzeit abzurufenden Unterinhaltsdaten spezifiziert, und der Schritt des Auswählens, basierend auf der durch den Schritt des Erzeugens einer Inhaltsabrufanfrage extrahierten Verbindungsverfahrensinformation, eines geeigneten Verbindungsverfahrens bestimmt ein geeignetes Verbindungsverfahren zum Empfang der Unterinhaltsdaten, die durch den Schritt des Erzeugens der Inhaltsabrufanfrage spezifiziert wurde, aus ent weder einem paketvermittelten Verbindungsverfahren oder einem leitungsvermittelten Verbindungsverfahren, die von einer Multi-Ruf-Funktion verwendet werden.
  18. Programm nach Anspruch 16, worin die Inhaltsdaten Ortsangabeninformation und ein Datei-Attributt von jeder der Unterinhaltsdaten enthalten, die mit den Inhaltsdaten verknüpft sind, der Schritt des Erzeugens einer Inhaltsabrufanfrage extrahiert eine Menge der Ortsangabeninformation und des Datei-Attributs von jeder der Unterinhaltsdaten durch Analysieren der empfangenen Inhaltsdaten und hält die Menge als interne Information und erzeugt dann eine Inhaltsabrufanfrage, welche die Ortsangabeninformation von derzeit abzurufenden Unterinhaltsdaten spezifiziert, und der Schritt des Bestimmens eines geeigneten Verbindungsverfahrens bestimmt ein geeignetes Verbindungsverfahren durch, nach Empfang der durch den Schritt des Erzeugens einer Inhaltsabrufanfrage erzeugten Inhaltsabrufanfrage, Empfangen des Datei-Attributs, das gepaart ist mit der Ortsangabeninformation, welche in der Inhaltsablufanfage spezifiziert ist, von dem Schritt des Erzeugens einer Inhaltsabrufanfrage, und dann Extrahieren des geeigneten Verbindungsverfahrens, welches gepaart ist mit dem Datei-Attribut, das empfangen wurde von dem Schritt des Erzeugens einer Inhaltsabrufanfrage, aus einer Verbindungsinformationstabelle, die im Voraus erzeugt wurde, welche Beschreibung eines geeigneten Verbindungsverfahrens in Verbindung mit dem Datei-Attribut der Inhaltsdaten enthält.
  19. Programm nach Anspruch 16, worin Ortsangabeninformation an Inhaltsdaten zugewiesen ist zum Anzeigen eines Speicherorts der Inhaltsdaten in dem Server, wobei ein Teil der Ortsangabeninformation eine Eigenschaft der Inhaltsdaten darstellt, der Schritt des Bestimmens eines geeigneten Verbindungsverfahrens bestimmt ein geeignetes Verbindungsverfahren durch, nach Empfang der durch den Schritt des Erzeugens einer Inhaltsabrufanfrage erzeugten Inhaltsabrufanfrage, Extrahieren des geeigneten Verbindungsverfahrens, welches gepaart ist mit dem Teil der Ortsangabeninformation, die in der Inhaltsabrufanfrage enthalten ist, aus einer Verbindungsinformationstabelle, die im Voraus erzeugt wurde, welche Beschreibung eines geeigneten Verbindungsverfahrens in Verbindung mit der Eigenschaft der Inhaltsdaten enthält.
  20. Programm nach Anspruch 16, worin der Server in der Lage ist, einen Inhalt-Header zu übertragen, welcher ein Datei-Attribut von Inhaltsdaten enthält, sowie die Inhaltsdaten, wobei das Verfahren weiterhin die Schritte umfasst des: nach Empfang der durch den Schritt des Erzeugens einer Inhaltsabrufanfrage erzeugten Inhaltsabrufanfrage, Erzeugens einer Header-Abrufanfrage zum Abrufen eines Inhalt-Headers der Inhaltsdaten, die in der Inhaltsabrufanfrage spezifiziert sind; und Empfangens des Inhalt-Headers, welcher in der durch den Schritt des Erzeugens einer Header-Abrufanfrage erzeugten Header-Abrufanfrage spezifiziert ist, von dem Server, und der Schritt des Bestimmens eines geeigneten Verbindungsverfahrens bestimmt ein geeignetes Verbindungsverfahren durch Extrahieren des geeigneten Verbindungsverfahrens, das gepaart ist mit dem Datei-Attribut, das in dem Inhalt-Header enthalten ist, der durch den Schritt des Empfangens des Inhalt-Headers empfangen wurde, aus einer Verbindungsinformationstabelle, die im Voraus erzeugt wurde, welche Beschreibung eines geeigneten Verbindungsverfahrens in Verbindung mit dem Datei-Attribut der Inhaltsdaten enthält.
DE60112982T 2000-03-16 2001-03-15 Einrichtung zur Bereitstellung von Server-Inhalten Expired - Fee Related DE60112982T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2000073808 2000-03-16
JP2000073808 2000-03-16

Publications (2)

Publication Number Publication Date
DE60112982D1 DE60112982D1 (de) 2005-10-06
DE60112982T2 true DE60112982T2 (de) 2006-07-06

Family

ID=18591991

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60112982T Expired - Fee Related DE60112982T2 (de) 2000-03-16 2001-03-15 Einrichtung zur Bereitstellung von Server-Inhalten

Country Status (3)

Country Link
US (1) US7185068B2 (de)
EP (1) EP1134672B1 (de)
DE (1) DE60112982T2 (de)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI108391B (fi) * 1998-10-27 2002-01-15 Nokia Corp Sijaintipalvelut pakettiradioverkossa
US7062274B2 (en) * 2001-06-21 2006-06-13 Microsoft Corporation Increasing the level of automation when establishing and managing network connections
JP4305004B2 (ja) * 2003-02-28 2009-07-29 ソニー株式会社 情報処理装置、およびコンテンツ情報処理方法、並びにコンピュータ・プログラム
US7457520B2 (en) * 2003-07-24 2008-11-25 Time Warner Cable, Inc. Technique for providing a virtual digital video recorder service through a communications network
US8280982B2 (en) 2006-05-24 2012-10-02 Time Warner Cable Inc. Personal content server apparatus and methods
US9386327B2 (en) 2006-05-24 2016-07-05 Time Warner Cable Enterprises Llc Secondary content insertion apparatus and methods
US8024762B2 (en) 2006-06-13 2011-09-20 Time Warner Cable Inc. Methods and apparatus for providing virtual content over a network
US8181206B2 (en) 2007-02-28 2012-05-15 Time Warner Cable Inc. Personal content server apparatus and methods
US9516128B2 (en) 2007-12-13 2016-12-06 International Business Machines Corporation Generic remote connection to a command line interface application
US9503691B2 (en) 2008-02-19 2016-11-22 Time Warner Cable Enterprises Llc Methods and apparatus for enhanced advertising and promotional delivery in a network
CN101931986B (zh) * 2010-08-17 2013-04-24 华为技术有限公司 网络能效指示方法、指示器及系统
US8966138B2 (en) * 2010-08-31 2015-02-24 Apple Inc. Communication between a host device and an accessory using multiple-endpoint identification
US20140282786A1 (en) 2013-03-12 2014-09-18 Time Warner Cable Enterprises Llc Methods and apparatus for providing and uploading content to personalized network storage

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2711468B1 (fr) 1993-10-19 1996-01-05 Ouest Standard Telematique Sa Dispositif d'interconnexion entre deux réseaux locaux distants, et procédé d'interconnexion correspondant.
US5729544A (en) * 1994-05-09 1998-03-17 Motorola, Inc. Method for transmitting data packets based on message type
JP2625388B2 (ja) 1994-08-24 1997-07-02 日本電気株式会社 ローカルエリアネットワーク間接続装置
US5838682A (en) * 1995-11-28 1998-11-17 Bell Atlantic Network Services, Inc. Method and apparatus for establishing communications with a remote node on a switched network based on hypertext dialing information received from a packet network
US6052710A (en) * 1996-06-28 2000-04-18 Microsoft Corporation System and method for making function calls over a distributed network
US5974430A (en) * 1997-09-30 1999-10-26 Unisys Corp. Method for dynamically embedding objects stored in a web server within HTML for display by a web browser
US6272127B1 (en) * 1997-11-10 2001-08-07 Ehron Warpspeed Services, Inc. Network for providing switched broadband multipoint/multimedia intercommunication
AU4810599A (en) 1998-06-15 2000-01-05 Telefonaktiebolaget Lm Ericsson (Publ) Headline hyperlink broadcast service and system
US6487663B1 (en) * 1998-10-19 2002-11-26 Realnetworks, Inc. System and method for regulating the transmission of media data
US6515964B1 (en) * 1998-12-29 2003-02-04 At&T Corp. Method and apparatus for dynamically controlling the admission of calls to a network
US6628617B1 (en) * 1999-03-03 2003-09-30 Lucent Technologies Inc. Technique for internetworking traffic on connectionless and connection-oriented networks

Also Published As

Publication number Publication date
EP1134672A2 (de) 2001-09-19
US20020049800A1 (en) 2002-04-25
EP1134672B1 (de) 2005-08-31
US7185068B2 (en) 2007-02-27
DE60112982D1 (de) 2005-10-06
EP1134672A3 (de) 2004-01-28

Similar Documents

Publication Publication Date Title
DE60112982T2 (de) Einrichtung zur Bereitstellung von Server-Inhalten
DE60033011T2 (de) Aufteilung einer datei zur emulation eines datenstroms
DE60015423T2 (de) Verfahren und Vorrichtung zur Objektwiedergabe in einem Netzwerk
DE60119045T2 (de) Informationsverteilungssystem und Informationsverteilungsverfahren
US7613810B2 (en) Segmenting electronic documents for use on a device of limited capability
DE60030618T4 (de) Ereignissteuergerät und digitales Rundfunksystem
DE69934871T2 (de) Verfahren und System zur optimalen Auswahl eines Webfirewalls in einem TCP/IP Netzwerk
US9015276B2 (en) Determining playability of media files with minimal downloading
DE10296790T5 (de) Multimediapräsentation
US20100281042A1 (en) Method and System for Transforming and Delivering Video File Content for Mobile Devices
DE10239061A1 (de) Verfahren zum Übertragen von Nutzdatenobjekten
JP2001515246A (ja) 自動化コンテンツのスケジューリング装置と表示装置
US7058816B2 (en) Apparatus and method for content entry management
DE19704694A1 (de) Verfahren und Vorrichtung zum Steuern eines Peripheriegerätes
KR19990044849A (ko) 하드웨어 장치와의 원격 대화를 위한 방법및 장치
DE202008013034U1 (de) System zum Beschleunigen von Browsing-Sitzungen
CA2423611C (en) Configurable transformation of electronic documents
US8054496B1 (en) Previewing a compound document
DE10295700T5 (de) Eine Anordnung und ein Verfahren in Bezug auf Endnutzerstationszugriff auf ein Portal
DE69925435T2 (de) Rechnerimplementiertes Verfahren und Apparat zur Bereitstellung eines logischen Zugriffspunktes zu einer oder mehreren Dateien
DE10041310B4 (de) Verfahren zum Plattformunabhängigen Streaming von Multimedia-Inhalten für IP-basierte Netze
DE10045409A1 (de) Modellierung von Verknüpfung und Navigation in einem Hostsystem mit alten Beständen
DE69834647T2 (de) System, verfahren und program zur dynamischen transkodierung von zwischen rechnern uebertragenen daten
DE60018534T2 (de) Datenübertragungs-und-anzeigeverfahren
JP2001333131A (ja) コンテンツ取得装置

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8339 Ceased/non-payment of the annual fee