Die Erfindung betrifft ein verteiltes Warenwirtschaftssystem, insbesondere ein Cloud- basiertes Warenwirtschaftssystem.

Wo früher Waren nur über den stationären Absatzkanal vertrieben wurden, d.h. zum Beispiel von Händlern in Ladengeschäften an Kunden verkauft wurden, gibt es heute eine Vielzahl von unterschiedlichen Absatzkanälen. Dabei versteht man unter dem Begriff Absatzkanal den Weg oder Fluss, den eine Ware zwischen Hersteller und Kunde nimmt. Waren können dabei insbesondere Produkte sein, die auch als physische Objekte bezeichnet werden können.

Waren können zum Beispiel den direkten Weg zwischen Hersteller und Kunden nehmen, oder zunächst an Großhändler geliefert werden, so dass die Ware dann entweder direkt von diesen an den Kunden geliefert wird oder an einen Händler, der dann wiederum die Ware an den Kunden verkauft. Dabei gewinnt in der heutigen Zeit der Absatz von Waren über das Internet immer stärkere Bedeutung und verdrängt dabei immer weiter den regulären stationären Handel, insbesondere weil der Online- Handel es erlaubt, Herstellern und Großhändlern direkt in Kontakt mit dem Kunden zu treten und Waren über diesen Absatzkanal zu verkaufen. Oftmals unterscheidet sich auch der Preis zwischen dem Online-Absatzkanal und dem stationären Absatzkanal sehr stark, weil der Online-Absatzkanal im Gegensatz zum stationären Absatzkanal im Allgemeinen geringere Selbstkosten hat und viel schneller auf veränderte

Marktgegebenheiten reagieren und die Preise entsprechend anpassen kann.

In der heutigen Zeit herrscht also eine heterogene Absatzkanalsituation vor. Dies stellt die Händler, aber auch Hersteller vor die Problematik, ihre Warenwirtschaftssysteme auf das Verhalten des Kunden, d.h. aus welchem Kanal sich dieser bedient, anzupassen. Innerhalb eines Warenwirtschaftssystems werden dabei alle mengen- und wertmäßigen Änderungen eines Warenflusses erfasst. Dabei werden die Waren selbst innerhalb der Systeme mit zum Beispiel allgemeinen Produktidentifikationen oder mit eineindeutigen Produktidentifikationen abgebildet. Allgemeine

Produktidentifikationen bilden beispielsweise die Waren auf der Produkttypebene mittels einer generellen EAN-Nummer ab, wohingegen eineindeutige

Produktidentifikationen einzelne Waren auf der Produktebene mittels einer EAN- Nummer und zumindest einer zusätzlichen Identifikation, wie zum Beispiel

Seriennummern, abbilden. D.h. es können entweder Warentypen oder einzelne Waren in den Warenwirtschaftssystemen abgebildet werden.

Die heterogene Absatzkanalsituation stellt insbesondere nicht in einem

Handelsverbund organisierten Händlern, d.h. Händler, welche nicht mit einem übergeordneten Warenwirtschaftssystem agieren, vor die Problematik, ihre

Warenflüsse stationär sowie online zu überwachen und abzubilden. Dabei müssen nicht nur die schnell schwankenden Mengen abgebildet werden, sondern auch die Preisfluktuationen nahezu in Echtzeit abgebildet werden. Dies ist gerade für stationäre Einzelhändler momentan mit den vorhandenen Warenwirtschaftssystemen und deren technischen Möglichkeiten nicht realisierbar. Bekannte Warenwirtschaftssysteme sind nicht in der Lage, mit den dynamischen Echtzeitpreis- und

Verfügbarkeitsinformationen mitzuhalten; dies gilt insbesondere für die

Warenbestände der stationären Einzelhändler. Diese Informationen den Kunden zur Verfügung zu stellen ist aber zwingende Voraussetzung, um konkurrenzfähig und attraktiv für Kunden zu bleiben, weil es gerade durch das immer stärkere und schnell wachsende Internetangebot zu Preiserosionen kommt. Passt sich der stationäre Absatzkanal hierbei nicht dem Online-Absatzkanal an, beispielsweise wird der stationäre Preis nicht dem Online-Preis angepasst oder kann der Kunde nicht vorab sehen, ob eine Ware verfügbar ist, so verliert der stationäre Absatzkanal immer weiter an Bedeutung.

Die heterogene Absatzkanalsituation stellt aber auch Hersteller vor die Problematik, dass Warenflüsse nicht mehr einfach nachvollziehbar sind und in den

Warenwirtschaftssystemen abgebildet werden können. Wurden Waren vormals vom Hersteller zum stationären Händler gesendet und dort verkauft, eventuell noch unter Zwischenschaltung von autorisierten Großhändlern, fallen beim immer stärker werdenden Online-Absatzkanal hier ganze Warenflüsse weg, weil Großhändler beispielsweise direkt die Bestellungen der Kunden über das Internet bekommen und direkt die Ware an den Kunden im Namen und auf Rechnung des Herstellers versenden. In diesen Fällen ist der Fluss, den die Ware vom Hersteller zum Kunden zurückgelegt hat, für den Hersteller nicht mehr einfach nachvollziehbar, d.h. der Hersteller weiß nicht, über welchen Absatzkanal der Kunde das Produkt letztendlich bekommen hat. Des Weiteren hat sich mit Aufkommen des Online-Handels ein

Absatzkanal durch bessere Preistransparenz ausgeweitet, nämlich der sogenannte Graumarkt. Hierbei wird häufig überschüssige Ware von nicht autorisierten

Großhändlern von nationalen und internationalen Händlern zu einem günstigen Preis eingekauft, wobei der günstige Einkaufpreis zum Beispiel durch Einrechnung von Rabatten und Boni der Hersteller erreicht wird, die aber originär nicht für den Zwecke der Senkung des Einkaufspreises gedacht waren, sondern beispielsweise für

Werbemaßnahmen, Produktplatzierung, etc. Diese nicht autorisierten Großhändler liefern dann an Händler zu einem geringeren Preis, als dies durch autorisierte

Großhändler der Fall ist. Da die heterogene Absatzkanalsituation unüberschaubar für die Hersteller geworden ist, führen diese immer öfter Testkäufe durch oder animieren den Kunden, gekaufte Produkte zu registrieren, um so Warenflüsse nachvollziehbar zu machen.

Die heterogene Absatzkanalsituation stellt aber auch Kunden vor die Problematik, dass diese nicht mehr einfach herausfinden können, wo sie Ware zum günstigsten Preis erhalten oder unter Berücksichtigung von zusätzlichen Dienstleistungen (Beratung, Montage, etc.) am preiswertesten erhalten oder wo Ware eventuell noch stationär vorhanden ist bzw. zu welchem Preis diese dann stationär angeboten wird. Selbst wenn Verfügbarkeitsanfragen möglich sind, so ist der stationäre Preis meistens schlechter als ein im Internet angebotener Preis oder es ist aufwendig und es verstreicht viel Zeit, bis eine Anfrage beantwortet wird. Dies führt entweder dazu, dass Kunden die Ware direkt online bestellen oder sich die Ware nur stationär ansehen, aber letztendlich doch online kaufen.

D.h. es werden Warenwirtschaftssysteme benötigt, die die neue heterogene

Absatzkanalsituation abbilden können.

Ein Beispiel eines derartigen Warenwirtschaftssystems durch absolute

Warenverfolgung ist in US 2012/0054049 Ai gezeigt. Hier werden die Waren bereits bei der Herstellung mit einer eineindeutigen Produktidentifikation versehen, beispielsweise mit einer eineindeutigen Seriennummer, und diese eineindeutige Produktidentifikation wird in einer Datenbank eines zentralen Servers gespeichert. Alle Änderungen am Standort vor dem Verkauf der Ware werden von Logistikunternehmen, die die Produktidentifikation scannen, an den zentralen Server gesendet, der die Standortänderung in der Datenbank den entsprechenden eineindeutigen

Produktidentifikationen zuordnet. Wird das Produkt an den Kunden verkauft, wird auch diese Information, entweder vom stationären Händler oder von den Online- Händlern, an den zentralen Server gesendet, wobei auch der Preis der verkauften Ware an den zentralen Server gesendet werden kann. In diesem Fall handelt es sich also um ein zentrales geschlossenes Warenwirtschaftssystem, welches den Warenfluss totalitär und proprietär in einem zentralen Server abbildet.

Das in US 2012/0054049 Ai beschriebene Warenwirtschaftssystem hat aber den Nachteil, dass große Datenmengen versendet werden, die zentral gespeichert werden. Des Weiteren hat dieses Warenwirtschaftssystem den Nachteil, dass eine große Anzahl an Akteuren, wie Hersteller, Händler, Kunden und Logistikunternehmen, nicht nur Zugriff auf das gleiche zentrale Warenwirtschaftssystem haben müssen, sondern ihre eigenen Systeme auf dieses anpassen müssen. Des Weiteren ergibt sich bei einem derartigen System auch die Problematik der Datensouveränität. Des Weiteren sieht das beschriebene Warenwirtschaftssystem zwar eine allumfängliche Nachvollziehbarkeit der Warenflüsse vor, allerdings keine Interaktion zwischen Herstellern, Händlern und Kunden, um gezielt Einfluss zu nehmen auf Warenflüsse.

Es stellt sich daher die Aufgabe, ein verteiltes Warenwirtschaftssystem bereitzustellen, dass die Nachteile der bekannten Warenwirtschaftssysteme nicht aufweist und den Herstellern, Händlern und Kunden ermöglicht einfach zu interagieren, aber gleichzeitig die Datensouveränität der einzelnen Akteure gewährleistet. D.h. dass jeder Akteur den Zugriff auf seine eigenen Daten gezielt steuern kann.

Diese Aufgabe wird gelöst mit den Gegenständen der unabhängigen Ansprüche, wobei die Unteransprüche bevorzugte Ausführungsformen der beanspruchten Gegenstände darstellen.

Die Aufgabe wird gelöst durch ein erfindungsgemäßes Verfahren zum Betreiben eines Cloud-Speichers, der auch als Warenwirtschaftssystemspeicher bezeichnet werden kann. Der Cloud-Speicher kann dabei ein Speicher sein, der sich auf einem zentralen Server befindet oder der auf mehrere Server verteilt ist. Dabei kann der Speicher auch ein redundanter Speicher sein, d.h. der gleiche Inhalt des Speichers kann nicht nur auf einem Server vorhanden sein, sondern kann auch auf zumindest einem weiteren Server vorhanden sein. Ein Server ist dabei als jegliches Gerät anzusehen, welches zumindest eine Schnittstelle zu zumindest einem Netzwerk aufweist und das zumindest einen Speicher aufweist. Das zumindest eine Netzwerk kann dabei jedes beliebige Netzwerk sein, über welches Daten ausgetauscht werden können, zum Beispiel das Internet. Der Cloud-Speicher steht dabei erfindungsgemäß in selektiver Kommunikation mit zumindest einem ersten Netzwerkteilnehmer, einem zweiten Netzwerkteilnehmer und einem dritten Netzwerkteilnehmer. Selektive Kommunikation in diesem Fall bedeutet, dass der Cloud-Speicher nicht ständig eine Verbindung mit den jeweiligen

