DE102013207118A1

DE102013207118A1 - Verfahren zum Betreiben einer mobilen DV-Anlage und zentrale DV-Anlage

Info

Publication number: DE102013207118A1
Application number: DE102013207118.3A
Authority: DE
Inventors: Susanne Bullert; Holger Last; Thomas Peter Mahr
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2013-04-19
Filing date: 2013-04-19
Publication date: 2014-10-23
Also published as: WO2014170040A1; EP2943900A1

Abstract

Erläutert wird ein Verfahren zum Betreiben einer mobilen DV-Anlage, enthaltend: – Übertragen einer Anforderungsnachricht für Daten von einer ersten mobilen DV-Anlage zu einer zentralen DV-Anlage, – Bearbeiten der Anforderungsnachricht und Erzeugen einer zugehörigen Antwortnachricht, wobei Daten gemäß der Anforderungsnachricht von einem Diensterbringungsprogramm (CIS) zumindest von einer zweiten DV-Anlage (DB1b) und/oder von einer dritten DV-Anlage (DB6b) angefordert werden, und wobei für die von der zweiten DV-Anlage (DB1b) und/oder die von der dritten DV-Anlage (DB6b) empfangenen Daten eine Formatumwandlung durchgeführt wird, – Übertragen der Antwortnachricht von der zentralen DV-Anlage (CIS) zu der ersten mobilen DV-Anlage, – in der ersten mobilen DV-Anlage Verwenden von in der Antwortnachricht enthaltenen Daten zur Erbringung eines Dienstes durch ein Programm, wobei auf mindestens eine vierte DV-Anlage unter Verwendung zumindest eines Teils oder nur eines Teils der in der Antwortnachricht enthaltenden Daten zugegriffen wird.

Description

Die Erfindung betrifft ein Verfahren zum Betreiben einer mobilen DV-Anlage (Datenverarbeitungsanlage) und eine zentrale DV-Anlage oder einen zentralen DV-Anlagen-Verbund.
Mobile Endgeräte werden auch als Smartphones bezeichnet und haben eine starke Verbreitung. Im Gegensatz dazu steht, dass es noch vergleichsweise wenige Programme gibt, die sich ändernde Kontextdaten unterstützen.
Die Erfindung betrifft ein Verfahren zum Betreiben einer mobilen DV-Anlage, enthaltend:

– Übertragen einer Anforderungsnachricht für Daten von einer ersten mobilen DV-Anlage zu einer zentralen DV-Anlage,
– Bearbeiten der Anforderungsnachricht und Erzeugen einer zugehörigen Antwortnachricht, wobei die Daten gemäß der Anforderungsnachricht von einem Diensterbringungsprogramm zumindest von einer zweiten DV-Anlage und/oder von einer dritten DV-Anlage angefordert werden, und wobei für die von der zweiten DV-Anlage und/oder die von der dritten DV-Anlage empfangenen Daten eine Formatumwandlung durchgeführt wird,
– Übertragen der Antwortnachricht von der zentralen DV-Anlage zu der ersten mobilen DV-Anlage,
– in der ersten mobilen DV-Anlage Verwenden von in der Antwortnachricht enthaltenen Daten zur Erbringung eines Dienstes durch ein Programm, vorzugsweise ein Anwendungsprogramm, wobei auf mindestens eine vierte DV-Anlage unter Verwendung zumindest eines Teils oder nur eines Teils der in der Antwortnachricht enthaltenden Daten zugegriffen wird.

Weiterhin betrifft die Erfindung eine zentrale DV-Anlage oder einen zentralen DV-Anlagen-Verbund, insbesondere zur Durchführung des oben genannten Verfahrens, enthaltend:

– mindestens einen Prozessor,
– mindestens einen Speicher zum Speichern von Programmbefehlen, bei deren Ausführung durch den Prozessor die Verfahrenschritte erbracht werden,
– eine Empfangseinheit zum Empfangen einer Anforderungsnachricht,
– eine Bearbeitungseinheit oder eine Bearbeitungseinheit in einer weiteren DV-Anlage zum Bearbeiten der Anforderungsnachricht und zum Erzeugen einer zugehörigen Antwortnachricht, wobei Daten gemäß der Anforderungsnachricht von einem Diensterbringungsprogramm zumindest von einer zweiten DV-Anlage und/oder von einer dritten DV-Anlage angefordert werden, und wobei für die von der zweiten DV-Anlage und/oder die von der dritten DV-Anlage empfangenen Daten eine Formatumwandlung durchgeführt wird, und
– eine Sendeeinheit zum Senden der Antwortnachricht.

Es ist Aufgabe von Weiterbildungen der Erfindung ein einfaches Verfahren zum Betreiben einer mobilen DV-Anlage anzugeben, das insbesondere einen geringen Speicherplatz für Daten benötigt und/oder eine Mehrfachnutzung von Daten und Datenstrukturen ermöglicht. Das Verfahren soll insbesondere auch zur Erhöhung der Konsistenz bzw. Widerspruchsfreiheit von Daten dienen und/oder die Archivierung erleichtern. Weiterhin soll insbesondere die Wiederverwendbarkeit von Festlegungen hoch sein bzw. Daten sollen insbesondere auf einfache Art selektiv gelöscht werden können. Außerdem soll insbesondere eine zugehörige DV-Anlage oder ein zugehöriger Datenverarbeitungsanlagenverbund angegeben werden.
Diese Aufgabe wird durch ein Verfahren nach Anspruch 1 gelöst. Weiterbildungen sind in den Unteransprüchen angegeben.
Das Verfahren zum Betreiben einer mobilen DV-Anlage kann die folgenden Verfahrensschritte enthalten:

– Übertragen einer Anforderungsnachricht für Daten von einer ersten mobilen DV-Anlage zu einer zentralen DV-Anlage,
– vorzugsweise in der zentralen DV-Anlage oder in einer weiteren DV-Anlage Bearbeiten der Anforderungsnachricht und Erzeugen einer zugehörigen Antwortnachricht, wobei die Daten gemäß der Anforderungsnachricht von einem Diensterbringungsprogramm zumindest von einer zweiten DV-Anlage und/oder von einer dritten DV-Anlage angefordert werden, und wobei für die von der zweiten DV-Anlage und/oder die von der dritten DV-Anlage empfangenen Daten eine Formatumwandlung durchgeführt wird,
– Übertragen der Antwortnachricht von der zentralen DV-Anlage zu der ersten mobilen DV-Anlage,
– in der ersten mobilen DV-Anlage Verwenden von in der Antwortnachricht enthaltenen Daten zur Erbringung eines Dienstes durch ein Programm, vorzugsweise ein Anwendungsprogramm, wobei auf mindestens eine vierte DV-Anlage unter Verwendung zumindest eines Teils oder nur eines Teils der in der Antwortnachricht enthaltenden Daten zugegriffen wird.

Der Begriff "zentral" kann hier bedeuten, dass eine Datenverarbeitungsanlage bzw. mehrere Datenverarbeitungsanlagen, auch Serverfarm genannt, für eine Vielzahl von anderen DV-Anlagen einen Dienst erbringt.
Die Formatwandlung spiegelt wieder, dass auf eine Vielzahl unterschiedlicher Quellen mit unterschiedlichen Formaten zugegriffen werden kann. Insbesondere mit Formaten, die erst nach der Festlegung der Datenfelder in der Antwortnachricht festgelegt werden und ohne Berücksichtigung dieser Datenfelder und der für diese Datenfelder festgelegten Formate. Die Dienstnutzer benötigen aber einheitliche und vorher festgelegte Formate.
Beim Erzeugen der Antwortnachricht kann auch auf bereits gespeicherte Daten zugegriffen werden, insbesondere die allgemeinen Daten, die sich nicht oft ändern. Typischerweise werden jedoch nicht alle Daten in der zentralen DV-Anlage oder einer DV-Anlage vorgehalten, insbesondere nicht die sich schnell ändernden Daten, die oft auch noch vergleichsweise neu sind, z.B. erst seit einer Zeitpanne bekannt sind, die weniger als 30 Minuten beträgt. Die ermittelten Daten können aber mit zuvor in einem Repositorium bzw. einer entsprechenden Datenbank gespeicherten Daten verglichen werden, wobei bspw. Abweichungen vermerkt werden können. Alternativ werden die ermittelten Daten für einen späteren Vergleich gespeichert.
Demgemäß kann der Zugriff auf die zweite DV-Anlage und auf die dritte DV-Anlage auch bereits vor dem Erzeugen der Anforderungsnachricht erfolgt sein.
Die Daten werden von der zentralen DV-Anlage insbesondere aus dem Internet geholt, Data mining, Text mining, social media, d.h. digitale soziale Netzwerke, z.B. Facebook, oder themenspezifische und/oder lokale soziale Netzwerke, etc. Alternativ können auch Firmendaten verwendet werden, insbesondere nach Klärung der Zugriffsberechtigung.
Ein Datenübertragungsnetz zwischen der zentralen DV-Anlage und der zweiten DV-Anlage sowie zwischen der zentralen DV-Anlage und der dritten DV-Anlage kann insbesondere verschieden von einem Bussystem und/oder einer Backplane sein. Ggf. können aber auch Hochgeschwindigkeits-Datenübertragungsnetze verwendet werden, die bspw. 10 Mal schneller als Datenübertragungsnetze zwischen der mobilen DV-Anlage und der zentralen DV-Anlage sind.
Insbesondere müssen die zweite DV-Anlage und die dritte DV-Anlage beim Festlegen nicht bekannt sein und können auch andere Formate unterstützen als in der Antwortnachricht benötigt, insbesondere Formate, die beim Festlegen eines Datenmodells noch nicht bekannt waren. Eine nachträgliche Formatwandlung auf das festgelegte Format kann durchgeführt werden.
Nur ein Teil der in der Antwortnachricht enthaltenden Daten wird insbesondere dann verwendet, wenn die Anforderungsnachricht nicht speziell für das Anwendungsprogramm entworfen worden ist, sondern für eine Vielzahl von verschiedenen Anwendungsprogrammen, die ähnliche Anforderungen an die benötigten Daten haben, bspw. Daten mit Kontextbezug.
Die zentrale DV-Anlage und/oder die zweite DV-Anlage und/oder die dritte DV-Anlage nutzen ihrerseits bspw.:

– RSS Feeds (Rich Site Summary, Really Simple Syndication),
– Programme, die im Internet automatisch nach Daten suchen, d.h. Crawler oder sogenannte Softwareagenten basierte Systeme.

Insbesondere bei mobilen DV-Anlagen treten häufig Änderungen von Daten auf, die für Anwendungsprogramme relevant sein können. Bspw. kann sich einer der folgenden Kontexte ändern:

– der Rollenkontext in dem der Nutzer die mobile Datenverarbeitungsanlage nutzt, z.B. Geschäft oder privat,
– der räumliche Kontext, in dem das mobile Gerät auf Grund seiner aktuellen Position und/oder Ausrichtung benutzt wird.

Die Verfahren können aber auch bei stationären DV-Anlagen eingesetzt werden, die bspw. sowohl im Rahmen eines Heim-Arbeitsplatzes als auch privat genutzt werden.
Die technische Wirkung des Verfahrens besteht darin, dass insbesondere auf Kontextdaten so auf einfache Art zugegriffen werden kann, insbesondere auf Kontextdaten, die sich schnell ändern. Weiterhin bietet das Verfahren die Möglichkeit, die angeforderte Datenmenge durch die Angabe von zusätzlichen Daten in der Anforderungsnachricht einzuschränken, insbesondere durch Angabe eines Auswahldatums, was unten näher erläutert wird.
Das vorgeschlagene Verfahren bzw. der vorgeschlagene Dienst kann dann auf effiziente Weise implementiert und erbracht werden, wenn zuvor Datenstrukturen und Datenformate festgelegt worden sind, wobei eine Strukturierung der Daten durchgeführt werden kann, die stärker und umfangreicher ist, als bei einer Realisierungen des Dienstes, die nur auf ein Anwendungsprogramm bezogen ist.
Deshalb werden bei einer Ausgestaltung vor dem Übertragen der Anforderungsnachricht und/oder vor dem Erstellen des Diensterbringungsprogramms Datenfelder und Datenformate für Daten festgelegt werden, die von der zentralen DV-Anlage angefordert werden können. Auch die Formatumwandlung oder die Formatumwandlungen können gemäß der festgelegten Datenformate festgelegt werden. Insbesondere müssen die zweite DV-Anlage und die dritte DV-Anlage beim Festlegen nicht bekannt sein und sie können auch andere Formate unterstützen als in der Antwortnachricht benötigt.
Für einen in der Antwortnachricht enthaltenen Datensatz können die folgenden Datenfelder oder Datenfeldgruppen festgelegt werden:

– mindestens ein erstes allgemeines Datenfeld oder mindestens eine erste allgemeine Datenfeldgruppe, deren Daten über einen ersten Zeitraum unverändert bleiben,
– mindestens ein zweites allgemeines Datenfeld oder mindestens eine zweite allgemeine Datenfeldgruppe, deren Daten sich im ersten Zeitraum mehrfach ändern,
– mindestens ein spezifisches Datenfeld des Datensatzes oder mindestens eine spezifische Datenfeldgruppe des Datensatzes, die abhängig von dem Datenwert eines in der Anforderungsnachricht enthaltenden Auswahldatums in die Antwortnachricht einbezogen werden.

Vorzugsweise enthält das zweite allgemeine Datenfeld oder die zweite allgemeine Datenfeldgruppe ein erstes Datenfeld oder besteht aus einem ersten Datenfeld, dessen Wert angibt, ob oder welches spezifische Datenfeld oder ob oder welche spezifische Datenfeldgruppe gültig sind, wobei das erste Datenfeld insbesondere ein Auswahldatum enthält.
An Stelle nur einer Antwortnachricht können die Daten des Datensatzes auch auf mehrere Antwortnachrichten für einen Gesamtdatensatz verteilt werden. Insbesondere können auf Grund des Auswahldatums nur die Daten übertragen werden, die relevant sein könnten. So lassen sich kurze Übertragungszeiten unter Verwendung kleiner Netzwerkressourcen realisieren, insbesondere für die Zwischenspeicherung und für die Weiterleitung der Daten.
Der Datensatz kann Umstände und/oder eine Situation angeben, unter deren Berücksichtigung das Programm bzw. das Anwendungsprogramm ausgeführt werden soll. Das Auswahldatum kann abhängig von der aktuellen Rolle einer Person oder eines Gegenstands die für diese Rolle festgelegten spezifische(n) Datenfelder oder Datenfeldgruppe des Datensatzes angeben.
Die Rolle ist z.B. unterteilt in:

– privat, Geschäft,
– Geschäft 1, Geschäft 2,
– Service Techniker, Experte für Bauteile,
– unteres Management, mittleres Management, oberes Management, oder
– Qualifikation: hoch, mittel, gering.

Im Zusammenhang mit einer Rolle kann auch von einem Profil gesprochen werden. Durch die Verwendung einer Rolle bzw. eines Profils wird in den Kontext ein weiterer veränderbarer Parameter eingeführt, der es gestattet, neue Dienste oder bereits bekannte Dienste auf bessere Art und Weise zu erbringen als bisher, insbesondere kontextsensitive Dienste, die auch von anderen variablen Parametern abhängen, z.B. Ort und Zeit. Insbesondere wird durch das Auswahldatum bzw. die Rolle erreicht, dass Daten auch eingeschränkt, selektiert bzw. gefiltert werden können. Dies erhöht den Nutzen eines Dienstes erheblich, weil der Nutzer nicht mit überflüssigen Daten konfrontiert wird.
Die Anforderungsnachricht kann eine erste Anforderungsnachricht sein und die Antwortnachricht kann eine erste Antwortnachricht sein. Auf der ersten DV-Anlage kann zu einer ersten Zeit ein erstes Auswahldatum auf einen ersten Datenwert festgelegt werden, bspw. manuell durch eine Nutzerauswahl oder automatisch, z.B. auf Grund von anderen Kontextdaten wie Ort oder Zeit. Das Programm, insbesondere ein Anwendungsprogramm auf einem mobilen Gerät, kann abhängig von einem Kennzeichen, insbesondere zum Kennzeichnen des angeforderten Datensatzes, die erste Anforderungsnachricht erzeugen und abhängig vom ersten Datenwert mindestens ein erstes spezifisches Datenfeld in der ersten Antwortnachricht berücksichtigen, das für den ersten Datenwert des Auswahldatums festgelegt worden ist. Auf der ersten DV-Anlage kann dann zu einer zweiten Zeit, die nach der ersten Zeit liegt, ein zweiter Datenwert für das erste Auswahldatum festgelegt werden. Das Programm kann anschließend abhängig von dem Kennzeichen oder abhängig von einem weiteren Kennzeichen, das sich von diesem Kennzeichen unterscheidet, eine zweite Anforderungsnachricht an die zentrale DV-Anlage erzeugen und abhängig vom zweiten Datenwert mindestens ein zweites spezifisches Datenfeld in einer zweiten Antwortnachricht der zentralen DV-Anlage berücksichtigen, das für den zweiten Datenwert festgelegt worden ist. Abhängig von dem zweiten Datenwert kann das erste spezifische Datenfeld nicht in der zweiten Antwortnachricht enthalten sein oder nicht vom Programm berücksichtigt werden, falls es doch in der zweiten Antwortnachricht enthalten ist.
Im Übrigen können die erste Antwortnachricht und die zweite Antwortnachricht die gleichen Datenfelder haben, wobei "im Übrigen" bedeuten kann: abgesehen von den spezifischen Datenfeldern, die durch das Auswahldatum oder durch die Auswahldaten festgelegt sind. Beide Antwortnachrichten können sich insbesondere auf das gleiche Datenmodell beziehen und können bspw. gleiche Grunddatenfelder haben, die unabhängig von einem Auswahldatum sind.
Bei einer Ausgestaltung werden in den Antwortnachrichten nur die spezifischen Datenfelder übertragen, die durch das Auswahldatum ausgewählt sind. Damit wird die Beschaffung der Daten auf die benötigten Daten beschränkt. Nicht benötigte Daten werden nicht beschafft. Auch die benötigten Ressourcen für die Übertragung sind somit gering.
Das Kennzeichen kann einen bestimmten Kontext oder Kontextbesitzer, z.B. eine Person oder einen Gegenstand, kennzeichnen, auf den sich die Anforderungsnachricht bezieht, d.h. eine Instanz bzw. eine bestimmte Sichtweise des ersten Programms oder des zweiten Programms auf die in der Antwortnachricht enthaltenen Daten. Die in der Antwortnachricht enthaltenen Daten können auch einen Datensatz bilden, der durch das Kennzeichen eindeutig bezeichnet ist. Die Daten können auch auf mehrere Antwortnachrichten verteilt werden, insbesondere wenn es zu einer Verzögerung bei der Beschaffung bestimmter Daten kommt.
Die angeforderten Daten können mindestens eines der folgenden Daten enthalten:

– Ort der mobilen DV-Anlage, und/oder
– Daten eines digitalen sozialen Netzwerkes.

Damit lassen sich auf einfache Art ortsabhängige Dienste und/oder Dienste unter Berücksichtigung von Vorlieben, Interessen, Freunden etc. erbringen.
Bei einer Ausgestaltung kann die Anforderungsnachricht ein Kennzeichen des Nutzers der mobilen DV-Anlage enthalten oder ein Kennzeichen der mobilen DV-Anlage. Das Kennzeichen und oder ein daraus ermitteltes Kennzeichen kann an die zweite DV-Anlage und/oder an die dritte DV-Anlage übertragen werden, vorzugsweise auch an die vierte DV-Anlage. Somit können Daten zu diesem Nutzer oder zu diesem mobilen Gerät auf einfache Art zusammengetragen werden, insbesondere kontextabhängige bzw. situationsabhängige Daten.
Bei einer anderen Ausgestaltung kann die Anforderungsnachricht ein Kennzeichen für einen Gegenstand enthalten, für den der Nutzer der mobilen DV-Anlage Daten benötigt. Das Kennzeichen oder ein daraus ermitteltes Kennzeichen kann an die zweite DV-Anlage und/oder an die dritte DV-Anlage übertragen werden, vorzugsweise auch an die vierte DV-Anlage. So lassen sich auf einfache Art Daten zu diesem Gegenstand ermitteln, insbesondere kontextabhängige bzw. situationsabhängige Daten. Das Kennzeichen des Gegenstands kann bspw. ein mit dem mobilen Endgerät, ggf. unter Verwendung einer Zusatzeinrichtung, einfach zu erfassender Barcode, QR-Code (Quick Response) oder ein RFID-(Radio Frequency Identification) Code sein. Bspw. wird der Code abfotografiert und das Kennzeichen mit einer an den Code angepassten Software ermittelt.
Der Zugriff auf die zweite DV-Anlage und/oder auf die dritte DV-Anlage kann gemäß HTTP (Hypertext Transfer Protokoll) erfolgen. HTTP ist das im Internet eingesetzte Übertragungsprotokoll, vgl. entsprechende RFC's (Request for Comment) der IETF (Internet Engineering Task Force). Auch auf die vierte DV-Anlage kann mit HTTP zugriffen werden.
Die mobile DV-Anlage kann eine erste mobile DV-Anlage sein. Das Verfahren kann weiter enthalten:

– Übertragen einer zweiten Anforderungsnachricht für Daten von einer zweiten mobilen DV-Anlage zu der zentralen DV-Anlage,
– vorzugsweise in der zentralen DV-Anlage oder in einer weiteren DV-Anlage Bearbeiten der zweiten Anforderungsnachricht und Erzeugen einer zugehörigen zweiten Antwortnachricht, wobei Daten gemäß der zweiten Anforderungsnachricht von dem Diensterbringungsprogramm zumindest von der zweiten DV-Anlage und/oder von der dritten DV-Anlage angefordert werden, und wobei für die von der zweiten DV-Anlage und/oder die von der dritten DV-Anlage empfangenen Daten eine Formatumwandlung durchgeführt wird,
– Übertragen der zweiten Antwortnachricht von der zentralen DV-Anlage zu der zweiten DV-Anlage,
– in der zweiten mobilen DV-Anlage Verwenden von in der zweiten Antwortnachricht enthaltenen Daten zur Erbringung eines Dienstes durch ein zweites Programm, vorzugsweise ein Anwendungsprogramm, wobei das zweite Programm gleich dem ersten Programm ist oder wobei das zweite Programm verschieden vom ersten Programm ist, und wobei auf mindestens eine vierte DV-Anlage unter Verwendung zumindest eines Teils oder nur eines Teils der in der zweiten Antwortnachricht enthaltenden Daten zugegriffen wird.

Ggf. greifen weitere mobile DV-Anlagen auf die zentrale DV-Anlage zu, z.B. mehr als 10 Tausend mehr als 100 Tausend am Tag. Dabei können eine Vielzahl verschiedener Anwendungsprogramme verwendeten werden, z.B. mehr als 10 oder mehr als 50 verschiedene Anwendungsprogramme je nach Verbreitung des Dienstes.
Für die zweite Antwortnachricht können die gleichen Ausführungen wie für die erste Antwortnachricht gelten, insbesondere auch bei unterschiedlichen Anwendungsprogrammen. Insbesondere können voneinander verschiedene Kennzeichen für Benutzer, mobile Endgeräte und/oder Gegenstände in der ersten DV-Anlage und in der zweiten DV-Anlage genutzt werden.
Das zweite Programm kann das gleiche Programm wie das erste Programm sein, z.B. ein Reiseplanungsprogramm oder ein Programm zur Unterstützung der Reparatur oder der Wartung eines Bauteils. Alternativ können das erste Programm und das zweite Programm voneinander verschiedene Programme sein, z.B. ist das erste Programm ein Reiseplanungsprogramm und das zweite Programm ein Programm zur Unterstützung der Reparatur oder der Wartung eines Bauteils.
Bei einer Ausgestaltung ist das zweite Programm verschieden vom ersten Programm und wird zusätzlich zum ersten Programm gleichzeitig mit diesem oder früher oder später auch auf der ersten DV-Anlage ausgeführt. Beispielsweise greifen ein Reiseplanungsprogramm und ein Programm zur Unterstützung der Reparatur oder der Wartung eines Bauteils von der ersten DV-Anlage aus auf dasselbe CIS (Context Integration Service) zu, d.h. auf dasselbe Diensterbringungsprogramm zur Erbringung eines kontextintegrierten Services.
In beiden Fällen, d.h. das zweite Programm wird auf der zweiten DV-Anlage (Datenverarbeitungsanlage) ausgeführt oder das zweite Programm wird auf der ersten DV-Anlage ausgeführt, kann im zweiten Programm dasselbe Datenmodell wie im ersten Programm für den Zugriff auf die zentrale DV-Anlage zu Grunde gelegt werden.
Auf der ersten mobilen DV-Anlage kann ein erstes Auswahldatum auf einen ersten Datenwert festgelegt werden. Auf der zweiten mobilen DV-Anlage kann ein zweites Auswahldatum auf einen zweiten Datenwert festgelegt werden, dessen Wert verschieden vom ersten Datenwert ist. Die erste mobile DV-Anlage kann abhängig von einem ersten Kennzeichen die erste Anforderungsnachricht erzeugen und abhängig vom ersten Datenwert mindestens ein erstes spezifisches Datenfeld in der ersten Antwortnachricht berücksichtigen, das für den ersten Datenwert festgelegt worden ist. Abhängig vom ersten Datenwert kann ein zweites spezifisches Datenfeld nicht in der ersten Antwortnachricht enthalten sein oder nicht vom ersten Programm berücksichtigt werden, falls es doch enthalten ist. Das zweite spezifische Datenfeld kann für den zweiten Datenwert festgelegt worden sein. Die zweite mobile DV-Anlage kann abhängig von dem ersten Kennzeichen oder einem zweiten Kennzeichen, das sich von dem ersten Kennzeichen unterscheidet, die zweite Anforderungsnachricht erzeugen und abhängig vom zweiten Datenwert mindestens ein zweites spezifisches Datenfeld in der zweiten Antwortnachricht berücksichtigen, das für den zweiten Datenwert festgelegt worden ist. Alternativ oder zusätzlich kann abhängig vom zweiten Datenwert das erste spezifische Datenfeld nicht in der zweiten Antwortnachricht enthalten sein oder vom zweiten Programm nicht berücksichtigt werden, falls es doch enthalten ist.
Im Übrigen können die erste Antwortnachricht und die zweite Antwortnachricht die gleichen Datenfelder haben, wobei "im Übrigen" bedeuten kann: abgesehen von den spezifischen Datenfeldern, d.h. nicht vom Auswahldatum abhängigen Datenfeldern. Beide Nachrichten können sich insbesondere auf das gleiche Datenmodell beziehen und können bspw. gleiche Grunddatenfelder haben, die unabhängig von einem Auswahldatum sind. Es kann aber auch auf verschiedene Datenmodelle Bezug genommen werden, bspw. Gegenstand oder Person. Auch eine Unterscheidung zwischen Gegenstand und Person über ein Auswahldatum desselben Datenmodels ist möglich.
Das erste Kennzeichen und/oder das zweite Kennzeichen können einen bestimmten Kontext oder Kontextbesitzer, z.B. Person oder Gegenstand, kennzeichnen, auf den sich die Anforderungsnachricht bezieht, d.h. eine Instanz bzw. eine bestimmte Sichtweise des ersten Programms oder des zweiten Programms auf die in der Antwortnachricht enthaltenen Daten. Die in der zweiten Antwortnachricht enthaltenen Daten können auch einen Datensatz bilden, der durch das Kennzeichen eindeutig bezeichnet ist. Die Daten können auch auf mehrere Antwortnachrichten verteilt werden, insbesondere wenn es zu einer Verzögerung bei der Beschaffung bestimmter Daten kommt.
Bei einer Ausgestaltung werden in den Antwortnachrichten nur die spezifischen Datenfelder übertragen, die durch das Auswahldatum ausgewählt sind. Damit wird die Beschaffung der Daten auf die benötigten Daten beschränkt. Nicht benötigte Daten werden nicht beschafft. Auch die benötigten Ressourcen für die Übertragung sind somit gering.
Der Datensatz kann mindestens zwei Datenfelder oder mindestens zwei Datenfeldgruppen enthalten, die die gleiche Datenstruktur – vorzugsweise mit voneinander verschieden Inhalt – haben, vorzugsweise mindestens eines der folgenden Datenfelder oder mindestens zwei der folgenden Datenfelder und/oder mindestens eine der folgenden Datenfeldgruppen oder mindestens zwei der folgenden Datengruppen:

– ein Datenfeld, dessen Wert die Interessen eines Nutzers angibt,
– ein Datenfeld, dessen Wert die Expertise eines Nutzers angibt,
– ein Datenfeld, das eine von einem Nutzer zu erfüllende Aufgabe angibt,
– ein Datenfeld oder eine Datenfeldgruppe, die den Ort der ersten mobilen DV-Anlage oder der zweiten mobilen DV-Anlage angibt, insbesondere in GPS Koordinaten, eine Postadresse, oder einen Ort in einem Gebäude,
– ein Datenfeld oder eine Datenfeldgruppe, die die Zeit angibt, insbesondere mindestens eine der folgenden Zeiten: ein Datum, eine Zeitzone, eine Startzeit, eine Endzeit, eine Zeitdauer, eine Dringlichkeit, einen Tag, einen Monat, eine Woche, ein Jahr.

Damit ist eine hohe Wiederverwendbarkeit gegeben, so dass sich der vorher erforderliche Aufwand für die Festlegung der Datenstrukturen und der Datenformate besonders lohnt.
Ein Datensatz und/oder ein dem Datensatz zu Grunde liegendes Datenmodell kann mindestens eines der folgenden Datenfelder, mindestens zwei der folgenden Datenfelder oder alle der folgenden Datenfelder enthalten:

– mindestens ein Datenfeld, dessen Wert eine Aktualisierungsperiode angibt, in welchen Abständen sich die Daten des Datensatzes oder die Daten einzelner Datenfelder des Datensatzes ändern,
– mindestens ein Datenfeld, dessen Wert angibt, aus welcher Datenquelle die Daten des Datensatzes oder die Daten einzelner Datenfelder des Datensatzes stammen,
– mindestens ein Datenfeld, dessen Wert angibt, ob die Daten des Datensatzes oder die Daten einzelner Datenfelder des Datensatzes mit einem Archivierungsprogramm archiviert werden sollen,
– mindestens ein Datenfeld, dessen Wert angibt, ob die Daten des Datensatzes oder die Daten einzelner Datenfelder des Datensatzes nur für Nutzer oder nur für Gegenstände bzw. Objekte gelten, die durch die Daten beschrieben werden.

Weil diese Daten andere Daten beschreiben, können sie auch als Metadaten bezeichnet werden. Metadaten können eine Voraussetzung für die Erbringung neuer Dienste oder für eine Verbesserung der Erbringung von bereits bekannten Diensten sein.
Die Aktualisierungsperiode kann verwendet werden, um ein Bewertungsmaß für die Aktualität und damit auch der Zuverlässigkeit der anderen Daten zu erhalten.
Die Quelle der Daten kann z.B. ein Sensor, eine Nutzereingabe, das Internet usw. sein. Diese Angabe kann z.B. zum Bewerten der Richtigkeit bzw. der Zuverlässigkeit der Daten verwendet werden, d.h. zur Bestimmung eines Fehlermaßes.
Die Archivierung der Daten kann für Anwendungsprogramme relevant sein, welche die Historie von Daten benötigen.
Durch das Datenfeld, das die Relevanz von Datenfeldern des Datensatzes bzw. des Datensatzes nur für Nutzer oder nur für Objekte beschreibt, kann auf einfache Art erreicht werden, dass gleiche Datenstrukturen sowohl für Nutzer als auch für Objekte genutzt werden können. Die Nutzer können Nutzer einer DV-Anlage sein oder andere Personen. Die Objekte können z.B. Produkte sein, wie Transportmittel (Auto, Flugzeug, Bahn usw.), Teile eines Transportmittels (Motor, Rad, Fahrgestell), aber auch die mobile DV-Anlage selbst.
Das Programm kann ein Anwendungsprogramm sein, vorzugsweise ein Anwendungsprogramm, welches eine Reiseplanung und/oder eine Reisedurchführung unterstützt. Alternativ ist das Programm ein Anwendungsprogramm, das die Wartung und/oder die Reparatur einer technischen Vorrichtung unterstützt. Derartige Programme sind dann besonders nutzbringend, wenn möglichst viele Daten bei der Diensterbringung genutzt werden, wobei der Nutzer aber vor einer Datenflut zu bewahren ist, was hier durch das Auswahldatum erreicht wird.
Bei einer Ausgestaltung ist ein in einem Datenmodell festgelegter Eigentümer eines zu erzeugenden Datensatzes ein Servicetechniker. Die allgemeine Datenfeldgruppe kann mindestens eines, mindestens zwei oder alle der folgenden Datenfelder oder Datenfeldgruppen enthalten:

– mindestens ein Datenfeld oder eine Datenfeldgruppe zur Angabe einer Serviceauftragsnummer,
– mindestens ein Datenfeld oder eine Datenfeldgruppe einer Gegenstandsnummer,
– mindestens ein Datenfeld oder eine Datenfeldgruppe zur Angabe einer Fehlerbeschreibung,
– mindestens ein Datenfeld oder eine Datenfeldgruppe zur Angabe der Historie des Gegenstands,
– mindestens ein Datenfeld oder eine Datenfeldgruppe zur Angebe der Relation zu anderen Komponenten,
– mindestens ein Datenfeld oder eine Datenfeldgruppe zur Angabe einer Wartungsanleitung und/oder einer Empfehlung,
– mindestens ein Datenfeld oder eine Datenfeldgruppe zur Angabe einer Fehlermeldung oder mehrerer Fehlermeldungen,
– mindestens ein Datenfeld oder eine Datenfeldgruppe zur Angabe aktueller Informationen des Herstellers des Gegenstandes,
– mindestens ein Datenfeld oder eine Datenfeldgruppe zur Angabe von Empfehlungen des Herstellers,
– mindestens ein Datenfeld oder eine Datenfeldgruppe zur Angabe der Rolle des Servicetechnikers, vorzugsweise Rang und/oder Fachgebiet, und/oder
– mindestens ein Datenfeld oder eine Datenfeldgruppe zur Angabe mindestens eines digitalen Netzwerkes in das der Servicetechniker eingebunden ist.

Alternativ kann es auch andere Anwendungen geben, z.B. Reise, siehe oben, insbesondere unter Verwendung eines Geschäfts- oder Businessprofils. Zwei wichtige Rollen jedes Nutzers sind bspw. Privatperson und Geschäftsperson, wobei auch mehrere Geschäftsrollen übernommen werden können, z.B. Haupterwerb und Nebenerwerb usw. Für jedes Geschäft können dann separate spezifische Daten verwendet werden.
Der Datensatz und/oder das Diensterbringungsprogramm kann ein vorgegebenes Datenmodell erfüllen, das bspw. über eine Datenmodellbeschreibungssprache bekannt gemacht und bspw. für Testzwecke einer Implementierung verteilt wird. Das Datenmodell kann mindestens ein, mindestens zwei oder alle der folgenden Elemente enthalten:

– mindestens ein Datenfeld zur Angabe eines "Eigentümers" des Datensatzes, insbesondere des Namens oder des Kennzeichens eines Nutzers einer DV-Anlage, oder eines Gegenstands, über den der Datensatz Daten enthält, insbesondere eines technischen Gegenstands und/oder eines Ersatzteils,
– mindestens eine allgemeine Datenfeldgruppe, die folgende Datenfelder oder Datenfeldgruppen enthält:
– mindestens ein Datenfeld oder mindestens eine Datenfeldgruppe mit Angaben, die über eine erste Zeitdauer gleich bleiben, insbesondere ein Geburtsdatum oder ein Herstellungsdatum, ein Geschlecht, ein Bautyp, und/oder eine Privatadresse,
– mindestens ein Datenfeld oder mindestens eine Datenfeldgruppe mit Angaben, die sich innerhalb der ersten Zeitdauer mehrfach ändern, insbesondere ein vorübergehender Zustand, eine Aufgabe, eine Ort einer Person oder eines Gegenstandes und/oder eine Rolle, vorzugsweise eine Rolle die ein Nutzer oder der Gegenstand einnimmt, z.B. Angestellter, Mitarbeiter, Vorgesetzter, o.ä.,
– mindestens ein spezifisches Datenfeld oder eine spezifische Datenfeldgruppe oder mindestens zwei spezifische Datenfelder oder mindestens zwei spezifische Datenfeldgruppen, die für eine Rolle eines Nutzers oder die Rolle eines Gegenstandes relevante Daten enthält, insbesondere ein Datenfeld, das das Interesse, z.B. Servicemanagement, einer Person angibt, ein Datenfeld, das die Expertise einer Person angibt, ein Datenfeld oder eine Datenfeldgruppe, die die Firmenadresse eines Nutzers angibt, ein Datenfeld oder eine Datenfeldgruppe, die die Beziehung zu anderen Personen oder Gegenständen angibt, z.B. Kollegen.

Die erste Zeitdauer kann mindestens ein Monat sein, mindestens ein Jahr oder es kann sich sogar um unveränderliche Daten handeln. Der Gegenstand kann insbesondere ungleich einer DV-Anlage sein oder mit der ersten DV-Anlage oder der zweiten DV-Anlage übereinstimmen.
Das Datenmodell kann insbesondere in den Befehlen, z.B. Maschinencode, des Diensterbringungsprogramm und/oder des Programms auf der mobilen DV-Anlage berücksichtigt sein, um eine definierte Datenschnittstelle zwischen der zentralen DV-Anlage und den mobilen DV-Anlagen bzw. Endgeräten zur Verfügung zu stellen, bzw. den auf diesen Geräten ausgeführten Anwendungsprogrammen.
Es können mindestens zwei oder alle der folgenden Beziehungen festgelegt sein:

– eine Beziehung zwischen dem Datenfeld zur Angabe des Eigentümers und der allgemeinen Datenfeldgruppe, wobei vorzugsweise ein Datenfeld zur Angabe des Eigentümers einer oder mehreren allgemeinen Datenfeldgruppen zugeordnet sein kann,
– und/oder wobei eine allgemeine Datenfeldgruppe einem oder mehreren Datenfeldern zur Angabe eines Eigentümers zugeordnet sein kann,
– eine Beziehung zwischen dem Datenfeld oder der Datenfeldgruppe zur Angabe der Rolle und den spezifischen Datenfeldern oder der spezifischen Datenfeldgruppe, wobei vorzugsweise ein Datenfeld oder eine Datenfeldgruppe zur Angabe der Rolle einem oder mehreren spezifischen Datenfeldern oder spezifischen Datenfeldgruppen zugeordnet werden kann, und/oder
– wobei ein spezifisches Datenfeld oder eine spezifische Datenfeldgruppe genau einem Datenfeld oder genau einer Datenfeldgruppe zur Angabe der Rolle zugeordnet werden muss.

Beim Festlegen der Beziehungen wird auf Einhaltung der Normalformen geachtet, insbesondere der ersten bis dritten Normalform, um Redundanz zu vermeiden. Weiterhin kann durch Beachten der Normalformen ein geringer Speicherplatz erforderlich sein, eine hohe Konsistenz kann einfach einzuhalten sein und das Löschen von Daten kann leicht und selektiv möglich sein ohne das Widersprüche entstehen.
Das Diensterbringungsprogramm kann die Antwortnachricht oder nur einen Teil der Antwortnachricht in einer Datenbank speichern, wobei der Teil insbesondere durch mindestens ein Archivierungsdatum festgelegt ist.
Durch diese Speicherung ist eine Historienbetrachtung möglich, insbesondere in Anwendungsprogrammen. So kann bspw. festgestellt werden, welche Daten früher relevant waren, falls zu aktuellen Daten keine sinnvollen Ausgaben durch das Anwendungsprogramm auf der mobilen DV-Anlage erzeugt werden können, d.h. es wird versucht, den Dienst dennoch auf der Grundlage älterer Daten zu erbringen.
Es kann zur Speicherung bzw. zur Archivierung eine elektronische Datenbank (Repository) verwendet werden, insbesondere eine in einem Verfahren nach einem der vorhergehenden Ansprüche verwendete Datenbank. Die Datenbank kann Datensätze enthalten, die ihrerseits mit den folgenden Datenfeldern oder Datenfeldgruppen gespeichert werden:

– mindestens ein erstes allgemeines Datenfeld oder mindestens eine erste allgemeine Datenfeldgruppe, deren Daten über einen ersten Zeitraum unverändert bleiben,
– mindestens ein zweites allgemeines Datenfeld oder mindestens eine zweite allgemeine Datenfeldgruppe, deren Daten sich im ersten Zeitraum mehrfach ändern,
– wobei vorzugsweise das zweite allgemeine Datenfeld oder die zweite allgemeine Datenfeldgruppe ein erstes Datenfeld enthält oder aus einem ersten Datenfeld besteht, dessen Wert angibt, ob oder welches spezifische Datenfeld oder ob oder welche spezifische Datenfeldgruppe gültig sind.

Bei einer Ausgestaltung der Datenbank ist das Datenmodell ein relationales Datenmodell, dessen Beziehungen zwischen Datenteilmodellen in der Datenbank hinterlegt sind, und wobei die hinterlegten Beziehungen zur Prüfung der Konsistenz der Datensätze verwendet werden.
Die oben genannte Aufgabe wird bezüglich der DV-Anlage bzw. bezüglich des Verbunds durch eine zentrale DV-Anlage oder einen zentralen DV-Anlagen-Verbund gelöst, die bzw. der die folgenden Einheiten enthält:

– eine Empfangseinheit zum Empfangen einer Anforderungsnachricht,
– eine Bearbeitungseinheit oder eine Bearbeitungseinheit in einer weiteren DV-Anlage zum Bearbeiten der Anforderungsnachricht und zum Erzeugen einer zugehörigen Antwortnachricht, wobei Daten gemäß der Anforderungsnachricht von einem Diensterbringungsprogramm zumindest von einer zweiten DV-Anlage und/oder von einer dritten DV-Anlage angefordert werden, und wobei für die von der zweiten DV-Anlage und/oder die von der dritten DV-Anlage empfangenen Daten eine Formatumwandlung durchgeführt wird, und
– eine Sendeeinheit zum Senden der Antwortnachricht.

