DE60302368T2 - System und Verfahren um den Transfer von Daten zwischen beliebigen Komponenten untereinander zu ermöglichen - Google Patents

System und Verfahren um den Transfer von Daten zwischen beliebigen Komponenten untereinander zu ermöglichen Download PDF

Info

Publication number
DE60302368T2
DE60302368T2 DE60302368T DE60302368T DE60302368T2 DE 60302368 T2 DE60302368 T2 DE 60302368T2 DE 60302368 T DE60302368 T DE 60302368T DE 60302368 T DE60302368 T DE 60302368T DE 60302368 T2 DE60302368 T2 DE 60302368T2
Authority
DE
Germany
Prior art keywords
data
component
computer
transfer
pda
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60302368T
Other languages
English (en)
Other versions
DE60302368D1 (de
Inventor
Keith W. Edwards
Mark W. Newman
Jana Z. Sedivy
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.)
Xerox Corp
Original Assignee
Xerox Corp
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 Xerox Corp filed Critical Xerox Corp
Application granted granted Critical
Publication of DE60302368D1 publication Critical patent/DE60302368D1/de
Publication of DE60302368T2 publication Critical patent/DE60302368T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols

Description

  • Die Erfindung betrifft grundsätzlich Kommunikationssysteme und Verfahren und im Spezielleren eine Vorrichtung und ein Verfahren für das Befähigen von beliebigen Komponenten, Daten unter Benutzung von einer oder mehrerer universeller Datenschnittstellen, die mobilen Code verwenden, zwischen einander zu transferieren.
  • In Datenkommunikationsumgebungen, wie zum Beispiel einem verteilten Netzwerk, stellen viele verschiedene Anbieter eine Anzahl von Produkten für spezifische Dienstleistungen zur Verfügung. Vordem war ein vorbestimmter Satz von Domänenspezifischen Protokollen notwendig, die spezifiziert wurden, um beliebige Komponenten in der Umgebung zu befähigen, miteinander zu kommunizieren, annehmend dass die Komponenten Daten übertragen oder empfangen (hiernach genannt „Übertragen von Daten"). Zum Beispiel hätte eine Einheit, die von einem Anbieter hergestellt worden ist, Schwierigkeiten gehabt, mit einer Einheit zu kommunizieren, die von einem anderen Anbieter hergestellt wurde, wenn nicht der oben erwähnte vorbestimmte Satz von Protokollen gebraucht wurde. Das Problem, dass verschiedene Anbieter verschiedene vorbestimmte Protokolle erfordern, wurde teilweise angegangen durch das Einführen von bestehenden Protokoll-Standards. Unabhängig davon bestehen verschiedene Standardisierungs-Organisationen und daher verschiedene Protokoll-Standards.
  • Wenn beliebige Komponenten wie Computer-Applikationen oder Programme, Daten, Speicher, Dateiverzeichnisse, individuelle Dateien, Druckereinheiten, mobile Telefone, Faxgeräte, Kopiermaschinen, Scanner-Einheiten, Desk-top-Computer, Lap-top-Computer, persönliche digitale Assistenten (personal digital assistant („PDA") oder jede andere Einheit, zum Beispiel versuchen, ohne ein a priori Wissen voneinander zu kommunizieren, müssen a priori bestimmte Domänen-spezifische Protokolle wie die Dateisystemdomäne (zum Beispiel NFS und CIFS) oder die Druckerdomäne (zum Beispiel IPP oder LPR) für beide Parteien bekannt sein, um erfolgreich zu kommunizieren. Eine beliebige Komponente wie ein PDA, der versucht, mit einem Dateisystem zu kommunizieren, oder eine Druckereinheit, die dasselbe versucht, müssen explizit programmiert sein, um ein oder mehrere der oben erwähnten standardisierten Protokolle zu verste hen. Ein Beispiel schließt eine Computer-Einheit oder eine Applikation ein, die durch die Installation eines Domänen-spezifischen Druckertreibers dafür programmiert sein muss, eine Druckereinheit zu verstehen. Wenn die Einheit oder Applikation dafür programmiert ist zu verstehen, wie zum Beispiel mit einer Druckereinheit kommuniziert und eine Druckereinheit benutzt wird, wird der Treiber generisch die Einheit oder Applikation nur befähigen, einen bestimmten Typ von Druckereinheit und nicht das ganze Universum von allen Druckereinheiten anzusteuern. Daher muss, wenn eine neue und unbekannte Komponente in die Gleichung eintritt, die Applikation neu programmiert werden, um die neuen standardisierten Protokolle, die benutzt werden, um mit den neuen Komponenten zu kommunizieren, zu verstehen. Bezugnehmend auf das obige Computer- und Drucker-Einheiten-Beispiel muss die Computer-Einheit, wenn ein neuer Typ von Drucker eingeführt wurde, durch die Installation eines Druckertreibers, der spezifisch ist für die neue Drucker-Einheit, neu programmiert werden, um in der Lage zu sein, Daten zu der neuen Druckereinheit zu übermitteln. Daher muss jede Applikation explizit dafür geschrieben werden, einen bestimmten Satz von standardisierten Protokollen zu benutzen, a priori zur Kommunikation mit den Komponenten, die mit den Protokollen assoziiert sind.
  • In einem System wie JiniTM, entwickelt durch Sun Microsystems aus Palo Alto, Californien und beschrieben in „A collection of JiniTM Technology Helper Utilities and Services Specifications," Palo Alto, Californien, Sun Microsystems, Inc., Seiten 1–214, 2000; und "JiniTM Technology Core Platform Specification," Palo Alto, Californien, Sun Microsystems, Inc., Seiten 1–126, 2000, welche alle hiermit durch Referenz in ihrer Gesamtheit mit eingeschlossen werden, welche Domänen-spezifische Schnittstellen nutzen, damit eine Komponente wie ein PDA-System mit einer anderen Komponente wie einem Drucker kommuniziert, muss das PDA-System ein a priori Wissen über die Semantik der programmatischen Schnittstellen des Druckers beinhalten. In anderen Worten mag eine Komponente, die weiß, wie zum Beispiel zu drucken ist, immer noch nicht wissen, wie Daten zwischen einem Dateisystem, einer Scanner-Einheit oder einem Netzwerk-Übersetzungsdienst zu transferieren sind bis sie explizit dafür programmiert ist, um zu wissen, wie mit den Schnittstellen für die bestimmten Komponenten zu kommunizieren ist.
  • DE 41 06 793 A1 offenbart eine Kommunikationsschnittstelle für eine offene Kommunikation von Nutzern mit Komponenten eines verteilten Kommunikationssystems, das eine geschichtete Struktur hat. Die Kommunikationsschnittstelle ist basierend auf einer Makrobibliothek und enthält verschiedene Gruppen von Prozeduren wie Initialisieren oder Beenden einer Kommunikation, Öffnen oder Schließen eines logischen Kommunikationskanals, Aufbauen oder Schließen einer Verbindung und Bedienen von eintreffenden Informationen.
  • US 5.915.252 offenbart einen objekt-orientierten Rahmen-Mechanismus für Datentransfer zwischen Datenquellen und Datenzielen, der eine Infrastruktur bereitstellt, die Schritte enthält, die notwendig sind, den Datentransfer auszuführen und einen Mechanismus zur Erweiterung des Rahmens zum Anpassen an eine bestimmte Daten-Transfer-Um gebung. Bestimmte Kernfunktionen werden durch den Rahmen bereitgestellt, welche mit erweiterbaren Funktionen interagieren, die durch den Nutzer des Rahmens bereitgestellt werden.
  • EP 0 685 952 A1 offenbart eine Multipfad-Kanal-Schnittstelle für Computer-Eingabe-Ausgabe-Systeme, welche die Fähigkeit einschließt, unsymmetrische Gruppen von unidirektionalen Kommunikations-Unterkanälen für eine Nutzer-Applikation zu definieren und aktivieren. Protokollunabhängige Austausch-Identifikationen erlauben nicht nur unsymmetrische Übertragungsgruppen sondern erlauben auch Nutzer-kontrollierte Erweiterungen zur Verhandlung der Werte der Übertragungsparameter zu der Zeit, zu der die Übertragungsgruppe aktiviert ist.
  • Es ist das Ziel der vorliegenden Erfindung, eine verbesserte Vorrichtung und ein verbessertes Verfahren bereitzustellen für die Befähigung von Komponenten, Daten zwischen einander zu transferieren.
  • Dieses Ziel wird erreicht durch eine Vorrichtung gemäß Anspruch 1 und ein Verfahren gemäß Anspruch 7. Vorteilhafte Ausführungsformen sind Gegenstand der abhängigen Ansprüche.
  • Die vorliegende Erfindung erlaubt Komponenten, die dasselbe oder verschiedene Kommunikationsprotokolle und/oder Datentypen nutzen, Daten zwischen einander zu transferieren, ohne dass sie a priori Wissen über irgendeine Domänen-spezifische Schnittstelle, Protokoll oder Datenformat haben. Zusätzlich befähigt die Erfindung Komponenten, Datentransfer-Sessions zwischen verschiedenen Komponenten zu initiieren.
  • 1 ist ein Diagramm eines Systems zur Befähigung beliebiger Komponenten, Daten zwischen einander zu transferieren;
  • 2 ist ein Blockdiagramm einer beispielhaften beliebigen Komponente, die in der Vorrichtung für die Befähigung von beliebigen Komponenten für den Datentransfer zwischen einander benutzt wird;
  • 3 ist ein Diagramm einer Vorrichtung für die Befähigung einer beliebigen Komponente, Daten von einer anderen beliebigen Komponente zu empfangen;
  • 4 ist ein Flussdiagramm eines Prozesses für das Empfangen von Daten von einer anderen beliebigen Komponente;
  • 5 ist ein Diagramm einer Vorrichtung für das Befähigen einer beliebigen Komponente, Daten zu einer anderen beliebigen Komponente zu übertragen;
  • 6 ist ein Flussdiagramm eines Prozesses für die Übertragung von Daten zu anderen beliebigen Komponenten;
  • 7 ist ein Blockdiagramm einer Vorrichtung, wo eine beliebige Komponente zwei andere beliebige Komponenten dazu befähigt, Daten zwischen einander zu transferieren; und
  • 8 ist ein Flussdiagramm eines Prozesses, wo eine beliebige Komponente andere beliebige Komponenten befähigt, Daten zwischen einander zu transferieren.
  • Eine Vorrichtung 10 für das Befähigen von beliebigen Komponenten, Daten zwischen einander zu transferieren, ist in 1 gezeigt. In dieser bestimmten Ausführungsform schließt die Vorrichtung 10 einen Computer 20, Drucker 21, persönlichen digitalen Assistenten (personal digital assistant „PDA") 22, Server 23, und Faxgerät 24 („Komponenten 2024"). Ein Verfahren gemäß einer Ausführungsform schließt einen Computer 20 ein, der eine der universellen Datentransfer-Schnittstellen (d.h. die Datenquellen-Schnittstelle oder die Datensenken-Schnittstelle), die mit einer oder mehrerer der Komponenten 2124 assoziiert ist, erhält und der die eine oder mehrere erhaltenen universellen Datentransfer-Schnittstellen aufruft, um Daten zwischen den Komponenten 2024 zu transferieren. Die vorliegende Erfindung erlaubt den Komponenten 2024, dass gleiche oder verschiedene Kommunikationsprotokolle und/oder Datentypen zu benutzen, um Daten zwischen sich zu transferieren, ohne a priori Wissen über irgendeine Domänen-spezifische Schnittstelle, Protokolle oder Datenformate zu haben. Die vorliegende Erfindung befähigt die Komponenten 2024 auch, Datentransfer-Sessions zwischen anderen Komponenten 20 und 24 zu initialisieren.
  • Mit Bezug im Spezifischen auf 1 ist der Computer 20 wirksam verbunden zu jeder der Komponenten 2124 dieses illustrierten Beispiels, obwohl andere Verbindungszusammenstellungen oder Konfigurationen, genauso wie eine größere oder kleinere Anzahl von Komponenten genutzt werden können. Zum Beispiel könnte die Vorrichtung 10 eine oder mehrere der Komponenten 2124 enthalten, die direkt mit einer oder mehrerer anderer Komponenten 2124 (zum Beispiel ein Peer-zu-Peer-System) verbunden sind oder Vorrichtung 10 könnte Komponenten 20 und 21 enthalten, welche miteinander verbunden sind.
  • Ein konventionelles Einwahl-Kommunikations-System über Nebenstellenanlagen (private branch exchanges „PBX") und benutzend öffentlich geschaltete Telefonleitungen und Leitungen, die auf Telefonkommunikationsprotokollen basieren, könnte durch die Komponenten 2024 genutzt werden, um miteinander zu kommunizieren. Obwohl ein Typ von Kommunikationssystem und Protokoll gezeigt ist, könnte eine Vielzahl von verschiedenen Typen von Kommunikationssystemen und/oder Protokollen genutzt werden. Zum Beispiel können Kommunikationssysteme oder Netzwerk-Architekturen genutzt werden wie lokale Netzwerke (local area networks „LAN"), Fernnetze (wide area networks „WAN") und mobile oder Satelliten-Kommunikations-Netzwerksysteme, die Signa- le nutzen wie Satelliten-Signale, Radiowellen, Mikrowellen und/oder Infrarot-Signale. Zusätzlich können auch eine Vielzahl von Kommunikations-Protokollen für das Transferieren von Daten genutzt werden wie xDSL, ISDN, TCP/IP oder Protokolle definiert durch die RFC und OSI-Organisationen. Der Typ von Protokoll, der genutzt wird, wird abhängen von dem Typ des Kommunikationssystems, das von einer bestimmten Komponente benutzt wird, dem Typ der Komponente (zum Beispiel eine Druckereinheit oder eine Scanner-Einheit) und/oder dem Typ der Netzwerkumgebung, in der die Komponente arbeitet (zum Beispiel die UNIX-Arbeitsumgebung). Komponenten 2024 können ein oder mehrere Kommunikationsprotokolle nutzen. Darüber hinaus zeigen die Pfeile in 1 den Kommunikationsfluss zwischen Komponenten 2024.
  • Bezugnehmend auf 2 enthält Computer 20 eine zentrale Verarbeitungseinheit (central processing unit „CPU") 30, Speicher 32 und I/O-Einheit 34, welche durch einen Bus 36 miteinander verbunden sind, obwohl Computer 20 jeden Typ von Einheit oder System beinhalten kann, der Anweisungen für das Ausführen von einem oder mehreren Verfahren der vorliegenden Erfindung speichert, verarbeitet und ausführen kann. Nur zum Beispiel kann Computer 20 auch enthalten einen Scanner, Mobiltelefon, Anzeigeeinheit, Video-Eingabe/Ausgabe-Einheit, Audio-Einheit/Ausgabe-Einheit, Fernbedienungseinheit oder ein Werkzeug. Computer 20 könnte auch enthalten jede Art von Einheit mit Schaltkreisen, die fest verdrahtet sind, um Anweisungen für das Ausführen von einer oder mehrerer Methoden der vorliegenden Erfindung auszuführen. Computer 20 führt Anweisungen für eine Betriebssystem-Umgebung, in der er arbeitet, aus, wie zum Beispiel die UNIX®-Umgebung, beschrieben in "Advanced Programming in the UNIX® Environments", W. Richard Stevens, Addison-Wesley Publishing Company, 1974, welche hiermit durch Referenz in ihrer Ganzheit miteingeschlossen ist. In dieser Ausführungsform benutzt Computer 20 nicht dasselbe Kommunikationsprotokoll, wie irgendeine der anderen Komponenten 2124, aber in anderen Ausführungsformen benutzt der Computer 20 dasselbe Kommunikationsprotokoll wie irgendeine andere der Komponenten 2124. Nur als Beispiel kann Computer 20 in der UNIX®-Umgebung unter Nutzung eines ersten Typs von Kommunikationsprotokoll für das Transferieren von Daten arbeiten, während Drucker 21 aber unter Benutzung eines zweiten Typs von Kommunikationsprotokoll in der Microsoft-Windows-Umgebung arbeiten mag.
  • CPU 30 kann einen Prozessor, wie zum Beispiel einen Intel Pentium III Prozessor einschließen. Die CPU 30 führt wenigstens ein Programm von gespeicherten Anweisungen aus, für ein Verfahren für das Befähigen von beliebigen Komponenten, zwischen einander Daten zu transferieren, gemäß der vorliegenden Erfindung, wie hierin beschrieben und illustriert. CPU 30 kann auch Anweisungen für andere Aufgaben, einschließlich Netzwerk-Dienstleistungen ausführen, wie zum Beispiel das Bereitstellen von Daten, Speicher, Datei-Verzeichnissen, individuelle Dateien, Textverarbeitungs-Applikationen, Buchhaltungs-Applikationen oder technische Applikationen. Als ein Ergebnis werden, wenn eine dieser Applikationen ausgeführt wird, die Anweisungen für diese Aufgabe, wie zum Beispiel für das Kreieren eines Kalkulationsblatts, genauso wie Anweisungen für das Ausführen eines oder mehrerer Verfahren der vorliegenden Erfindung durch die CPU 30 im Computer 20 ausgeführt. Die Anweisungen können als ausführbares Programm ausgedrückt sein, das in einer Anzahl von Computer-Programmiersprachen geschrieben sein kann, wie zum Beispiel BASIC, Pascal, C, C++, C#, Java, Perl, COBOL, FORTRAN, Assembler-Sprache, Maschinen-Code-Sprache oder jede andere Computer-Code oder Sprache, die durch die CPU 30 verstanden und ausgeführt werden kann.
  • Speicher 32 kann jeden Typ von fester oder portabler Speichereinheit enthalten, welche durch die CPU 30 ansteuerbar ist, wie zum Beispiel Festplatten, Disketten, Compakt-Disks („CD"), digitale Video Disks, Magnetband, optische Disks, fenoelektronischen Speicher, Lesespeicher (read only memory), Direktzugriffsspeicher (random access memory), elektrisch-löschbarer programmierbarer Lesespeicher (electrically erasable programmable read only memory), Flash-Speicher (flash memory), löschbarer programmierbarer Lesespeicher (erasable programmable read only memory, statischer Direktzugriftsspeicher (static random access memory), dynamischer Direktzugriffsspeicher (dynamic random access memory), ferromagnetischer Speicher, Ladungsspeicher-Bausteine (charge coupled devices), smart cards oder jeder andere Typ von Computerlesbarem Medium. Speicher 32 speichert gemäß einer Ausführungsform der vorliegenden Erfindung Anweisungen 38 für ein Verfahren zur Befähigung von beliebigen Komponenten, Daten zwischen einander auszutauschen, für das Ausführen durch CPU 30, obwohl einige oder alle dieser Anweisungen woanders gespeichert werden können. Ein oder mehrere Sätze von universellen Schnittstellen oder Datenobjekten können in dem Speicher 32 gespeichert sein, so dass sie abgerufen werden können, sobald sie von der CPU 30 während der Ausführung der vorliegenden Erfindung gebraucht werden, wie später detaillierter beschrieben wird. Obwohl in diesem erläuterndem Beispiel die CPU 30 und Speicher 32 an derselben physischen Stelle gezeigt sind, können sie auch an unterschiedlichen physischen Orten angeordnet sein, wie zum Beispiel in Server 23 gezeigt in 1.
  • Computer 20 kann mit Komponenten 2124 unter Gebrauch der I/0-Einheit 34 kommunizieren. In diesem erläuternden Beispiel enthält I/O-Einheit 34 einen Vermittlungsknoten (router), wie zum Beispiel jeden Typ von Ethernet basierten Einheiten, die ausreichende Anschlüsse haben, um Computer 20 wirksam mit den Komponenten 2124 zu verbinden.
  • Wiederum mit Bezug auf 1 umfasst Drucker 21 eine konventionelle Druckereinheit, die zum Beispiel fähig ist, grafische Repräsentationen auf einem Druckmedium darzustellen. Da Einheiten wie Drucker 21 im Stand der Technik wohl bekannt sind, werden hier die spezifischen Elemente ihrer Anordnung innerhalb von Drucker 21 und ihr Arbeiten nicht im Detail erläutert.
  • PDA 22 umfasst eine konventionelle Handgeräte-Einheit (hand held device), die Funktionen ausführen kann wie zum Beispiel Telefonieren, Faxübertragung oder Netzwerkern. Da Einheiten wie PDA 22 im Stand der Technik wohl bekannt sind, werden hier die spezifischen Elemente ihre Anordnung innerhalb von PDA 22 und ihr Arbeiten nicht im Detail beschrieben.
  • Server 23 umfasst ein konventionelles Computer-System, das eine oder mehrere CPU's, Speicher, I/O-Einheiten und eines oder mehrere Speichermedien enthält, welche über einen Bus miteinander verbunden sind und von Computer 23 benutzt werden, um Anweisungen gemäß einer oder mehrerer Alternativen, die hier weiter beschrieben sind, zu speichern und zu verarbeiten. Da Einheiten wie Server 23 im Stand der Technik wohl bekannt sind, werden hier die spezifischen Elemente, ihre Anordnung innerhalb Server 23 und ihr Arbeiten nicht im Detail beschrieben.
  • Faxgerät 24 umfasst eine konventionelle Faxeinheit, die Bilder oder Text über eine Telefonleitung oder ein Netzwerk senden und empfangen kann. Da Einheiten wie Faxgerät 24 im Stand der Technik wohl bekannt sind, werden hier die spezifischen Elemente, deren Anordnung innerhalb Faxgerät 24 und ihr Arbeiten nicht im Detail beschrieben.
  • Bezugnehmend auf 3, ist Computer 20, wie oben in Verbindung mit 1 beschrieben, verbunden mit PDA 22. PDA 22 hat einen Satz von universellen Schnittstellen 22a, einschließlich einer Datenquellen-Schnittstelle, einer Kontext-Schnittstelle, einer Benachrichtigungs-Schnittstelle und einer Nutzer-Schnittstelle, im Speicher gespeichert oder anderweitig, zum Beispiel über Ansteuern von Server 23, im Zugriff, welches im Folgenden bezeichnet wird als „damit assoziiert sein". Die spezielle Anzahl und/oder Kombinationen von Schnittstellen kann variieren und hängt davon ab, von welchem bestimmten Typ von Einheit PDA 22 ist und welche Fähigkeiten und/oder Dienstleistung von ihm gewünscht oder durch ihn bereitgestellt werden. Auch kann PDA 22 und damit der Satz von universellen Schnittstellen 22a zu jeder Zeit aktualisiert werden, um Schnittstellen hinzuzufügen, zu löschen oder zu modifizieren. Weiterhin ist Computer 20 dafür programmiert, Schnittstellen, die mit PDA 22 assoziiert sind, anzusteuern. In ähnlicher Weise könnte PDA 22 eine oder mehrere Schnittstellen (nicht dargestellt) ansteuern, die mit Computer 20 assoziiert sind.
  • Computer 20 kann den Satz von universellen Schnittstellen 22a durch Datenobjekte 22b ansteuern, um verschiedene Typen von Kommunikation, wie hier weiter beschrieben, zu erreichen. Jede der Schnittstellen in dem Satz von universellen Schnittstellen 22a umfasst Anweisungen, Sets von Anweisungen und/oder andere Daten, die durch Computer 20 verstanden und ausgeführt werden können, um ihn zu befähigen, mit PDA 22 zu kommunizieren und Daten zu transferieren (d.h. Daten übertragen oder empfangen), Kontext-Informationen mit PDA 22 auszutauschen, Computer 20 Ereignisbenachrichtigung für PDA 22 bereitzustellen oder Computer 20 zu befähigen, Nutzerschnittstellen zu empfangen, um Benutzern von Computer 20 zu erlauben, PDA 22 anzusteuern und/oder zu manipulieren. Grundsätzlich ist jede Schnittstelle in dem Satz von universellen Schnittstellen 22a mit Bezug auf PDA 22keine Domänen-spezifische Schnittstelle.
  • Im Speziellen schließt die Datenquellen-Schnittstelle verschiedene Befehle wie einen getSourceDataFlavor() Befehl und einen beginTransferSession() Befehl. Weiterhin enthält die Datenquellen-Schnittstelle Anweisungen und Daten, die durch Computer 20 ausgeführt werden können, um eine Daten-Transfer-Session zu etablieren, um Computer 20 zu befähigen, Daten von PDA 20 zu empfangen. Der getSourceDataFlavor() Befehl schließt Anweisungen und Daten ein, die durch Computer 20 ausgeführt werden können, um die Typen von Daten festzustellen, die PDA 20 übertragen kann. In diesem erläuternden Beispiel führt Computer 20 den getSourceDataFlavor() Befehl aus, der eine Liste von einem oder mehreren Datentypen, die durch PDA 22 unterstützt werden, zurückgibt. Darüber hinaus sind die Datentypen in dieser Ausführungsform typischerweise MIME-Datentypen. Zum Beispiel kann Computer 20 nach der Ausführung der oben erwähnten Befehle feststellen, dass PDA 20 Daten in einem „JPEG"-Format unterstützt. Der beginTransferSession() Befehl schließt Anweisungen und Daten ein, die durch Computer 20 ausgeführt werden können, um PDA 22 aufzufordern, eine Datentransfer-Session zu etablieren, um Daten zu empfangen, durch Zurückgeben eines Datentransfer-Session-Objekts 22c zum Computer 20 durch Datenobjekt 22b. Darüber hinaus können dem beginTransferSession() Befehl Parameter beim Aufruf weitergegeben werden, wie zum Beispiel ein Kontext-Parameter, ein initialer Freigabe-Dauer-Parameter und ein Daten-Art-Parameter. In dieser Ausführungsform ergibt Computer 20 beim Aufrufen zu dem beginTransferSession() Befehl einen Kontextparameter weiter, um PDA 22 aus einer Reihe von Gründen über seine Identität zu informieren, wie zum Beispiel für das Identifizieren von Computer 20 zu PDA 22, das Identifizieren eines Nutzers an Computer 22 zu PDA 22, das Identifizieren des Ortes von Computer 20 auf einem Netzwerk zu PDA 22 oder aus Sicherheitsgründen. PDA 22 kann aufgrund der Identitäts-Information, die durch den Kontextparameter bereitgestellt wird, entscheiden, ob Daten zu Computer 20 transferiert werden. Weiterhin werden Datentransfer-Sessions freigegeben und daher müssen sie periodisch durch Computer 20 erneuert werden, zu Zeitintervallen, die mit einem Wert korrespondieren, der in dem initialen Freigabe-Dauer-Parameter spezifiziert ist, der zu dem beginTransferSession() Befehl weitergegeben wurde, um die Datentransfer-Session aktiv zu halten, obwohl in anderen Alternativen die Session nicht freigegeben werden muss. Wenn Sessions freigegeben werden, wird PDA 22 in dem Fall das Transferieren von Daten zu Computer 20 stoppen, dass Computer 20 darin scheitert, die Freigabe zu erneuern unter der Annahme, dass Computer 20 daran gescheitert ist, die Freigabe zu erneuern, weil er entweder zusammengebrochen ist oder auf andere Art unerreichbar geworden ist. Zusätzlich, in dem Fall, dass PDA 22, wie ermittelt durch Ausführen des getSourceDataFlavor() Befehls, einen oder mehrere Ty pen von Daten unterstützt, kann in den beginTransferSession() Befehl ein Datenart-Parameter weitergegeben werden. Computer 20 kann einen bevorzugten Datentypwert zu dem Datenart-Parameter aus einer Reihe von Gründen bereitstellen, wie zum Beispiel in dem Fall, dass Computer 20 und PDA 22 vielfältige, kompatible Datentypen unterstützen, wobei Computer 20 unter Benutzung des Parameters einen bevorzugten Datentyp für den Datentransfer spezifiziert. In diesem Beispiel kann Computer 20 einen bevorzugten Datentyp unter Benutzung einer Reihe von Methoden feststellen, wie zum Beispiel durch das Befähigen des Nutzers an Computer 20, einen bevorzugten Datentypen anzuzeigen, zufällig Auswählen eines kompatiblen Datentypes zwischen Computer 20 und PDA 22 oder Wählen des Datentypen, der am effektivsten für die spezifischen zu transferierenden Daten ist.
  • Die Kontext-Schnittstelle enthält einen getContext() Befehl, der Anweisungen und Daten enthält, die durch Computer 20 ausgeführt werden können, um Kontext-Informationen von PDA 22 abzurufen. In dieser Ausführungsform sind die Kontext-Informationen in einem Speicher bei PDA 22 als eine mehrwertige Datenstruktur, die einer Hash-Tabelle ähnelt gespeichert, obwohl die Kontext-Informationen auch in einem anderen Format gespeichert sein kann. Ebenfalls in diesem Beispiel schließt die Kontext-Information Informationen über PDA 22 ein, wie zum Beispiel von welchem Typ von Einheit er ist, sein Betriebsstatus, Identität, Ort, administrative Domäne oder jeder andere Typ von Umweltdaten. In einer anderen Ausführungsform kann die Kontext-Information an einem anderen physischen Ort, wie zum Beispiel Server 23, gespeichert sein.
  • Die Benachrichtigungs-Schnittstelle schließt einen Register() Befehl ein, welchem einer oder mehrere Parameter weitergegeben werden können und welcher durch Computer 20 ausgeführt werden kann, um ihn zu befähigen, asynchrone Benachrichtigungen über Ereignisse, die durch PDA 22 generiert werden, zu empfangen, obwohl er auch genauso synchrone Benachrichtigungen erhalten kann. Computer 20 führt den Register() Befehl aus und gibt ihm dabei einen Kontextparameter, einen Komponenten-Parameter und einen initialen Freigabe-Dauer-Parameter weiter. Der Kontext-Parameter stellt PDA 22 die Identität von Computer 20 für eine Reihe von Gründen zur Verfügung, wie zum Beispiel als Befähigung für PDA 22, um zu entscheiden, ob er das Senden von Benachrichtigung zu Computer 20 aus Sichefieitsgründen oder zur Bestandsführung wünscht. Der Komponenten-Parameter zeigt an, dass Computer 20 wünscht, von Ereignissen, die bei PDA 22 auftreten, benachrichtigt zu werden. Weiterhin werden Ereignis-Registrierungen von Computer 20 freigegeben und müssen, um die Ereignis-Registrierung aktiv zu halten, von Computer 20 periodisch erneuert werden, zu Zeitintervallen, die zu dem Wert korrespondieren, der in dem Initialen-Freigabe-Dauer-Parameter spezifiziert ist. Falls Computer 20 darin scheitert, die Freigabe zu erneuern, schließt die Benachrichtigungs-Schnittstelle Anweisungen ein, PDA 22 von der Pflicht zu befreien, Computer 20 Benachrichtigungen über generierte Ereignisse bereitzustellen, da er annehmen wird, dass Computer 20 daran gescheitert ist, die Freigabe zu erneuern, weil er zusammengebrochen ist oder aus anderen Gründen unerreichbar geworden ist. Wenn Computer 20 sich selbst mit PDA 22 durch Ausführen des Register() Befehls registriert hat, wird PDA 22, falls eine Bedingung bei PDA 22 auftritt, welche ihn veranlasst, Computer 20 gemäß den Anweisungen in der Benachrichtigungs-Schnittstelle und den assoziierten Befehlen zu benachrichtigen, ein Ereignis-Benachrichtigungsobjekt zu Computer 20 schicken. Computer 20 kann dann ein Nutzerfenster erzeugen, wie weiter unten weiterhin beschrieben, um die Ereignis-Informationen für den Nutzer anzuzeigen. Zum Beispiel, falls PDA statt dessen eine Druckereinheit und Computer 20 statt dessen Textverarbeitungs-Applikation ist, wäre PDA 22 in der Lage, Computer 20 in dem Fall eine Ereignis-Benachrichtigung bereitzustellen, dass Papier in der Druckereinheit klemmt. Darüber hinaus könnte Computer 20 in diesem Beispiel die Ereignis-Benachrichtigung (d.h. Papierstau) für den Nutzer durch Gebrauch einer graphischen Nutzer-Schnittstelle (graphical user interface „GUI") anzeigen.
  • Die Nutzer-Schnittstelle umfasst einen getUI(), getState() und setState() Befehl, der Anweisungen und Daten einschließt, die durch Computer 20 ausgeführt werden können, um ein Nutzer-Fenster abzufragen oder zu generieren, das spezifisch ist für PDA 22, um es den Nutzern von Computer 22 zur Verfügung zu stellen, so dass sie PDA 22 ansteuern und/oder manipulieren können, um die zusätzliche Funktionalität von PDA 20 ausnutzen zu können. In dieser Ausführungsform kann dem getUI() Befehl beim Aufruf durch Computer 20 ein Parameter weitergegeben werden, um anzuzeigen, welchen Typ von Nutzer-Fenster der Nutzer generiert haben will, wie weiter unten weiterhin beschrieben. Der getUI() Befehl gibt vom PDA 22 zum Computer 20 ein Nutzer-Fenster und/oder Anweisungen für das Generieren oder Abfragen eines Nutzer-Fensters zurück, welche durch Computer 20 instanziiert werden können, um zum Beispiel ein Nutzer- Fenster für die Nutzer anzuzeigen. Der getState() Befehl schließt Anweisungen und Daten für die Anforderung ein, dass ein Status-Merkmalobjekt von PDA 22 zum Computer zurückgegeben wird. Das Status-Merkmalobjekt kann mit Bezug darauf ein opaques Objekt sein, welches spezifisch für PDA 22 ist und weiterhin den gegenwärtigen Status (zum Beispiel Einstellungen der Einheit oder Konfiguration) von PDA 22 einkapselt, obwohl das Status-Merkmalobjekt mit Bezug auf Computer 20 auch transparent sein kann, in dem Fall, dass Computer 20 in der Lage ist, das Status-Merkmalobjekt von PDA 22 zu verstehen. Weiterhin kann PDA 22 verschiedene Typen von Status-Merkmalobjekten abhängig davon, von welchem Typ Einheit er ist (zum Beispiel eine Druckereinheit oder eine Textverarbeitungs-Applikation), benutzen. Weiterhin kann PDA 22 seine jeweiligen Status-Merkmalobjekte in vielfältiger Weise kodieren, wie zum Beispiel als Zeiger oder URLs, die zu spezifischen Konfigurationen zeigen. Alternativ können die Status-Merkmalobjekte eine Repräsentation des gegenwärtigen Status von PDA 22 enthalten. Zusätzlich schließt der setState() Befehl Anweisungen und Daten ein, welche durch Computer 20 ausgeführt werden können, um das Nutzer-Fenster zu erzeugen unter Benutzung der Konfigurationsdaten, die in dem Status-Merkmalobjekt enthalten sind. Computer 20 kann das Status-Merkmalobjekt als einen Parameter zu dem setState() Befehl weitergeben, wenn dieser aufgerufen wird, welches durch PDA 22 dazu genutzt werden kann, Anweisungen und Daten zurückzugeben, welche durch Computer 20 ausgegeben werden können, um das Nutzer-Fenster abzufragen oder zu generieren, während die gespeicherte Konfiguration in dem Status Merkmalobjekt enthalten ist. Der setState() Befehl kann auch durch Computer 20 aufgerufen werden, um den Status von PDA 22 zurückzustellen, ohne dass das Nutzer-Fenster für den Nutzer wieder hergestellt werden muss.
  • Jede der oben beschriebenen Schnittstellen und der damit assoziierten Befehle wie auch alle anderen, die nachfolgend hierin beschrieben sein können, umfassen mobilen Code. Mobiler Code besteht aus ausführbaren Daten, die zu Computer 20 übertragen werden können, wo sie ausgeführt werden können. Zum Beispiel ist Java eine Implementierung von ausführbarem Inhalt (d.h. mobilem Code), die im Internet weit verbreitet ist. Nutzer können zum Beispiel mobilen Code vom Internet herunterladen und lokal ein Programm laufen lassen, das in einer wirklich gebräuchlichen Programmiersprache geschrieben ist. In dieser Ausführungsform ist der mobile Code objektorientierter mobiler Code, welches eine Programmier-Methode ist, die im Fachgebiet der Programmierung wohl bekannt ist, wobei Datentypen entlang von assoziierten Prozeduren oder Sätzen von Anweisungen definiert werden können, diese Datentypen werden in diesem Kontext oft als Klassen bezeichnet. Daher kann ein Satz von Prozeduren oder Anweisungen assoziiert sein mit einem oder mehreren Datentypen. Darüber hinaus kann derselbe Name oder Bezeichnet zugeordnet sein, um eine Prozedur oder einen Satz von Anweisungen zu identifizieren, die entsprechende Anweisungen ausführen, abhängig davon, welche spezifischen Datentypen damit assoziiert sind, dies wird oft Polymorphismus genannt. Daher, nur zur exemplarischen Verwendung, kann eine Mal-Prozedur ausgeführt werden, um Kreise oder Rechtecke zu malen, abhängig davon, welcher Typ von Daten für die Prozedur bereitgestellt oder weitergegeben wird, wenn dieser aufgerufen wird. Weiterhin kann in diesem Beispiel, wenn zum Beispiel ein Kreisdatentyp eine Radius-Koordinate definiert und eine Mal-Prozedur aufgerufen wird und der Kreisdatentyp zu der Mal-Prozedur weitergegeben wird, die Mal-Prozedur, da sie alle weiteren Datentypen, die zu der Mal-Prozedur assoziiert sind, die Daten, die für sie bereitgestellt wurden, nutzen, um die passende Prozedur oder den passenden Satz von Anweisungen auszuführen, um einen Kreis zu malen. In dieser Ausführungsform werden, wenn der Satz von universellen Schnittstellen 22a für den Computer 20 bereitgestellt wird, die Prozeduren, Sätze von Anweisungen und andere Daten, die mit der spezifischen Schnittstelle assoziiert sind, verfügbar für den Computer 20 für das Ansteuern und Ausführen wie im Weiteren beschrieben werden wird. Darüber hinaus können Variablen, Parameter und Daten weitergegeben oder den universellen Schnittstellen zur Verfügung gestellt werden, welche entsprechend von Computer 20 verstanden und benutzt werden, abhängig davon, welcher spezifische Typ von Kommunikation gewünscht ist. Weiterhin können die Schnittstellen Sätze von Anweisungen oder Referenzen zu anderen Schnittstellen enthalten, wobei Computer 20 entsprechend diese Daten nutzen oder diese Anweisungen ausführen kann.
  • Computer 20 kann direkt jede der Schnittstellen, die in dem Satz von universellen Schnittstellen 22a enthalten sind ansteuern, ohne den Bedarf, das Datenobjekt 22b zu erhalten, um die verschiedenen Typen von Kommunikationen, die hier nun beschrieben sind, zu erzielen. Darüber hinaus würde jede der Schnittstellen in dem Satz von universellen Schnittstellen 22a dieselben Anweisungen, Sätze von Befehlen und/oder andere Daten, die von Computer 20 verstanden und ausgeführt werden können, enthalten, um ihn zu befähigen, mit dem PDA 22 zu kommunizieren oder Daten zu transferieren, ge nauso wie für die anderen Funktionen, die oben beschrieben wurden. Daher mag mobiler Code in diesem Beispiel nicht notwendig sein, obwohl er als notwendig benutzt werden könnte, wie zum Beispiel wenn Daten transferiert werden.
  • In diesem erläuternden Beispiel wird das Datenobjekt 22b vom PDA 22 empfangen und im Computer 20 gespeichert, obwohl das Datenobjekt 22b woanders gespeichert werden könnte, wie zum Beispiel beim Server 23. Der Satz von universellen Schnittstellen 22a ist zugänglich für den Computer 20 durch das Datenobjekt 22b. Im Spezifischen unterstützt das Datenobjekt 22b die verschiedenen Befehle, die von den Schnittstellen, die mit dem PDA 22 assoziiert sind, definiert sind, von welchem angenommen wird, dass sie für Computer 20 bekannt sind und von Computer 20 verstanden werden. Die Datenobjekte 22b enthalten Anweisungen (d.h. Code, der von Computern ausführbar ist) und/oder Daten, die spezifische Implementierungen von der einen oder anderen Schnittstelle, die mit PDA 22 assoziiert sind, bereitstellen, mit welchen das Datenobjekt 22b assoziiert ist. Zum Beispiel stellt Datenobjekt 22b, welches von PDA 22 zum Computer 20 bereitgestellt wurde, eine spezifisch Implementierungen von der Datenquellen-Schnittstelle bereit, die dafür spezialisiert wäre, mit PDA 22, unter Benutzung von Protokollen und/oder Datenformaten, für welche auch immer der Entwickler (PDA 22) sich entschieden hat, zu kommunizieren.
  • In diesem erläuternden Beispiel schließt das Datentransfer-Session-Objekt 22c einen getTransferData() Befehl, einen getDataSource() Befehl, einen abort() Befehl, einen Fail() Befehl, einen completed() Befehl, den register() Befehl, der mit der oben beschriebenen Benachrichtigungs-Schnittstelle assoziiert ist, einen getLease() Befehl, einen getViewer() Befehl, einen getEditor Befehl, einen getPrinter() Befehl genauso wie jede andere Anweisung die notwendig ist, um den Computer 20 zu befähigen, Daten von PDA 22 zu empfangen, einschließlich zum Beispiel Protokollen für Video- oder Dateien-Transfer, welche abhängen können von dem Typen von Daten, der empfangen wird. Daten-Transfer-Session-Objekt 22c schließt die oben erwähnten Befehle und Anweisungen ein, welche spezifisch sind für PDA 22, aber durch den Computer 20 ausgeführt werden können, um Daten zu empfangen. In einer Alternative, wo zum Beispiel Computer 20 (d.h. eine Datensenken-Komponente) Daten von PDA 22 (d.h. eine Datenquellen-Komponente) empfängt, ruft Computer 20 den getDataTransfer() Befehl auf, um tatsächlich die Daten von PDA 22 abzufragen. Weiterhin kann Computer 20 den getDataSource() Befehl aufrufen, um die Identität und andere Merkmale von PDA 22 zu ermitteln. Computer 20 kann auch den getDataSource() Befehl aufrufen, um zu ermitteln, ob er sein Verhalten während des Datentransfers modifizieren sollte oder ob er überhaupt das Auftreten eines so bestimmten Datentransfers erlauben soll.
  • In diesem erläuternden Beispiel braucht Computer 20 mit Bezug darauf, wie Daten, die von PDA 20 durch das Datentransfer-Session-Objekt 22c geschickt wurden, empfangen und verstanden werden, keine Details zu kennen. Im Spezifischen schließen die Anweisungen und verschiedenen Befehle, welche im Datentransfer Session Objekt 22c enthalten sind, Information über die spezifischen Protokolle, Medien und Typen von Daten ein, die spezifisch sind für PDA 22, welche von Computer 22 ausgeführt werden können, um fähig zu sein, Daten, die von PDA 22 transferiert werden, zu empfangen und zu verstehen, obwohl PDA 20 verschiedene Protokolle, Medien oder Typen von Daten benutzen kann. Darüber hinaus schließt das Datentransfer-Session-Objekt 22c Anweisungen ein, für das Befähigen des Computers mit PDA 22 während der Transfer von Daten zu verhandeln, um für den Transfer von Daten zwischen einander basierend auf dem Typ von Daten, die transferiert werden, ein Kommunikationsprotokoll oder Medium für den Gebrauch, auszuwählen. Die Anweisungen können Computer 20 und PDA 22 auch befähigen, miteinander zu verhandeln, um verschiedene Protokolle für die Datentransfer-Session, basierend auf den Typen von Daten, die transferiert werden, zu nutzen. Außerdem können die Anweisungen Computer 20 befähigen, das Format oder den Inhalt der Daten, die durch das Datentransfer-Session-Objekt 22c transferiert werden, zu modifizieren, um die Daten von einem ersten Datentransfer-Protokoll, das mit Computer 20 assoziiert ist, zu einem zweiten Datentransfer-Protokoll, das mit PDA 22 assoziiert ist, zu konvertieren. Zum Beispiel, wenn PDA 22 streaming video zu Computer 20 transferiert, dann könnte es für PDA 22 effizienter sein, die Daten unter Benutzung von Komprimierung oder progressivem Kodieren zu transferieren. Computer 20 könnte die Anweisungen und Befehle, die im Datentransfer-Session-Objekt 22c enthalten sind, ausführen, so dass das Datentransfer-Session-Objekt 22c mit dem Computer 20 darüber verhandelt, zu entscheiden, welches spezifische Protokoll für die Datentransfer-Session genutzt wird und umgekehrt werden dem Computer 20 durch das Datentransfer-Session-Objekt 22c die Befehle, Anweisungen und Daten, die notwendig sind, um den Computer 20 zu befähigen, Daten, die durch das Datentransfer-Session-Objekt 22c transferiert werden, abzufragen und zu verstehen, bereitgestellt. Weiterhin können Computer 20 und PDA 22 über ein präferiertes physisches Transportmedium verhandeln, falls eines verfügbar ist. Zum Beispiel, falls gemeinsam benutzte eine FireWire, IR oder eine Bluetooth Verbindung zu finden ist, die Computer 20 und PDA 22 miteinander verbindet, können diese als das physische Transportmedium anstatt einer Ethernet-Verbindung benutzt werden, um die Daten zu transferieren. Die Anweisungen können also auch Befehle enthalten für das Reduzieren von Datenraten über langsame Datenübertragungsverbindungen oder kann Befehle beinhalten für das Erhöhen von Redundanz angesichts von Fehlern während der Datentransfer-Session.
  • Darüber hinaus kann das Datentransfer-Session-Objekt 22c Anweisungen enthalten, welche durch den Computer 20 ausgeführt werden können, um ihn zu befähigen, den Typ von Daten zu sehen, der durch das Datentransfer-Session-Objekt 22c transferiert wird. Zum Beispiel, wo Computer 20 nicht programmiert oder konfiguriert ist, um „JPEG" Bilddateien oder Streaming Video Datenübertragungen, die von PDA 22 übertragen werden, anzuzeigen, kann Computer 20 die Anweisungen, die in dem Datentransfer-Session-Objekt 22c enthalten sind, ausführen, um zum Beispiel auf einer Anzeigeeinheit, die mit Computer 20 assoziiert ist, die Daten, die übertragen werden, zu sehen. Im Speziellen kann das Datentransfer-Session-Objekt 22c einen getViewer() Befehl enthalten, der ein Betrachterobjekt zurückgibt, wenn der Befehl von Computer 20 aufgerufen wird. Das Betrachterobjekt ist spezifisch für einen speziellen Typ von Daten, der von PDA 22 verstanden und benutzt wird. Weiterhin kann das Betrachtobjekt dieselben Anweisungen, wie oben beschrieben, enthalten, um Computer 20 eine Benutzer-Schnittstelle bereitzustellen, mit der Ausnahme, dass die Anweisungen, wenn sie durch Computer 20 ausgeführt werden, Computer 20 befähigen, die Daten zu sehen, die transferiert werden. Das Betrachterobjekt kann auch Anweisungen enthalten, um Computer 20 zu befähigen, einen bestimmten Datentypen zu sehen, der assoziiert ist mit PDA 22 und transferiert wird, unabhängig davon, dass Computer 20 nicht vorprogrammiert wurde, solche Typen von Data zu sehen. Zusätzlich können dem getViewer() Befehl Parameter weitergegeben werden, wie oben beschrieben mit Bezug auf die Nutzer-Schnittstelle, um Computer 20 zu befähigen, den Typen des Nutzer-Fensters (d.h. graphisch oder Sprache) zu spezifizieren, den Computer 20 anzeigen möchte. In diesem Beispiel kann der getViewer() Befehl in PDA 22 gespeichert werden und von durch Datenobjekt 22b Computer 20 erreicht werden. Alternativ oder zusätzlich kann der getViewer() Befehl in einem zentralen Speicher gespeichert werden, wie zum Beispiel in Ser ver 23 (1). In diesem Beispiel kann Server 23 einen oder mehrere getVewer() Befehle speichern, wobei jeder Befehl Anweisungen beinhaltet, Computer 20 zu befähigen, einen speziellen Typen von Daten zu sehen. Es sollte anerkannt sein, dass die Ausdrücke (Sehen) oder (Anzeigen) in diesem Beispiel andere Formen der Ausgabe umfassen können, wie dort, wo die Anweisungen in Datentransfer-Session-Objekt 22c Computer 20 befähigen, einen Audio-File in einem spezifischen Format durch eine Audio-Ausgabe-Einheit, wie zum Beispiel einen Lautsprecher, abzuspielen. Weiterhin kann Datentransfer-Session-Objekt 22c zusätzliche Befehle beinhalten wie einen getEditor() Befehl und einen getPrinter() Befehl, welcher dieselben Anweisungen wie der getViewer() Befehl hat mit der Ausnahme, dass der getEditor() Befehl und der getPrinter() Befehl Anweisungen beinhalten, die Computer 20 befähigen, jeweils die Daten, die transferiert werden, zu editieren oder zu drucken, unabhängig davon, ob Computer 20 dafür programmiert wurde, den spezifischen Typen von Daten, der mit PDA 22 assoziiert ist, zu verstehen. Daher bräuchte Computer 20 in dieser Ausführungsform nicht alle die Typen von Datenformaten verstehen zu können, welchen er in einer Datentransfer-Session begegnen kann, weil die Anweisungen dafür, solche Daten zu verstehen, in dem Datentransfer-Session-Objekt 22c enthalten sein können. Es sollte angemerkt werden, dass Computer 20 wenigstens die Fähigkeit hat, die zahlreichen Anweisungen und Befehle, die in Datentransfer-Session-Objekt 22c enthalten sind, auszuführen.
  • In diesem erläuterndem Beispiel schließt der abort() Befehl Anweisungen ein, die den Computer 20 befähigen, den Datentransfer mit PDA 22 zu beenden. Weiterhin kann Computer 20 dem PDA 22 durch jeweils Ausführen des fail() Befehls oder des complete() Befehls anzeigen, dass eine Datentransfer-Session gescheitert ist oder beendet wurde. In dem Fall, dass eine Datentransfer-Session zwischen Computer 20 und PDA 22 gescheitert ist, komplettiert wurde, oder abgebrochen wurde, werden die Zuhörer an den Komponenten 2024, welche durch Registrierung ein Interesse am Status der Datentransfer-Session ausgerückt haben, durch den register() Befehl von dem Ereignis benachrichtigt. Ein signalisierendes Protokoll befähigt Computer 20 unter der Benutzung des Datentransfer-Session-Objekts 21c anzuzeigen, wenn Computer 20 fertig ist, in dem Fall, wo PDA 20 nicht automatisch ermitteln kann, wann Computer 20 fertig ist sowie wenn die Datentransfer-Session eine unbestimmte Dauer hat (zum Beispiel streaming video). Der getLease() Befehl befähigt Computer 20, die Freigabe gemäß dem Initialen Freigabe-Dauer-Parameter zu ernmeuern, um abzusichern, dass die Datentransfer-Session aktiv bleibt.
  • Mit Bezug auf 4 bei Schritt 40, führt Computer 20 einen Ermittlungsprozess durch, um festzustellen, ob Computer 20 und der PDA 22 Daten zwischen einander transferieren können. In dieser Ausführungsform entdeckt Computer 20 PDA 22 durch Benutzung einer Vielzahl von Entdeckungssystemen, wie zum Beispiel durch das BluetoothTM Dienstortungsprotokoll (Service Location Protocol „SLP"), das von der Bluetooth SIG, Inc. entwickelt wurde, beschrieben in „Specification of the Bluetooth System", Version 1.1 core, Bluetooth Consortium 2001, durch das universelle Beschreibungs-, Ermittlungs- und Integrationsprotokoll (Universal Description, Discovery, and Integration Protocol „UDDI"), das entwickelt wurde von den Firmen Ariba, IBM und Microsoft, beschrieben in „UDDI Technical Whitepaper", Universal Description, Discovery and Integration Consortium, Seiten 1–12, 2000; „Universal Description, Discovery and Integration Data Structure Reference V 1.0," Ariba Inc., International Business Machines Corporation and Microsoft Corporation, Seiten 1–131, 2000; „Universal Description, Discovery and Integration Programmer's API 1.0", Ariba, Inc. und International Business Machines Corporation und Microsoft Corporation, Seiten 1–67, 2000; und „Universal Description, Discovery and Integration Technical White Paper", Ariba, Inc. International Business Machines Corporation und Microsoft Corporation, Seiten 1–12, 2000, durch die vielfältigen JiniTM-System Ermittlungsprotokolle oder zum Beispiel durch einfaches Nachschauen in einem Namens-Server, wobei alle diese in ihrer Gesamtheit durch Referenz mit eingebunden sind. Der ermittelte PDA 22 gibt das Daten-Objekt 22b zu Computer 20 zurück. Computer 20 kann das empfangene Datenobjekt 22b überprüfen, um festzustellen, welche eine oder mehrere Schnittstellen mit PDA 22 assoziiert sind. Daher prüft Computer 20, wenn Computer 20 die oben beschriebene Ermittlung durchgeführt hat und das Datenobjekt 22b von PDA 22 erhalten hat, das empfangene Daten-Objekt 22b um festzustellen, welche universellen Schnittstellen mit PDA 22 assoziiert sind. Computer 20 stellt fest, dass PDA 22 wenigstens mit einer Datenquellen-Schnittstelle assoziiert ist und daher PDA 22 damit Daten bereitstellen kann. Computer 20 ruft die Datenquellen-Schnittstelle auf, die mit PDA 22 assoziiert ist und in dem Datenobjekt 22b enthalten ist, welches Anweisung enthält, den Computer 20 zu instruieren, den getSourceDataFlavors() Befehl, der in Datenobjekt 22b enthalten ist, auszuführen. Der getSourceDataFlavors() Befehl schließt umgekehrt Anweisungen für das Ansteuern von PDA 22 ein, um Computer 20 die von PDA 22 unterstützten Typen von Daten bereitzustellen.
  • Weiter bei Schritt 42 führt Computer 20 den beginTransferSession() Befehl aus, der in der Datenquellen-Schnittstelle enthalten ist. Zusätzlich kann dem beginTransfer-Session() Befehl beim Aufrufen der Kontext-Parameter, der initiale Freigabe-Dauer-Parameter und der Datenart-Parameter weitergegeben werden. PDA 22 gibt das Datentransfer-Session-Objekt 22c zu Computer 20 zurück. Computer 20 kann einen präferierten Datentyp unter Benutzung der oben beschriebenen Verfahren feststellen und einen präferierten Datentypwert, um in diesem Daten zu empfangen, dem Datenart-Parameter bereitstellen, auf der anderen Seite wird Computer 20 die Daten, in welchem Datenformat auch immer sie von PDA 22 bereitgestellt werden, empfangen. Computer 20 kann durch die Hilfe des Daten-Transfer-Session-Objekts 22c Daten von PDA 22 empfangen.
  • Weiter bei Schritt 44 schließt das Daten-Transfer-Session-Objekt 22c den getTransferData() Befehl und die anderen Befehle und Anweisungen, die oben beschrieben wurden, ein, welche von Computer 20 ausgeführt werden können, um Daten von PDA 22 abzurufen. Die Daten werden von PDA 22 zu Computer 20 durch Daten-Transfer-Session-Objekt 21c bei Schritt 46 transferiert. Weiterhin kann Computer 20 fähig sein, Datentypen zu sehen, für die er natürlicherweise nicht programmiert ist sie zu verstehen. Wenn Computer 20 den beginTransferSession() Befehl ausführt, kann PDA 22 die Anweisungen, Befehle oder Daten direkt zu Computer 20 zurückgeben, um ihn zu befähigen, die Daten zu verstehen, welche von PDA 22 transferiert werden.
  • Mit Bezug auf 5 ist Computer 20 mit einem Faxgerät 24, wie oben in Verbindung mit 1 beschrieben, verbunden. Das Faxgerät 24 hat zum Beispiel einen Satz von universellen Schnittstellen 24a in einem Speicher gespeichert oder anderweitig im Zugriff, durch zum Beispiel Zugreifen auf Server 23, welcher eine Datensenken-Schnittstelle umfassen, die detailreicher im Folgenden beschrieben wird. Unabhängig davon kann man das Faxgerät 24 mit jeder Zahl von Schnittstellen und jeder Kombination davon assoziiert sein.
  • Faxgerät 24 kann den Satz von universellen Schnittstellen 24a durch das Datenobjekt 24b ansteuern, um verschiedene Typen von Kommunikationen zu erreichen. Je de der Schnittstellen in dem Satz von universellen Schnittstellen 24a erteilt Anweisungen, Sitze von Befehlen und/oder andere Daten, die durch den Computer 20 verstanden und ausgeführt werden können, um ihn anzuweisen mit dem Faxgerät 24 zu kommunizieren und Daten zu transferieren. Mit Ausnahme der Datensenken-Schnittstelle sind alle der oben genannten Schnittstellen die gleichen, wie sie oben in Verbindung mit PDA 22 beschrieben wurden, aber jede Schnittstelle enthält Anweisungen, die spezifisch sind für eine spezifische Einheit, mit der sie assoziiert sind (d.h. Faxgerät 24).
  • Im Speziellen schließt die Datensenken-Schnittstelle vielfältige Befehle ein, wie zum Beispiel einen get-SinkDataFlavor() und einen Transfer() Befehl. Weiterhin schließt die Datensenken-Schnittstelle Anweisungen und Daten ein, die von Computer 20 ausgeführt werden können, um eine Datentransfer-Session zu etablieren, um Computer 20 anzuweisen, Daten zu Faxgerät 24 zu übertragen. Im Speziellen schließt der getSinkDataFlavor() Befehl Anweisungen und Daten ein, die von Computer 20 ausgeführt werden können, um festzustellen, welche Typen von Daten das Faxgerät 24 unterstützen kann. In dieser speziellen Ausführungsform kann Computer 20 den getSinkDataFlavor() Befehl ausführen, welcher eine Liste von einem oder mehreren Datentypen, die vom Faxgerät 24 unterstützt werden, zurückgibt. Außerdem sind die Datentypen in dieser Ausführungsform typischerweise MIME-Datentypen. Der Transfer() Befehl schließt Anweisungen und Daten ein, die von Computer 20 ausgeführt werden können, um vom Faxgerät 24 zu verlangen, eine Daten-Transfer-Session zu etablieren, so dass Computer 20 beginnen kann, Daten zum Faxgerät 24 zu übermitteln. Dem Transfer() Befehl können in dieser Ausführungsform beim Aufrufen Parameter weitergegeben werden, wie zum Beispiel das Daten-Transfer-Session-Objekt 20c, welches mit Computer 20 assoziiert ist, einen Kontext-Parameter und einen Datenart-Parameter. Im Speziellen gibt Computer 20 das Datentransfer-Session-Objekt 20c in den Transfer() Befehl, um ihn für das Faxgerät 24 verfügbar zu machen, so dass es die darin enthaltenen Anweisungen ausführen kann, um tatsächlich Daten vom Computer 20 zu empfangen. In dieser Ausführungsform enthält das Datentransfer-Session-Objekt 20c, welches mit Computer 20 assoziiert ist, dieselben Typen von Anweisungen, Daten und Befehlen, wie das oben beschriebene Datentransfer-Session-Objekt 22c, mit der Ausnahme, dass die Anweisung, Daten und Befehle, die dann enthalten sind, spezifisch für Computer 20 sind. Computer 20 gibt einen Kontext-Parameter beim Aufrufen in den Transfer() Befehl, um das Faxgerät 24 aus einer Reihe von Gründen, wie zum Beispiel Sicherheitsgründe, über seine Identität zu informieren. Faxgerät 24 kann, basierend auf der Identitäts-Information, die durch den Kontext-Parameter bereitgestellt wird, entscheiden, ob es dem Computer 20 erlaubt, Daten zu transferieren. Zusätzlich kann, wenn das Faxgerät 24 einen oder mehrere Typen von Daten unterstützt, wie durch das Ausführen des getSinkDataFlavor() Befehls ermittelt wird, ein Datenart-Parameter in den Transfer() Befehl weitergegeben werden, um das Faxgerät 24 davon zu informieren, welcher Datentyp durch den Computer 20 übertragen werden wird. Zusätzlich kann Computer 20 einen präferierten Datentypwert zu dem Datenart-Parameter aus einer Reihe von Gründen bereitstellen, wie zum Beispiel in dem Fall, dass Computer 20 und Faxgerät 24 eine Vielzahl von kompatiblen Datentypen unterstützen, wobei Computer 20 unter Benutzung des Parameters einen präferierten Datentypen für den Datentransfer spezifiziert. In dieser Ausführungsform kann Computer 20 einen präferierten Datentypen durch Benutzung einer Anzahl von Methoden feststellen, wie zum Beispiel das Befähigen des Nutzers am Computer 20 den präferierten Datentypen anzuzeigen, zufälliges Aussuchen eines der kompatiblen Datentypen zwischen Computer 20 und Faxgerät 24 oder Selektieren des Datentypen, der für die spezifischen Daten, die transferiert werden, am effizientesten ist. Zusätzlich, wo Computer 20 und Faxgerät 24 mit Bezug aufeinander eine endliche Anzahl von kompatiblen Datentypen unterstützen, kann Computer 20 den kompatiblen Datentypen auswählen, um die Daten zu Faxgerät 24 zu übertragen.
  • Bezugnehmend auf 6 bei Schritt 50 führt Computer 20 den Ermittlungsprozess aus und stellt durch Überprüfen des Datenobjekts 24b, wie oben in Verbindung mit einer oder mehrerer Alternativen beschrieben, fest, dass Computer 20 oder Faxgerät 24 Daten zwischen einander transferieren können, weil Faxgerät 24 wenigstens mit einer Datensenken-Schnittstelle assoziiert ist. Computer 20 ruft die Datensenken-Schnittstelle auf, die mit Faxgerät 24 assoziiert ist und im Datenobjekt 24b enthalten ist, welche Anweisungen enthält, die Computer 20 instruieren, den getSinkDataFlavor() Befehl auszuführen. Der getSinkDataFlavor() Befehl schließt umgekehrt, wie oben beschrieben, Anweisungen für das Ansteuern von Faxgerät 24 zum Bereitstellen von Typen von Daten, welche von Faxgerät 24 für den Computer 20 unterstützt werden, ein.
  • Weiter bei Schritt 52 führt Computer 20 den Transfer() Befehl der in der Datensenken-Schnittstelle enthalten ist, aus. Zusätzlich gibt Computer 20 in den Transfer() Befehl das Datenobjekt 20c, den Kontext-Parameter und den Datenart-Parameter, wenn er wie oben beschrieben, aufgerufen wird.
  • Weiter bei Schritt 54 führt Faxgerät 24 die Anweisungen aus, welche wie bereitgestellt, durch den Transfer() Befehl im Datentransfer-Session-Objekt 20c enthalten sind, um Daten von Computer 20 zu empfangen. Die Daten werden von Computer 20 zu Faxgerät 24 durch das Datentransfer-Session-Objekt 20c bei Schritt 56 übertragen.
  • Mit Bezug auf 7 sind Computer 20, Drucker 21 und Server 23, wie oben beschrieben in Verbindung mit 1, miteinander verbunden. In dieser Ausführungsform ist Drucker 21 mit einem Satz von universellen Schnittstellen 21a assoziiert, beinhaltend eine Datenquellen-Schnittstelle, eine Datensenken-Schnittstelle und eine Kontext-Schnittstelle. Server 23 ist assoziiert mit einem Satz von universellen Schnittstellen 23a, beinhaltend eine Datenquellen-Schnittstelle, eine Datensenken-Schnittstelle und eine Kontext-Schnittstelle. Jeder der oben erwähnten Schnittstellen ist dieselbe wie die, die oben in Verbindung mit 3 und 5 beschrieben, wurden mit der Ausnahme, dass jede Schnittstelle in dieser Ausführungsform Anweisungen beinhaltet, die spezifisch sind für eine spezielle Einheit, mit der sie assoziiert sind (d.h. Drucker 21 oder Server 23). Weiterhin schließt das Datentransfer-Session-Objekt 25, das mit dem Drucker 21 assoziiert ist, dieselben Anweisungen, Daten und Befehle ein, wie die oben beschriebenen Datentransfer-Session-Objekte 20c und 22c, mit der Ausnahme, dass die Anweisungen, Daten und Befehle, die dann enthalten sind, spezifisch sind für Drucker 21.
  • Mit Bezug auf 8 bei Schritt 60 führt Computer 20 den Ermittlungsprozess aus und stellt, wie oben in Verbindung mit einer oder mehreren Alternativen beschrieben, durch Überprüfen der Datenobjekte 21b und 23b fest, dass Drucker 21 und Server 23 Daten zwischen einander transferieren können, weil Drucker 21 mit einer Datenquellen-Schnittstelle assoziiert ist und Server 23 mit einer Datensenken-Schnittstelle assoziiert ist. Computer 20 ruft die Datenquellen-Schnittstelle, die mit Drucker 21 assoziiert ist, auf, und führt den getSourceDataFIavors() Befehl der in Datenobjekt 21b enthalten ist, aus, um den Drucker 21 anzusteuern, um die Typen von Daten, welche durch Drucker 21 unterstützt werden, wie oben beschrieben, festzustellen.
  • Weiter bei Schritt 62 führt Computer 20 den beginTransferSession() Befehl, der in der Datenquellen-Schnittstelle enthalten ist, aus. Zusätzlich kann dem beginTransfer-Session() Befehl der Kontext-Parameter, der mit Computer 20 oder Server 23 assoziiert ist, weitergegeben werden. Zum Beispiel kann Computer 20 die Kontext-Schnittstelle, die mit Server 23 assoziiert ist und durch das Datenobjekt 23b ansteuerbar ist, aufrufen. In diesem Beispiel würde Computer 20 die Kontext-Information von Server 23 empfangen, aber umgekehrt diese durch den beginTransferSession() Befehl für den Drucker 21 bereitstellen. Dies befiehlt Drucker 21 zu entscheiden, ob er Daten mit Server 23 austauschen will. Alternativ kann Computer 20 aus denselben Gründen, wie oben beschrieben, sowohl seine eigenen Kontext-Informationen für Drucker 21 wie auch den initialen Freigabe-Dauer-Parameter beim Aufruf bereitstellen. Computer 20 ruft die Datensenken-Schnittstelle, welche mit Server 23 assoziiert ist und im Datenobjekt 23b enthalten ist, auf, welche Anweisungen beinhaltet, die Computer 20 instruieren, den getSinkDataFlavor() Befehl auszuführen. Der getSinkDataFIavor() Befehl schließt umgekehrt Anweisungen für das Ansteuern von Server 23 ein, um Computer 20 die Typen von Daten bereitzustellen, die von Server 23 unterstützt werden. Zusätzlich, wenn Server 23, wie ermittelt durch Durchführen des getSinkDataFIavor() Befehls, einen oder mehrere Typen von Daten unterstützt, kann ein Datenart-Parameter in den Transfer() Befehl weitergegeben werden, um Server 23 über den Typ von Daten zu informieren, der zu ihm übertragen werden wird. Weiterhin kann Computer 20 aus einer Reihe von Gründen einen präferierten Datentypwert für den Datenart-Parameter bereitstellen, sowie zum Beispiel in dem Fall, dass der Drucker 21 und Server 23 vielfältige kompatible Datentypen unterstützen, wobei Computer 20 unter Benutzung des Parameters einen präferierten Datentypen für den Datentransfer zwischen Drucker 21 und Server 23 spezifiziert. Drucker 21 gibt das Datenquellenobjekt 25 zu Computer 20 durch das Datenobjekt 21b zurück.
  • Weiter bei Schritt 64 führt Computer 20 den Transfer() Befehl, der in der Datensenken-Schnittstelle, die mit Server 23 assoziiert ist und in dem Datenobjekt 23b enthalten ist, aus. Dem Transfer() Befehl können auch Parameter beim Aufrufen weitergegeben werden, einschließlich des Datenquellenobjekts 25, das der Computer 20 vom Drucker 21 empfangen hat, eines Kontext-Parameters und/oder eines Datenart-Parameters, der mit dem Drucker 21 assoziiert ist. Der Computer 20 stellt dem Server 23 den Kontext-Parameter, der mit Computer 20 und/oder Drucker 21 assoziiert ist, zur Verfügung, so dass Server 23 aus einer Vielzahl von Gründen, wie zum Beispiel Sichefieitsgrün den, entscheiden kann, ob er in dem Datentransfer teilnehmen will. Computer 20 ist in der Lage, Server 23 seine eigenen Kontext-Informationen durch Ausführung seiner eigenen Anweisungen, um seine Kontext-Informationen zu bekommen und diese Informationen in den Transfer() Befehl durch den Kontext-Parameter weiterzugeben, bereitsstellen. Server 23 kann Daten von Drucker 21 durch das Datentransfer-Session-Objekt 25 empfangen, welches Computer 20 vom Drucker 21 empfangen hat und zu Server 23 von Computer 20 durch den Transfer() Befehl übertragen wurde.
  • Weiter bei Schritt 66 führt Server 23 den getTransferData() Befehl, der in das Datentransfer-Session-Objekt 25 enthalten ist, aus, um Daten vom Drucker 21 abzurufen. Die Daten werden von Drucker 21 zu Server 23 durch das Datentransfer-Session-Objekt 25 bei Schritt 68 transferiert. In diesem Beispiel können ein oder mehrere der Computer 20, Drucker 21 oder Server 23 ansteuern und ausführen, wie oben beschrieben und in dem Datentransfer-Session-Objekt 25 enthalten, den abort() Befehl, fail() Befehl oder den complete() Befehl. Auch können ein oder mehrere der Computer 20, Drucker 21 oder Server 23 dafür verantwortlich gemacht werden, die Freigabe der Datentransfer-Session zu erneuern. In einer anderen Alternative können ein oder mehrere von Computer 20, Drucker 21 oder Server 23 durch das Aufrufen der Benachrichtigungs-Schnittstelle (nicht gezeigt), welche mit Computer 20, Drucker 21 oder Server 23 assoziiert ist, als Zuhörer miteinander registriert sein, um, wie oben beschrieben, Ereignis-Benachrichtigungen zu empfangen. In diesem Beispiel kann Computer 20 die Benachrichtigungs-Schnittstelle, die mit Drucker 21 und/oder Server 22 assoziiert ist, aufrufen, um sich als ein Zuhörer zu registrieren, um den Fortschritt des Datentransfers zu überwachen. Während der Datentransfer-Session zwischen Drucker 21 und Server 22 ist die Beteiligung von Computer 20 nicht erforderlich. Ob oder ob nicht Computer 20 damit fortfährt, an der Datentransfer-Session teilzunehmen, hängt von einer Vielzahl von Faktoren ab, wie zum Beispiel, ob Computer 20 Ereignisbenachrichtigungen empfangen möchte, die mit der Datentransfer-Session assoziiert sind und ob Computer 20 verantwortlich ist dafür, die Freigabe der Datentransfer-Session, wie oben beschrieben, zu erneuern.
  • In einer anderen Alternative kann jeweils Computer 20, Drucker 21 oder Server 23 durch Anwenden von einer oder mehrerer der oben beschriebenen Alternativen als Datenquelle oder Datensenke zwischen einander fungieren. Zum Beispiel kann Compu ter 20 einen Datentransfer initiieren, wobei Server 23 als eine Datenquelle dient und daher folgend denselben Schritten wie oben beschrieben mit Bezug auf Drucker 21, der Daten zu Server 23 überträgt, durch das Datentransfer-Session-Objekt 25 Daten zu Drucker 21 überträgt.
  • Während Einheiten wie Computer 20, Drucker 21, PDA 22, Server 23 und Faxgerät 24 (d.h. Komponenten 2024) als Beispiele in einer oder mehrerer der oben beschriebenen Alternativen benutzt wurden, können eine Anzahl von anderen Systemen als Komponenten 2024 benutzt werden, wie zum Beispiel Software-Dienstleistungen, Applikationen oder Teile davon, einschließlich Sprachübersetzungs-Dienstleistungen, Datenformat-Umwandler, e-mail-Anwendungen, Kalender-Anwendungen oder Rechtschreib-Routinen, die innerhalb einer Textverarbeitung ausgeführt werden. Zum Beispiel kann eine Textverarbeitung einen gegenwärtig markierten Text als eine Datenquellen-Komponente bereitstellen, so dass dieser zu PDA 22 gesendet werden kann, welcher eine Datensenken-Komponente ist.
  • Die vorgetragene Ordnung der Verfahrenselemente oder Sequenzen kann in weiteren Alternativen unterschiedlich sein.

Claims (12)

  1. System für das Befähigen von Komponenten (2024) Daten zwischen einander zu transferieren, wobei das System umfasst: eine erste Komponente die über ein Daten-Transfer-Session-Objekt verfügt; und eine zweite Komponente; dadurch gekennzeichnet, dass diese Komponenten dafür konfiguriert sind, ein Daten-Transfer-Session-Objekt von der ersten Komponente zu der zweiten Komponente zu transferieren, wobei das Daten-Transfer-Session-Objekt Befehle beinhaltet, die innerhalb der zweiten Komponente oder innerhalb anderer Komponenten auszuführen sind, um jeweils Daten zwischen der ersten Komponente und der zweiten Komponente oder den anderen Komponenten zu transferieren.
  2. System gemäß Anspruch 1, wobei das Daten-Transfer-Session-Objekt über quellenspezifischen objektorientierten mobilen Code verfügt, der durch die zweite Komponente interpretiert und ausgeführt werden kann, um Daten zu empfangen.
  3. System gemäß Anspruch 1 oder 2, wobei das Daten-Transfer-Session-Objekt Anweisungen beinhaltet, um die zweite Komponente zu befähigen, mit der ersten Komponente über das Transferieren von Daten zu verhandeln, für das Selektieren eines Kommunikationsprotokolls, das genutzt wird, Daten zwischen der ersten und der zweiten Komponente zu transferieren, basierend auf einem Typ von Daten die transferiert werden, oder für das Selektieren eines Übertragungsmediums, das benutzt wird, um Daten zu transferieren, basierend auf dem Typ von Daten.
  4. System gemäß einem der Ansprüche 1 bis 3, wobei das Daten-Transfer-Session-Objekt Anweisungen beinhaltet, den Datentransfer zu beenden, wenn die zweite Komponente darin versagt, eine Datentransferfreigabe zu erneuern oder anzeigt, dass der Datentransfer komplettiert wurde oder fehlgeschlagen ist.
  5. System gemäß einem der Ansprüche 1 bis 3, weiterhin umfassend: eine dritte Komponente, wobei die Komponenten dafür konfiguriert sind, das Daten-Transfer-Session-Objekt zuerst von der ersten Komponente zu der dritten Komponente zu transferieren und dann von der dritten Komponente zu der zweiten Komponente zu transferieren.
  6. System gemäß Anspruch 5, wobei der Datentransfer endet, wenn die dritte Komponente darin versagt, eine Datentransferfreigabe zu erneuern oder anzeigt, dass der Datentransfer komplettiert wurde oder fehlgeschlagen ist.
  7. Verfahren für das Befähigen von Komponenten (2024) Daten zwischen einander zu transferieren, wobei das Verfahren umfasst: (a) Transferieren eines Daten-Transfer-Session-Objekts von einer ersten Komponente zu einer zweiten Komponente; und (b) Ausführen, innerhalb der zweiten Komponente, von Befehlen, die in dem Daten-Transfer-Session-Objekt enthalten sind, um Daten zwischen der ersten Komponente und der zweiten Komponente zu transferieren.
  8. Verfahren gemäß Anspruch 7, weiterhin umfassend, vor dem Schritt (a) die Schritte: (c) starten eines Ermittlungsprozesses von der zweiten Komponente; (d) Transferieren, als eine Antwort zu Schritt (c), eines Datenobjekts von der ersten Komponente zu der zweiten Komponente; (e) Ausführen, innerhalb der zweiten Komponente, von Befehlen, die in dem Datenobjekt enthalten sind, um von der ersten Komponente den Transfer des Daten-Transfer-Session-Objekts anzufordern.
  9. Verfahren gemäß Anspruch 7, weiterhin umfassend, vor dem Schritt (a), die Schritte: (f) Starten eines Ermittlungsprozesses von der ersten Komponente; (g) Transferieren, als eine Antwort zu Schritt (c), eines Datenobjekts von der zweiten Komponente zu der ersten Komponente; (h) Ausführen, innerhalb der ersten Komponente, von Befehlen, die in dem Datenobjekt enthalten sind, um von der zweiten Komponente Informationen über die Typen von Daten anzfordern, die von der zweiten Komponente unterstützt werden.
  10. Verfahren nach Anspruch 7, weiterhin umfassend, vor dem Schritt (a), die Schritte: (i) Starten eines Ermittlungsprozesses von einer dritten Komponente; (k) Transferieren, als eine Antwort zu Schritt (i), eines Datenobjekts von der ersten Komponente zu der dritten Komponente und eines Datenobjekts von der zweiten Komponente zu der dritten Komponente; (l) Ausführen, innerhalb der ersten Komponente, von Befehlen, die in dem Datenobjekt enthalten sind, das von der ersten Komponente transferiert wurde, um von der ersten Komponente Informationen über die Typen von Daten anzufordern, die von der ersten Komponente unterstützt werden; (m) Ausführen, innerhalb der ersten Komponente, von Befehlen, die in dem Datenobjekt enthalten sind, das von der zweiten Komponente transferiert wurde, um von der zweiten Komponente Informationen über die Typen von Daten anzfordern, die von der zweiten Komponenten unterstützt werden; (n) Transferieren des Datenobjekts, das vorher von der ersten Komponente zu der dritten Komponente transferiert wurde, von der dritten Komponente weiter zu der zweiten Komponente.
  11. Verfahren gemäß einem der Ansprüche 7 bis 10, dafür adaptiert, das System eines der Ansprüche 1 bis 6 zu betreiben.
  12. Ein computerlesbares Medium, auf dem Anweisungen gespeichert sind, die, wenn sie von einem Computer ausgeführt werden, den Computer veranlassen, das Verfahren nach einem der Ansprüche 7 bis 10 auszuführen.
DE60302368T 2002-01-29 2003-01-29 System und Verfahren um den Transfer von Daten zwischen beliebigen Komponenten untereinander zu ermöglichen Expired - Lifetime DE60302368T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/058,268 US20030145089A1 (en) 2002-01-29 2002-01-29 System and method for enabling arbitrary components to transfer data between each other
US58268 2002-01-29

Publications (2)

Publication Number Publication Date
DE60302368D1 DE60302368D1 (de) 2005-12-29
DE60302368T2 true DE60302368T2 (de) 2006-06-08

Family

ID=22015738

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60302368T Expired - Lifetime DE60302368T2 (de) 2002-01-29 2003-01-29 System und Verfahren um den Transfer von Daten zwischen beliebigen Komponenten untereinander zu ermöglichen

Country Status (4)

Country Link
US (2) US20030145089A1 (de)
EP (1) EP1331571B1 (de)
JP (1) JP4424910B2 (de)
DE (1) DE60302368T2 (de)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7367029B2 (en) * 2002-08-01 2008-04-29 Xerox Corporation Method and system for handling data
US20080313282A1 (en) 2002-09-10 2008-12-18 Warila Bruce W User interface, operating system and architecture
US7464110B2 (en) * 2004-06-30 2008-12-09 Nokia Corporation Automated grouping of image and other user data
US20060004834A1 (en) * 2004-06-30 2006-01-05 Nokia Corporation Dynamic shortcuts
US8438633B1 (en) 2005-04-21 2013-05-07 Seven Networks, Inc. Flexible real-time inbox access
US20070070392A1 (en) * 2005-09-16 2007-03-29 Harrison Karen L Processing requests for data sinks in a logical printer
US8176097B2 (en) * 2009-01-02 2012-05-08 International Business Machines Corporation Maintaining data coherency within related multi-perspective user interfaces via session-less queries
JP5550385B2 (ja) * 2009-03-04 2014-07-16 キヤノン株式会社 画像処理装置及びその制御方法、並びに記憶媒体
US10277683B2 (en) 2009-03-16 2019-04-30 Apple Inc. Multifunctional devices as virtual accessories
US8285860B2 (en) 2009-03-16 2012-10-09 Apple Inc. Efficient service discovery for peer-to-peer networking devices
US20100235523A1 (en) * 2009-03-16 2010-09-16 Robert Garcia Framework for supporting multi-device collaboration
US20100233960A1 (en) * 2009-03-16 2010-09-16 Brian Tucker Service discovery functionality utilizing personal area network protocols
TW201116002A (en) * 2009-10-30 2011-05-01 Askey Computer Corp System and method for data transmission via special line
EP3926931A3 (de) 2012-04-13 2022-05-04 Goldman Sachs & Co. LLC Systeme und verfahren zur skalierbaren strukturierten datenverteilung
US9270929B2 (en) 2013-12-19 2016-02-23 Lattice Semiconductor Corporation Formatting audio-video information compliant with first transmission format to second transmission format in integrated circuit for offloading physical layer logic for first transmission format to separate integrated circuit
CN107786556A (zh) * 2017-10-24 2018-03-09 江苏神州信源系统工程有限公司 一种端口快速扫描方法与装置

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5475836A (en) * 1987-04-01 1995-12-12 Lotus Development Corporation Interface for providing access to external data sources/sinks
US6345288B1 (en) * 1989-08-31 2002-02-05 Onename Corporation Computer-based communication system and method using metadata defining a control-structure
DE4106793A1 (de) * 1991-03-04 1992-09-17 Licentia Gmbh Kommunikationsschnittstelle
CA2134620A1 (en) * 1993-11-05 1995-05-06 Arul Menezes System and method for exchanging computer data processing capabilities
US5546549A (en) * 1994-06-01 1996-08-13 International Business Machines Corporation Multi-path channel (MPC) interface with user transparent, unbalanced, dynamically alterable computer input/output channels
US5664102A (en) * 1995-02-07 1997-09-02 At&T Intelligent network internetworking access arrangement
US6148346A (en) * 1996-06-20 2000-11-14 Peerless Systems Imaging Products, Inc. Dynamic device driver
US5915252A (en) * 1996-09-30 1999-06-22 International Business Machines Corporation Object oriented framework mechanism for data transfer between a data source and a data target
US6751647B1 (en) * 1998-06-19 2004-06-15 Intel Corporation Method and apparatus for automated data exchange between a user computer and a provider computer using improved object-oriented programming components
GB2342196A (en) * 1998-09-30 2000-04-05 Xerox Corp System for generating context-sensitive hierarchically-ordered document service menus
US6675196B1 (en) * 1999-01-08 2004-01-06 Amazon.Com, Inc. Universal protocol for enabling a device to discover and utilize the services of another device
US6725281B1 (en) * 1999-06-11 2004-04-20 Microsoft Corporation Synchronization of controlled device state using state table and eventing in data-driven remote device control model
US6718377B1 (en) * 1999-08-13 2004-04-06 Lucent Technologies Inc. Telecommunications network management system interface
AU1104601A (en) * 1999-10-29 2001-05-14 Singleshop.Com System and method of aggregate electronic transactions with multiple sources
JP3430509B2 (ja) * 1999-12-03 2003-07-28 日本電気株式会社 データ通信システム及び方法
US20010033554A1 (en) * 2000-02-18 2001-10-25 Arun Ayyagari Proxy-bridge connecting remote users to a limited connectivity network
US20020022453A1 (en) * 2000-03-31 2002-02-21 Horia Balog Dynamic protocol selection and routing of content to mobile devices
US6643650B1 (en) * 2000-05-09 2003-11-04 Sun Microsystems, Inc. Mechanism and apparatus for using messages to look up documents stored in spaces in a distributed computing environment
US6591312B1 (en) * 2000-05-23 2003-07-08 Hewlett-Packard Development Company, L.P. Digital communication devices and digital communication methods
US7031945B1 (en) * 2000-07-24 2006-04-18 Donner Irah H System and method for reallocating and/or upgrading and/or rewarding tickets, other event admittance means, goods and/or services
US6938087B1 (en) * 2000-09-12 2005-08-30 Hewlett-Packard Development Company, L.P. Distributed universal communication module for facilitating delivery of network services to one or more devices communicating over multiple transport facilities
US7152110B2 (en) * 2001-04-18 2006-12-19 Microsoft Corporation Information exchange between non-networked devices through an intermediary device via a piconet
US6842460B1 (en) * 2001-06-27 2005-01-11 Nokia Corporation Ad hoc network discovery menu

Also Published As

Publication number Publication date
EP1331571A1 (de) 2003-07-30
EP1331571B1 (de) 2005-11-23
US20040122957A1 (en) 2004-06-24
JP2003223336A (ja) 2003-08-08
DE60302368D1 (de) 2005-12-29
US7421494B2 (en) 2008-09-02
US20030145089A1 (en) 2003-07-31
JP4424910B2 (ja) 2010-03-03

Similar Documents

Publication Publication Date Title
DE60302368T2 (de) System und Verfahren um den Transfer von Daten zwischen beliebigen Komponenten untereinander zu ermöglichen
DE602005002679T2 (de) WEB-Dienst-Anwendungsprotokoll und SOAP-Verarbeitungsmodell
DE602004004300T2 (de) Verfahren, System und Computerprogramm für das Senden und Empfangen von Meldungen durch einen individuellen Kommunikationskanal
DE602004006902T2 (de) Verfahren und System zur Verarbeitung von Mitteilungen von geteilten Ressourcen
DE69814900T2 (de) Verfahren und system zur unterstützung verteilter software- entwicklung ohne bewusstsein der verteilten charakteristik der software
DE60124440T2 (de) Namensverwaltungskonvention für verschiedene Gerätetypen, und Vorrichtung und Verfahren zur Anwendung dieser Namensverwaltungskonvention
DE69734189T2 (de) Verteiltes Netzwerkrechnersystem und Datenaustauschgerät
DE69832354T2 (de) Netzwerkverwaltungsrahmenwerk
DE69534411T2 (de) Offenes Transaktionverwaltungszugriffsystem und Verfahren
DE69824879T2 (de) Verteilter web- anwendungs- server
DE69730690T2 (de) Verfahren und apparat zum dynamischen austausch von objekt-nachrichten zwischen objekt-modellen
DE60315558T2 (de) Verteiltes Rechnersystem für Vorrichtungsresourcen basierend auf Identität
DE60210343T2 (de) Persönlicher benutzer-agent
DE602004009902T2 (de) System und verfahren für kompakte nachrichtenübermittlung in der netzwerkkommunikation
DE102006032108B4 (de) System und Verfahren für eine Mehr-Ort-Testausführung
EP1532797B1 (de) Verfahren zum übertragen von nutzdatenobjekten gemüss einem profilinformationsobjekt
DE69637436T2 (de) Objektorientiertes Kommunikationssystem mit Unterstützung für mehrere entfernte Maschinentypen
DE60027247T2 (de) Verfahren und Systeme zur Konvertierung von Datenformaten
DE10297998B4 (de) Erstellen verteilter Proxy-Konfigurationen
DE19805891A1 (de) Telephonie-Schalter-Konfigurator
DE10205108A1 (de) System und Verfahren zum Zugreifen auf Softwarekomponenten in einer verteilten Netzwerkumgebung
DE69930695T2 (de) Verfahren und Vorrichtung für ein Applikationsverteiler für eine Serverapplikation
DE60316466T2 (de) Unterstüzung von mehreren nativen netzwerkprotokollimplementiurungen in einem einzigen system
DE602005005727T2 (de) Verfahren und Vorrichtung zur Verbindung von Knoten mit heterogenen Kommunikationsprotokollen
DE60035348T2 (de) Verlängerbarer Bereitstellungsmechanismus für einen Diensten-gateway

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
R082 Change of representative

Ref document number: 1331571

Country of ref document: EP

Representative=s name: GRUENECKER, KINKELDEY, STOCKMAIR & SCHWANHAEUSSER,