Netzwerkteilnehmem hat, sondern nur mit diesen eine Verbindung aufbaut, wenn Daten ausgetauscht werden sollen. Die Netzwerkteilnehmer können Geräte sein, die eine Schnittstelle zu zumindest einem Netzwerk aufweisen. Die Netzwerkteilnehmer können dabei unterschiedlich ausgestaltet sein und können Zugang zu

unterschiedlichen Netzwerken aufweisen. Die Netzwerke müssen es nur erlauben, dass eine Kommunikation mit dem Cloud-Speicher möglich ist. Dabei kann der erste Netzwerkteilnehmer ein Gerät sein, welches bei einem Händler vorgehalten wird, beispielsweise kann dies ein Computer, Tablet oder Kassensystem sein, welches eine Schnittstelle aufweist, die den Zugang zu zumindest einem Netzwerk, z.B. dem

Internet, erlaubt. Dabei muss die Funktionalität des ersten Netzwerkteilnehmers nicht vollständig auf dem Gerät, welches beim Händler vorgehalten wird, selbst

implementiert sein, sondern kann auch im Cloud-Speicher implementiert sein. Das erste Netzwerkgerät muss in diesem Fall nur einen Zugriff auf die entsprechende implementierte Funktionalität bereitstellen. Es kann auch sein, dass der zweite Netzwerkteilnehmer nicht beim Händler vorgehalten wird, sondern bei einem

Großhändler, oder dass die gleiche Funktionalität wie beim Händler auch beim

Großhändler implementiert wird, insbesondere wenn der Großhändler auch direkt an Kunden verkauft ohne Zwischenschaltung eines Händlers. Der zweite

Netzwerkteilnehmer kann ein Gerät sein, welches bei einem Kunden vorgehalten wird, beispielsweise ein Computer, Tablet oder Smartphone, welches eine Schnittstelle aufweist, die den Zugang zu zumindest einem Netzwerk, z.B. dem Internet, erlaubt. Dabei muss die Funktionalität des zweiten Netzwerkteilnehmers nicht vollständig auf dem Gerät, welches beim Kunden vorgehalten wird, selbst implementiert sein, sondern kann auch im Cloud-Speicher implementiert sein. Das zweite Netzwerkgerät muss in diesem Fall nur einen Zugriff auf die entsprechende implementierte Funktionalität bereitstellen. Der dritte Netzwerkteilnehmer kann ein Gerät sein, welches bei einem Hersteller vorgehalten wird, beispielsweise ein Computer oder Server, welches eine Schnittstelle aufweist, die den Zugang zu zumindest einem Netzwerk, z.B. dem Internet, erlaubt. Dabei muss die Funktionalität des dritten Netzwerkteilnehmers nicht vollständig auf dem Gerät, welches beim Hersteller vorgehalten wird, selbst

implementiert sein, sondern kann auch im Cloud-Speicher implementiert sein. Das dritte Netzwerkgerät muss in diesem Fall nur einen Zugriff auf die entsprechende implementierte Funktionalität bereitstellen. Es kann auch sein, dass der dritte

Netzwerkteilnehmer nicht beim Hersteller vorgehalten wird, sondern bei einem

Großhändler, oder dass die gleiche Funktionalität wie beim Hersteller auch beim Großhändler implementiert wird.

Das erfindungsgemäße Verfahren umfasst die Schritte von Empfangen von ersten Daten von dem ersten Netzwerkteilnehmer an dem Cloud-Speicher, wobei die ersten Daten zugehörig sind zu einem physischen Objekt. Das physische Objekt kann beispielsweise eine Ware oder Produkt sein, welche bzw. welches am Ort des ersten Netzwerkteilnehmers vorhanden ist. Beispielsweise kann der erste Netzwerkteilnehmer eine Eingabeeinheit aufweisen, mit deren Hilfe die ersten Daten betreffend das physische Objekt eingegeben werden können. Dies kann beispielsweise mit Hilfe einer Tastatur oder eines Scanners geschehen. Die ersten Daten können dabei beispielsweise die für ein Warenwirtschaftssystem charakterisierenden Daten aufweisen, wie beispielsweise die Menge und den Preis eines physischen Objektes. Die ersten Daten können dann im Cloud-Speicher gespeichert werden, beispielsweise in einem dem ersten Netzwerkteilnehmer zugehörigen Teil des Cloud-Speichers. Die ersten Daten selbst können auffindbar sein durch eine dem physischen Objekt zugehörige

Identifikation, die ebenfalls auf dem Cloud-Speicher gespeichert ist. Beispielsweise kann auf dem Cloud-Speicher die Produktidentifikation eines physischen Objektes oder eines physischen Objekttyps gespeichert sein und die empfangenen ersten Daten können dieser Produktidentifikation zugeordnet werden. Dabei kann eine

Produktidentifikation derart ausgestaltet sein, dass diese eine eineindeutige

Produktidentifikation ist, d.h. die Produktidentifikation identifiziert genau ein einzelnes physisches Objekt. Die Produktidentifikation kann aber auch derart ausgestaltet sein, dass die Produktidentifikation einen Objekttyp identifiziert, d.h. die Produktidentifikation identifiziert eine Vielzahl von physischen Objekten des gleichen Typs. Dabei teilen physische Objekte des gleichen Typs zumindest ein diesen Typ charakterisierendes Merkmal. Hierbei können nicht nur erste Daten von einem physischen Objekt von einem ersten Netzwerkteilnehmer an dem Cloud-Speicher empfangen werden, sondern eine Vielzahl von ersten Daten von einer Vielzahl von ersten Netzwerkteilnehmem betreffend eine Vielzahl von physischen Objekten. Es ist dabei auch möglich, dass die ersten Daten nicht nur ein einzelnes physisches Objekt betreffen, sondern eine Vielzahl von physischen Objekten oder eine Vielzahl von physischen Objekttypen.

In einem weiteren Schritt weist das erfindungsgemäße Verfahren auf, Empfangen von Anfragedaten, die von einem zweiten Netzwerkteilnehmer gesendet wurden. Diese Anfragedaten können sich beziehen auf ein spezielles physisches Objekt, eine Vielzahl von physischen Objekten, einen speziellen ersten Netzwerkteilnehmer und/oder eine spezielle Untermenge von ersten Netzwerkteilnehmern. Dabei kann der zweite

Netzwerkteilnehmer eine Eingabeeinheit aufweisen, mit deren Hilfe die Anfragedaten eingegeben werden können. Auch hierbei können Anfragedaten nicht nur von einem zweiten Netzwerkteilnehmer an dem Cloud-Speicher empfangen werden, sondern von einer Vielzahl von zweiten Netzwerkteilnehmern. Die Anfragedaten können am Cloud- Speicher entweder direkt von dem zweiten Netzwerkteilnehmer empfangen werden oder können an den Cloud-Speicher weitergeleitet werden, d.h. indirekt empfangen werden.

In einem weiteren Schritt weist das erfindungsgemäße Verfahren auf, Empfangen von zweiten Daten von einem dritten Netzwerkteilnehmer, wobei die zweiten Daten zugehörig sind zu den ersten Daten und zumindest ein Datum aufweisen, welches angepasst ist, die ersten Daten zu ändern, zumindest teilweise basierend auf den empfangenen Anfragedaten. Beispielsweise können die zweiten Daten für ein

Warenwirtschaftssystem charakterisierende Daten aufweisen, zum Beispiel einen Preis eines einzelnen physischen Objektes oder eines Typs eines physischen Objektes. Zum Beispiel kann der Cloud-Speicher den dritten Netzwerkteilnehmer über die

Anfragedaten informieren oder der Cloud-Speicher kann diese beispielsweise dem dritten Netzwerkteilnehmer zur Verfügung stellen, also diesem entweder senden oder zum Abruf bereitstellen. Es ist auch denkbar, dass der Cloud-Speicher dem dritten Netzwerkteilnehmer Statistiken bzgl. der Anfragedaten bereitstellt. Hierzu kann der Cloud-Speicher den Schritt des Verarbeitens der Anfragedaten aufweisen. Anhand der Anfragedaten oder der verarbeiteten Anfragedaten kann der dritte Netzwerkteilnehmer bestimmen, wie viel Interesse an einem physischen Objekt oder einem Typ eines physischen Objekts besteht und kann entsprechend den Preis anpassen. Es ist aber auch denkbar, dass durch die Abwesenheit von Anfragedaten eine Änderung der ersten Daten angezeigt ist und dementsprechend zweite Daten erzeugt werden. Es ist aber auch denkbar, dass auf Grund der aktuellen Lagersituation beim Hersteller, dieser den Preis anpasst, um so den Warenfluss zu steigern, um wieder Lagerkapazitäten zu erhalten. Es ist auch denkbar, dass der Preis auf Grund von Neukundengewinnung oder zur Promotion eines besonderen physischen Objektes angepasst wird. Dem Fachmann ist aber bewusst, dass es auch noch andere Situationen und äußere Zwänge geben wird, die den dritten Netzwerkteilnehmer zu einer Änderung der ersten Daten bewegt, um die Warenflüsse gezielt zu steuern.

Der Cloud-Speicher kann dann erfindungsgemäß die ersten Daten zumindest zum Teil basierend auf den zweiten Daten und den Anfragedaten ändern. Dieses Ändern kann darin bestehen, die ersten Daten, also zum Beispiel den Preis des physischen Objektes anhand des neuen Preises, erhalten vom dritten Netzwerkteilnehmer, zu ändern. D.h. nach der Änderung sind die ersten Daten in dem Cloud-Speicher, die beispielsweise über die Produktidentifikation auffindbar sind, geändert.

Das erfindungsgemäße Verfahren weist weiter den Schritt des Sendens des geänderten Teils der ersten Daten an den ersten Netzwerkteilnehmer auf. D.h. der erste

Netzwerkteilnehmer erhält Delta-Daten zu seinen ersten Daten, um seine eigenen ersten Daten anzupassen. Delta-Daten dabei meint, dass diese gegenüber den originären Daten kleiner sind. Zum Beispiel ist die Bitanzahl zur Repräsentation des geänderten Teils der ersten Daten kleiner als die Bitanazahl zur Repräsentation der originären ersten Daten. Unter dem Begriff Delta-Daten versteht man die Speicherung oder Übertragung von Datenveränderungen anstatt der gesamten Daten. Um Delta- Daten zu speichern und zu übertragen, kann die symmetrische oder die direkte

Deltavariante verwendet werden. Bei der symmetrischen Variante werden alle notwendigen Modifikationen zwischen zwei unterschiedlichen Versionen der Daten gespeichert und übertragen. Die direkte Deltavariante speichert und überträgt die Änderungsoperatoren die nötig sind, um aus einer Version der Daten die andere Version der Daten zu machen. Zum Beispiel erhält der erste Netzwerkteilnehmer im ersten Fall (symmetrische Variante) einen neuen Preis für ein physisches Objekt, im zweiten Fall (direkte Variante) einen Veränderungspreis oder eine Prozentzahl, um die der Preis des physischen Objektes gesenkt werden kann. Das Senden nur eines Teils der Daten hat den Vorteil, dass weniger redundante Daten vorgehalten werden müssen. Des Weiteren ergibt sich ein reduzierter Umfang der Datenübertragung und damit Einsparung in der Übertragungsbandbreite, was insbesondere für den mobilen