Damit handelt es sich bei der DV-Anlage bzw. dem DV-Anlagenverbund um einen CIS-Rechner (Context Integration Service) bzw. um einen Diensterbringungsrechner, der Kontext integriert. Es gelten die oben genannten technischen Wirkungen. Insbesondere kann die DV-Anlage oder der DV-Anlagen-Verbund nur Einheiten zur Durchführung eines oder einiger der oben für das Diensterbringungsprogramm genannten Verfahrensschritte enthalten. Auch ein zugehöriges Programm ist geschützt und kann beansprucht werden.
Bei einer Ausgestaltung ist auch die mobile DV-Anlage geschützt, insbesondere mit dem darauf installierten Anwendungsprogramm. Insbesondere kann die mobile DV-Anlage nur Einheiten zur Durchführung eines oder einiger der oben für die mobile DV-Anlage genannten Verfahrensschritte enthalten. Es gelten wieder die oben genannten technischen Wirkungen.
Mit anderen Worten ausgedrückt, wird auch ein Metadatenmodell zur Kontextdatenmodellierung als Grundlage eines generischen Context Integration Services erläutert. Die Ansprüche beziehen sich jedoch insbesondere auf die technische Realisierung in einer Datenverarbeitungsanlage, insbesondere auf Nachrichten, die Datensätze enthalten, die als Instanzen des Datenmodells bzw. Teilinstanzen von Teilmodellen des Datenmodells angesehen werden können oder auf in einem Speicher gespeicherte Datensätze, d.h. Instanzen, die die Datenmodelle berücksichtigen.
Die Informations- und Datenmenge wächst exponentiell. Immer mehr digital verfügbare Informationen und Services, physische Produkte und Verkaufseinrichtungen (z.B. Restaurants) stehen dem Nutzer permanent zur Verfügung. Gleichzeitig möchte der Nutzer in verschiedenen, zunehmend mobilen Situationen nur die Informationen und Dienste angezeigt bekommen, die für ihn in seinem Kontext relevant sind, das heißt in seiner Situation, seiner Rolle, Absicht, etc.
Die Einschränkung der angebotenen Informationen wird durch eine intelligente Filterung erreicht. Um bei der Filterung die Relevanz aus Sicht des Nutzers zu berücksichtigen, wird z.B. der Kontext des Nutzers verwendet.
Folgende Anwendungen und Szenarien werden in Zukunft vorwiegend kontextbasiert Informationen bereitstellen und verarbeiten:

– Buchungssysteme, z.B. übergreifende Buchung einer Reise über verschiedene Verkehrsträger wie Auto, Bahn, Bus hinweg,
– Location based Services, z.B. zeige mir alle Restaurant in der Nähe meines Standortes, die meinen Interessen entsprechen,
– Einkaufsempfehlungen, z.B. Empfehlung von Produkten in einem Internet-Shop,
– Question Answering Systeme, z.B. Auskunftssysteme wie Siri von Apple,
– Knowledge Management Systeme, z.B. ein Servicetechniker möchte alle relevanten Informationen zu einem Bauteil finden.

Heutige Systeme, z.B. Applikationen, Suchservices, Location based Services, haben das Problem, dass der Kontext des Nutzers:

a) nicht oder nur teilweise berücksichtigt wird, z.B. wird häufig nur der Standort ermittelt,
b) es keine übergreifende Kontext-Datenmodelle oder Datenstandards gibt, die eine Wiederverwendung von Kontextinformationen ermöglichen, und
c) für jede Applikation/Service/Suche separat erfasst wird und es keine Ansätze zur Nutzung von extern gespeicherten Kontextdaten gibt.

Damit fehlt dem Nutzer langfristig die Möglichkeit:

a) seinen Kontextdaten selbst zu erzeugen, zu speichern und zu aktualisieren,
b) verschiedene Kontextdaten bedarfsweise zu integrieren,
c) einmal eingegebene Kontextdaten, z.B. Präferenzen, von einer Applikation bzw. Anwendung für eine Wiederverwendung übergreifend zu speichern und anderen Applikationen zur Verfügung zu stellen.

Technisch können die Kontextdaten in einem eigenen Service, einem Context Integration Service (CIS) bzw. kontextintegrierenden Service bzw. einer kontextintegrierenden Diensterbringung über die Context Integration Architektur zusammengeführt werden, siehe den in der dargestellten Überblick. Der CIS bündelt diverse verfügbare Kontextdaten und bietet sie Applikationen an, so dass diese nur die aktuellen, für den Nutzer relevanten Daten anzeigen.
Die Herausforderung für diesen Context Integration Service (CIS) liegt nun darin, dass Kontextdaten aus verschiedenen Quellen in unterschiedlichen Formaten gebündelt werden müssen.
Neben dieser technischen Integration sollte auch schon auf Konzeptionsebene definiert werden, welche Kontextdaten in einem gewissen Anwendungsfall relevant sind. Aus diesem Grund kann es erforderlich sein, ein übergreifendes logisches Meta-Modell für Kontextdaten zu definieren, so dass sowohl Business Experten als auch IT (Informationstechnologie) Experten für ihre Szenarien Kontextdatenmodelle erstellen können. Der Begriff "logisch" bezieht sich hier zunächst auf ein Datenmodell, das zunächst unabhängig von einer Implementierung ist. Der Begriff "Meta" bezieht sich hier zunächst auf ein Datenmodell, das als Grundlage für konkrete bzw. implementierte Datenmodelle dient.
Um einen integrierten, modellierungsgetriebenen Entwicklungsansatz zu unterstützen, sollte ein plattformunabhängiges Kontext-Datenmodell zudem mit existierenden logischen Datenmodellen verknüpft werden können, z.B. Daten über einen Reisenden, ein Bauteil, d.h. z.B. in Verbindung mit einem DIS (Data Integration Service), siehe 1.
Aktuell ist kein Service bekannt, der Kontextdaten aus verschiedenen Quellen bezieht und diese Daten zentral anderen Applikationen zur Filterung von Daten zur Verfügung stellt. Ein Überblick ist zu finden in Henricksen, K., Indulska, J., and Rakotonirainy, A., "Modeling context information in pervasive computing systems". 1st International Conference on Pervasive Computing (Pervasive), Band 2414 der Lectures Notes in Computer Science, Springer, 2002.
Es gibt verschiedene Ansätze, um technische Kontextinstanzen zu definieren, zum Beispiel Ontologien oder Key-Value Paare, d.h. Schlüssel oder Bezeichner und Wert. Eine Übersicht über die Ansätze findet man in Strang, T., Linnhoff-Popien, C., "A Context Modeling Survey", Workshop on Advanced Context Modelling, Reasoning and Management, UbiComp 2004 – The Sixth International Conference on Ubiquitous Computing, Nottingham/England, 2004.
Für die logische Modellierung von Daten im Allgemeinen bietet sich zwar UML (Unified Markup Language) als objekt-orientierte Sprache an, jedoch ist diese Notation für IT Anwender gedacht und nicht für Business Experten und hat zudem keine Vorgaben bezüglich der Modellierung von Kontextdaten.
Die Context Modeling Language (CML) ermöglicht zwar speziell das Design von Kontextdaten, es findet jedoch keine Verknüpfung zu logischen Datenmodellen statt. Außerdem sind auch hier Software Engineers (Ingenieure) die Anwender, für Business Anwender ist die Notation nicht geeignet.
Industrielösungen wie Google Places fokussieren sich auf die technische Repräsentation von Kontext in Form eines vordefinierten Schemas, die konzeptuelle Modellierungsebene wird nicht betrachtet.
Für die Modellierung von Kontextdaten wird das Konzept eines logischen Metadatenmodells eingeführt. Das Konzept spezifiziert, dass einem "Context Owner" bzw. einem "Kontexteigentümer", z.B. einem Objekt bzw. Gegenstand oder einer Person, Kontextinformationen zugeordnet werden. Diese Kontextinformationen können in zwei Kategorien aufgeteilt werden:

1) Bei den allgemeinen Einstellungen bzw. den sogenannten "General Settings", handelt es sich um meist statische Kontextinformationen, wie z.B. – das Geburtsdatum einer Person oder das – Gewicht eines Objektes. Profildaten beinhalten meist Teile dieser allgemeinen Einstellungen.
2) Zustände bzw. sogenannte "States" unterscheiden sich dadurch, dass sie sich dynamisch ändern können, z.B. – der aktuelle Aufenthaltsort einer Person oder eines Gegenstands.

Die Summe aller Zustände beschreibt die aktuelle Situation des Context Owners. Ein Spezialfall ist hierbei die Rolle des Context Owners. Abhängig von ihr können zusätzliche rollenspezifische Informationen herangezogen werden.
Ein Überblick über diese Kategorien des Metadatenmodells findet sich in der , in der Kategorien des Kontext Metadatenmodells dargestellt sind.
Jede dieser Kategorien kann nun durch die Business Experten bzw. aus Sicht von Geschäftsprozessen festgelegt werden, d.h. für jeden Context Owner, z.B. Person, können nun die General Settings, States und Role Specific Settings festgelegt werden. Bei Kontextdaten kann es sich um atomare, z.B. eine Aufgabe, oder um zusammengesetzte Kontextinformationen, z.B. eine Adresse, handeln.
Ein Context Domain Cluster stellt dabei ein thematisches Bündel an Kontextinformationen dar. So beinhaltet z.B. die Domäne "Location" die Postadresse, lokale Adresse (wie Gebäudenummer, Stockwerk), und GPS (Global Positioning System) Koordinaten. Auf Ebene des Metadatenmodells können jegliche Cluster wieder verwendet werden, d.h. der Aufbau einer Adresse kann z.B. bei den General Settings (z.B. Privatadresse) aber auch bei den States bzw. Zuständen, z.B. aktueller Aufenthaltsort, oder den Role Specific Settings, z.B. Firmenadresse bei der Rolle Mitarbeiter, referenziert werden.
Ein Beispiel für ein ausgeprägtes Kontext-Metadatenmodell zeigt die , in der ein Metadatenmodell für einen Mitarbeiter Mr. X dargestellt ist.
Beispiele für insbesondere wieder verwendbare oder zumindest teilweise wieder verwendbare Kontext Cluster des Metadatenmodells sind:

– Interesse,
– Expertise:
– Gebiet,
– Grad,
– Aufgabe,
– Ort,
– GPS Koordinaten,
– Postadresse: Straße, Hausnummer, Postleitzahl, Stadt, Bundesland, Land, Kontinent,
– lokale Adresse: Gebäude, Flur, Raumnummer.
– Zeit,
– Datum, Zeitzone, Anfangszeit, Endzeit, Dauer, Dringlichkeit, Monat.

Jedes Kontextdatum kann dabei alle oder einige der folgenden Metadaten tragen:

– Aktualisierungsperiode: In welchen Abständen ändern sich die Kontextdaten? Diese Information ist besonders relevant für die Applikationen, die aktuelle Informationen benötigen. Gleichzeitig kann mit diesem Attribut festgelegt werden, dass sich ein Kontextdatum niemals ändert, d.h. statisch ist, wie z.B. das Geburtsdatum einer Person.
– Quelle bzw. "Source": Woher stammt dieses Kontextdatum?
– Archivierungsrelevanz: Sollte dieses Kontextdatum archiviert werden?
– Besitzerrelevanz: Ist dieses Kontextdatum relevant für jeden Kontextdatenbesitzer (standard) oder es beschränkt auf spezifische Kontextdatenbesitzer, z.B. Personen oder Objekte.

Als Notation für diese Metadatenmodellierung kann die Siemens BOT (Business Object Types) Methodik oder eine entsprechende Methodik einer anderen Firma verwendet werden, sowie ggf. ein durch ein UML (Unified Markup Language) Profil angepasstes UML Klassendiagramm. Die Siemens BOT Methodik bietet die durch das Business getriebene Datenmodellierung von Geschäftsobjekten (Business Objekts) auf einer logischen Ebene an.
Als weitere Möglichkeit der Abbildung des Metadatenmodells bietet sich die Verwendung einer Ontologie an. In allen Fällen wird durch die Notation eine direkte Verknüpfung mit der Datenmodellierung ermöglicht, z.B. des Kontextdatenbesitzers bzw. des Context Owners.
Ein logisches Kontextdatenmodell ist die Grundlage für einen Context Integration Service, aber auch vor allem für die einheitliche und übergreifende Verwendung von Kontextdaten in kontextsensitiven Applikationen.
Aktuell gibt es kein Metadatenmodell für die Modellierung von Kontextdaten, das die folgenden Anforderungen realisiert:

– logische, plattformunabhängige Modellierung von Kontext als Grundlage für die technische Implementierung,
– integriertes Modellieren von Daten und Kontextdaten, und
– benutzerfreundliche Datenmodellierung durch Business Experten.

Mit Hilfe dieses Metadatenmodells können jegliche Kontextdaten definiert werden. Gleichzeitig bildet es die Grundlage für einen kontextintegrierenden Service bzw. einen Context Integration Service (CIS), der verschiedene Kontextdaten bündelt und aggregiert bzw. gebündelt verschiedenen Applikationen zur Verfügung stellt, die somit kontextspezifisch Daten ihren Nutzern anbieten können.
Szenario 1: Intermodale Reisebuchung und Reisedurchführung
Ein Geschäftsreisender möchte unter Einbeziehungen seiner Präferenzen von München-Umgebung nach Köln-Umgebung reisen. Als Hauptverkehrsmittel nutzt er die Bahn. Für die halbstündige Fahrt zum Bahnhof nutzt er z.B. den Car Sharing Anbieter DriveNow, falls zurzeit ein Fahrzeug in der Nähe seines Wohnortes vorhanden ist und es ausreichend Parkplätze im Parkhaus am Bahnhof in der Nähe des Bahnsteiges gibt. Nach der Bahnreise nutzt er einen anderen, regionalen Car Sharing Anbieter, z.B. DB (Deutsche Bahn) Flinkster, für eine Fahrt von bspw. 50 km und benötigt bspw. am Zielort eine Schnellladesäule.
Er möchte:

– seine Reise verkehrsmittelübergreifend, d.h. z.B. Taxi, Bahn, E-Car, buchen und bezahlen,
– auf der Fahrt Daten bekommen, die für seine Fahrt notwendig/erwünscht sind, z.B.:
– Park & Ride Angebote,
– Ladesäulen mit Schnellladefunktion und deren Auslastung,
– mit ihm reisende Kollegen zur Bildung von Fahrgemeinschaften,
– Verspätungen, Staus und Events, die zu Staus führen können,
– Auslastung von Strecken.

Er ist an personalisierten Sonderangeboten im Bahnhofsbereich interessiert und möchte personalisierte Restaurantempfehlungen.
Folgende Probleme treten auf:

– Buchung: Übergreifende Buchungsmöglichkeiten werden derzeit nicht angeboten, so dass der Reisende sich bei den verschiedenen Portalen, z.B. Taxi, Car Sharing, Bahn, ggf. Bus, mit seinen umfangreichen Daten wie z.B. den Präferenzen und der Route separat anmelden muss.
– Auf der Reise: Nach der Buchung müssen die Daten den Auskunftsservices zur Verfügung gestellt werden, z.B. Online Navigation mit Routen und Stauberechnung, Echtzeit-Information der öffentlichen Verkehrsmittel, Assistenzdienste am Bahnhof, damit die erforderlichen Informationen abgerufen werden können.
– Geschäfte im Bahnhofsbereich haben keine Möglichkeit, personalisierte Sonderangebote oder Restaurantempfehlungen zu geben, da der Nutzer mit seinen Präferenzen nicht sichtbar ist.

Beispieldaten: Kontextdaten für einen Geschäftsreisenden
Allgemein (general):

– Vorname: Max,
– Nachname: Muster,
– Stadt: München,
– Straße: An der Isar 3,
– Firma: Siemens,
– Mobilfunknummer: +1234567.

Business Profil ohne Gepäck:

– Gültigkeit des Profils von 6 bis 22 Uhr, Montag bis Freitag,
– Präferenz: Schnelle Umsteigezeit, nicht gehbehindert,
– Präferenz: Großraum, Arbeit, Handyunterstützung, Leselicht,
– Wagenklasse: 1. Klasse,
– Bistronutzung: ja,
– Gepäck: nein.

Business Profil mit Gepäck

– wie Business Profil,
– Gepäck: ja.

Zahlung bzw. Payment:

– Präferenzzahlung: Paypal,
– Bezahlung1: American Express, Kartennummer XX,
– Bezahlung2: EC-Karte, Kontonummer XY, Bankleitzahl BLZ,
– Bonuscard-Präferenz: Bahnbonus,
– Bonuscard: Miles and More,
– Bonuscard: Air Berlin.

Deutsche Bahn

– Ermäßigung und Rabattkarten: Bahncard 50,
– Klasse: Klasse 2.

Networks:

– Facebook: Ein, d.h. Zugriff auf Facebook-Konto zum Finden von Freunden für Mitfahrgelegenheiten, inkl. Lokalisierung, ist erlaubt,
– Siemens: Ein, d.h. Mitfahrgelegenheiten für Siemens Mitarbeiter sind erlaubt.

Car Sharing:

– DriveNow: XA (Kundennummer),
– Flinkster: XB (Kundennummer),
– Cart2Go: XC (Kundennummer).

Favorisierte Reiserouten:

– München, Stuttgart,
– München, Köln,
– München, Frankfurt.

Szenario 2: Datenbereitstellung/Suche für den Servicetechniker
Ein erfahrener Servicetechniker ist zuständig für die Reparatur von Drehgestellen (Englisch: bogie) für Züge. Er repariert Drehgestelle verschiedener Firmen, die aus verschiedenen Komponenten bestehen, z.B. Bremsen, Elektromotoren usw.
Er benötigt die folgenden Daten zu seinem Fachgebiet:

– Welche Fehler gibt es zu einem Drehgestell und dessen Komponenten und wie wurden diese gelöst?
– Welche Updates, z.B. Software- oder Teileaktualisierungen, gibt es für Drehgestelle und Komponenten – z.B. über die RSS-Feeds (urspr. Rich Site Summary, Really Simple Syndication):
– der Webseiten eines Komponentenherstellers,
– dem Customer Service Portal (Wiki),
– den internen Veröffentlichungen (Blog) von Experten, z.B. Technik und Einkauf, seiner Firma,
– Welche ggf. neuen Experten und Best Practices gibt es zu einzelnen Komponenten?
– Welche neuen Daten gibt es zu den eingesetzten Technologien (z.B. RFID Radio Frequency Identification)?
– Welche neuen Vorträge/Seminare gibt es zu meinen Themen?

Diese Daten möchte er nicht nur beim Auftreten eines Fehlerfalles bekommen, sondern laufend, damit er entsprechende Maßnahmen vorbeugend ergreifen kann, z.B. werden alle Fehlermeldungen und Lösungen als RSS bereit gestellt.
Da er selbst seine Expertise in einem internationalen Netzwerk zur Verfügung stellen möchte, nimmt er an einer Wissensaustauschplattform teil. Folgende Daten benötigt er:

– Welche Anfragen, z.B. dringliche Anfragen bzw. Urgent Requests, betreffen mein Fachgebiet?
– Welche Kollegen beschäftigen sich mit ähnlichen Themen wie ich?

Beispiel für die Kontextdaten eines Servicetechnikers:
Ticket bzw. Wartungsauftrag:

– Ticket ID,
– Drehgestellnummer,
– Fehlerbeschreibung.

Drehgestell, d.h. Komponente:

– Historie des Drehgestells,
– Relation zu anderen Komponenten/Items,
– Wartungsanleitung und Empfehlung,
– Fehlermeldungen.

Aktuelle Informationsdaten der Hersteller:

– Empfehlungen.

Rolle:

– Senior Techniker,
– Experte für: ICE (Inter City Express) Drehgestelle.

Netzwerk

– Technoweb Gruppe.

Die oben beschriebenen Eigenschaften, Merkmale und Vorteile dieser Erfindung sowie die Art und Weise, wie diese erreicht werden, werden klarer und deutlicher verständlich im Zusammenhang mit der folgenden Beschreibung der Ausführungsbeispiele. Sofern in dieser Anmeldung der Begriff "kann" verwendet wird, handelt es sich sowohl um die technische Möglichkeit als auch um die tatsächliche technische Umsetzung. Sofern in dieser Anmeldung der Begriff "etwa" verwendet wird, bedeutet dies, dass auch der exakte Wert offenbart ist. Die Figuren sind nicht maßstabsgerecht gezeichnet, insbesondere können die Aspektverhältnisse der Elemente anders gewählt werden.
Im Folgenden werden Ausführungsbeispiele der Erfindung an Hand der beiliegenden Zeichnungen erläutert.
Darin zeigen:
1 einen Überblick über Netzwerkeinheiten,
2 Festlegungen für Datenfelder und Datenformate,
3 detaillierte Festlegungen für Datenfelder und Datenformate,
4 Display-Ansichten oder Bildschirmansichten an einem Endgerät,
5 eine Tabelle zur Verdeutlichung der Zuordnung von Daten zu zwei Nutzerprofilen oder zu zwei Nutzerrollen,
6 einen Datensatz, der in einer Antwortnachricht übertragen wird,
7 Verfahrensschritte, die in einem Endgerät ausgeführt werden,
8 Verfahrensschritte, die in einer zentralen DV-Anlage (Datenverarbeitungsanlage) ausgeführt werden,
9 ein erstes Anwendungsszenario mit einem Endgerät,
10 ein zweites Anwendungsszenario mit zwei Endgeräten, und
11 Einheiten einer zentralen DV-Anlage.
Die 1 zeigt einen Überblick 10 über Netzwerkeinheiten, die für die im Folgenden erläuterten Verfahren relevant sind, wobei auf das ISO-Schichtenmodell (International Standardization Organization) Bezug genommen wird. Bei anderen Ausführungsbeispielen können die Einheiten aber auch ohne Berücksichtigung des Schichtenmodells ausgeführt werden:

– auf einer unteren Ebene befindet sich das Internet 12 mit einer Vielzahl von DV-Anlagen, die bspw. eigene Datenbanken DB1 bis DB10 enthalten, wobei diese Datenbanken auch von Firmen für eigene Zwecke betrieben werden können,
– ein kontextintegrierender Diensterbringungsrechner 14 (DER, Server) bzw. mehrere solche Rechner greifen bspw. auf die Datenbanken DB1 bis DB6 und ggf. DB20 zu, um einen kontextintegrierenden Dienst (CIS) zu erbringen, der unten noch näher erläutert wird, wobei diese Datenbanken auch von Firmen für eigene Zwecke betrieben werden können,
– ein datenintegrierender Diensterbringungsrechner 16 (DER, Server) oder eine Rechnercluster greift bspw. auf die Datenbanken DB7 bis DB10 zu, um einen datenintegrierenden Dienst (DIS) zu erbringen, der jedoch im folgenden nicht weiter erläutert wird, weil er nur einen geringen Bezug zu der Erfindung hat,
– eine Anwendungseinheit 18, z.B. eine DV-Anlage mit zugehörigem Programm, nutzt den CIS bzw. den Rechner 14 und/oder den DIS bzw. Rechner 16, wobei vorzugsweise auch wieder auf DV-Anlagen im Internet 12 zugegriffen wird, was unten näher erläutert ist,
– eine Prozesseinheit 20, z.B. eine DV-Anlage mit einem zugehörigen Programm, wie ein SCM (Supply Chain Management) oder CRM (Customer Relation Management) Programm, d.h. zum Ausführen von Geschäftsprozessen,
– und eine Darstellungseinheit 22, z.B. eine DV-Anlage mit einem zugehörigen Programm, zur Erzeugung einer Ausgabe, bspw. auf einem Bildschirm.

Die Anwendungseinheit 18 erhält kontextspezifische Daten oder ist selbst kontextspezifisch, so dass der Prozesseinheit 20 bspw. nur kontextspezifische Applikationen bzw. Anwendungsprogramme angeboten werden.
Für die Datenbanken DB1 bis DB20 gilt:

– die Datenbank DB1 speichert bspw. Ortsdaten, z.B. Mobilfunkbetreiber o.ä.,
– die Datenbank DB2 speichert bspw. Profildaten, siehe 2 bzw. 3,
– die Datenbank DB3 speichert bspw. Interessendaten, wie sie in digitalen sozialen Netzwerken zu finden sind, z.B. Facebook, Twitter etc.,
– die Datenbank DB4 speichert bspw. Daten von Prozessen, die früher ausgeführt worden sind, insbesondere firmenspezifische Prozesse,
– die Datenbanken DB5 und DB6 speichern weitere Kontextdaten,
– die Datenbank DB7 speichert Dokumente, z.B. Briefe etc., z.B. in bestimmten Dokumentenformaten, wie z.B. Word-Format oder Excel-Format, d.h. z.B. Microsoft Formate,
– die Datenbank DB8 speichert bspw. Masterdaten, z.B. wo und wann archiviert werden soll,
– die Datenbank DB9 speichert Inhalte, z.B. strukturierte Inhalte wie IT-Daten, z.B. Rechnungsdaten, die z.B. in Rechnungen übernommen werden können, und unstrukturierte Daten, wie z.B. Bilddaten der Rechnungen selbst,
– die Datenbank DB10 speichert weitere Datenquellen, z.B. wo Inhalte liegen können,
– die Datenbank DB20 enthält bspw. ein Archiv der bisher gestellten Anforderungen an den CIS, was unten noch näher erläutert wird.

Die Datenbanken DB7 bis DB10 enthalten Daten, die bspw. ebenfalls einem Metadatenmodell entsprechen, z.B. BOT (Business Types Objects) der Firma SIEMENS AG oder ein entsprechendes Datenmodell einer anderen Firma.
Die 2 zeigt Festlegungen 50 für die folgenden Datenfelder, was auch als Datenmodell bezeichnet werden kann:

– ein Besitzerdatum 52 bezieht sich auf eine Person oder auf einen Gegenstand der durch die Kontextdaten beschrieben wird,
– allgemeine Einstellungsdaten 54,
– Zustandsdaten 55,
– Situationsdaten 56, die zu den Zustandsdaten 55 gehören,
– mindestens ein zu den Zustandsdaten 55 bzw. zu den Situationsdaten 56 gehörendes Auswahldatum 57, und
– auswahlspezifische Einstellungsdaten 58.

Die allgemeinen Einstellungsdaten 54 und die Zustandsdaten 55 bilden allgemeine Kontextdaten 60. Die allgemeinen Kontextdaten 60 und die auswahlspezifische Einstellungsdaten 58 bilden Kontextdaten 62.
Eine Beziehung 70 ist zwischen den Besitzerdaten 52 und den allgemeinen Kontextdaten 60 festgelegt, z.B. in beide Richtungen eine 0 ... n Beziehung, wobei n eine natürliche Zahl größer Null ist. Insbesondere können für die Beziehung 70 aber in beiden Richtungen auch 1:1 Beziehungen verwendet werden.
Eine Beziehung 72 ist zwischen den Auswahldaten 57 und den auswahlspezifischen Einstellungsdaten 58 festgelegt. Die Beziehung 72 ist bspw. in beide Richtungen eine 0 ... x Beziehung, wobei x eine natürliche Zahl größer Null ist. Insbesondere können für die Beziehung 72 aber in beiden Richtungen auch 1:1 Beziehungen verwendet werden.
Metadaten 80 können enthalten:

– ein Aktualisierungsdatum 82 zur Angabe des Zeitraums, in dem Daten aktualisiert werden,
– ein Quellendatum 84 zur Angabe der Datenquelle aus der Daten stammen,
– ein Archivierungsdatum 86 zur Angabe, ob und ggf. wann eine Archivierung der betreffenden Daten erfolgen soll, und
– ein Besitzerauswahldatum 88 zur Angabe, ob es sich beim "Besitzer", siehe Besitzerdatum 52, um eine Person oder um einen Gegenstand handelt.

Die Metadaten 80 oder zumindest ein Teil der Metadaten 80 können den Daten 50 insgesamt oder einzelnen Teildaten zugeordnet sein, siehe z.B. Zuordnung 90.
Außerdem können zu den in der 1 gezeigten Datenfeldern 52, 54, 55, 57, 56 und 58 zugehörige Datenformate festgelegt werden. Das Datenmodell kann auch weitere Datenfelder enthalten.
Die 3 zeigt detaillierte Festlegungen 100 für Datenfelder und Datenformate. Es gelten die an Hand der 2 gemachten Aussagen entsprechend für:

– ein dem Besitzerdatum 52 entsprechendes Besitzerdatum 52b,
– den allgemeinen Einstellungsdaten 54 entsprechende Einstellungsdaten 54b,
– den Zustandsdaten 55 entsprechende Zustandsdaten 55b,
– den Situationsdaten 56 entsprechende Situationsdaten 56b,
– ein dem Auswahldatum 57 entsprechendes Auswahldatum 57b,
– den auswahlspezifischen Einstellungsdaten 58 entsprechende Einstellungsdaten 58b,
– den allgemeinen Kontextdaten 60 entsprechende Kontextdaten 60b, und
– den Kontextdaten 62 entsprechende Kontextdaten 62b.

Der Beziehung 70 entspricht eine Beziehung 70b. Der Beziehung 72 entspricht eine Beziehung 72b. Den Metadaten 80 entsprechen Metadaten 80b, die mindestens eines der folgenden Daten enthalten:

– ein Aktualisierungsdatum 82b,
– ein Quellendatum 84b,
– ein Archivierungsdatum 86b, und/oder
– ein Besitzerauswahldatum 88b.

Die Metadaten können einer Instanz des Modells zugeordnet sein, siehe Zuordnung 90 oder einzelnen Datenfeldern, z.B. Zuordnung 92b, die sich bspw. auf die unten noch näher erläuterten Adressdaten 114 bezieht.
Die Detailfestlegung 100 von Datenfeldern und Datenformaten enthalten weiterhin:
– Besitzerdaten 102 bis 106, wobei sich die Besitzerdaten 102 auf einen Hr. X beziehen, dessen Kennzeichen im Datenfeld 102 vermerkt ist. Die Besitzerdaten 104 (Fahrgestell bzw. Bogie mit der Nummer 123) und 106 (Person: Hr. Z) deuten weitere Instanzen bzw. Datensätze an, die jedoch nicht zu der in der 3 gezeigten Instanz bzw. zu dem in dem in der 3 gezeigten Datensatz gehören,

– ein Geburtsdatum 110, das zu den allgemeinen Einstellungsdaten 54b gehört,
– ein Geschlechtsdatum 112, das zu den allgemeinen Einstellungsdaten 54b gehört,
– ein Adressdatensatz 114, der ebenfalls zu den allgemeinen Einstellungsdaten 54b gehört, z.B. eine Privatadresse, insbesondere Straße und Stadt,
– ein Aufgabendatum 120, das zu den Zustandsdaten 55b gehört und das z.B. die Aufgabe angibt, ein bestimmtes Fahrgestell zu warten, z.B. mit der Nummer 123, z.B. das Fahrgestell eines ICE (Inter City Express),
– ein Ortsdatum 122, das zu den Zustandsdaten 55b gehört,
– ein Adressdatensatz 124, der zu dem Ortsdatum 122 gehört und bspw. den Standort des Fahrgestells oder eines Wartungsortes des Fahrgestells angibt, z.B. Straße und Stadt,
– ein Auswahldatum 130, das zu den Zustandsdaten 55b gehört, das eine erste Rolle des Besitzers betrifft und das dem Auswahldatum 57b zugeordnet ist bzw. dieses ausprägt (Instanz),
– ein Interessendatum 140, das den auswahlspezifischen Einstellungsdaten 58b zugeordnet ist und das das Interesse des Besitzers angibt, z.B. hier Servicemanagement,
– ein Expertisendatum 142, das den auswahlspezifischen Einstellungsdaten 58b zugeordnet ist und das die Kenntnisse des Besitzers angibt, z.B. hier die Reparatur von Drehgestellen (Bogies),
– ein Adressdatensatz 144, der den auswahlspezifischen Einstellungsdaten 58b zugeordnet ist und hier bspw. die Firmenadresse des Besitzers 52b, 102 angibt, z.B. Straße und Stadt,
– ein Beziehungsdatum 146, das den auswahlspezifischen Einstellungsdaten 58b zugeordnet ist und das eine Beziehung des Besitzers zu anderen Besitzern oder zu anderen Gegenständen angibt,
– ein Typdatum 148, das dem Beziehungsdatum 146 zugeordnet ist und die Art der Beziehung angibt, z.B. Kollege, sowie
– ein Beziehungsdatum 150, das dem Beziehungsdatum 146 zugeordnet ist und das die in Bezug genommene Person bzw. den in Bezug genommenen Gegenstand angibt, hier Hr. Z.

Eine Beziehung 160 kann vom Datum 120 zum Datum/Datensatz 104 hergestellt werden. Eine Beziehung 162 kann vom Datum 150 zum Datum/Datensatz 106 hergestellt werden. Die Beziehung 160 bzw. 150 kann über ein entsprechendes Kennzeichen (Schlüssel) erfolgen, das bspw. in einer nächsten Anforderungsnachricht angegeben wird.
Die Adressdaten 114, 124 und 144 können auch um weitere Angaben ergänzt sein, z.B. Hausnummer, Postleitzahl, Stockwerk, GPS Koordinaten etc.
Es gelten die gleichen Festlegungen für die Adressdaten 114, 124 und 144 (Cluster), so dass sich der Aufwand für die Festlegung hier besonders lohnt.
Bei anderen Rollen sind andere auswahlspezifische Datenfelder gültig.
Die 4 zeigt Display-Ansichten oder Bildschirmansichten 200 bis 204 an einem Endgerät, z.B. am mobilen Endgerät 454, 454c, 454d, siehe 9 und 10, z.B. an einem Mobiltelefon oder an einem Smartphone.
Die Bildschirmansicht 200 zeigt eine Auswahlfläche 210 (Toggle) mit der das Profil bzw. die Rolle manuell ausgewählt werden kann, z.B. Geschäft oder privat. Abhängig von der Auswahl wird der Wert eines Auswahldatums festgelegt. An Stelle einer Auswahlfläche 210 können auch zwei Auswahlflächen 210, 212 oder mehr als zwei Auswahlflächen verwendet werden, oder eine andere Art der Dateneingabe, z.B. simulierter Schiebeschalter (Toggle). Die Festlegung des Wertes des Auswahldatums kann aber auch automatisch erfolgen, bspw. abhängig vom Ort des Endgerätes und/oder der Zeit und/oder einem anderen veränderlichen Kontext.
Die Bildschirmansicht 202, dient nur der Information des Nutzers und ist optional. Es werden vier Textfelder 220 bis 226 dargestellt, die bspw. den in der 5 in der Spalte "Business" gezeigten Einstellungen für die Rolle "Geschäft" entsprechen. So zeigt der Text 220 bspw. das Wort "allgemein", womit angezeigt wird, dass in der Rolle "Geschäft" allgemeine Daten verwendet werden, z.B. Name, Vorname, Geburtsdatum etc. Dem Nutzer können Wahlmöglichkeiten zur Auswahl der Daten gegeben werden, d.h. Kombination von angezeigtem Text und Auswahlfeldern.
Die Bildschirmansicht 204, dient bspw. ebenfalls nur der Information des Nutzers und kann optional sein. Es werden vier Textfelder 230 bis 236 dargestellt, die bspw. den in der 5 in der rechten Spalte gezeigten Einstellungen für die Rolle "privat" entsprechen. So zeigt der Text 230 bspw. wieder das Wort "allgemein", womit angezeigt wird, dass in der Rolle " privat" allgemeine Daten verwendet werden, z.B. Name, Vorname, Geburtsdatum etc. Dem Nutzer können Wahlmöglichkeiten zur Auswahl der Daten gegeben werden, d.h. Kombination von angezeigtem Text und Auswahlfeldern. Die anderen Textfelder werden unten an Hand der 5 näher erläutert.
Pfeile 240, 242 zeigen die Umschaltmöglichkeit des Nutzers zwischen verschiedenen Profilen bzw. Rollen.
Die 5 zeigt eine Tabelle 250 zur Verdeutlichung der Zuordnung von Daten zu zwei Nutzerprofilen oder zu zwei Nutzerrollen. Diese Zuordnungen können in einem Speicher des Endgeräts vermerkt sein. Zusätzlich oder alternativ können diese Zuordnungen nur in einem Anwendungsprogramm auf dem Endgerät und/oder in einem Programm des CIS vermerkt bzw. implementiert sein.
Für die Rolle "Geschäft" gelten im Ausführungsbeispiel die folgenden Daten:

– allgemeine Daten, siehe 4, Textfeld 220,
– firmenspezifische Daten, siehe 4, Textfeld 220,
– Daten aus digitalen sozialen Netzwerken, siehe 4, Textfeld 224, und
– zusätzliche Präferenzen, siehe 4, Textfeld 226.

Für die Rolle "privat" gelten im Ausführungsbeispiel die folgenden Daten:

– allgemeine Daten, siehe 4, Textfeld 230,
– Daten aus digitalen sozialen Netzwerken, siehe 4, Textfeld 232,
– zusätzliche Präferenzen siehe 4, Textfeld 234,, und
– private Präferenzen, siehe 4, Textfeld 236.

Die für die Rollen "Geschäft" und "privat" erforderlichen Festlegungen können sich von den in den 2 und 3 gezeigten Festlegungen unterscheiden bzw. zumindest teilweise mit diesen Festlegungen übereinstimmen.
Bei einem anderen Ausführungsbeispiel gibt es die Daten "private Präferenzen" bspw. nicht, so dass im Profil "privat" im Vergleich zu dem Profil "Geschäft" keine zusätzlichen Daten sondern nur weniger Daten gelten.
Die 6 zeigt einen Datensatz 300, der in einer Antwortnachricht übertragen wird, und für den die in der 2 gezeigten Vorgaben erfüllt sind. Der Datensatz 300 entspricht damit der Sicht eines Anwendungsprogramms 18 auf einem mobilen Endgerät, siehe bspw. Endgerät 454, 454c, 454d in den 9 und 10.
Der Datensatz 300 enthält die folgenden Datenfelder:

– ein Datenfeld 310 mit einem Besitzerdatum, d.h. einem Kennzeichen, das die Person oder den Gegenstand kennzeichnet, die bzw. der durch die Datenfelder des Datensatzes 300 beschrieben wird,
– ein Datenfeld 312 mit allgemeinen Einstellungsdaten, z.B. Name einer Person, Name eines Gegenstands, Geburtsdatum, Herstellungsdatum usw.,
– ein Datenfeld 314, mit dem Zustände der durch den Datensatz 300 beschriebenen Person oder des durch den Datensatz 300 beschriebenen Gegenstands angegeben werden, z.B. ein Verweisdatum oder eine Verweisliste, ggf. ist das Datenfeld 314 optional, wenn die Zustandsdaten auf andere Art markiert werden können,
– ein Datenfeld 316, das dem Datenfeld 314 zugeordnet ist bzw. eine Realisierung dieses Datenfeldes ist. Das Datenfeld 316 enthält im Beispiel eine Ortsangabe, siehe bspw. Adressdaten 124 in der 3.
– ein optionales Datenfeld 318, das ein Auswahldatum oder ein Rollendatum enthält, z.B. einen Wert bzw. ein Kennzeichen für die Rolle "Geschäft",
– rollenspezifische Datenfelder 320 bis 326, die in dieser Reihenfolge bspw. eine bevorzugte oder zu verwendende Komfort-Klasse für Bahnfahrten, eine bevorzugte zu verwendende

Komfort-Klasse für Flugreisen, eine bevorzugte oder zu verwendende Fluglinie und/oder eine bevorzugte oder zu verwendende Hotelkette angeben.
Zwischen den Datenfeldern 310 bis 326 kann es implizite Zuordnungen, z.B. über die Reihenfolge der Datenfelder, oder explizite Zuordnung 330 bis 338 geben, bspw. über Verweise:

– die Zuordnung 330 besteht zwischen dem Datenfeld 310 und dem Datenfeld 312,
– die Zuordnung 332 besteht zwischen dem Datenfeld 310 und dem Datenfeld 314,
– die Zuordnung 334 besteht zwischen dem Datenfeld 314 und dem Datenfeld 316,
– die Zuordnung 336 besteht zwischen dem Datenfeld 314 und dem Datenfeld 318, und
– die Zuordnung 338 besteht zwischen dem Datenfeld 318 und den Datenfeldern 320 bis 326.

Metadaten 80c entsprechen den Metadaten 80 bzw. 80b und enthalten:

– ein Aktualisierungsdatum 82c, das dem Datum 82 entspricht,
– ein Quellendatum 84c, das dem Datum 84 entspricht,
– ein Archivierungsdatum 86c, das dem Datum 86 entspricht, und/oder
– ein Besitzerauswahldatum 88c, das dem Datum 88 entspricht.

