VERFAHREN ZUM BETREIBEN EINER MOBILEN UND ZENTRALEN DV-ANLAGE

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 än ^¬ dernde 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 zu ^¬ gehö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 zu ^¬ mindest eines Teils oder nur eines Teils der in der Antwort ^¬ nachricht enthaltenden Daten zugegriffen wird. Weiterhin betrifft die Erfindung eine zentrale DV-Anlage oder einen zentralen DV-Anlagen-Verbund, insbesondere zur Durch ^¬ fü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 Dienst ^¬ erbringungsprogramm 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 Daten- strukturen 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 se- lektiv gelöscht werden können. Außerdem soll insbesondere ei ^¬ ne zugehörige DV-Anlage oder ein zugehöriger Datenverarbei ^¬ tungsanlagenverbund angegeben werden.

Diese Aufgabe wird durch ein Verfahren nach Anspruch 1 ge- lö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 wei ^¬ teren DV-Anlage Bearbeiten der Anforderungsnachricht und Er ^¬ zeugen 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 wer ^¬ den,

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, wo- bei auf mindestens eine vierte DV-Anlage unter Verwendung zu ^¬ mindest eines Teils oder nur eines Teils der in der Antwort ^¬ nachricht enthaltenden Daten zugegriffen wird.

Der Begriff "zentral" kann hier bedeuten, dass eine Datenver- arbeitungsanlage 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 ge ^¬ speicherte Daten zugegriffen werden, insbesondere die allge ^¬ meinen 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 entsprechen- den 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. Alterna ^¬ tiv 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 verschie ^¬ den 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übert ^¬ ragungsnetze 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 Datenmo ^¬ dells noch nicht bekannt waren. Eine nachträgliche Format ^¬ wandlung auf das festgelegte Format kann durchgeführt werden. Nur ein Teil der in der Antwortnachricht enthaltenden Daten wird insbesondere dann verwendet, wenn die Anforderungsnach ^¬ richt 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 (Rieh 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ön ^¬ nen. 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 Da ^¬ ten 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 Anwen- dungsprogramm bezogen ist.

Deshalb werden bei einer Ausgestaltung vor dem Übertragen der Anforderungsnachricht und/oder vor dem Erstellen des Dienst ^¬ erbringungsprogramms 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 festge- legt 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 mindes- tens 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 Anforderungsnach- rieht enthaltenden Auswahldatums in die Antwortnachricht ein ^¬ bezogen 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 spezi- fische Datenfeldgruppe gültig sind, wobei das erste Datenfeld insbesondere ein Auswahldatum enthält.

An Stelle nur einer Antwortnachricht können die Daten des Da ^¬ tensatzes auch auf mehrere Antwortnachrichten für einen Ge- samtdatensatz verteilt werden. Insbesondere können auf Grund des Auswahldatums nur die Daten übertragen werden, die rele ^¬ vant sein könnten. So lassen sich kurze Übertragungszeiten unter Verwendung kleiner Netzwerkressourcen realisieren, insbesondere für die Zwischenspeicherung und für die Weiterlei- tung 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) Da ^¬ tenfelder 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 Manage ^¬ ment, 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 be ^¬ reits 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 er ^¬ reicht, dass Daten auch eingeschränkt, selektiert bzw. gefil ^¬ tert werden können. Dies erhöht den Nutzen eines Dienstes er- heblich, weil der Nutzer nicht mit überflüssigen Daten konfrontiert wird.