Anwendungsfall für den zweiten Netzwerkteilnehmer, allerdings auch für reduzierte Bandbreiten des ersten Netzwerkteilnehmers, vorteilhaft ist. Das erfindungsgemäße Verfahren ermöglicht erstmalig, dass Händler, Hersteller und Kunden miteinander agieren können, ohne dass hierzu große Datenmengen nötig sind oder das aufwendige Schnittstellen realisiert werden müssen. Diese Interaktion ermöglicht nicht nur die Nachvollziehbarkeit der Warenflüsse, sondern auch deren gezielte Steuerung.

In einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens weist dieses weiter das Empfangen einer Objektbeschreibung an dem Cloud-Speicher auf. Die Objektbeschreibung kann dabei vom dritten Netzwerkteilnehmer empfangen werden oder von einem anderen Gerät. Beispielsweise kann der Hersteller eine Beschreibung eines physischen Objektes oder einer Vielzahl von physischen Objekten an den Cloud- Speicher senden. Diese Objektbeschreibung kann beispielsweise von dem ersten Netzwerkteilnehmer abgerufen werden, um diese für seine Angebote und

Beschreibungen der physischen Objekte zu nutzen. D.h. diese Beschreibung kann beispielsweise die technischen Spezifikationen des physischen Objekts oder andere das physische Objekt betreffende Daten bereitstellen. Die Objektbeschreibung kann im Cloud-Speicher zum Beispiel mit der Produktidentifikation des physischen Objektes verknüpft werden.

In einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens weisen die, vom zweiten Netzwerkteilnehmer, erhaltenen Anfragedaten Daten auf, die auf ein spezielles physisches Objekt gerichtet sind. Des Weiteren können die Anfragedaten auch Positionsdaten des zweiten Netzwerkteilnehmers aufweisen. Die auf das physische Objekt gerichteten Daten können beispielsweise dessen Verfügbarkeit anfragen. Die Positionsdaten können entweder von einer Positionsbestimmungseinheit am zweiten Netzwerkteilnehmer zur Verfügung gestellt werden oder können von einer Eingabe herrühren. Die Positionsdaten können die aktuelle oder prognostizierte Position des zweiten Netzwerkteilnehmers aufweisen. Es kann also beispielsweise die Verfügbarkeit und der Preis eines physischen Objektes an einem Ort abgefragt werden, an dem sich der zweite Netzwerkteilnehmer befindet oder an dem er sich befinden wird. Für die prognostizierte Position können beispielsweise Bewegungsprofildaten oder andere Daten verwendet werden, die einen Aufschluss über die zukünftige

Position des zweiten Netzwerkteilnehmers geben. Die Anfragedaten können auch noch weitere Daten umfassen, welche für eine Komplettierung einer Anfrage genutzt werden. In einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens weist dieses weiter auf das Senden von ersten geänderten Daten auch an den zweiten

Netzwerkteilnehmer. Der Cloud-Speicher kann also auch dazu angepasst sein, um den zweiten Netzwerkteilnehmer über geänderte erste Daten zu informieren. Dies kann beispielsweise vorteilhaft sein, wenn erkannt wird, dass die Verbindung zwischen dem Cloud-Speicher und dem zweiten Netzwerkteilnehmer diesem die entsprechenden Daten schneller zur Verfügung stellen kann als die Verbindung über den ersten

Netzwerkteilnehmer.

Die oben genannte Aufgabe wird auch gelöst durch einen Cloud-Speicher, wobei der Cloud-Speicher in selektiver Kommunikation mit zumindest einem ersten

Netzwerkteilnehmer, einem zweiten Netzwerkteilnehmer und einem dritten

Netzwerkteilnehmer steht. Der erfindungsgemäße Cloud-Speicher weist dabei auf, ein Mittel zum Speichern von Daten, ein Mittel zum Empfangen von ersten Daten von dem ersten Netzwerkteilnehmer, wobei die ersten Daten zugehörig sind zu einem

physischen Objekt, ein Mittel zum Empfangen von Anfragedaten von dem zweiten Netzwerkteilnehmer, ein Mittel zum Empfangen von zweiten Daten von dem dritten Netzwerkteilnehmer, wobei die zweiten Daten zugehörig sind zu den ersten Daten und zumindest ein Datum aufweisen, welches angepasst ist, die ersten Daten zu ändern in Abhängigkeit der empfangenen Anfragedaten, ein Mittel zum Ändern der ersten Daten basierend zumindest im Teil auf den zweiten Daten und den Anfragedaten und ein Mittel zum Senden eines geänderten Teils der ersten Daten von dem Cloud-Speicher an den ersten Netzwerkteilnehmer. Der Cloud-Speicher kann dabei ein Datenraum (Dataspace) sein, wobei dieser unterstützt wird durch eine Datenraum- Unterstützungsplattform (Data Space Support Plattform), welche sich um eine einheitliche Datennutzung sowie die Bereitstellung einfacher Dienste, wie zu Beispiel das Durchsuchen und Verändern der Daten kümmert. Zusätzlich können einzelne logische Komponenten verwendet werden, durch die die Datenquellen und

Datensenken, hier die Netzwerkteilnehmer, und deren Beziehung innerhalb des Datenraumes beschrieben werden. Der Cloud-Speicher kann dabei ein Dienst sein, welcher auf den Plattformen von IBM Bluemix, Microsoft Azure oder

Google App Engine basiert. Der Cloud-Speicher kann beispielsweise auch eine

Datenbank auf Basis von MongoDB mit einem Webserver auf Basis von Node / Express sein. Die oben genannte Aufgabe wird auch gelöst durch ein Verfahren zum Betreiben eines ersten Netzwerkteilnehmers, wobei das Verfahren das Bestimmen von ersten Daten zugehörig zu zumindest einem physischen Objekt aufweist. Dabei kann das Bestimmen bewerkstelligt werden durch ein Scannen einer Produktidentifikation des physischen Objekts. Beispielsweise kann die Produktidentifikation eine elektronisch scanbare Markierung sein, wie zum Beispiel ein Barcode, ein QR-Code, ein RFID-Tag oder eine andere Markierung, die Aufschluss über die Produktidentifikation gibt. Die ersten Daten können aber auch manuell eingegeben werden, beispielsweise durch eine Tastatur. Dem Fachmann ist aber bewusst, dass auch andere als die genannten

Möglichkeiten zur Bestimmung der ersten Daten am ersten Netzwerkteilnehmer vorhanden sein können bzw. Teil des ersten Netzwerkteilnehmers sein können.

Beispielsweise kann der erste Netzwerkteilnehmer eine Schnittstelle aufweisen, um mit einem bereits vorhandenen Warenwirtschaftssystem zu agieren und Daten bzgl.

physischer Objekte daraus zu bestimmen. Die ersten Daten können dabei

beispielsweise die für ein Warenwirtschaftssystem charakterisierenden Daten aufweisen, wie beispielsweise die Menge und den Preis eines physischen Objektes. Es ist dem Fachmann bewusst, dass der Schritt des Bestimmens auch das Bestimmen erster Daten für eine Vielzahl von physischen Objekten aufweisen kann. Das einzelne physische Objekt oder die Vielzahl der physischen Objekte können dabei beispielsweise am Ort des ersten Netzwerkteilnehmers vorhanden sein.

Das erfindungsgemäße Verfahren weist weiter das Senden der ersten Daten an einen Cloud-Speicher auf. Dabei kann das Senden über ein Netzwerk geschehen, welches in Kommunikation mit dem ersten Netzwerkteilnehmer sowie dem Cloud-Speicher steht. Hierzu kann der erste Netzwerkteilnehmer beispielsweise zumindest eine Schnittstelle aufweisen, mit der der erste Netzwerkteilnehmer mit dem Netzwerk, zum Beispiel dem Internet, verbunden werden kann.

Das erfindungsgemäße Verfahren weist weiter das Empfangen von einem geänderten Teil der ersten Daten von dem Cloud-Speicher auf. Dabei ist der geänderte Teil der ersten Daten kleiner als die ersten Daten. D.h. die Bitanzahl des geänderten Teils der ersten Daten ist geringer als die gesendeten ersten Daten. Dabei kann der geänderte Teil Delta-Daten enthalten bzw. komplett auf Delta-Daten basieren.

Das erfindungsgemäße Verfahren weist weiter auf, das Verknüpfen des geänderten Teils der ersten Daten mit den bestimmten ersten Daten. Hierbei werden also mit Hilfe des empfangenen geänderten Teils der ersten Daten die ersten Daten geändert.

Beispielswiese kann der geänderte Teil der ersten Daten den Preis des physischen Objektes betreffen, und der erste Netzwerkteilnehmer kann diesen entsprechend dem geänderten Teil der ersten Daten anpassen.

In einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens weist das Bestimmen der ersten Daten weiter auf, Abrufen von ersten Daten von dem Cloud- Speicher und Ergänzen der abgerufenen ersten Daten. Beispielsweise können die ersten Daten eine allgemeine Objektbeschreibung enthalten, beispielsweise die technischen Eigenschaften eines physischen Objektes. Diese Objektbeschreibung kann auch eine Produktidentifikation enthalten. Der erste Netzwerkteilnehmer kann diese

Objektbeschreibung vom Cloud-Speicher abrufen und speichern, d.h. herunterladen, und durch weitere Angaben, beispielsweise die vorhandene Menge und seinen Preis ergänzen, um so komplette erste Daten zu erhalten. Dies hat den Vorteil, dass der erste Netzwerkteilnehmer nicht selbst eine Objektbeschreibung erzeugen muss, sondern eine zentral vorgehaltene und vor allem aktualisierte Objektbeschreibung in seinen Teil des Warenwirtschaftssystems herunterladen kann und durch eigene Angaben

komplettieren kann. Es ist dem Fachmann bewusst, dass wenn der erste

Netzwerkteilnehmer erste Daten an den Cloud-Speicher sendet, nicht mehr die bereits heruntergeladenen Teile der ersten Daten gesendet werden, sondern nur noch die ergänzten Teile. Dies hat den Vorteil, dass nur eine geringe Bandbreite benötigt wird. Gleichfalls kann der erste Netzwerkteilnehmer auch nur einen Teil der ersten Daten von dem Cloud-Speicher abrufen, wenn bereits Teile gespeichert sind.

In einer weiteren bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens weist dieses auf, Empfangen von Anfragedaten von einem zweiten Netzwerkteilnehmer und Senden der Anfragedaten an den Cloud-Speicher. Die Anfragedaten können dabei beispielsweise ein spezielles physisches Objekt oder einen Typ eines physischen Objektes betreffen und/oder einen speziellen ersten Netzwerkteilnehmer oder eine Vielzahl von ersten Netzwerkteilnehmern. In diesem Fall agiert der erste

Netzwerkteilnehmer als Relay für die Anfragedaten des zweiten Netzwerkteilnehmers. D.h. der erste Netzwerkteilnehmer empfängt die Anfragedaten von dem zweiten Netzwerkteilnehmer und leitet diese unbearbeitet an den Cloud-Speicher weiter.