Eine Zuordnung 90c entspricht der Zuordnung 90 und ordnet die Metadaten 80c bspw. dem gesamten Datensatz 300 zu. Eine alternative Zuordnung 92b entspricht der Zuordnung 92. So können mehrere Datensätze 80c mit voneinander verschiedenen Inhalten bspw. jedem der in der 6 gezeigten Datenfelder 310 bis 326 bzw. einigen dieser Datenfelder 310 bis 326 zugeordnet sein.
Die Metadaten 80c können in der Antwortnachricht vom CIS zur mobilen DV-Anlage übertragen werden. Alternativ oder zusätzlich werden die Metadaten 80c im CIS gespeichert, siehe die 1, Datenbank DB20, bzw. die 9 und 10, Datenbank DB20b bzw. DB20c.
Die 7 zeigt Verfahrensschritte 350 bis 362, die in einem Endgerät ausgeführt werden, siehe bspw. Endgerät 454, 454c und 454d in den folgenden Figuren. Das Verfahren beginnt in einem Verfahrensschritt 350. Die Verfahrensschritte 350 bis 362 werden im Folgenden auch kurz als Schritte 350 bis 362 bezeichnet. In einem dem Schritt 350 zeitlich folgenden Schritt 352 wird der Wert eines Auswahldatums ermittelt, bspw. ein Wert, der über die an Hand der 4 erläuterte Auswahlmöglichkeit eingegeben worden ist.
In einem nächsten Schritt 354 wird unter Verwendung des Auswahldatums eine Anfrage an den CIS gestellt, d.h. den kontextintegrierenden Service-Rechner.
Die im bzw. vom CIS-Rechner ausgeführten Schritte werden unten an Hand der 8 näher erläutert und gelten ebenfalls für die 9 und 10 sowie für die 11.
In einem Schritt 358 werden im Endgerät Daten in einer Antwortnachricht empfangen, siehe bspw. die 6, Datensatz 300. Daraufhin erbringt das mobile Endgerät im Schritt 360 einen Dienst unter Verwendung der in der Antwortnachricht enthaltenden Daten, wobei typischerweise weitere Zugriffe auf das Internet 12 erfolgen.
In einem Schritt 362 wird das Verfahren dann beendet. Alternativ wird der Wert des Auswahldatums geändert und es erfolgt eine weitere Anfrage an den CIS-Rechner. Es können auch mehrere Abfragen mit dem gleichen Wert des Auswahldatums hintereinander an den CIS-Rechner gestellt werden.
Die 8 zeigt Verfahrensschritte 400 bis 410, die in einer zentralen DV-Anlage (Datenverarbeitungsanlage) ausgeführt werden, siehe bspw. 1, Rechner 14 bzw. CIS sowie 9, Rechner 490, 10, Rechner 490c sowie 11, Rechner 490. Das Verfahren beginnt in einem Verfahrensschritt 400. Die Verfahrensschritte 400 bis 410 werden im Folgenden auch kurz als Schritte 400 bis 410 bezeichnet. In einem dem Schritt 400 folgenden optionalen Schritt 402 wird der Nutzer des Dienstes bzw. sein Endgerät registriert, bspw. im Rahmen einer Anmeldung, bei der auch allgemeine Daten angegeben werden, z.B. Name, Vorname, Geburtsdatum oder ein Herstellungsdatum eines Gegenstands.
In einem nächsten Schritt 403 erhält der zentrale Rechner eine Anfrage von einem mobilen Endgerät. Die Anfrage enthält insbesondere ein Auswahldatum zur Auswahl spezifischer Daten. Bei einem anderen Beispiel werden die Zustandsdaten des Datensatzes bzw. ein Teil der Zustandsdaten bspw. periodisch aktualisiert, ohne dass es einer Anforderungsnachricht 403 bedarf. Beim Eintreffen der Anforderungsnachricht sind dann bereits alle Daten oder ein Großteil der Daten im CIS-Rechner vorhanden, so dass die Antwortnachricht schnell erzeugt werden kann.
In einem Schritt 404 ermittelt der CIS-Rechner die angeforderten Daten, wobei auch auf externe Rechner bzw. Datenbanken zugegriffen wird, siehe bspw. die 1, Datenbanken DB1 bis DB6.
In einem Schritt 408 werden die ermittelten Daten ggf. in der Datenbank DB20 gespeichert bzw. archiviert. Alternativ werden nur ausgewählte Daten gespeichert. Danach werden die ermittelten Daten in einer Antwortnachricht von dem zentralen Rechner (CIS) an das mobile Endgerät gesendet, das die Anforderungsnachricht gesendet hat.
Die 9 zeigt ein erstes Anwendungsszenario mit einem Endgerät 454. Das Endgerät 454 wird von einem Nutzer 452 genutzt und ist bspw. ein Smartphone, ein Mobiltelefon bzw. ein Handy. Ein Zeitstrahl 460 dient zur Darstellung der Zeit t.
Zu einem Zeitpunkt t2 erzeugt ein auf dem Endgerät 454 ausgeführtes Anwendungsprogramm 480 eine Anforderungsnachricht 492 an den Rechner bzw. das Diensterbringungsprogramm 490 (CIS). Die Anforderungsnachricht 492 enthält ein Auswahldatum mit einem Wert AW1a, der angibt, dass der Nutzer 452 das Endgerät 454 geschäftlich nutzt.
Das Diensterbringungsprogramm 490 greift nach dem Empfang der Anforderungsnachricht 492 auf die oder auf einige der Datenbanken DB1b bis DB6b zu, die den Datenbanken DB1 bis DB6 entsprechen, um die Anforderung zu erfüllen, siehe Zugriffe 494 und 496. Dabei werden aus diesen Datenbanken DB1b bis DB6b Daten gelesen, insbesondere firmenspezifische Daten.
Das Diensterbringungsprogramm 490 erzeugt nach der Beschaffung der Daten eine Antwortnachricht 498, die an das Programm 480 gesendet wird. Das Diensterbringungsprogramm 490 speichert ggf. die gesendeten Daten oder einen Teil dieser Daten in der Datenbank DB20b, die der Datenbank DB20 entspricht. Ggf. werden auch nur Änderungen in der Datenbank DB20b vermerkt, siehe Zugriff 497.
Nach dem Empfang der Antwortnachricht 498 erbringt das Programm 480 seinen Dienst bspw. unter Zugriff auf mindestens eine weitere DV-Anlage 504. Dabei werden insbesondere die firmenspezifischen Daten genutzt. Das Programm 480 ist bspw. ein Reisebuchungsprogramm und/oder ein Reiseplanungsprogramm. Alternativ ist das Programm 480 ein Programm zur Unterstützung der Wartung eines technischen Bauteils oder einer technischen Anlage oder ein anderes Programm.
Zu einem Zeitpunkt t4, der nach dem Zeitpunkt t2 liegt, sendet das Programm 480 eine weitere Anforderungsnachricht 500 an den zentralen Rechner 490, wobei sich zwischenzeitlich aber der Wert des Auswahldatums auf einen Wert AW1b geändert hat, der angibt, dass der Nutzer 452 das Gerät 454 nun privat nutzt, so dass bspw. private Präferenzen zu berücksichtigen sind und/oder firmenspezifische Daten nicht mehr ermittelt werden müssen oder nicht mehr ermittelt werden.
Der Rechner 490 greift wieder auf die Datenbanken DB1b bis DB6b zu, um die erforderlichen Daten zu ermitteln. Danach wird eine Antwortnachricht 502 vom zentralen Rechner 490 an das Endgerät 454 bzw. an das Programm 480 erzeugt. Die Nachricht 502 enthält bspw. private Präferenzdaten und vorzugsweise keine firmenspezifischen Daten. Sind firmenspezifische Daten in der Nachricht 502 enthalten, so werden diese firmenspezifischen Daten jedoch nicht vom Programm 480 genutzt.
Das Programm 480 erbringt nach dem Empfang der Antwortnachricht 502 seinen Dienst bspw. unter Zugriff auf die DV-Anlage 504 oder auf eine andere DV-Anlage, wobei insbesondere die privaten Präferenzdaten verwendet werden. Firmenspezifische Daten werden nach dem Zeitpunkt t4 also nicht mehr berücksichtigt, insbesondere beim Zugriff auf die DV-Anlage 504. Die DV-Anlage 504 ist bspw. ein Buchungssystem für eine Bahnfahrt oder für einen Flug.
Bei einem anderen Ausführungsbeispiel wird zum Zeitpunkt t4 ein zweites Programm auf dem Endgerät 454 ausgeführt, das sich vom ersten Programm unterscheidet. Auch das zweite Programm greift auf den Rechner 490 bzw. den CIS-Rechner zu.
Die 10 zeigt ein zweites Anwendungsszenario mit zwei Endgeräten 454c und 454d. Das Endgerät 454c wird von einem Nutzer 452c genutzt und ist bspw. ein Smartphone, ein Mobiltelefon bzw. Handy. Das Endgerät 454d wird von einem Nutzer 452d genutzt und ist bspw. ebenfalls ein Smartphone, ein Mobiltelefon bzw. Handy.
Ein auf dem Endgerät 454c ausgeführtes Anwendungsprogramm 480c, das bspw. dem Anwendungsprogramm 480 entspricht, erzeugt eine Anforderungsnachricht 512 an einen Rechner bzw. das Diensterbringungsprogramm 490c (CIS), der dem Rechner 490 entspricht. Die Anforderungsnachricht 512 enthält ein Auswahldatum mit einem Wert AW1a1, der angibt, das der Nutzer 452c das Endgerät 454c geschäftlich nutzt. Alternativ wird ein Wert AW1b1 verwendet, der angibt, dass der Nutzer 452c das Endgerät 454c privat nutzt.
Das Diensterbringungsprogramm 490c greift nach dem Empfang der Anforderungsnachricht 512 auf die oder auf einige der Datenbanken DB1c bis DB6c zu, die den Datenbanken DB1 bis DB6 entsprechen, um die Anforderung zu erfüllen, siehe Zugriffe 514 und 516. Dabei werden aus diesen Datenbanken DB1c bis DB6c Daten gelesen, insbesondere firmenspezifische Daten.
Das Diensterbringungsprogramm 490c erzeugt nach der Beschaffung der Daten eine Antwortnachricht 520, die an das Programm 480c gesendet wird. Das Diensterbringungsprogramm 490c speichert ggf. die gesendeten Daten oder einen Teil dieser Daten in der Datenbank DB20c, die der Datenbank DB20 entspricht. Ggf. werden auch nur Änderungen in der Datenbank DB20c vermerkt, siehe Zugriff 518.
Nach dem Empfang der Antwortnachricht 512 erbringt das Programm 480c seinen Dienst bspw. unter Zugriff auf mindestens eine weitere DV-Anlage 504c. Dabei werden insbesondere die firmenspezifischen Daten genutzt. Das Programm 480c ist bspw. ein Reisebuchungsprogramm und/oder ein Reiseplanungsprogramm. Alternativ ist das Programm 480c ein Programm zur Unterstützung der Wartung eines technischen Bauteils oder einer technischen Anlage oder ein anderes Programm.
Ein Programm 510, das bspw. gleich dem Programm 480c ist oder verschieden von diesem ist, sendet gleichzeitig zu der Anforderungsnachricht 512 oder früher oder später eine Anforderungsnachricht 530 an den zentralen Rechner 490c, wobei ein Auswahldatum mit einem Wert AW1a2 (Geschäft) oder AW1b2 (privat) angegeben wird. Im Beispiel sei angenommen, das der Wert AW1b2 (privat) gilt.
Der Rechner 490c greift wieder mindestens auf eine der Datenbanken DB1c bis DB6c zu, um die erforderlichen Daten zu ermitteln. Danach wird eine Antwortnachricht 540 vom zentrale Rechner 490c an das Endgerät 454d bzw. an das Programm 510 erzeugt. Die Nachricht 540 enthält bspw. private Präferenzdaten und vorzugsweise keine firmenspezifischen Daten. Sind firmenspezifische Daten in der Nachricht 540 enthalten, so werden diese firmenspezifischen Daten jedoch nicht vom Programm 480c genutzt.
Das Programm 510 erbringt nach dem Empfang der Antwortnachricht 540 seinen Dienst bspw. unter Zugriff auf die DV-Anlage 504c oder auf eine andere DV-Anlage, wobei insbesondere die privaten Präferenzdaten des Nutzers 452d verwendet werden. Firmenspezifische Daten werden dabei bspw. nicht berücksichtigt.
Die DV-Anlage 504c ist bspw. ein Buchungssystem für eine Bahnfahrt oder für einen Flug, insbesondere ein Buchungssystem einer speziellen Bahngesellschaft oder einer speziellen Fluggesellschaft.
Die 11 zeigt Einheiten einer zentralen DV-Anlage 490, auf der der CIS ausgeführt wird. Die DV-Anlage 490 enthält einen Prozessor P, bspw. einen Mikroprozessor oder einen Mikrocontroller. Weiterhin enthält die DV-Anlage 490 einen Speicher M, in dem bspw. Programmbefehle des CIS-Programms gespeichert sind. Der Speicher M ist bspw. ein flüchtig speichernder Speicher oder ein nicht flüchtig speichernder Speicher.
Außerdem enthält die DV-Anlage 490 ein Empfangseinheit E zum Empfangen der Anforderungsnachtrichten und der Antworten zu den Datenbankzugriffen auf die Datenbanken DB1 bis DB6. Eine in der DV-Anlage 490 enthaltenden Sendeeinheit S dient zum Senden der Antwortnachricht und zum Senden von Anfragenachrichten an die Datenbanken DB1 bis DB6.
Die Ausführungsbeispiele sind nicht maßstabsgetreu und nicht beschränkend. Abwandlungen im Rahmen des fachmännischen Handelns sind möglich. Obwohl die Erfindung im Detail durch das bevorzugte Ausführungsbeispiel näher illustriert und beschrieben worden ist, ist die Erfindung nicht durch die offenbarten Beispiele eingeschränkt und andere Variationen können vom Fachmann hieraus abgeleitet werden, ohne den Schutzumfang der Erfindung zu verlassen. Die in der Einleitung genannten Weiterbildungen und Ausgestaltungen können untereinander kombiniert werden. Die in der Figurenbeschreibung genannten Ausführungsbeispiele können ebenfalls untereinander kombiniert werden. Weiterhin können die in der Einleitung genannten Weiterbildungen und Ausgestaltungen mit den in der Figurenbeschreibung genannten Ausführungsbeispielen kombiniert werden.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

Henricksen, K., Indulska, J., and Rakotonirainy, A., "Modeling context information in pervasive computing systems". 1st International Conference on Pervasive Computing (Pervasive), Band 2414 der Lectures Notes in Computer Science, Springer, 2002 [0080]
Strang, T., Linnhoff-Popien, C., "A Context Modeling Survey", Workshop on Advanced Context Modelling, Reasoning and Management, UbiComp 2004 – The Sixth International Conference on Ubiquitous Computing, Nottingham/England, 2004 [0081]

Claims