Die Anforderungsnachricht kann eine erste Anforderungsnach ^¬ richt sein und die Antwortnachricht kann eine erste Antwort- nachricht sein. Auf der ersten DV-Anlage kann zu einer ersten Zeit ein erstes Auswahldatum auf einen ersten Datenwert fest ^¬ gelegt 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 ei- nem weiteren Kennzeichen, das sich von diesem Kennzeichen unterscheidet, eine zweite Anforderungsnachricht an die zentra ^¬ le 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 Aus- wahldatum ausgewählt sind. Damit wird die Beschaffung der Da ^¬ ten auf die benötigten Daten beschränkt. Nicht benötigte Da ^¬ ten 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 In ^¬ stanz 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 Anforderungsnach- rieht ein Kennzeichen für einen Gegenstand enthalten, für den der Nutzer der mobilen DV-Anlage Daten benötigt. Das Kennzei ^¬ chen 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) er ^¬ folgen. HTTP ist das im Internet eingesetzte Übertragungspro ^¬ tokoll, 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 Anwen ^¬ dungsprogramm, 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 Anwendungspro ^¬ gramme 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üh ^¬ rungen wie für die erste Antwortnachricht gelten, insbesonde ^¬ re auch bei unterschiedlichen Anwendungsprogrammen. Insbeson- dere 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 Rei- seplanungsprogramm 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 ab ^¬ hängig von einem ersten Kennzeichen die erste Anforderungsnachricht erzeugen und abhängig vom ersten Datenwert mindes- tens ein erstes spezifisches Datenfeld in der ersten Antwort ^¬ nachricht 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 Antwort ^¬ nachricht enthalten sein oder nicht vom ersten Programm be- rücksichtigt werden, falls es doch enthalten ist. Das zweite spezifische Datenfeld kann für den zweiten Datenwert festge ^¬ legt 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 Da ^¬ tenwert 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 Da ^¬ tenfeld 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 Daten- feldern, d.h. nicht vom Auswahldatum abhängigen Datenfeldern. Beide Nachrichten können sich insbesondere auf das gleiche Datenmodell beziehen und können bspw. gleiche Grunddatenfel ^¬ der haben, die unabhängig von einem Auswahldatum sind. Es kann aber auch auf verschiedene Datenmodelle Bezug genommen werden, bspw. Gegenstand oder Person. Auch eine Unterschei ^¬ dung 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 Anforderungs ^¬ nachricht 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 Aus- wahldatum ausgewählt sind. Damit wird die Beschaffung der Da ^¬ ten auf die benötigten Daten beschränkt. Nicht benötigte Da ^¬ ten 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 Datenfel- der 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 an ^¬ gibt,

- ein Datenfeld, dessen Wert die Expertise eines Nutzers an ^¬ gibt,

- ein Datenfeld, das eine von einem Nutzer zu erfüllende Auf ^¬ gabe 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 an ^¬ gibt, 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 Aktualisierungs ^¬ periode 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 einzel ^¬ ner Datenfelder des Datensatzes stammen,

- mindestens ein Datenfeld, dessen Wert angibt, ob die Daten des Datensatzes oder die Daten einzelner Datenfelder des Da- tensatzes 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. Objek- te 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 Be ^¬ wertungsmaß für die Aktualität und damit auch der Zuverläs- sigkeit 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 ver- wendet werden, d.h. zur Bestimmung eines Fehlermaßes.

Die Archivierung der Daten kann für Anwendungsprogramme rele ^¬ vant 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, Fahrge ^¬ stell), 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 Pro ^¬ gramm 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 Ser- vicetechniker . Die allgemeine Datenfeldgruppe kann mindestens eines, mindestens zwei oder alle der folgenden Datenfelder oder Datenfeldgruppen enthalten:

- mindestens ein Datenfeld oder eine Datenfeldgruppe zur An ^¬ gabe einer Serviceauftragsnummer,

- mindestens ein Datenfeld oder eine Datenfeldgruppe einer GegenStandsnummer,

- mindestens ein Datenfeld oder eine Datenfeldgruppe zur An ^¬ gabe einer Fehlerbeschreibung,

- mindestens ein Datenfeld oder eine Datenfeldgruppe zur An- gäbe der Historie des Gegenstands,

- mindestens ein Datenfeld oder eine Datenfeldgruppe zur An ^¬ gebe der Relation zu anderen Komponenten,

- mindestens ein Datenfeld oder eine Datenfeldgruppe zur An ^¬ gabe einer Wartungsanleitung und/oder einer Empfehlung, - mindestens ein Datenfeld oder eine Datenfeldgruppe zur An ^¬ gabe einer Fehlermeldung oder mehrerer Fehlermeldungen, - mindestens ein Datenfeld oder eine Datenfeldgruppe zur An ^¬ gabe aktueller Informationen des Herstellers des Gegenstandes,