Die oben genannte Aufgabe wird auch gelöst durch ein Verfahren zum Betreiben eines zweiten Netzwerkteilnehmers, das Verfahren aufweisend Senden von Anfragedaten an einen Cloud-Speicher oder einen ersten Netzwerkteilnehmer, wobei die Anfragedaten zugehörig sind zu zumindest einem physischen Objekt und/oder zumindest einem ersten Netzwerkteilnehmer. Die Anfragedaten können dabei beispielsweise ein spezielles physisches Objekt oder einen Typ eines physischen Objektes betreffen und/oder einen speziellen ersten Netzwerkteilnehmer oder eine Vielzahl von ersten Netzwerkt eilnehmem. Zum Beispiel kann ein zweiter Netzwerkteilnehmer eine Anfrage bzgl. der Verfügbarkeit und des Preises eines bestimmten physischen Objektes senden. Diese Anfrage kann entweder an einen ersten Netzwerkteilnehmer gesendet werden, d.h. an dessen Teil des Warenwirtschaftssystems, oder an den Cloud-Speicher. Diese Anfrage wird über den Cloud-Speicher auch an den dritten Netzwerkteilnehmer gesendet, der dazu in der Lage ist, die auf Grund der Anfragesituation ersten Daten zugehörig zu dem physischen Objekt zu ändern. D.h. wenn ein zweiter

Netzwerkteilnehmer, beispielsweise ein Kunde, eine Preisanfrage stellt, so kann diese Preisanfrage nicht nur dem ersten Netzwerkteilnehmer, beispielsweise dem Händler, zur Verfügung gestellt werden, sondern sie wird auch dem dritten Netzwerkteilnehmer, beispielsweise dem Hersteller, zur Verfügung gestellt, der den Preis in Abhängigkeit der Anfragesituation in Echtzeit ändern kann, nämlich durch Senden von zweiten Daten an den Cloud-Speicher. Der zweite Netzwerkteilnehmer empfängt dann erfindungsgemäß erste Daten, wobei die ersten Daten auf den Anfragedaten und zweiten Daten von einem dritten Netzwerkteilnehmer basieren. D.h. beispielsweise wird die Preisanfrage mit einem geänderten Preis beantwortet, wobei der Preis durch den dritten

Netzwerkteilnehmer geändert wurde.

In einer weiteren bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens weist dieses weiter auf, Erzeugen eines Identifikationsobjektes mit den empfangenen ersten Daten und Identifizierungsdaten. Die Identifizierungsdaten können

beispielsweise den zweiten Netzwerkteilnehmer identifizieren und/oder das physische Objekt, welches angefragt wurde mit den ersten Daten identifizierend das physische Objekt. Das Identifikationsobjekt kann beispielsweise verwendet werden, damit eine Online-Anfrage eines physischen Objektes durch den zweiten Netzwerkteilnehmer sowie die erhaltenen ersten Daten des physischen Objektes gegenüber dem ersten Netzwerkteilnehmer verifiziert werden können. Dabei kann das Identifikationsobjekt ein QR-Code sein, der die entsprechenden Daten beinhaltet. Beispielsweise kann ein zweiter Netzwerkteilnehmer, beispielsweise Kunde, eine Preisanfrage bzgl. eines bestimmten physischen Objektes an den Cloud-Speicher senden und erhält als Antwort einen durch die Interaktion des Cloud-Speichers mit dem dritten Netzwerkteilnehmer, beispielsweise dem Hersteller, geänderten Preis des angefragten physischen Objektes. Um die Anfrage und insbesondere den erhaltenen Preis zu verifizieren, kann das Identifikationsobjekt erzeugt werden. Wird dieses anschließend vom zweiten

Netzwerkteilnehmer an den ersten Netzwerkteilnehmer übertragen, bzw. vom ersten Netzwerkteilnehmer gescannt, so kann dieser die Preisanfrage und den geänderten Preis mit dem Cloud-Speicher verifizieren. Die Identifikationsobjekte können aber auch im Sinne einer Blockchain, d.h. unveränderlich, auf dem Cloud-Speicher gespeichert werden und der erste Netzwerkteilnehmer und der zweite

Netzwerkteilnehmer können durch die Eintragung in der Blockchain überprüfen, ob die Anfrage des zweiten Netzwerkteilnehmers zu einer Änderung der ersten Daten geführt hat oder nicht. Dies schützt den ersten und dritten Netzwerkteilnehmer vor Betrugsversuchen durch einen nicht berechtigten zweiten Netzwerkteilnehmer.

Die oben genannte Aufgabe wird auch gelöst durch ein Verfahren zum Betreiben eines dritten Netzwerkteilnehmers, das Verfahren aufweisend Erzeugen von zweiten Daten, wobei die zweiten Daten angepasst sind, erste Daten zu ändern in Abhängigkeit von Anfragedaten, und Senden von den zweiten Daten an einen Cloud-Speicher.

In einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens weist dieses weiter auf, Empfangen von den ersten Daten und Anfragedaten von dem Cloud- Speicher, und wobei das Erzeugen der zweiten Daten basiert auf den ersten Daten und den Anfragedaten. Dabei kann auch das Fehlen von Anfragedaten, was beispielsweise durch das Empfangen von Leer- oder Nulldaten angezeigt wird, zur Erzeugung der zweiten Daten dienen. Dabei können zum Beispiel die Leer- oder Nulldaten erzeugt werden, wenn Anfragedaten bzgl. eines bestimmten physischen Objektes für eine gewisse Zeit ausbleiben. Beispielsweise kann das Fehlen von Anfragedaten eine mangelnde Nachfrage nach einem physischen Objekt bedeuten. Um dennoch den Warenfluss zu steuern, kann beispielsweise der Preis angepasst werden und die Anpassung in Form von zweiten Daten an den Cloud-Speicher gesendet werden. Dabei können die zweiten Daten Delta-Daten sein.

In einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens weist dieses weiter auf, Erzeugen von einer Objektbeschreibung eines Objektes und Senden der Objektbeschreibung an den Cloud-Speicher. Die Objektbeschreibung kann

beispielsweise die Produktidentifikation eines physischen Objektes beinhalten. Des Weiteren kann die Objektbeschreibung die technischen Daten eines physischen Objektes beinhalten.

Die oben genannte Aufgabe wird auch gelöst durch ein verteiltes

Warenwirtschaftssystem, aufweisend einen Cloud- Speicher, einen ersten

Netzwerkteilnehmer, einen zweiten Netzwerkteilnehmer und einen dritten

Netzwerkteilnehmer. Dabei ist der Cloud-Speicher in selektiver Kommunikation mit dem ersten Netzwerkteilnehmer, dem zweiten Netzwerkteilnehmer und dem dritten Netzwerkteilnehmer. Der Cloud-Speicher stellt dabei eine indirekte Verbindung zwischen den jeweiligen Netzwerkteilnehmem zur Verfügung. Dabei werden in dem verteilten Warenwirtschaftssystem erste Daten bzgl. eines physischen Objektes, gesendet von einem ersten Netzwerkteilnehmer, im Cloud-Speicher hinterlegt. Diese ersten Daten können dann von dem ersten Netzwerkteilnehmer geändert, aktualisiert oder modifiziert werden. Der erste Netzwerkteilnehmer kann dabei beispielsweise auch festlegen, wer und in welchem Umfang Zugriff auf die hinterlegten ersten Daten hat.

Der zweite Netzwerkteilnehmer kann diese hinterlegten ersten Daten mit einer Anfrage an den Cloud-Speicher abfragen. Bevor die Anfrage eines zweiten Netzwerkteilnehmers beantwortet wird, wird die Anfrage vom Cloud-Speicher an den dritten

Netzwerkteilnehmer gesendet. Dieser kann auf Basis der Anfragedaten zweite Daten generieren und an den Cloud-Speicher senden. Diese zweiten Daten sind in der Lage, die ersten Daten im Cloud-Speicher zu ändern. Beispielsweise sind die zweiten Daten dazu angepasst, den Preis eines physischen Objektes zu ändern. Die Anfrage des zweiten Netzwerkteilnehmers kann dann mit den geänderten ersten Daten beantwortet werden.

Auch wenn in den obigen Ausführungen der Preis als Beispiel eines zu ändernden Datensatzes eines physischen Objektes beschrieben ist, so ist dem Fachmann klar, dass dies nur exemplarisch zum besseren Verständnis aufgezeigt wurde, durch den

Gegenstand der Erfindung aber beliebige Datensätze des physischen Objektes geändert werden können; insbesondere die Datensätze, die von einem Hersteller vorgegeben werden und die für Händler sowie Kunden im gleichen Maße von Interesse sind.

Weitere Einzelheiten und vorteilhafte Ausgestaltungen der Erfindung sind der nachfolgenden Beschreibung und den Figuren zu entnehmen, anhand derer die in den Figuren dargestellte Ausführungsform der Erfindung näher beschrieben und erläutert ist.

Dabei zeigen:

Fig. l einen Datenfluss innerhalb eines Ausführungsbeispiels des

erfindungsgemäßen verteilten Warenwirtschaftssystems mit einem Cloud-Speicher;

Fig. 2 eine Schnittstellenansicht des erfindungsgemäßen verteilten

Warenwirtschaftssystems mit dem Cloud-Speicher wie in Figur l gezeigt;

Fig. 3 ein Flussdiagramm zum Betrieb des Cloud-Speichers des

erfindungsgemäßen verteilten Warenwirtschaftssystems wie in Figuren l und 2 gezeigt;

Fig. 4 ein Flussdiagramm zum Betrieb eines ersten Netzwerkteilnehmers des erfindungsgemäßen verteilten Warenwirtschaftssystems wie in Figuren l und 2 gezeigt;

Fig. 5 ein Flussdiagramm zum Betrieb eines zweiten Netzwerkteilnehmers des erfindungsgemäßen verteilten Warenwirtschaftssystems wie in Figuren l und 2 gezeigt; und

Fig. 6 ein Flussdiagramm zum Betrieb eines dritten Netzwerkteilnehmers des erfindungsgemäßen verteilten Warenwirtschaftssystems wie in Figuren l und 2 gezeigt.

Figur l zeigt in einem Ausführungsbeispiel einen Datenfluss zwischen einem Cloud- Speicher 105 und drei Netzwerkteilnehmern 110, 120, 130. Zusammen bilden der Cloud-Speicher 105 und die Netzwerkteilnehmer 110, 120, 130 ein Ausführungsbeispiel eines verteilten erfindungsgemäßen Warenwirtschaftssystems.

Der Cloud-Speicher 105 kann ein beliebiger Speicher sein, zum Beispiel ein

Datenbanksystem eines Serversystems. Zum Beispiel ein Datenbanksystem, welches als eine In-Speicher Lösung vorgesehen ist, um Echtzeitanforderungen zu genügen. Hier kann zum Beispiel ein SAP HANA System als ein entsprechendes MEMSQL System verwendet werden. Es ist dem Fachmann aber bewusst, dass beliebige