Verfahren zum Betreiben einer mobilen DV-Anlage (200, 454, 454c), enthaltend Übertragen einer Anforderungsnachricht (492) für Daten von einer ersten mobilen DV-Anlage (454) zu einer zentralen DV-Anlage (490), Bearbeiten der Anforderungsnachricht (492) und Erzeugen einer zugehörigen Antwortnachricht (498), wobei Daten gemäß der Anforderungsnachricht (492) von einem Diensterbringungsprogramm (490, CIS) zumindest von einer zweiten DV-Anlage (DB1b) und/oder von einer dritten DV-Anlage (DB6b) angefordert werden, und wobei für die von der zweiten DV-Anlage (DB1b) und/oder die von der dritten DV-Anlage (DB6b) empfangenen Daten eine Formatumwandlung durchgeführt wird, Übertragen der Antwortnachricht (498) von der zentralen DV-Anlage (490) zu der ersten mobilen DV-Anlage (454), in der ersten mobilen DV-Anlage (454) Verwenden von in der Antwortnachricht enthaltenen Daten zur Erbringung eines Dienstes durch ein Programm (480), wobei auf mindestens eine vierte DV-Anlage (504) unter Verwendung zumindest eines Teils oder nur eines Teils der in der Antwortnachricht (498) enthaltenden Daten zugegriffen wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei für einen in der Antwortnachricht (498) enthaltenen Datensatz (300) die folgenden Datenfelder oder Datenfeldgruppen festgelegt werden: mindestens ein erstes allgemeines Datenfeld (312) oder mindestens eine erste allgemeine Datenfeldgruppe (312), deren Daten über einen ersten Zeitraum unverändert bleiben, mindestens ein zweites allgemeines Datenfeld (314) oder mindestens eine zweite allgemeine Datenfeldgruppe (314), deren Daten sich im ersten Zeitraum mehrfach ändern, mindestens ein spezifisches Datenfeld (320 bis 326) des Datensatzes (300) oder mindestens eine spezifische Datenfeldgruppe (320 bis 326) des Datensatzes (300), die abhängig von dem Datenwert eines in der Anforderungsnachricht (492) enthaltenen Auswahldatums (318) in die Antwortnachricht (498) einbezogen werden, wobei vorzugsweise das zweite allgemeine Datenfeld (314) oder die zweite allgemeine Datenfeldgruppe (314) ein erstes Datenfeld (318) enthält oder aus einem ersten Datenfeld (318) besteht, dessen Wert angibt, ob oder welches spezifische Datenfeld (320 bis 326) oder ob oder welche spezifische Datenfeldgruppe (320 bis 326) gültig sind, wobei das erste Datenfeld (314) insbesondere ein Auswahldatum enthält.
Verfahren nach Anspruch 2, wobei der Datensatz (300) Umstände und/oder eine Situation angibt, unter deren Berücksichtigung das Programm (480) ausgeführt werden soll, wobei das Auswahldatum (318) abhängig von der aktuellen Rolle einer Person (452) oder eines Gegenstands die für diese Rolle festgelegten spezifischen Datenfelder (320 bis 326) oder Datenfeldgruppe (320 bis 326) des Datensatzes (300) angibt.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Anforderungsnachricht (492) eine erste Anforderungsnachricht (492) ist und wobei die Antwortnachricht (498) eine erste Antwortnachricht (498) ist, bei dem auf der ersten DV-Anlage (454) zu einer ersten Zeit (t2) ein erstes Auswahldatum auf einen ersten Datenwert (AW1a) festgelegt wird, bei dem das Programm (480) abhängig von einem Kennzeichen (316) die erste Anforderungsnachricht (492) erzeugt und abhängig vom ersten Datenwert mindestens ein erstes spezifisches Datenfeld (320 bis 326) in der ersten Antwortnachricht (498) berücksichtigt, das für den ersten Datenwert (AW1a) des Auswahldatums festgelegt worden ist, bei dem auf der ersten DV-Anlage (454) zu einer zweiten Zeit (t4), die nach der ersten Zeit (t2) liegt, ein zweiter Datenwert (AW1b) für das erste Auswahldatum festgelegt wird, und bei dem das Programm (480) abhängig von dem Kennzeichen (316) oder abhängig von einem Kennzeichen (316), das sich von diesem Kennzeichen unterscheidet, eine zweite Anforderungsnachricht (500) an die zentrale DV-Anlage (490) erzeugt und abhängig vom zweiten Datenwert (AW1b) mindestens ein zweites spezifisches Datenfeld in einer zweiten Antwortnachricht (502) der zentralen DV-Anlage (490) berücksichtigt, das für den zweiten Datenwert (AW1b) festgelegt worden ist, oder abhängig von dem zweiten Datenwert (AW1b) das erste spezifische Datenfeld (320 bis 326) nicht in der zweiten Antwortnachricht (502) enthalten ist und/oder nicht vom Programm (480) berücksichtigt wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die angeforderten Daten mindestens eines der folgenden Daten enthalten: – Ortsdatum (316) der mobilen DV-Anlage (454), und/oder – Daten (DB3) eines digitalen sozialen Netzwerkes.
Verfahren nach einem der vorhergehenden Ansprüche, wobei der Zugriff auf die zweite DV-Anlage (DB1c) und/oder auf die dritte DV-Anlage (DB6c) gemäß HTTP erfolgt
Verfahren nach einem der vorhergehenden Ansprüche, wobei die mobile DV-Anlage eine erste mobile DV-Anlage (454c) ist, enthaltend: Übertragen einer zweiten Anforderungsnachricht (530) für Daten von einer zweiten mobilen DV-Anlage (454d) zu der zentralen DV-Anlage, Bearbeiten der zweiten Anforderungsnachricht (530) und Erzeugen einer zugehörigen zweiten Antwortnachricht (540), wobei die Daten gemäß der zweiten Anforderungsnachricht (530) von dem Diensterbringungsprogramm (490c) zumindest von der zweiten DV-Anlage (DB1c) und/oder von der dritten DV-Anlage (DB6c) angefordert werden, wobei für die von der zweiten DV-Anlage (DB1c) und/oder die von der dritten DV-Anlage (DB6c) empfangenen Daten eine Formatumwandlung durchgeführt wird, Übertragen der zweiten Antwortnachricht (540) von der zentralen DV-Anlage (490c) zu der zweiten mobilen DV-Anlage (454d), in der zweiten mobilen DV-Anlage (454d) Verwenden von in der zweiten Antwortnachricht (540) enthaltenen Daten zur Erbringung eines Dienstes durch ein zweites Programm (510), wobei das zweite Programm (510) gleich dem ersten Programm (480c) ist oder wobei das zweite Programm (510) verschieden vom ersten Programm (480c) ist, und wobei auf mindestens eine vierte DV-Anlage (504c) unter Verwendung zumindest eines Teils oder nur eines Teils der in der zweiten Antwortnachricht (540) enthaltenden Daten zugegriffen wird.
Verfahren nach Anspruch 7, bei dem auf der ersten DV-Anlage (454c) ein erstes Auswahldatum auf einen ersten Datenwert (AW1a1) festgelegt wird, bei dem auf der zweiten mobilen DV-Anlage (454d) ein zweites Auswahldatum auf einen zweiten Datenwert (AW1b2) festgelegt wird, dessen Wert verschieden vom ersten Datenwert ist, und bei dem die erste mobile DV-Anlage (454c) abhängig von einem ersten Kennzeichen die erste Anforderungsnachricht (512) erzeugt und abhängig vom ersten Datenwert mindestens ein erstes spezifisches Datenfeld in der ersten Antwortnachricht berücksichtigt, das für den ersten Datenwert festgelegt worden ist und/oder abhängig vom ersten Datenwert (AW1a1) ein zweites spezifisches Datenfeld nicht in der ersten Antwortnachricht (520) enthalten ist oder nicht vom ersten Programm (480c) berücksichtigt wird, das für den zweiten Datenwert (AW1b2) festgelegt worden ist, und bei dem die zweite mobile DV-Anlage (454d) abhängig von dem ersten Kennzeichen oder einem zweiten Kennzeichen, das sich von dem ersten Kennzeichen unterscheidet, die zweite Anforderungsnachricht (530) erzeugt und abhängig vom zweiten Datenwert (AW1b2) mindestens ein zweites spezifisches Datenfeld in der zweiten Antwortnachricht (540) berücksichtigt, das für den zweiten Datenwert (AW1b2) festgelegt worden ist, und/oder abhängig vom zweiten Datenwert (AW1b2) das erste spezifische Datenfeld nicht enthalten ist oder vom zweiten Programm (510) nicht berücksichtigt wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei der Datensatz (300) mindestens zwei Datenfelder oder mindestens zwei Datenfeldgruppen (114, 124) enthält, die die gleiche Datenstruktur haben, vorzugsweise mindestens eines der folgenden Datenfelder, mindestens zwei der folgenden Datenfelder und/oder mindestens eine Datenfeldgruppe (114, 124) oder mindestens zwei der folgenden Datengruppen: – ein Datenfeld, dessen Wert die Interessen (140) eines Nutzers angibt, – ein Datenfeld, dessen Wert die Expertise (142) eines Nutzers angibt, – ein Datenfeld (120), das eine von einem Nutzer zu erfüllende Aufgabe angibt, – ein Datenfeld oder eine Datenfeldgruppe (114, 124), die den Ort der ersten mobilen DV-Anlage (454, 454c) oder der zweiten mobilen DV-Anlage (454d) angibt, insbesondere in GPS Koordinaten, eine Postadresse, oder einen Ort in einem Gebäude, – ein Datenfeld oder eine Datenfeldgruppe, die die Zeit angibt, insbesondere mindestens eine der folgenden Zeiten: ein Datum, eine Zeitzone, eine Startzeit, eine Endzeit, eine Zeitdauer, eine Dringlichkeit, einen Tag, einen Monat, eine Woche, ein Jahr.
Verfahren nach einem der vorhergehenden Ansprüche, wobei ein Datensatz (300) und/oder ein dem Datensatz zu Grunde liegendes Datenmodell (50, 100) mindestens eines der folgenden Datenfelder, mindestens zwei der folgenden Datenfelder oder alle der folgenden Datenfelder enthält: mindestens ein Datenfeld (82 bis 82c), dessen Wert eine Aktualisierungsperiode angibt, in welchen Abständen sich die Daten des Datensatzes (300) oder die Daten einzelner Datenfelder des Datensatzes (300) ändern, mindestens ein Datenfeld (84 bis 84c), dessen Wert angibt, aus welcher Datenquelle die Daten des Datensatzes (300) oder die Daten einzelner Datenfelder des Datensatzes (300) stammen, mindestens ein Datenfeld (88 bis 88c), dessen Wert angibt, ob die Daten des Datensatzes (300) oder die Daten einzelner Datenfelder des Datensatzes (300) mit einem Archivierungsprogramm archiviert werden sollen, mindestens ein Datenfeld (88 bis 88c), dessen Wert angibt, ob die Daten des Datensatzes (300) oder die Daten einzelner Datenfelder des Datensatzes (300) nur für Nutzer (542) oder nur für Gegenstände gelten, die durch die Daten beschrieben werden.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Programm (480) ein Anwendungsprogramm (480) ist, vorzugsweise ein Anwendungsprogramm (480), welches eine Reiseplanung und/oder eine Reisedurchführung unterstützt, oder ein Anwendungsprogramm (480), das die Wartung und/oder Reparatur einer technischen Vorrichtung unterstützt.
Verfahren nach einem der vorhergehenden Ansprüche, wobei der Datensatz (300) und/oder das Diensterbringungsprogramm (490c, CIS) ein vorgegebenes Datenmodell (50, 100) erfüllt, wobei das Datenmodell (50, 100) mindestens ein, mindestens zwei oder alle der folgenden Elemente enthält: mindestens ein Datenfeld (52, 52b, 310) zur Angabe eines Eigentümers des Datensatzes (300), insbesondere des Namens oder des Kennzeichens eines Nutzers einer DV-Anlage, oder eines Gegenstands, insbesondere eines technischen Gegenstands und/oder eines Ersatzteils, mindestens eine allgemeine Datenfeldgruppe (54, 54b, 312), die folgenden Datenfelder oder Datenfeldgruppen enthält: mindestens ein Datenfeld oder mindestens eine Datenfeldgruppe mit Angaben, die über eine erste Zeitdauer gleich bleiben, insbesondere ein Geburtsdatum (110) oder ein Herstellungsdatum, ein Geschlecht (112) ein Bautyp, und/oder eine Privatadresse (114), mindestens ein Datenfeld (55, 55b) oder mindestens eine Datenfeldgruppe mit Angaben, die sich innerhalb der ersten Zeitdauer mehrfach ändern, insbesondere ein vorübergehender Zustand, eine Aufgabe (120), eine Ort (122) einer Person oder eines Gegenstandes und/oder eine Rolle (57, 57b, 334), vorzugsweise eine Rolle, die ein Nutzer der DV-Anlage oder ein Gegenstand einnimmt, mindestens ein spezifisches Datenfeld (58, 58b, 140 bis 150, 320 bis 326) oder eine spezifische Datenfeldgruppe oder mindestens zwei spezifische Datenfelder oder mindestens zwei spezifische Datenfeldgruppen, die für eine Rolle eines Nutzers (452) oder die Rolle eines Gegenstandes relevante Daten enthält, insbesondere ein Datenfeld (140), das das Interesse einer Person angibt, ein Datenfeld (142), das die Expertise einer Person angibt, ein Datenfeld oder eine Datenfeldgruppe (144), die die Firmenadresse eines Nutzers (452) angibt, ein Datenfeld (146 bis 150) oder eine Datenfeldgruppe, die die Beziehung zu anderen Personen oder Gegenständen angibt.
Verfahren nach Anspruch 12, wobei mindestens eine, mindestens zwei oder alle der folgenden Beziehungen festgelegt sind: eine Beziehung (70) zwischen dem Datenfeld (52, 52b) zur Angabe des Eigentümers und der allgemeinen Datenfeldgruppe (54, 54b), wobei vorzugsweise ein Datenfeld (52, 52b) zur Angabe des Eigentümers genau einer allgemeinen Datenfeldgruppen (54, 54b) zugeordnet werden kann oder zugeordnet werden muss, und/oder wobei eine allgemeine Datenfeldgruppe (54, 54b) genau einem Datenfeld (52b) zur Angabe eines Eigentümers zugeordnet werden kann oder zugeordnet werden muss, eine Beziehung (72, 72b, 338) zwischen dem Datenfeld (58, 58b, 318) oder der Datenfeldgruppe zur Angabe der Rolle und den spezifischen Datenfeldern (320 bis 326) oder der spezifischen Datenfeldgruppe, wobei vorzugsweise ein Datenfeld (58, 58b, 318) oder eine Datenfeldgruppe zur Angabe der Rolle genau einem Datenfeld oder genau einer spezifischen Datenfeldgruppe (320 bis 326) zugeordnet werden kann oder zugeordnet werden muss, und/oder wobei ein spezifisches Datenfeld oder eine spezifische Datenfeldgruppe (320 bis 326) genau einem Datenfeld (318) oder genau einer Datenfeldgruppe zur Angabe der Rolle zugeordnet werden kann oder zugeordnet werden muss.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Diensterbringungsprogramm (490, 490c, CIS) die Antwortnachricht (498, 520, 540) oder nur einen Teil der Antwortnachricht (498, 520, 540) in einer Datenbank (DB20, DB20b, DB20c) speichert, wobei der Teil insbesondere durch mindestens ein Archivierungsdatum (86, 86b) festgelegt ist.
Zentrale DV-Anlage (14, 490, 490c), insbesondere zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 14, enthaltend mindestens einen Prozessor (P) und mindestens einen Speicher (M) zum Speichern von Programmbefehlen, bei deren Ausführung durch den Prozessor (P) Verfahrenschritte erbracht werden, enthaltend: eine Empfangseinheit (E) zum Empfangen einer Anforderungsnachricht, eine Bearbeitungseinheit zum Bearbeiten der Anforderungsnachricht (492) und zum Erzeugen einer zugehörigen Antwortnachricht (498), wobei Daten gemäß der Anforderungsnachricht von einem Diensterbringungsprogramm (490, CIS) zumindest von einer zweiten DV-Anlage (DB1) und/oder von einer dritten DV-Anlage (DB6b) angefordert werden, und wobei für die von der zweiten DV-Anlage (DB1, DB1b) und/oder die von der dritten DV-Anlage (DB6, DB6b) empfangenen Daten eine Formatumwandlung durchgeführt wird, und eine Sendeeinheit (S) zum Senden der Antwortnachricht (498).