- mindestens ein Datenfeld oder eine Datenfeldgruppe zur An- gäbe von Empfehlungen des Herstellers,

- mindestens ein Datenfeld oder eine Datenfeldgruppe zur An ^¬ gabe der Rolle des Servicetechnikers, vorzugsweise Rang und/oder Fachgebiet, und/oder

- mindestens ein Datenfeld oder eine Datenfeldgruppe zur An- gäbe mindestens eines digitalen Netzwerkes in das der Ser ^¬ vicetechniker 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 Daten- modellbeschreibungssprache bekannt gemacht und bspw. für Testzwecke einer Implementierung verteilt wird. Das Datenmo- dell kann mindestens ein, mindestens zwei oder alle der fol ^¬ genden 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 techni ^¬ schen Gegenstands und/oder eines Ersatzteils,

- mindestens eine allgemeine Datenfeldgruppe, die folgende Datenfelder oder Datenfeldgruppen enthält:

- mindestens ein Datenfeld oder mindestens eine Daten- feldgruppe mit Angaben, die über eine erste Zeitdauer gleich bleiben, insbesondere ein Geburtsdatum oder ein Herstellungs- datum, ein Geschlecht, ein Bautyp, und/oder eine Privatadres ^¬ se,

- mindestens ein Datenfeld oder mindestens eine Daten ^¬ feldgruppe mit Angaben, die sich innerhalb der ersten Zeit- dauer mehrfach ändern, insbesondere ein vorübergehender Zustand, eine Aufgabe, eine Ort einer Person oder eines Gegen ^¬ standes und/oder eine Rolle, vorzugsweise eine Rolle die ein Nutzer oder der Gegenstand einnimmt, z.B. Angestellter, Mitarbeiter, Vorgesetzter, o.a.,

- 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 Daten ^¬ feld 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, mindes ^¬ tens 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. Ma ^¬ schinencode, des Diensterbringungsprogramm und/oder des Pro- gramms 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 vorzugswei ^¬ se ein Datenfeld zur Angabe des Eigentümers einer oder mehre ^¬ ren 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 Da ^¬ tenfeldgruppe genau einem Datenfeld oder genau einer Daten ^¬ feldgruppe zur Angabe der Rolle zugeordnet werden muss.

Beim Festlegen der Beziehungen wird auf Einhaltung der Nor- malformen 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 elektroni- sehe Datenbank (Repository) verwendet werden, insbesondere eine in einem Verfahren nach einem der vorhergehenden Ansprüche verwendete Datenbank. Die Datenbank kann Datensätze ent ^¬ halten, 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 mindes ^¬ tens 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 ent ^¬ hält oder aus einem ersten Datenfeld besteht, dessen Wert an ^¬ gibt, ob oder welches spezifische Datenfeld oder ob oder wel- che spezifische Datenfeldgruppe gültig sind.

Bei einer Ausgestaltung der Datenbank ist das Datenmodell ein relationales Datenmodell, dessen Beziehungen zwischen Daten- teilmodellen 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 ei- nen 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 Dienst- erbringungsprogramm 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 Ser- vice) 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 Verfahrensschrit- te enthalten. Auch ein zugehöriges Programm ist geschützt und kann beansprucht werden.

Bei einer Ausgestaltung ist auch die mobile DV-Anlage ge ^¬ schützt, insbesondere mit dem darauf installierten Anwen- dungsprogramm. 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 bezie ^¬ hen sich jedoch insbesondere auf die technische Realisierung in einer Datenverarbeitungsanlage, insbesondere auf Nachrich- ten, die Datensätze enthalten, die als Instanzen des Datenmo ^¬ dells bzw. Teilinstanzen von Teilmodellen des Datenmodells angesehen werden können oder auf in einem Speicher gespeicherte Datensätze, d.h. Instanzen, die die Datenmodelle be ^¬ rü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 Situati ^¬ on, 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 verarbei- ten:

- 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 entspre- chen,

- 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 Nut- zers :

a) nicht oder nur teilweise berücksichtigt wird, z.B. wird häufig nur der Standort ermittelt,