Datenbanksysteme verwendet werden können, die entsprechend der Anforderungen an die Echtzeitprozesse ausgewählt werden. Echtzeit bedeutet dabei, dass die Datenflüsse, Auswertungen und das Weitergeben von Daten eine möglichst geringe Verzögerung aufweisen.

Der Cloud-Speicher 105 ist dabei angepasst, Daten zu empfangen und zu senden, beispielsweise über ein Netzwerk. Zum Beispiel kann das Serversystem, auf welchem die Datenbank des Cloud-Speichers 105 gespeichert ist, einen Zugang zum Internet haben. Es ist dem Fachmann bewusst, dass wenn hier von einer Cloud-basierten Lösung gesprochen wird, diese auch auf mehreren vernetzten Serversystemen angesiedelt sein kann.

Mittels der Verbindung des Cloud-Speichers 105 zu einem Netzwerk kann dieser in selektive Kommunikation mit mehreren Netzwerkteilnehmern 110, 120, 130 treten. Selektiv in diesem Fall bedeutet, dass nicht zwangsläufig proprietäre Verbindungen zwischen den Netzwerkteilnehmern 110, 120 und 130 bestehen, sondern diese

Verbindungen nach Bedarf ab- und aufgebaut werden können.

Die in dem hier gezeigten Ausführungsbeispiel gezeigten Netzwerkteilnehmer 110, 120 und 130 sind Computer oder anderweitige Geräte, die zumindest eine Schnittstelle aufweisen, um mit dem Cloud-Speicher 105 zu kommunizieren. Dabei können die Netzwerkteilnehmer 110, 120 und 130 räumlich beabstandet sein vom Cloud-Speicher 105, zum Beispiel kann ein erster Netzwerkteilnehmer 110 bei einem Händler vor Ort sein, ein zweiter Netzwerkteilnehmer 120 kann bei einem Kunden vor Ort sein und ein dritter Netzwerkteilnehmer 130 kann bei einem Hersteller vor Ort sein. Es ist dem Fachmann bewusst, dass durch diese unterschiedliche Verortung die

Netzwerkteilnehmer 110, 120 und 130 auch unterschiedlich ausgestaltet sein können. Beispielsweise kann der erste Netzwerkteilnehmer 110 ein Computer eines

Kassensystems sein, welches beim Händler vor Ort ist, der zweite Netzwerkteilnehmer 120 kann ein Tablet oder Smartphone sein, welches von einem Kunden bedient wird, und der dritte Netzwerkteilnehmer 130 kann ein Computer eines Herstellersystems sein. Des Weiteren kann auch die Funktion der einzelnen Netzwerkteilnehmer 110, 120 und 130 selbst auf anderen Geräten implementiert sein, beispielsweise Servern - hier nicht gezeigt - wobei die am Ort der jeweiligen Benutzer - Händler, Kunde, Hersteller - vorhandenen Geräte nur einen Zugriff auf diese Server bereitstellen. Es ist auch denkbar, dass die Funktionalität der einzelnen Netzwerkteilnehmer 110, 120 und 130 auf dem Cloud-Speicher 105 realisiert ist und am Ort der jeweiligen Benutzer - Händler, Kunde, Hersteller - vorhandene Geräte nur einen Zugriff auf den Cloud- Speicher 105 ermöglichen.

In dem erfindungsgemäßen verteilten Warenwirtschaftssystem werden dabei Daten zwischen den Netzwerkteilnehmern 110, 120 und 130 und dem Cloud-Speicher 105 ausgetauscht. In dem hier gezeigten Ausführungsbeispiel wird zunächst im optionalen Schritt (1) eine Objektbeschreibung eines physischen Objektes von einem dritten Netzwerkteilnehmer 130 an den Cloud-Speicher 105 gesendet und dort gespeichert. Diese Objektbeschreibung umfasst beispielsweise eine eineindeutige Identifikation eines physischen Objektes oder dessen Objekttyps, beispielsweise eine EAN-Nummer, eine Seriennummer etc. Die Objektbeschreibung kann auch noch weitere Daten des physischen Objektes enthalten, die das physische Objekt beschreiben, wie dessen UVP, Listpreis, dessen technische Spezifikationen, Abbildungen des physischen Objektes etc. Diese weiteren Daten können in dem Cloud-Speicher 105 anhand der eineindeutigen Identifikation des physischen Objektes oder dessen Objekttyps gespeichert werden.

In einem weiteren optionalen Schritt (2) kann ein erster Netzwerkteilnehmer 110 sich die Objektbeschreibungen oder zumindest Teile der Objektbeschreibung

herunterladen. Beispielsweise kann der erste Netzwerkteilnehmer 110 für die

Erstellung eines Angebots, Katalogs etc. die in der Objektbeschreibung enthaltenen Daten verwenden. Dies hat den Vorteil, dass die vom Hersteller ständig auf dem aktuellen Stand gehaltenen Daten, die das physische Objekt beschreiben, nicht redundant beim Händler vorgehalten werden müssen, sondern sich der Händler der Objektbeschreibung aus dem Cloud-Speicher 105 bedienen kann. D.h. es gibt bereits hierdurch eine substantielle Einsparung an Hardwarevoraussetzungen und

Aktualisierungsbedarf beim Warenwirtschaftssystem des Händlers.

In einem weiteren Schritt (3) sendet der erste Netzwerkteilnehmer 110 an den Cloud- Speicher 105 von dem ersten Netzwerkteilnehmer 110 bestimmte erste Daten zugehörig zu einem physischen Objekt. Zum Beispiel können die ersten Daten die Menge der am ersten Netzwerkteilnehmer 110 vorhandenen physischen Objekte sein, wobei die Menge nach den jeweiligen physischen Objekten oder deren Typ aufgeschlüsselt sein kann. Diese ersten Daten können entweder durch Scannen der physischen Objekte selbst, beispielsweise durch Scannen des Barcodes der physischen Objekte, oder Einlesen eines QR-Codes erfasst werden oder von einem bereits am ersten

Netzwerkteilnehmer 110 vorhandenen Warenwirtschaftssystem stammen. Diese ersten Daten werden dann am Cloud-Speicher 110 empfangen und entsprechend der eineindeutigen Identifikation des ersten Netzwerkteilnehmers 110 gespeichert. Es ist dem Fachmann bewusst, dass die ersten Daten nicht nur entsprechend der ersten Netzwerkteilnehmer 110 gespeichert werden können, sondern auch entsprechend der eineindeutigen Identifikation des physischen Objektes. Nach diesem Schritt sind im Cloud-Speicher 105 also zum Beispiel die Mengen einzelner physischer Objekte bei den ersten Netzwerkteilnehmem 110 bekannt.

In einem weiteren Schritt (4) können von einem zweiten Netzwerkteilnehmer 120 Anfragedaten an den Cloud-Speicher 105 gesendet werden. Auch wenn in dem hier gezeigten Ausführungsbeispiel die Anfragedaten direkt von dem zweiten

Netzwerkteilnehmer 120 an den Cloud-Speicher 105 gesendet werden, so ist dem Fachmann bewusst, dass diese auch durch Zwischenschaltung weiterer Geräte an den Cloud-Speicher 105 gesendet werden können. Zum Beispiel ist auch denkbar, dass der zweite Netzwerkteilnehmer 120 die Anfragedaten an den ersten Netzwerkteilnehmer 110 oder den dritten Netzwerkteilnehmer 130 sendet und diese die Anfragedaten an den Cloud-Speicher 105 senden. Die Anfragedaten können dabei Anfragen bzgl. eines oder mehrerer physischer Objekte beinhalten. Zu diesem Zweck können die

Anfragedaten Suchparameter enthalten. Zum Beispiel können die Anfragedaten die Verfügbarkeit eines physischen Objektes bei einem ersten Netzwerkteilnehmer 110 anfragen. Dem Fachmann ist dabei bewusst, dass die Anfragedaten beliebige Daten aufweisen können, die beliebige Informationen bzgl. eines physischen Objektes anfragen können. Die Anfragedaten können dabei auch eine Information bzgl. eines bestimmten ersten Netzwerkteilnehmers 110 aufweisen, also zum Beispiel die Anfrage bzgl. eines speziellen physischen Objektes bei einem speziellen ersten

Netzwerkteilnehmer 110, oder Informationen bzgl. des Standortes des zweiten

Netzwerkteilnehmers 120, entweder des aktuellen oder des prognostizierten Standortes und einem Umkreisparameter zur Anfrage des physischen Objektes entsprechend der Suchparameter.

Der Cloud-Speicher 105 beantwortet diese Anfragen aber nicht sofort, wie bei üblichen Verfügbarkeitsanfragen bekannt, sondern sendet in einem weiteren Schritt (5) die Anfragedaten bzw. eine Teil der darin enthaltenen Suchparameter an den dritten Netzwerkteilnehmer 130 weiter. Es ist dem Fachmann bewusst, dass der Cloud- Speicher 105 dabei die Anfragen derart anonymisieren kann, dass die Identität des zweiten Netzwerkteilnehmers 120 dem dritten Netzwerkteilnehmer 130 verborgen bleibt. Es kann also beispielsweise dem dritten Netzwerkteilnehmer 130 nur ein Teil der Anfragedaten zugesandt werden. Beispielsweise nur die Information, dass es bzgl. eines physischen Objektes eine Anfrage gab, zusätzlich vielleicht noch eine

Information, wo diese Anfrage getätigt wurde oder über welchen Standort diese Verfügbarkeitsanfrage getätigt wurde. Es ist dem Fachmann auch bewusst, dass mehrere Anfragedaten von mehreren zweiten Netzwerkteilnehmern 120 kumuliert an den dritten Netzwerkteilnehmer 130 gesendet werden können. Beispielsweise dass ein bestimmtes physisches Objekt in einer bestimmten Häufigkeit angefragt wurde. Auch wenn hier aus exemplarischen Gründen eine Verfügbarkeitsanfrage beschrieben wird, so ist dem Fachmann bewusst, dass auch andere Daten angefragt werden können, zum Beispiel der Preis. Der Cloud-Speicher 105 kann auch zunächst eine Verarbeitung der Anfragedaten durchführen. Zum Beispiel kann der Cloud-Speicher 105 eine Statistik bzgl. der Anfragedaten anfertigen und dem dritten Netzwerkteilnehmer 130 zur Verfügung stellen. Um die Datenübertragungen auf ein geringes Maß zu begrenzen, kann der Cloud-Speicher 105 beispielsweise auch Grenzwerte bzgl. gewisser

Suchpaarmeter von dem dritten Netzwerkteilnehmer 130 erhalten und nur bei Unter- oder Überschreitung dieser Grenzwerte werden dem dritten Netzwerkteilnehmer 130 die entsprechenden Anfragedaten oder die verarbeiteten Anfragedaten zur Verfügung gestellt. Beispielsweise kann der dritte Netzwerkteilnehmer 130 dem Cloud-Speicher 105 mitteilen, dass nur bei einer gewissen Anzahl von Anfragen dieser informiert werden möchte.