b) es keine übergreifende Kontext-Datenmodelle oder Daten ^¬ standards gibt, die eine Wiederverwendung von Kontextinforma- tionen 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 ei- ner 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. kontextintegrie ^¬ renden Service bzw. einer kontextintegrierenden Diensterbringung über die Context Integration Architektur zusammengeführt werden, siehe den in der Abbildung 1 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 ei- nem gewissen Anwendungsfall relevant sind. Aus diesem Grund kann es erforderlich sein, ein übergreifendes logisches Me- ta-Modell für Kontextdaten zu definieren, so dass sowohl Bu ^¬ siness Experten als auch IT (Informationstechnologie) Exper ^¬ ten 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. implemen ^¬ tierte Datenmodelle dient.

Um einen integrierten, modellierungsgetriebenen Entwicklungs- ansatz zu unterstützen, sollte ein plattformunabhängiges Kon ^¬ text-Datenmodell zudem mit existierenden logischen Datenmo ^¬ dellen 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 Figur 1.

Aktuell ist kein Service bekannt, der Kontextdaten aus ver ^¬ schiedenen 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". Ist 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 Model- üng, Reasoning and Management, UbiComp 2004 - The Sixth International Conference on Ubiquitous Computing, Notting ^¬ ham/England, 2004.

Für die logische Modellierung von Daten im Allgemeinen bietet sich zwar UML (Unified Markup Language) als ob- j ekt-orientierte Sprache an, jedoch ist diese Notation für IT Anwender gedacht und nicht für Business Experten und hat zu ^¬ dem 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üp- fung zu logischen Datenmodellen statt. Außerdem sind auch hier Software Engineers (Ingenieure) die Anwender, für Busi ^¬ ness Anwender ist die Notation nicht geeignet. Industrielösungen wie Google Places fokussieren sich auf die technische Repräsentation von Kontext in Form eines vordefi ^¬ nierten Schemas, die konzeptuelle Modellierungsebene wird nicht betrachtet. Für die Modellierung von Kontextdaten wird das Konzept eines logischen Metadatenmodells eingeführt. Das Konzept spezifi ^¬ ziert, dass einem "Context Owner" bzw. einem "Kontexteigentü ^¬ mer", z.B. einem Objekt bzw. Gegenstand oder einer Person, Kontextinformationen zugeordnet werden. Diese Kontextinforma- tionen können in zwei Kategorien aufgeteilt werden:

1) Bei den allgemeinen Einstellungen bzw. den sogenannten "General Settings", handelt es sich um meist statische Kon ^¬ textinformationen, 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 da ^¬ durch, dass sie sich dynamisch ändern können, z.B.

- der aktuelle Aufenthaltsort einer Person oder eines Gegen ^¬ stands . 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 Abbildung 2, 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 wer- den. 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ün- del an Kontextinformationen dar. So beinhaltet z.B. die Domäne "Location" die Postadresse, lokale Adresse (wie Gebäude ^¬ nummer, Stockwerk) , und GPS (Global Positioning System) Koordinaten. Auf Ebene des Metadatenmodells können jegliche Clus ^¬ ter 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 Abbildung 3, 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 Metadatenmo ^¬ dells 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 Ge- Schä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äl- len 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 Kontextda- ten 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 Applikatio ^¬ nen 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ün ^¬ dige Fahrt zum Bahnhof nutzt er z.B. den Car Sharing Anbieter DriveNow, falls zurzeit ein Fahrzeug in der Nähe seines Woh ^¬ nortes vorhanden ist und es ausreichend Parkplätze im Park- haus 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 Schnelllade ^¬ sä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 notwen- dig/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 Restaurant ^¬ empfehlungen .

Folgende Probleme treten auf:

- Buchung: Übergreifende Buchungsmöglichkeiten werden derzeit nicht angeboten, so dass der Reisende sich bei den verschie ^¬ denen 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 Aus- kunftsservices zur Verfügung gestellt werden, z.B. Online Na ^¬ vigation 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, per ^¬ sonalisierte 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 Frei- tag,

- 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,