Der dritte Netzwerkteilnehmer 130 sendet basierend auf den Anfragedaten - wenn der dritte Netzwerkteilnehmer 130 über diese informiert wird - in einem weiteren Schritt (6) zweite Daten an den Cloud-Speicher 105, wobei es sich bei diesen zweiten Daten um Delta-Daten handelt und diese basierend auf den Anfragedaten zumindest einen Teil der ersten Daten des physischen Objektes im Cloud-Speicher 105 zu ändern vermögen. Beispielsweise wird vom dritten Netzwerkteilnehmer 130 ein Delta zu dem Preis des physischen Objektes gesendet. Der dritte Netzwerkteilnehmer 130 ist dabei

beispielswiese durch die Anfragedaten darauf aufmerksam geworden, dass eine erhöhte Nachfrage nach dem physischen Objekt besteht und kann darauf aufbauend den Preis des physischen Objektes, dessen Listpreis oder anderweitige Preisgestaltungen, wie beispielsweise die Rabattierung etc. ändern. Die Änderung der ersten Daten wird auf Basis der zweiten Daten von dem Cloud- Speicher 105 vorgenommen. Der Cloud-Speicher 105 sendet dann im Schritt (7) geänderte Teile der ersten Daten an den ersten Netzwerkteilnehmer 110. Beispielsweise sendet der Cloud-Speicher 105 die vom dritten Netzwerkteilnehmer 130 erhaltenen zweiten Delta-Daten an den ersten Netzwerkteilnehmer 110 oder sendet den bereits geänderten Teil der ersten Daten an den ersten Netzwerkteilnehmer 110. D.h. in diesem Fall kann der erste Netzwerkteilnehmer 110 das physische Objekt mit den geänderten ersten Daten versehen. Der Cloud-Speicher 105 kann dem ersten Netzwerkteilnehmer 110 auch ein Identifikationsobjekt senden, welches einen bestimmten zweiten

Netzwerkteilnehmer 120 und die geänderten ersten Daten identifiziert. D.h. die geänderten ersten Daten werden nur demjenigen zur Verfügung gestellt bzw.

angeboten, der die entsprechenden Anfragedaten gesendet hat. Der zweite

Netzwerkteilnehmer 120 kann sich dann beim Kauf des physischen Objektes ebenfalls mit einem Identifikationsobjekt gegenüber dem ersten Netzwerkteilnehmer 110 authentifizieren, d.h. nachweisen, dass die Anfragedaten, auf deren Basis die ersten Daten geändert wurden, von genau diesem zweiten Netzwerkteilnehmer 120 stammen. Dieses Identifikationsobjekt kann beispielsweise ein QR-Code sein. Beim Kauf des physischen Objektes kann dann das Identifikationsobjekt empfangen und an dem ersten Netzwerkteilnehmer 110 mit dem Identifikationsobjekt des zweiten

Netzwerkteilnehmers 120 verglichen werden. Die Identifikationsobjekte können auch im Sinne einer Blockchain auf dem Cloud-speicher 105 gespeichert werden, so dass die jeweiligen Netzwerkteilnehmer 110, 120, 130 auf den für Sie wichtigen Teil der

Blockchain zugreifen können und so beispielsweise die Änderung der ersten Daten verifizieren können.

In einem weiteren Schritt (8) sendet der Cloud-Speicher 105 dem zweiten

Netzwerkteilnehmer 120 eine Antwort auf seine Anfragedaten, nämlich in Form der geänderten ersten Daten. Beispielsweise kann dem zweiten Netzwerkteilnehmer 120 dann auf Grund seiner Verfügbarkeitsanfrage nicht nur die Verfügbarkeit des physischen Objektes angezeigt werden, sondern auch dessen vom dritten

Netzwerkteilnehmer 130 geänderter Preis. Es ist dem Fachmann bewusst, dass diese Beantwortung der Anfragedaten, auch wenn in dem hier gezeigten Ausführungsbeispiel als direkt vom Cloud-Speicher 105 zum zweiten Netzwerkteilnehmer 120 gezeigt, auch indirekt über andere Verbindungen geschehen kann. Der zweite Netzwerkteilnehmer 120 kann dabei aus den geänderten ersten Daten und seiner Identifikation ein Identifikationsobjekt erstellen, welches der zweite Netzwerkteilnehmer 120 verwenden kann, um seine Anfrage und die auf der Anfrage geänderten ersten Daten gegenüber dem ersten Netzwerkteilnehmer zu verifizieren, d.h. nachzuweisen, dass diesem zweiten Netzwerkteilnehmer 120 durch seine Anfragedaten durch den dritten

Netzwerkteilnehmer 130 geänderte erste Daten zur Verfügung gestellt wurden. Also beispielsweise durch die Anfragedaten des zweiten Netzwerkteilnehmers 120 der dritte Netzwerkteilnehmer 130 den Preis geändert hat. Dieses Identifikationsobjekt kann der zweite Netzwerkteilnehmer 120 an den Cloud-Speicher 105 senden, der wiederrum dieses Identifikationsobjekt an den ersten Netzwerkteilnehmer 110, zum Beispiel in Schritt (7) senden kann.

Mit einem derartigen verteilten Warenwirtschaftssystem, bei dem nicht nur eine Interaktion zwischen Händler und Kunde besteht, sondern eben auch eine Interaktion zwischen Händler, Kunde und Hersteller, wird es dem Händler ermöglicht, in Echtzeit auf Anfragen zu reagieren. D.h. der stationäre Handel kann direkt auf Online-Anfragen reagieren und kann durch die Verbindung zum Hersteller auch den Online-Preis halten bzw. diesen teilweise unterbieten. Den heute bekannten Systemen fehlt eben diese Komponente der Verbindung zum Hersteller.

Die Verbindung von dem Cloud-Speicher 105 zu den einzelnen Netzwerkteilnehmern 110, 120 und 130 lässt sich durch Schnittstellen realisieren. Dies ist in Figur 2 gezeigt, wo der Cloud-Speicher 105 eine Schnittstelle 210 zum ersten Netzwerkteilnehmer 110 aufweist, eine zweite Schnittstelle 220 zum zweiten Netzwerkteilnehmer 120 und eine dritte Schnittstelle 230 zum dritten Netzwerkteilnehmer 130. Diese Schnittstellen 210, 220 und 230 können Hardware- oder Softwareschnittstellen sein. Diese können dementsprechend nicht nur die Verbindung hardwaremäßig, sondern auch

softwaremäßig in Form von entsprechenden Modellierungen und Fehlerkorrekturen bereitstellen sowie insbesondere auch die Verschlüsselung der gesendeten Daten übernehmen, so dass die Daten vor Zugriff Dritter geschützt sind.

Die Schnittstellen können beispielsweise als REST-Schnittstellen auf Basis von LoopBack implementiert werden. Für die Verschlüsselung der Schnittstellen kann zum Beispiel OpenSSL verwendet werden. Die Verschlüsselung der Datenflüsse zwischen dem Cloud-Speicher 105 und den Netzwerkteilnehmern 110, 120, 130 kann auch hardwaremäßig implementiert werden, zum Beispiel mittels Dongle und Chipkarten, um beispielsweise ein DES-DES oder RSA-DES-Verfahren zu implementieren. Der Cloud-Speicher 105 selbst weist dabei einen Speicher 105a auf, in dem die Daten der physischen Objekte gespeichert sind. Dabei können unterschiedliche

Speicherbereiche des Speichers 105a den einzelnen ersten Netzwerkteilnehmern 110 zugeordnet sein, um so Datensouveränität zu ermöglichen. Des Weiteren weist der Cloud-Speicher die funktionalen Blöcke tosb-f auf.

Dabei stellt Block 105b beispielsweise die serverseitige Funktionalität einer App zur Verfügung. Die clientseitige Funktionalität der App liegt beispielsweise auf Seiten des ersten und zweiten Netzwerkteilnehmers 110, 120. So hat beispielsweise der erste Netzwerkteilnehmer 110 eine clientseitige App-Funktionalität, mittels derer der erste Netzwerkteilnehmer 110 die ersten Daten des physischen Objektes bestimmen bzw. eingeben kann und an den Cloud-Speicher 105 senden kann, wobei die serverseitige Funktionalität der App die entsprechenden Daten im Speicher 105a des Cloud- Speichers 105 speichert. Auch der zweite Netzwerkteilnehmer 120 kann eine clientseitige App-Funktionalität aufweisen, mit der Anfragedaten bestimmt bzw.

eingegeben werden können und an den Cloud-Speicher 105 gesendet werden können. Die serverseitige Funktionalität der App verarbeitet dann die Anfragedaten.

Der Block 105c stellt beispielsweise die Funktionalität eines Brokers dar und vermittelt die Daten zwischen den jeweiligen Netzwerkt eilnehmem 110, 120, 130. Dazu stellt der Broker einen Katalog bereit, in welchem Datengeber, also die Netzwerkteilnehmer 110, 120, 130, ihre Schnittstellen melden und Datennutzer, also ebenfalls die

Netzwerkteilnehmer 110, 120, 130, diese auffinden können. Des Weiteren gilt er auch als zentrale Stelle zwischen den Netzwerkteilnehmern 110, 120, 130, um

Vereinbarungen über die Datennutzung zu machen. Mit anderen Worten, der Block 105c ist für die Vermittlung der Datenzugriffe zuständig. Er stellt die Funktionalität zur Verfügung, in der sich die ersten und dritten Netzwerkteilnehmer 110, 130 registrieren können. Diese können nun untereinander eine Rechtefreigabe bzgl. zu vermittelnder Daten beantragen, welche von der Gegenseite bestätigt werden muss, um einen Datenzugriff zu ermöglichen. Dabei kann es sich bei der Rechtevergabe um eine token- basierte Rechtevergabe handeln. Bei dieser Authentifizierungsart tauschen die einzelnen Teilnehmer keinerlei Zugriffspasswörter aus. Stattdessen werden von einer zentralen Authentifizierungsstelle Tokens vergeben, welche dann zu einem zeitlich begrenzten Zugriff zu einer Ressource genutzt werden können. Hier kann

beispielsweise das Open-Authentication-Protokoll OAuth verwendet werden. Der Block tosd stellt beispielsweise die Funktionalität einer Zertifizierungsstelle zur Verfügung, die dazu dient, die Echtheit der einzelnen Netzwerkteilnehmer 110, 120, 130 zu verifizieren, so dass der Cloud-Speicher 105 vor Zugriffen unberechtigter Dritter oder eventuellen Manipulationen geschützt ist. Es muss dabei insbesondere

sichergestellt werden, dass kein Unberechtigter sich als dritter Netzwerkteilnehmer 130 ausgibt, weil diesem zum Beispiel die Preishoheit obliegt. Auch kann durch die

Zertifizierungsstelle sichergestellt werden, dass nur verifizierte Objektbeschreibungen von authentisierten dritten Netzwerkteilnehmern 130 hochgeladen werden.

Beispielsweise wird beim Hochladen einer Objektbeschreibung sichergestellt, dass die eineindeutige Identifikation des physischen Objektes auch zu dem dritten

Netzwerkteilnehmer 130 gehört, der diese hochlädt. Beispielsweise kann dies Anhand der Registrierung der EAN bei einer zentralen Stelle geprüft werden.

Der Block tose stellt beispielsweise die Funktionalität eines