- Bezahlungl: 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 Servicetechni ^¬ ker

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 verschiede ^¬ nen 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 Kom ^¬ ponenten 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. Rieh 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 Zusam- menhang mit der folgenden Beschreibung der Ausführungsbeispiele. Sofern in dieser Anmeldung der Begriff "kann" verwendet wird, handelt es sich sowohl um die technische Möglich- keit als auch um die tatsächliche technische Umsetzung. So ^¬ fern 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:

Fig. 1 einen Überblick über Netzwerkeinheiten, Fig. 2 Festlegungen für Datenfelder und Datenformate,

Fig. 3 detaillierte Festlegungen für Datenfelder und Datenformate, Fig. 4 Display-Ansichten oder Bildschirmansichten an einem

Endgerät,

Fig. 5 eine Tabelle zur Verdeutlichung der Zuordnung von

Daten zu zwei Nutzerprofilen oder zu zwei Nutzer- rollen,

Fig. 6 einen Datensatz, der in einer Antwortnachricht

übertragen wird, Fig. 7 Verfahrensschritte, die in einem Endgerät ausge ^¬ führt werden,

Fig. 8 Verfahrensschritte, die in einer zentralen DV- Anlage (Datenverarbeitungsanlage) ausgeführt wer ^¬ den,

Fig. 9 ein erstes Anwendungsszenario mit einem Endgerät, Fig. 10 ein zweites Anwendungsszenario mit zwei Endgeräten, und Fig. 11 Einheiten einer zentralen DV-Anlage.

Die Figur 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 kontextin- tegrierenden 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 Daten- banken 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 zuge- hö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. Anwendungs ^¬ programme angeboten werden. Für die Datenbanken DB1 bis DB20 gilt:

- die Datenbank DB1 speichert bspw. Ortsdaten, z.B. Mobilfunkbetreiber o.a.,

- die Datenbank DB2 speichert bspw. Profildaten, siehe Figur 2 bzw. Figur 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 In ^¬ halte 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 er- lä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 Figur 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. Insbeson ^¬ dere 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 Figur 1 gezeigten Datenfeldern 52, 54, 55, 57, 56 und 58 zugehörige Datenformate festgelegt werden. Das Datenmodell kann auch weitere Datenfelder enthal ^¬ ten . Die Figur 3 zeigt detaillierte Festlegungen 100 für Datenfel ^¬ der und Datenformate. Es gelten die an Hand der Figur 2 ge ^¬ machten Aussagen entsprechend für:

- ein dem Besitzerdatum 52 entsprechendes Besitzerdatum 52b,

- den allgemeinen Einstellungsdaten 54 entsprechende Einstel- lungsdaten 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 entspre ^¬ chen 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 Figur 3 gezeigten Instanz bzw. zu dem in dem in der Figur 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, insbe ^¬ sondere 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 ei ^¬ nes 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 Wartungs ^¬ ortes 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 Aus ^¬ wahldatum 57b zugeordnet ist bzw. dieses ausprägt (Instanz),

- ein Interessendatum 140, das den auswahlspezifischen Ein- Stellungsdaten 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 Ein- Stellungsdaten 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 Figur 4 zeigt Display-Ansichten oder Bildschirmansichten 200 bis 204 an einem Endgerät, z.B. am mobilen Endgerät 454, 454c, 454d, siehe Figuren 9 und 10, z.B. an einem Mobiltele ^¬ fon 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 Schiebe ^¬ schalter (Toggle) . Die Festlegung des Wertes des Auswahlda ^¬ tums 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 Nut ^¬ zers und ist optional. Es werden vier Textfelder 220 bis 226 dargestellt, die bspw. den in der Figur 5 in der Spalte "Bu ^¬ siness" gezeigten Einstellungen für die Rolle "Geschäft" ent- sprechen. 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 Aus- wahlfeldern.