Produktinformationsdienstes zur Verfügung, der dazu dient, ein umfangreiches Informationsangebot zu den physischen Objekten und den hinterlegten

Objektbeschreibungen der physischen Produkte bereitzustellen.

Der Block tosf stellt beispielsweise die Funktionalität einer dynamischen Preis- und Lageranpassung bereit. Dieser Block tosf dient zum Beispiel dazu, den Preis und die Lagerbestände der physischen Objekte dynamisch festzulegen. Der Preis eines physischen Objektes kann dabei auf verschiedene Weise dynamisch festgelegt werden. Zum Beispiel über den Einkaufspreis von physischen Objekten für Einzelhändler im standardisierten Orderverfahren bei Erreichen eines vom Einzelhändler erreichten Mindestbestellbestandes eines physischen Produktes. Dabei legt der Hersteller (oder Großhändler) einen Preis unter Berücksichtigung weiterer Konditionen (z.B. Boni, Skonti) fest. Sobald ein Produkt einen bestimmten Bestand oder eine bestimmte Bestellmenge bei einem Händler erreicht hat, ändert der Block tosf den Preis für den entsprechenden Händler. Auch kann der Hersteller dem Cloud-Speicher 105 mitteilen, dass seine Lagerbestände eines physischen Objektes zu hoch sind und der Hersteller zur Senkung der Lagerbestände den Preis eines physischen Objektes anpassen möchte. Der Block tosf kann aus dieser Information sowie der Information, wo große Nachfrage nach dem physischen Objekt besteht oder wo Lagerbestände bei Händlern gerade gering ist, den Preis anpassen, so dass der Lagerbestand beim Hersteller gesenkt werden kann. Auch kann der Hersteller durch den Block tosf eine additive Vergütung zur Verfügung stellen, die den Kunden oder Händlern in entsprechend definierter Parameter freigeschaltet werden.

Figur 3 zeigt ein Flussdiagramm zum Betrieb des Cloud-Speichers 105 des

erfindungsgemäßen verteilten Warenwirtschaftssystems wie in Figuren 1 und 2 gezeigt. Dabei wird in einem optionalen ersten Schritt 310 eine Objektbeschreibung an dem Cloud-Speicher 105 empfangen. Diese Objektbeschreibung kann von einem dritten Netzwerkteilnehmer 130 oder von einem anderen Netzwerkteilnehmer, zum Beispiel Datendienst, empfangen werden. Die Objektbeschreibung selbst kann Daten bezogen auf ein einzelnes physisches Objekt oder bezogen auf einen Typ eines physischen Objektes beinhalten. Ein Datendienst kann dabei sein ein weiterer

Netzwerkteilnehmer, der damit beauftragt ist Objektbeschreibungen für dritte

Netzwerkteilnehmer dem Cloud-Speicher 105 zur Verfügung zu stellen, bzw. diese aktuell zu halten.

In einem weiteren Schritt 320 werden an dem Cloud-Speicher 105 erste Daten von einem ersten Netzwerkteilnehmer 110 empfangen. Diese ersten Daten sind zugehörig zu der Objektbeschreibung und können dieser innerhalb des Cloud-Speichers 105 durch den Cloud-Speicher 105 zugeordnet werden. Zum Beispiel kann der erste Netzwerkteilnehmer 110 in Schritt 320 die Menge eines physischen Objektes in Form von ersten Daten an den Cloud-Speicher 105 senden, wobei sich die Menge auf eine Menge an physischen Objekten bezieht, die am ersten Netzwerkteilnehmer 110 vorhanden sind oder auf die der erste Netzwerkteilnehmer 110 Zugriff hat. Die ersten Daten können dabei auch Daten aufweisen, die den ersten Netzwerkteilnehmer 110 identifizieren. Durch die Wiederholung des Schrittes 320 wird im Cloud-Speicher 105 ein Abbild des Warenbestandes am ersten Netzwerkteilnehmer 110 geschaffen. Es ist dem Fachmann bewusst, dass wenn in diesem Ausführungsbeispiel auch nur von einem ersten Netzwerkteilnehmer 110 die Rede ist, es eine Vielzahl von ersten

Netzwerkteilnehmem 110 gibt. Wenn diese alle ihre ersten Daten an den Cloud- Speicher 105 senden, so wird auf diese Weise der Warenbestand über die Vielzahl der ersten Netzwerkteilnehmer 110 abgebildet und sie bilden somit einen Teil des erfindungsgemäßen verteilten Warenwirtschaftssystems.

In einem weiteren Schritt 330 empfängt der Cloud-Speicher 105 Anfragedaten bezüglich im verteilten Warenwirtschaftssystem abgebildeter physischer Objekte. Die Anfragedaten können dabei entweder direkt von zweiten Netzwerkteilnehmern 120 stammen oder die Anfragedaten sind nur originär von zweiten Netzwerkteilnehmern 120, wurden aber beispielsweise am ersten Netzwerkteilnehmer lio empfangen und an den Cloud-Speicher 105 weitergeleitet. Die Anfragedaten selbst können Daten bzgl. des zweiten Netzwerkteilnehmers 120 enthalten sowie Daten, die auf ein spezielles physisches Objekt gerichtet sind. Zum Beispiel können die Anfragedaten eine Preis- und/oder Verfügbarkeitsanfrage enthalten. Dabei können die Anfragedaten selbst unterschiedliche Suchparameter aufweisen.

Der Cloud-Speicher 105 sendet dann in einem optionalen Schritt 340 die Anfragedaten an einen dritten Netzwerkteilnehmer 130 weiter. Dieser kann aus den Anfragedaten ermitteln, welche Nachfrage nach einem speziellen physischen Objekt besteht.

Alternativ oder zusätzlich kann der Cloud-Speicher 105 auch eine Verarbeitung der Anfragedaten durchführen und das Ergebnis der Anfragedaten dem dritten

Netzwerkteilnehmer 130 zur Verfügung stellen.

Hierauf aufbauend kann der dritte Netzwerkteilnehmer 130 entsprechend der

Nachfrage den Preis, Rabatte etc. zugehörig zu den physischen Objekten anpassen und dies anfragespezifisch. D.h. wenn am Samstag eine große Nachfrage nach einem Produkt im stationären Handel besteht, so kann der entsprechende Preis des Produktes für den stationären Händler angepasst werden. Auch kann gezielt auf die

Lagersituation physischer Objekte eingegangen werden, um beispielsweise den

Abverkauf eines physischen Objektes zu steigern. Dies stellt einen weiteren Teil des erfindungsgemäßen verteilten Warenwirtschaftssystems dar. Der dritte

Netzwerkteilnehmer 130 erzeugt basierend auf den Anfragedaten zweite Daten, die in der Lage sind, erste Daten im Cloud-Speicher 105 zu ändern. Dabei sind diese zweiten Daten Delta-Daten der ersten Daten. Diese zweiten Daten werden dann vom dritten Netzwerkteilnehmer 130 an den Cloud-Speicher 105 gesendet.

Im Schritt 350 empfängt der Cloud-Speicher 105 die zweiten Daten. Optional können dann in einem Schritt 360 Berechnungen, statistische Auswertungen oder ähnliches mit den ersten Daten ausgeführt werden. Zum Beispiel können die zweiten Daten vorgeben, dass nur eine Anpassung der ersten Daten vorgenommen werden soll, wenn ein bestimmter Lagerbestand überschritten ist, eine Lagerzeit einen bestimmten Grenzwert erreicht hat oder andere Voraussetzungen erfüllt sind. Diese

Voraussetzungen können im Schritt 360 überprüft werden. Im Schritt 370 kann der Cloud-Speicher 105 dann auf Basis der in Schritt 360 durchgeführten Berechnungen oder ohne diese eine Änderung der ersten Daten auf Basis der in Schritt 350 empfangenen zweiten Daten durchführen. Zum Beispiel kann der Preis eines im Cloud-Speicher 105 gespeicherten physischen Objektes anhand der Herstellervorgaben geändert werden, wobei diese Vorgaben also anfragespezifisch angepasst werden.

Anschließend kann der Cloud-Speicher 105 in Schritt 380 einen Teil der geänderten ersten Daten, also zum Beispiel den geänderten Preis in Form von Delta-Daten an den ersten Netzwerkteilnehmer 110 senden. Damit kann der erste Netzwerkteilnehmer 110 den nach Herstellervorgaben geänderten Preis für das physische Objekt verlangen. Dies ermöglicht eine Anpassung eines stationären Preises auf Basis anfragespezifischen Herstellervorgaben.

Figur 4 zeigt ein Flussdiagramm zum Betrieb eines ersten Netzwerkteilnehmers 110 des erfindungsgemäßen verteilten Warenwirtschaftssystems wie in Figuren 1 und 2 gezeigt.

Dabei wird in einem ersten optionalen Schritt 410 eine Objektbeschreibung von dem Cloud-Speicher 105 heruntergeladen. Diese kann beispielsweise für einen Offline-Teil des verteilten Warenwirtschaftssystems beim ersten Netzwerkteilnehmer 110 verwendet werden.

In einem Schritt 420 bestimmt der erste Netzwerkteilnehmer 110 erste Daten zugehörig zu einem physischen Objekt. Diese ersten Daten können manuell oder automatisch bestimmt werden. Beispielsweise weist der erste Netzwerkteilnehmer 110 eine

Eingabeeinheit auf, über die die ersten Daten eingegeben oder gescannt werden können. Auch ist denkbar, dass die ersten Daten von einem bereits beim ersten

Netzwerkteilnehmer implementierten Warenwirtschaftssystems bestimmt werden.

Der erste Netzwerkteilnehmer 110 kann auch als Relay für Anfragedaten von einem zweiten Netzwerkteilnehmer 120 verwendet werden. In diesem Fall werden in Schritt 430 Anfragedaten von einem zweiten Netzwerkteilnehmer 120 am ersten

Netzwerkteilnehmer 110 empfangen und im Schritt 440 von dem ersten

Netzwerkteilnehmer 110 an den Cloud-Speicher 105 weitergeleitet. In einem Schritt 450 werden die in Schritt 420 bestimmten ersten Daten an den Cloud- Speicher 105 gesendet. Beispielsweise sendet der erste Netzwerkteilnehmer eine Menge an einem physischen Objekt an den Cloud-Speicher 105.

Der Cloud-Speicher 105, wie in Figur 3 gezeigt, baut bei eingehenden Anfragedaten eine Verbindung zum dritten Netzwerkteilnehmer 130 auf und erhält von diesem zweite Daten, die angepasst sind, erste Daten zugehörig zu einem physischen Objekt zu ändern. Mit diesen zweiten Daten erstellt der Cloud-Speicher 105 geänderte erste Daten des physischen Objektes, beispielsweise passt der Cloud-Speicher 105 den Preis des physischen Objektes an. Anschließend werden Delta-Daten an den ersten

Netzwerkteilnehmer 110 gesendet. Diese werden in Schritt 460 von dem ersten

Netzwerkteilnehmer 110 empfangen. In Schritt 470 werden diese Delta-Daten mit den ersten Daten bzgl. des physischen Objektes verknüpft. D.h. der Preis des physischen Objektes kann angepasst werden anhand von anfragespezifischen Herstellervorgaben.