Die Bildschirmansicht 204, dient bspw. ebenfalls nur der In ^¬ formation des Nutzers und kann optional sein. Es werden vier Textfelder 230 bis 236 dargestellt, die bspw. den in der Figur 5 in der rechten Spalte gezeigten Einstellungen für die Rolle "privat" entsprechen. So zeigt der Text 230 bspw. wie ^¬ der 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öglichkei ^¬ ten zur Auswahl der Daten gegeben werden, d.h. Kombination von angezeigtem Text und Auswahlfeldern. Die anderen Textfel- der werden unten an Hand der Figur 5 näher erläutert.

Pfeile 240, 242 zeigen die Umschaltmöglichkeit des Nutzers zwischen verschiedenen Profilen bzw. Rollen. Die Figur 5 zeigt eine Tabelle 250 zur Verdeutlichung der Zu ^¬ ordnung 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 Figur4, Textfeld 220,

- firmenspezifische Daten, siehe Figur4, Textfeld 220,

- Daten aus digitalen sozialen Netzwerken, siehe Figur4, Textfeld 224, und

- zusätzliche Präferenzen, siehe Figur4, Textfeld 226.

Für die Rolle "privat" gelten im Ausführungsbeispiel die fol ^¬ genden Daten:

- allgemeine Daten, siehe Figur4, Textfeld 230,

- Daten aus digitalen sozialen Netzwerken, siehe Figur4, Textfeld 232,

- zusätzliche Präferenzen siehe Figur4, Textfeld 234,, und

- private Präferenzen, siehe Figur4, Textfeld 236.

Die für die Rollen "Geschäft" und "privat" erforderlichen Festlegungen können sich von den in den Figuren 2 und 3 gezeigten Festlegungen unterscheiden bzw. zumindest teilweise mit diesen Festlegungen übereinstimmen. Bei einem anderen Ausführungsbeispiel gibt es die Daten "pri ^¬ vate 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 Figur 6 zeigt einen Datensatz 300, der in einer Antwortnachricht übertragen wird, und für den die in der Figur 2 gezeigten Vorgaben erfüllt sind. Der Datensatz 300 entspricht damit der Sicht eines Anwendungsprogramms 18 auf einem mobi ^¬ len Endgerät, siehe bspw. Endgerät 454, 454c, 454d in den Fi ^¬ guren 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 beschrie ^¬ ben 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 Verweisda- tum oder eine Verweisliste, ggf. ist das Datenfeld 314 optio ^¬ nal, 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. Adress ^¬ daten 124 in der Figur 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 Kom ^¬ fort-Klasse für Bahnfahrten, eine bevorzugte zu verwendende Komfort-Klasse für Flugreisen, eine bevorzugte oder zu ver ^¬ wendende Fluglinie und/oder eine bevorzugte oder zu verwen ^¬ dende 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 ent- halten:

- 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ön- nen mehrere Datensätze 80c mit voneinander verschiedenen Inhalten bspw. jedem der in der Figur 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 Figur 1, Datenbank DB20, bzw. die Figuren 9 und 10, Datenbank DB2 Ob bzw. DB20c.

Die Figur 7 zeigt Verfahrensschritte 350 bis 362, die in ei- nem 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 Figur 4 erläuterte Auswahlmöglichkeit eingegeben worden ist.

In einem nächsten Schritt 354 wird unter Verwendung des Aus- wahldatums eine Anfrage an den CIS gestellt, d.h. den kon ^¬ textintegrierenden Service-Rechner .

Die im bzw. vom CIS-Rechner ausgeführten Schritte werden unten an Hand der Figur 8 näher erläutert und gelten ebenfalls für die Figuren 9 und 10 sowie für die Figur 11.

In einem Schritt 358 werden im Endgerät Daten in einer Antwortnachricht empfangen, siehe bspw. die Figur 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. Alter- nativ 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 hinter ^¬ einander an den CIS-Rechner gestellt werden. Die Figur 8 zeigt Verfahrensschritte 400 bis 410, die in ei ^¬ ner zentralen DV-Anlage (Datenverarbeitungsanlage) ausgeführt werden, siehe bspw. Figur 1, Rechner 14 bzw. CIS sowie Figur 9, Rechner 490, Figur 10, Rechner 490c sowie Figur 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 ei ^¬ ne 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 Da- tensatzes 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 wer- den kann.