Optional können im Schritt 480 die geänderten ersten Daten an einen zweiten

Netzwerkteilnehmer 120 gesendet werden. Zum Beispiel kann dem zweiten

Netzwerkteilnehmer 120 mitgeteilt werden, dass ein geänderter anfragespezifischer Preis vorliegt.

Optional kann im Schritt 490 ein Identifikationsobjekt vom Cloud-Speicher 105 empfangen werden. Mittels dieses Identifikationsobjektes kann sich deijenige zweite Netzwerkteilnehmer 120 gegenüber dem ersten Netzwerkteilnehmer 110

authentifizieren, auf Basis dessen Anfragedaten die ersten Daten geändert wurden. D.h. es kann eine Einschränkung bzgl. der geänderten ersten Daten geben, diese können beispielsweise nur denjenigen zur Verfügung gestellt werden, die eine entsprechende Anfrage gestellt haben.

Figur 5 zeigt ein Flussdiagramm zum Betrieb eines zweiten Netzwerkteilnehmers 120 des erfindungsgemäßen verteilten Warenwirtschaftssystems wie in Figuren 1 und 2 gezeigt.

Dabei kann in einem optionalen ersten Schritt 510 eine Position des zweiten

Netzwerkteilnehmers 120 bestimmt werden. Die Positionsbestimmung kann dabei eine momentane oder ein prognostizierte Position des zweiten Netzwerkteilnehmers 120 sein. Die Position kann beispielsweise mit einem GPS-Modul des zweiten Netzwerkteilnehmers 120 bestimmt werden, oder durch eine Eingabe an dem zweiten Netzwerkteilnehmer 120.

Im Schritt 520 werden vom zweiten Netzwerkteilnehmer 120 Anfragedaten an den Cloud-Speicher 105 gesendet. Diese Anfragedaten können optional die Positionsdaten des zweiten Netzwerkteilnehmers 120 aufweisen sowie nicht optionale Daten bzgl. zumindest eines physischen Objektes. Beispielsweise können die Anfragedaten eine Preis- und/oder Verfügbarkeitsanfrage enthalten bzgl. eines physischen Objektes.

Diese Anfragedaten werden vom Cloud-Speicher 105 an den dritten

Netzwerkteilnehmer 130 gesendet, der basierend auf den Anfragedaten zweite Daten generiert, die wiederum an den Cloud-Speicher 105 gesendet werden, um dort erste Daten eines physischen Objektes zu ändern. Beispielsweise, den Preis des physischen Objektes.

Der Cloud-Speicher 105 kann nach Erhalt der zweiten Daten von dem dritten

Netzwerkteilnehmer 130 die ersten Daten ändern und diese an den zweiten

Netzwerkteilnehmer 120 in Antwort auf die Anfragedaten senden. Diese geänderten Daten werden dann im Schritt 530 von dem zweiten Netzwerkteilnehmer 120 empfangen.

Anschließend kann der zweite Netzwerkteilnehmer 120 im Schritt 540 ein

Identifikationsobjekt erzeugen, welches die vom Cloud-Speicher 105 erhaltenen geänderten ersten Daten und eine ID des zweiten Netzwerkteilnehmers 120 aufweist. Dieses Identifikationsobjekt kann beispielsweise in Form eines QR-Codes gespeichert werden.

Wenn der Benutzer des zweiten Netzwerkteilnehmers 120 entscheidet, den stationären Handel aufzusuchen, dann kann das Identifikationsobjekt auf dem zweiten

Netzwerkteilnehmer 120 in Schritt 550 gespeichert werden und an den Cloud-Speicher 105 gesendet werden. Das Identifikationsobjekt kann dann im stationären Handel verwendet werden, um sich gegenüber dem ersten Netzwerkteilnehmer 110 zu authentifizieren. Das Identifikationsobjekt wird zum Beispiel verwendet, damit der Kunde seine Anfrage und die darauf erhaltene anfragespezifische Änderung des Preises eines physischen Objektes gegenüber dem Händler verifizieren kann. Dieser kann beispielsweise mittels des ersten Netzwerkteilnehmers 110 das Identifikationsobjekt scannen und über eine Anfrage am Cloud-Speicher 105 verifizieren oder mit einem vom Cloud-Speicher 105 erhaltenen Identifikationsobjekt vergleichen.

Wenn der Benutzer des zweiten Netzwerkteilnehmers 120 entscheidet, den Online- Handel aufzusuchen, so kann eine Bestellung in Schritt 560 erzeugt werden, die das Identifikationsobjekt umfasst. Damit wird bei der Bestellung deutlich gemacht, dass zum Beispiel ein anfragespezifisch geänderter Preis gilt. In Schritt 570 kann dann die Bestellung versendet werden.

Figur 6 zeigt ein Flussdiagramm zum Betrieb eines dritten Netzwerkteilnehmers 130 des erfindungsgemäßen verteilten Warenwirtschaftssystems wie in Figuren 1 und 2 gezeigt.

In einem ersten optionalen Schritt 610 kann der dritte Netzwerkteilnehmer 130 eine Objektbeschreibung eines physischen Objektes erzeugen und in Schritt 620 an den Cloud-Speicher 105 senden.

Der dritte Netzwerkteilnehmer 130 kann auch in einem weiteren optionalen Schritt 630 erste Daten zugehörig zu einem physischen Objekt von dem Cloud-Speicher 105 erhalten. Beispielsweise können beim Cloud-Speicher 105 die momentanen

Lagerbestände eines physischen Objektes bei verschiedenen ersten

Netzwerkt eilnehmem 110 abgefragt werden. Durch einen Abgleich mit dem

Lagerbestandssystem des dritten Netzwerkteilnehmers 130 lässt sich hierdurch feststellen, ob die Lagerbestände mit der prognostizierten Warenverteilung

übereinstimmen. Werden hierbei Abweichungen festgestellt, so ist dies ein Indikator für eventuelle Graumarkt Situationen, d.h. Ware ist über einen nicht authentifizierten Absatzkanal zu einem Händler gelangt. Des Weiteren kann hierüber auch eventuelle Produktpiraterie aufgedeckt werden, wenn zum Beispiel physische Objekte im Cloud- Speicher 105 auftauchen, für die es keinerlei Aufzeichnungen beim dritten

Netzwerkteilnehmer 130 gibt, oder es tauchen doppelte erste Datensätze für physische Objekte auf.

Die Auswertung der ersten Daten über eine gewisse Zeit und/oder Region erlaubt es dem Hersteller auch, Lagerbestände, wertmäßige Umsätze, Stückzahlen und den Verkaufspreis zu analysieren. Diese Analyse kann beispielsweise auf dem dritten Netzwerkteilnehmer 130 geschehen. Es ist aber auch denkbar, dass diese Analyse auf dem Cloud-Speicher 105 abgewickelt wird und dem dritten Netzwerkteilnehmer 130 als Ergebnis zur Verfügung gestellt wird, entweder als Teil der ersten Daten, als separate Daten, oder separat zum Herunterladen. Der dritte Netzwerkteilnehmer 130 kann dem Cloud Speicher 105 auch optional zumindest einen Grenzwert senden, bei dessen Unter- oder Überschreitung der Cloud-Speicher 105 dem dritten Netzwerkteilnehmer 130 eine Meldung schickt, so dass der dritte Netzwerkteilnehmer entsprechende Maßnahmen ergreifen kann. Sofern erste Daten weiterer Hersteller zum Vergleich auf dem Cloud-Speicher 105 freigeschaltet sind, lassen sich diese Informationen auch in prozentualer oder wertmäßiger Relation abrufen und vergleichen.

Im Schritt 640 empfängt der dritte Netzwerkteilnehmer 130 Anfragedaten bzgl. eines physischen Objektes. Diese Anfragedaten stammen originär vom zweiten

Netzwerkteilnehmer 120 und wurden durch den Cloud-Speicher 105 an den dritten Netzwerkteilnehmer 130 gesendet.

Alternativ oder zusätzlich kann der Cloud-Speicher 105 dem dritten

Netzwerkteilnehmer 130 auch statistische Auswertungen der Anfragedaten zur Verfügung stellen, so dass der dritte Netzwerkteilnehmer 130 über die Anfragesituation informiert werden kann. Zum Beispiel kann der Cloud-Speicher 105 auswerten, welche Anfragedaten er zu welchen physischen Objekten oder vergleichbaren physischen Objekten erhalten hat. Hierbei kann der Cloud-Speicher 105 alle Anfragedaten von zweiten Netzwert eilnehmern 120 in Richtung vergleichbarer physischer Objekte von unterschiedlichen Herstellern in prozentualer oder wertmäßiger Relation zur

Verfügung stellen, sofern die jeweiligen Hersteller diese Information zum Vergleich im Cloud-Speicher 105 autorisiert haben. Basierend hierauf können Hersteller ihr

Marketing für eine Marke und/oder ein Produkt optimieren. Hierbei können beispielsweise dritte Netzwerkteilnehmer 130 regionale Grenzwerte im Cloud-Speicher 105 einstellen. Werden diese Grenzwerte unter- oder überschritten, so generiert der Cloud-Speicher 105 eine Meldung und sendet diese an den dritten Netzwerkteilnehmer 130, so dass entsprechende Maßnahmen ergriffen werden können.

Basierend auf den Anfragedaten kann im Schritt 650 entschieden werden, ob eine Anpassung erster Daten eines physischen Objektes durchgeführt wird oder nicht. Zum Beispiel kann anhand der Anzahl von Anfragen bzgl. eines physischen Objektes, der Lagersituation eines bestimmten physischen Objektes oder anderer handelstechnischer Überlegungen eine Anpassung der ersten Daten angezeigt sein. Im Falle dessen, dass eine Anpassung stattfinden soll, werden im Schritt 660 zweite Daten erzeugt, die in der Lage sind, erste Daten zu ändern. Diese werden dann in Schritt 670 an den Cloud-Speicher 105 gesendet, um die entsprechende Änderung durchzuführen. Dabei können die zweiten Daten Delta-Daten der ersten Daten sein.

Sollte in Schritt 650 entschieden werden, dass keine Anpassung vorgenommen werden soll, so kann optional in Schritt 680 eine Information bzgl. der Nicht-Anpassung an den Cloud-Speicher 105 gesendet werden, damit dieser darüber in Kenntnis gesetzt wird, dass es keine Anpassung geben wird. Es ist aber auch denkbar, dass der Cloud- Speicher 105 eine gewisse Zeit auf eine Antwort des dritten Netzwerkteilnehmers 130 wartet; wenn in dieser Zeit keine zweite Daten empfangen werden, geht der Cloud- Speicher 105 davon aus, dass keine Anpassung der ersten Daten durch den dritten Netzwerkteilnehmer 130 vorgenommen worden ist.

Alle in den oben genannten Ausführungsbeispielen genannten Datenflüsse können auf dem EDI-Standard ANSI X 12 oder UN EDIFACT Standard beruhen.

Die in den oben gennannten Ausführungsbeispielen genannten Funktionen können auf unterschiedliche Weise implementiert werden, alle diese unterschiedlichen

Implementierungen, sofern vom Umfang der angefügten Ansprüche umfasst, sind als erfindungsgemäß zu verstehen.