In einem Schritt 404 ermittelt der CIS-Rechner die angeforderten Daten, wobei auch auf externe Rechner bzw. Datenbanken zugegriffen wird, siehe bspw. die Figur 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 ermit- telten Daten in einer Antwortnachricht von dem zentralen

Rechner (CIS) an das mobile Endgerät gesendet, das die Anfor ^¬ derungsnachricht gesendet hat.

Die Figur 9 zeigt ein erstes Anwendungsszenario mit einem Endgerät 454. Das Endgerät 454 wird von einem Nutzer 452 ge ^¬ nutzt 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 ausge ^¬ führtes Anwendungsprogramm 480 eine Anforderungsnachricht 492 an den Rechner bzw. das Diensterbringungsprogramm 490 (CIS) . Die Anforderungsnachricht 492 enthält ein Auswahldatum mit einem Wert AWla, 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 Daten- banken DBlb bis DB6b zu, die den Datenbanken DB1 bis DB6 ent ^¬ sprechen, um die Anforderung zu erfüllen, siehe Zugriffe 494 und 496. Dabei werden aus diesen Datenbanken DBlb 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 spei ^¬ chert 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 Pro ^¬ gramm 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 tech- nischen Anlage oder ein anderes Programm.

Zu einem Zeitpunkt t4, der nach dem Zeitpunkt t2 liegt, sen ^¬ det das Programm 480 eine weitere Anforderungsnachricht 500 an den zentralen Rechner 490, wobei sich zwischenzeitlich aber der Wert des Auswahldatums auf einen Wert AWlb 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 DBlb 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 Nach ^¬ richt 502 enthält bspw. private Präferenzdaten und vorzugs ^¬ weise 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 Bahn- fahrt 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 Pro- gramm greift auf den Rechner 490 bzw. den CIS-Rechner zu.

Die Figur 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 Mobil- telefon bzw. Handy. Das Endgerät 454d wird von einem Nutzer 452d genutzt und ist bspw. ebenfalls ein Smartphone, ein Mo ^¬ biltelefon 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 Aus ^¬ wahldatum mit einem Wert AWlal, der angibt, das der Nutzer 452c das Endgerät 454c geschäftlich nutzt. Alternativ wird ein Wert AWlbl 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 Da ^¬ tenbanken DBlc 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 DBlc bis DB6c Daten gelesen, insbesondere firmenspezifische Daten.

Das Diensterbringungsprogramm 490c erzeugt nach der Beschaf- fung der Daten eine Antwortnachricht 520, die an das Programm 480c gesendet wird. Das Diensterbringungsprogramm 490c spei ^¬ chert 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 ver- merkt, siehe Zugriff 518.

Nach dem Empfang der Antwortnachricht 512 erbringt das Pro ^¬ gramm 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 Anforde ^¬ rungsnachricht 530 an den zentralen Rechner 490c, wobei ein Auswahldatum mit einem Wert AWla2 (Geschäft) oder AWlb2 (privat) angegeben wird. Im Beispiel sei angenommen, das der Wert AWlb2 (privat) gilt. Der Rechner 490c greift wieder mindestens auf eine der Daten ^¬ banken DBlc 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äferenzda ^¬ ten und vorzugsweise keine firmenspezifischen Daten. Sind firmenspezifische Daten in der Nachricht 540 enthalten, so werden diese firmenspezifischen Daten jedoch nicht vom Pro- gramm 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ücksich ^¬ tigt .

Die DV-Anlage 504c ist bspw. ein Buchungssystem für eine Bahnfahrt oder für einen Flug, insbesondere ein Buchungssys ^¬ tem einer speziellen Bahngesellschaft oder einer speziellen Fluggesellschaft .

Die Figur 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 Mik- rocontroller . Weiterhin enthält die DV-Anlage 490 einen Spei ^¬ cher M, in dem bspw. Programmbefehle des CIS-Programms ge ^¬ speichert sind. Der Speicher M ist bspw. ein flüchtig spei- chernder 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 DBl 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 be ^¬ schrieben worden ist, ist die Erfindung nicht durch die offenbarten Beispiele eingeschränkt und andere Variationen kön- nen 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.