DE102020123880A1 - Automatisierte konfiguration von produkt- und dienstbereitstellung - Google Patents

Automatisierte konfiguration von produkt- und dienstbereitstellung Download PDF

Info

Publication number
DE102020123880A1
DE102020123880A1 DE102020123880.0A DE102020123880A DE102020123880A1 DE 102020123880 A1 DE102020123880 A1 DE 102020123880A1 DE 102020123880 A DE102020123880 A DE 102020123880A DE 102020123880 A1 DE102020123880 A1 DE 102020123880A1
Authority
DE
Germany
Prior art keywords
data
vehicle
request
order
hash value
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102020123880.0A
Other languages
English (en)
Inventor
Abraham Mezaael
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ford Global Technologies LLC
Original Assignee
Ford Global Technologies LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ford Global Technologies LLC filed Critical Ford Global Technologies LLC
Publication of DE102020123880A1 publication Critical patent/DE102020123880A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/01—Social networking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G06Q10/06311—Scheduling, planning or task assignment for a person or group
    • G06Q10/063112—Skill-based matching of a person or a group to a task
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/46—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for vehicle-to-vehicle communication [V2V]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/02—Reservations, e.g. for tickets, services or events
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G06Q10/06311—Scheduling, planning or task assignment for a person or group
    • G06Q10/063114—Status monitoring or status determination for a person or group
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/083—Shipping
    • G06Q10/0835—Relationships between shipper or supplier and carriers
    • G06Q10/08355—Routing methods
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84—Vehicles

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Human Resources & Organizations (AREA)
  • Economics (AREA)
  • Strategic Management (AREA)
  • Tourism & Hospitality (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Marketing (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Operations Research (AREA)
  • Development Economics (AREA)
  • Quality & Reliability (AREA)
  • Educational Administration (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Game Theory and Decision Science (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Die Offenbarung stellt eine automatisierte Konfiguration von Produkt- und Dienstbereitstellung bereit. Technologien zur automatisierten Konfiguration einer Lieferung von Produkten oder Bereitstellung von Diensten werden bereitgestellt. Die Technologien beinhalten ein Fahrzeugnetzwerk, das Auftragsanfragen für die Lieferung eines Produkts oder Bereitstellung eines Dienstes erfassen kann, wobei die Auftragsanfragen auf Hashtags basieren. Jedes Fahrzeug im Fahrzeugnetzwerk kann eine Vorrichtung beinhalten, die Anfragedaten von einem Rechensystem empfangen kann, das sich entfernt relativ zu dem Fahrzeug befindet. Ein erster Teil der Anfragedaten definiert eine Auftragsanfrage, die durch die Vorrichtung durch Validieren der Anfragedaten erkannt werden kann. Die Vorrichtung kann dann einen Verzeichniseintrag aktualisieren und kann auch andere Fahrzeuge im Fahrzeugnetzwerk dazu veranlassen, andere entsprechende Verzeichniseinträge zu aktualisieren. Zusätzlich kann die Vorrichtung eine Antwort auf die Auftragsanfrage an das Rechensystem senden. Die Antwort ermöglicht das Umsetzen oder Verwalten der Umsetzung einer Transaktion, die der Auftragsanfrage entspricht.

Description

  • TECHNISCHES GEBIET
  • Die Offenbarung betrifft im Allgemeinen Mobilanwendungen und insbesondere die Bereitstellung von Produkten und Diensten über Mobilanwendungen.
  • ALLGEMEINER STAND DER TECHNIK
  • Bestellungen für Produkte und Dienste können unter Verwendung einer dedizierten Mobilanwendung in einer mobilen Vorrichtung bereitgestellt werden. Status- und Kosteninformationen einer Bestellung können ebenfalls mittels der dedizierten Kundenanwendung abgerufen werden. Dies kann besonders praktisch sein, wenn Produkte oder Dienste von bekannten Plattformen angefordert werden, die dedizierte Mobilanwendungen bereitstellen.
  • Das Bereitstellen einer Mobilanwendung zum Bestellen von Produkten und Diensten kann jedoch eine erhebliches Maß an Verarbeitungsleistung, Netzwerkbandbreite, Massenspeicher und/oder andere Rechenressourcen erfordern, um Bestellungen zu verwalten, Endbenutzerinformationen sicher zu speichern und die Mobilanwendung zu warten (Aktualisierungen ausgeben, Sicherheitspatches bereitstellen usw.). Infolgedessen ist die Anzahl dedizierter Mobilanwendungen zum Bestellen von Produkten und Diensten eher begrenzt.
  • Daher ist bei herkömmlichen Technologien zum Konfigurieren der Bereitstellung von Produkten und Diensten noch viel zu verbessern.
  • KURZDARSTELLUNG
  • Die Offenbarung erkennt und befasst sich neben anderen technischen Herausforderungen mit dem Problem des Konfigurierens der Bereitstellung von Produkten und Diensten. Die Offenbarung stellt Technologien für eine automatisierte Konfiguration von Produkt- und Dienstbereitstellung bereit. Die offenbarten Technologien ermöglichen das Anfordern und Empfangen eines Produkts oder eines Dienstes, ohne auf eine dedizierte Mobilanwendung angewiesen zu sein. Zu diesem Zweck nutzen die offenbarten Technologien Hashtags in einer sozialen Netzwerkplattform, um eine Anfrage für ein Produkt oder einen Dienst zu bestimmen, und verarbeiten die Auftragsanfrage mittels einer verteilten Rechenplattform, die ein Fahrzeug-Peer-Netzwerk beinhaltet. Infolgedessen verbessern die offenbarten Technologien die Effizienz und Effektivität vorhandener Rechensysteme, indem sie die Verwendung von Rechenressourcen reduzieren, die andernfalls von einer Rechenplattform benötigt würden, um die dedizierte Mobilanwendung bereitzustellen und zu unterstützen.
  • Wie nachstehend ausführlicher beschrieben, beinhalten die offenbarten Technologien ein Fahrzeugnetzwerk, das Auftragsanfragen für die Bereitstellung eines Produkts oder eines Dienstes validieren kann. Die Auftragsanfragen basieren auf Hashtags, die in einem Social-Media-Netzwerk gepostet werden. Das Fahrzeugnetzwerk ermöglicht, Aufzeichnungen über Transaktionen zu führen, die jeweiligen Auftragsanfragen entsprechen. Dazu beinhaltet in einigen Ausführungsformen jedes Fahrzeug im Fahrzeugnetzwerk eine Vorrichtung. Die Vorrichtung kann Anfragedaten von einem Rechensystem empfangen, das sich entfernt relativ zu dem Fahrzeug befindet. Ein erster Teil der Anfragedaten definiert eine Auftragsanfrage für ein Produkt oder einen Dienst. Die Vorrichtung kann eine Auftragsanfrage durch Validieren der Anfragedaten erfassen. Die Vorrichtung kann dann einen Verzeichniseintrag aktualisieren und kann auch andere Fahrzeuge im Fahrzeugnetzwerk dazu veranlassen, andere entsprechende Verzeichniseinträge zu aktualisieren. Zusätzlich kann die Vorrichtung eine Antwort auf die Auftragsanfrage an das Rechensystem senden. Die Antwort ermöglicht das Umsetzen oder Verwalten der Umsetzung einer Transaktion, die der Bereitstellung des Produkts oder Dienstes entspricht, die der Auftragsanfrage entspricht.
  • Während einige Ausführungsformen der offenbarten Technologien in Bezug auf eine mobile Vorrichtung und ein Automobil veranschaulicht sind, ist die Offenbarung nicht hierauf beschränkt. Tatsächlich können die in dieser Schrift offenbarten Grundsätze und praktischen Elemente auf andere Arten von Kommunikationsvorrichtungen und Fahrzeugen angewendet werden. Die Kommunikationsvorrichtungen können als kabelgebundene Rechenvorrichtungen ausgeführt sein, die Informationen (Daten und/oder Signalisierung) drahtlos und/oder über eine drahtgebundene Verbindung senden und empfangen können. Eine kabelgebundene Rechenvorrichtung kann ein Telefon mit Voice-over-Internet-Protocol (VoIP) oder eine Zweiwege-Kommunikationsvorrichtung beinhalten. Wiederum können derartige Fahrzeuge Flugzeuge, Boote, Landtechnik und dergleichen beinhalten.
  • Figurenliste
  • Die beigefügten Zeichnungen bilden Teil der Offenbarung und in die vorliegende Beschreibung eingeschlossen. Die Zeichnungen, die nicht maßstabsgetreu sind, veranschaulichen einige Ausführungsformen der Offenbarung. Die Zeichnungen dienen zusammen mit der Beschreibung und den Ansprüchen dazu, verschiedene Grundsätze, Aspekte und praktische Elemente der Offenbarung zumindest teilweise zu erklären. Einige Ausführungsformen sind nachfolgend in Bezug auf die beigefügten Zeichnungen genauer beschrieben. Verschiedene Aspekte und Elemente der Offenbarung können jedoch in vielen verschiedenen Formen umgesetzt sein und sollen nicht als auf die in dieser Schrift dargelegten Umsetzungen beschränkt angesehen werden. Gleiche Zahlen beziehen sich in der gesamten Schrift auf ähnliche, jedoch nicht notwendigerweise auf dieselben oder identische Elemente.
    • 1 stellt ein Beispiel für eine Betriebsumgebung zur automatisierten Konfiguration einer Produkt- oder Dienstbereitstellung gemäß einer oder mehreren Ausführungsformen dieser Offenbarung dar.
    • 2 stellt ein Beispiel für eine Rechenvorrichtung zur automatisierten Konfiguration einer Produkt- oder Dienstbereitstellung gemäß einer oder mehreren Ausführungsformen dieser Offenbarung dar.
    • 3 stellt ein Beispiel für eine andere Rechenvorrichtung zur automatisierten Konfiguration einer Produkt- oder Dienstbereitstellung gemäß einer oder mehreren Ausführungsformen dieser Offenbarung dar.
    • 4 stellt ein Beispiel für einen Prozess in einem Rechensystem zur automatisierten Konfiguration einer Produkt- oder Dienstbereitstellung gemäß einer oder mehreren Ausführungsformen dieser Offenbarung dar.
    • 5 stellt ein Beispiel für einen anderen Prozess in einem Rechensystem zur automatisierten Konfiguration einer Produkt- oder Dienstbereitstellung gemäß einer oder mehreren Ausführungsformen dieser Offenbarung dar.
    • 6 stellt ein Beispiel für ein Verfahren zum Automatisieren der Konfiguration einer Produkt- oder Dienstbereitstellung gemäß einer oder mehreren Ausführungsformen dieser Offenbarung dar.
    • 7 stellt ein Beispiel für eine Vorrichtung zur automatisierten Konfiguration einer Produkt- oder Dienstbereitstellung gemäß einer oder mehreren Ausführungsformen dieser Offenbarung dar.
    • 8 stellt ein Beispiel für eine Rechenumgebung zur automatisierten Konfiguration einer Produkt- oder Dienstbereitstellung gemäß einer oder mehreren Ausführungsformen dieser Offenbarung dar.
  • DETAILLIERTE BESCHREIBUNG
  • Unter Bezugnahme auf die Zeichnungen veranschaulicht 1 ein Beispiel für eine Betriebsumgebung 100 zur automatisierten Konfiguration einer Produkt- oder Dienstbereitstellung gemäß einer oder mehreren Ausführungsformen dieser Offenbarung dar. Die beispielhafte Betriebsumgebung 100 beinhaltet eine mobile Vorrichtung 105, die auf ein Benutzerkonto innerhalb einer Social-Media-Plattform (z. B. Facebook, Instagram, Twitter, Snapchat oder dergleichen) zugreifen kann. Zu diesem Zweck kann die mobile Vorrichtung 105 eine dedizierte Softwareanwendung und/oder eine Webbrowseranwendung beinhalten (keine dieser Anwendungen ist in 1 abgebildet). Die mobile Vorrichtung 105 kann zum Beispiel als ein mobiler Tablet-Computer, ein-Buch-Lesegerät, ein Mobiltelefon (z. B. ein Smartphone) und dergleichen ausgeführt sein. In einem anderen Beispiel kann die mobile Vorrichtung 105 als tragbare Rechenvorrichtung, wie etwa eine Uhr, eine Brille oder ein am Kopf befestigtes Visier oder dergleichen, ausgeführt sein oder dies beinhalten. In einem weiteren Beispiel kann die mobile Vorrichtung 105 als tragbare Unterhaltungselektronik, wie etwa eine Kamera, eine Medienwiedergabevorrichtung, ein tragbares Fernsehgerät, eine Spielekonsole, eine Navigationsvorrichtung und dergleichen, ausgeführt sein oder diese beinhalten.
  • Beim Zugriff auf das Benutzerkonto oder nachdem auf das Benutzerkonto zugegriffen wurde, kann die mobile Vorrichtung 105 digitale Inhalte bereitstellen, die anderen Benutzerkonten innerhalb der Social-Media-Plattform zur Verfügung gestellt werden können (gemeinhin als „gepostet“ bezeichnet). Die digitalen Inhalte können Text- und/oder Medienobjekte beinhalten.
  • Um solche digitalen Inhalte bereitzustellen, kann die mobile Vorrichtung 105 Daten, die den digitalen Inhalt angeben, an die Social-Media-Plattform senden. Insbesondere kann die mobile Vorrichtung 105 den digitalen Inhalt an mindestens eine Vorrichtung von mehreren Vorrichtungen 120 für Social-Media-Plattformen senden, die die Social-Media-Plattform bilden. Der digitale Inhalt kann über ein oder viele Netzwerke 130 gesendet werden. Jedes Netzwerk, das das/die Netzwerk(e) 130 bildet, weist einen definierten Footprint auf und kann ein drahtloses Netzwerk oder ein drahtgebundenes Netzwerk sein. Der Footprint kann zum Beispiel eines von einem Weitverkehrsnetzwerk (WAN), einem Großraumnetzwerk (MAN), einem lokalen Netzwerk (LAN), einem Heimnetzwerk (HAN) und/oder einem Personal Area Network (PAN) sein. Als ein Beispiel kann mindestens eines des/der Netzwerke 130 ein Mobilfunknetz oder einen Teil davon und eine Internetprotokoll(IP)-Multimedia-Subsystem(IMS)-Plattform beinhalten.
  • In einigen Fällen können die digitalen Inhalte mit Metadaten erweitert werden, die es mindestens einer Vorrichtung der Social-Media-Plattform-Vorrichtungen 120 ermöglichen, die digitalen Inhalte zu verarbeiten. Die Metadaten können gemäß den Datenschutzeinstellungen, die für den digitalen Inhalt konfiguriert sein können, gleichzeitig mit dem digitalen Inhalt gepostet werden. Somit können die Metadaten öffentlich oder privat auf der Social-Media-Plattform veröffentlicht werden. Die Metadaten können zum Beispiel einen oder mehrere Hashtags beinhalten.
  • Die Verarbeitung, die durch solche Metadaten ermöglicht wird, kann neben anderen Vorgängen beinhalten, den digitalen Inhalt zu kategorisieren und/oder den digitalen Inhalt gegenüber Softwareanwendungen oder anderen Arten von Programmcode freizugeben (wie etwa Anwendungsprogrammierschnittstellen (APIs), Bibliotheken oder dergleichen). Dazu kann die Betriebsumgebung 100 eine oder mehrere Dienstautomatisierungsvorrichtungen 140 (als Dienstautomatisierungsvorrichtung 140 bezeichnet) beinhalten, die Hashtag-Aktivitätsdaten in Bezug auf Benutzerkonten innerhalb einer oder mehrerer Social-Media-Plattformen überwachen können. Dementsprechend kann sich die Dienstautomatisierungsvorrichtung 140 mit jeder Social-Media-Plattform verbinden, für die Hashtag-Aktivität überwacht werden soll. Der Veranschaulichung halber kann das Verbinden mit einer Social-Media-Plattform Ausführen von Programmcode beinhalten, der auf digitalen Inhalt zugreift (z. B. diesen abfragt und empfängt), welcher von der Social-Media-Plattform offengelegt wird, wobei der digitale Inhalt Hashtag(s) beinhaltet.
  • Die Dienstautomatisierungsvorrichtung 140 kann in einigen Fällen Hashtag-Aktivitätsdaten für Benutzerkonten überwachen, die eine Automatisierungsfunktionalität (oder einen Automatisierungsdienst) zur automatisierten Bereitstellung von Produkten und/oder Diensten abonniert haben. Eine solche Automatisierungsfunktionalität kann durch die Dienstautomatisierungsvorrichtung 140 bereitgestellt werden. Auf die Automatisierungsfunktionalität kann beispielsweise durch logisches Koppeln jedes der Benutzerkonten an ein Konto auf der Social-Media-Plattform zugegriffen werden, wobei das Konto der Dienstautomatisierungsvorrichtung 140 entspricht. Eine solche Art der Kopplung kann als dem Konto „folgen“ bezeichnet werden. In einem anderen Beispiel kann auf die Automatisierungsfunktionalität zugegriffen werden, indem jedes der Benutzerkonten zum Beispiel über einen Anmeldeprozess direkt an die Dienstautomatisierungsvorrichtung 140 gekoppelt wird. Unabhängig von der Art und Weise, in der auf die Automatisierungsfunktionalität zugegriffen wird, bestätigt das Benutzerkonto die Funktionalität und kann darauf aufmerksam gemacht werden, dass jeder gepostete Hashtag durch die Dienstautomatisierungsvorrichtung 140 überwacht und darauf zugegriffen werden kann.
  • In Fällen, in denen nicht auf die Automatisierungsfunktionalität zugegriffen wird, kann die Dienstautomatisierungsvorrichtung 140 Hashtag-Aktivitätsdaten, die von digitalem Inhalt stammt, den der Benutzer öffentlich postet, überwachen und/oder darauf zugreifen.
  • Um Hashtag-Aktivitätsdaten für ein Benutzerkonto 124 zu überwachen, das entweder die Automatisierungsfunktionalität abonniert hat oder digitalen Inhalt öffentlich postet, kann die Dienstautomatisierungsvorrichtung 140 auf digitalen Inhalt zugreifen, der durch das Benutzerkonto 124 auf einer Social-Media-Plattform gepostet wird, und kann nach Hashtags suchen, die in solchem Inhalt vorhanden sein können. Somit kann die Dienstautomatisierungsvorrichtung 140 in einer Konfiguration den von dem Benutzerkonto geposteten digitalen Inhalt filtern, um eine beliebige Anzahl von Hashtags zu identifizieren, die in dem digitalen Inhalt vorhanden sein können. In einigen Ausführungsformen, wie in 2 gezeigt, kann die Dienstautomatisierungsvorrichtung 140 ein Erfassungsmodul 204 beinhalten, das Hashtag-Aktivitätsdaten für das Benutzerkonto überwachen kann. In einigen Ausführungsformen kann das Erfassungsmodul 204 Programmcode ausführen, um Hashtags von digitalen Medien zu erhalten, die in sozialen Medien gepostet sind. Zur Veranschaulichung kann der Programmcode als eine Abfrage oder ein Skript ausgeführt sein oder diese beinhalten. Die Abfrage kann zum Beispiel eine JavaScript-Abfrage oder eine andere Art von Abfrage sein. Das Script kann zum Beispiel eine Crawler-Komponente sein, die APIs verwendet. Zusätzlich dazu oder in anderen Ausführungsformen kann das Erfassungsmodul 204 reguläre Ausdrücke anwenden, um eine bestimmte Art von Hashtag innerhalb des digitalen Inhalts zu erfassen. Das Erfassungsmodul 204 kann beliebige identifizierte Hashtags in einer oder mehreren Speichervorrichtungen (als Hashtag-Aktivitätsdaten 216 bezeichnet) speichern, die in die Dienstautomatisierungsvorrichtung integriert oder anderweitig funktionell an diese gekoppelt sind.
  • In einem beispielhaften Szenario kann das Benutzerkonto 124 über die mobile Vorrichtung 105 digitale Inhalte auf einer Social-Media-Plattform posten. Zu diesem Zweck kann die mobile Vorrichtung 105 eine dedizierte Softwareanwendung und/oder eine Webbrowseranwendung ausführen (oder weiterhin ausführen) (keine dieser Anwendungen ist in 1 abgebildet). Als Reaktion darauf veranlasst die dedizierte Softwareanwendung oder Webbrowseranwendung die mobile Vorrichtung 105, eine Benutzerschnittstelle (UI) 110 darzustellen, die das Empfangen und Posten von digitalem Inhalt ermöglichen kann. Zu dem geposteten digitalen Inhalt kann ein Hashtag 114 gehören (allgemein zur Veranschaulichung als „#A_Hashtag“ abgebildet). In einem Fall, in dem der Hashtag 114 öffentlich auf einer Social-Media-Plattform gepostet wird, kann die Dienstautomatisierungsvorrichtung 140 den Hashtag 114 erfassen, wenn sie mit der Social-Media-Plattform verbunden ist. In einem Fall, in dem das Benutzerkonto die Automatisierungsfunktionalität abonniert hat, die durch die Dienstautomatisierungsvorrichtung 140 bereitgestellt wird, kann eine derartige Vorrichtung den Hashtag 114 beispielsweise unabhängig von Datenschutzeinstellungen erkennen.
  • Die Dienstautomatisierungsvorrichtung 140 kann mindestens einen Teil der Hashtag-Aktivitätsdaten verwenden, um die Bereitstellung eines Produkts oder eines Dienstes oder beider zu automatisieren. Zu diesem Zweck kann die Dienstautomatisierungsvorrichtung 140 Auftragsanfragen mindestens basierend auf Hashtags erzeugen, die in den Hashtag-Aktivitätsdaten enthalten sind. Insbesondere gibt ein definierter Hashtag vor, welche Art von Produkt oder Dienst bereitgestellt werden soll. Somit gibt der definierte Hashtag den Auftragstyp einer Auftragsanfrage vor. Die Auftragsanfrage stellt eine beabsichtigte Transaktion zwischen einer anfragenden Vorrichtung und einer Anbietereinheit (einer Vorrichtung, einem Fahrzeug, einer Plattform usw.) dar, wobei die Transaktion das Produkt oder den Dienst beinhaltet. Das Produkt kann zum Beispiel ein Lebensmittel, wie etwa Pizza, chemische Reinigungsartikel oder dergleichen beinhalten. Der Dienst kann zum Beispiel einen Mitfahrdienst, ein Lkw-, Zug- oder Schiffsversand oder dergleichen beinhalten. Dementsprechend kann der Dienstautomatisierungsserver 140 in einigen Ausführungsformen eine Auftragsanfrage als Blockchain-Transaktion generieren.
  • Um eine Auftragsanfrage für einen veröffentlichten Hashtag (z. B. Hashtag 114) zu generieren, der in den Hashtag-Aktivitätsdaten erfasst wird, kann die Dienstautomatisierungsvorrichtung 140 den veröffentlichten Hashtag normalisieren. Der veröffentlichte Hashtag kann normalisiert werden, indem zuerst die Semantik des Hashtags bestimmt wird. Zu diesem Zweck kann die Dienstautomatisierungsvorrichtung 140 eine oder mehrere Formatierungsregeln auf den veröffentlichten Hashtag anwenden, wobei die Formatierungsregel(n) ein standardisiertes Format festlegen. In einer Konfiguration kann das Formatieren des Hashtags auf solche Weise Entfernen spezifischer Zeichen (z. B. Unterstriche), Korrigieren einer Rechtschreibung von mindestens einem Teil des veröffentlichten Hashtags und/oder Umschreiben des Hashtags unter Verwendung von Kleinbuchstaben beinhalten. Durch das Neuformatieren des veröffentlichten Hashtags auf solche Weise kann der resultierende standardisierte Hashtag für einen Prozess, der das Bestimmen der semantischen Bedeutung des veröffentlichten Hashtags ermöglicht, geeigneter sein. Die Standardisierung veröffentlichter Hashtags trägt der Tatsache Rechnung, dass verschiedene veröffentlichte Hashtags trotz unterschiedlicher Formate die gleiche semantische Bedeutung haben können. Zum Beispiel können Hashtags, wie etwa #Ich_will_Pizza, #IchWillPizza, #Will_Pizza, #Pizawäretoll, #pizzaAbend und dergleichen, die gleiche semantische Bedeutung - „Pizza ist erwünscht“ - haben, auch wenn jedes dieser Hashtags ein unterschiedliches Format aufweist. Solche Hashtags können beispielsweise auf #IchwillPizza standardisiert werden. Standardisierte Hashtags können nach Typ kategorisiert werden, wie etwa als Typ Lebensmittel, Typ Flotte, Typ Lieferung, Typ Standort und dergleichen.
  • Somit kann die Dienstautomatisierungsvorrichtung 140 eine semantische Klassifizierung auf den standardisierten Hashtag anwenden, um eine semantische Kategorie (oder semantische Bedeutung) eines solchen Hashtags zu bestimmen. In einer Ausführungsform kann die Dienstautomatisierungsvorrichtung 140 ein Convolutional Neural Network (CNN) anwenden, um die semantische Kategorie zu bestimmen. Andere Arten von Klassifizierungstechniken können ebenfalls angewendet werden. Fortfahrend mit der in 2 veranschaulichten Ausführungsform kann die Dienstautomatisierungsvorrichtung 140 ein Hashtag-Normalisierungsmodul 208 beinhalten, das veröffentlichte Daten gemäß einem standardisierten Format umformatieren kann. Zu diesem Zweck können eine oder mehrere Formatierungsregeln in einem oder mehreren Speicherelementen (als Formatierungsregeln 220 bezeichnet) beibehalten werden, die in die Dienstautomatisierungsvorrichtung 140 integriert oder funktionell an diese gekoppelt sind.
  • Die Dienstautomatisierungsvorrichtung 140 kann eine semantische Kategorie verwenden, die einem veröffentlichten Hashtag (z. B. Hashtag 114) entspricht, um den veröffentlichten Hashtag einem Auftragstyp zuzuordnen. Zum Beispiel kann der standardisierte Hashtag #IchwillPizza als Typ schneller Liefer- und Verpflegungsdienst eingestuft werden. In einigen Ausführungsformen, wie in 2 veranschaulicht, kann die Dienstautomatisierungsvorrichtung 140 ein Auftragsanfragemodul 212 beinhalten, das den veröffentlichten Hashtag mindestens auf Grundlage einer semantischen Kategorie einem Auftragstyp zuordnen kann.
  • Die Dienstautomatisierungsvorrichtung 140 kann dann eine Auftragsanfrage mindestens basierend auf dem Auftragstyp erzeugen, der einem erfassten Hashtag für das Benutzerkonto 124 zugeordnet ist. Die Auftragsanfrage kann Informationen beinhalten oder mit Informationen assoziiert sein, die notwendig sind, um auf die Auftragsanfrage zu reagieren. Die Informationen können somit Anforderinformationen beinhalten, wie etwa Benutzerdaten, die einen Endbenutzer identifizieren, der den Hashtag postet. Die Informationen, die erforderlich sind, um auf die Auftragsanfrage zu reagieren, können auch Auftragsdaten beinhalten, die eine Zieltransaktion charakterisieren, die durch die Auftragsanfrage repräsentiert wird. In einigen Ausführungsformen kann das Auftragsanfragemodul 212 (2) die Auftragsanfrage erzeugen, wobei die Benutzerdaten und/oder die Auftragsdaten wie hierin beschrieben erlangt werden.
  • Die Dienstautomatisierungsvorrichtung 140 kann auf mindestens einige der Anfragerinformationen aus einem Benutzerprofil (in 1 nicht abgebildet), das in dem Benutzerkonto 124 beinhaltet ist, und/oder von einem anderen Teil des Benutzerkontos 124 zugreifen (z. B. anfordern und/oder abrufen). Zusätzlich oder in anderen Ausführungsformen kann die Dienstautomatisierungsvorrichtung 140 auf mindestens einige der Anfragerinformationen von einer oder mehreren Verzeichnisvorrichtungen 150 (als Verzeichnisvorrichtung 150 bezeichnet) zugreifen. Zum Beispiel können derartige Anfragerinformationen in einer oder mehreren Speichervorrichtungen (die als Mitgliederverzeichnis bezeichnet werden können) innerhalb des Verzeichnisses 150 gepeichert werden. Die Anfragerinformationen (z. B. Benutzerdaten), auf die von dem Benutzerprofil, einem anderen Teil des Benutzerkontos oder dem Mitgliederbuch zugegriffen wird, können Benutzernamen, Kontaktinformationen (Telefonnummer, E-Mail-Adresse usw.), Zahlungsinformationen, eine Kombination davon oder dergleichen beinhalten.
  • Die Dienstautomatisierungsvorrichtung 140 kann zudem auf mindestens einige der Auftragsdaten aus Metadaten zugreifen, die in dem Social-Media-Beitrag enthalten sind, der den erfassten Hashtag beinhaltet. Derartige Auftragsdaten können zum Beispiel einen Zeitstempel und einen Zielort beinhalten, der durch Standortmetadaten bestimmt werden kann, die in dem Social-Media-Beitrag vorliegen. Die Standortmetadaten können zum Beispiel Koordinaten der mobilen Vorrichtung 105 im Wesentlichen zu einem Zeitpunkt darstellen, zu dem der erfasste Hashtag veröffentlicht wird. Derartige Koordinaten können durch die mobile Vorrichtung 105 unter Verwendung von Signalen von einem satellitenbasierten Navigationssystem (z. B. Signalisierung des globalen Positionsbestimmungssystems (GPS), Signalisierung des globalen Navigationssatellitensystems (GLONASS) oder dergleichen) erzeugt werden. In einem anderen Beispiel können die Standortmetadaten eine bestimmte Adresse darstellen, an der die mobile Vorrichtung 105 den erfassten Hashtag veröffentlicht hat. In einigen Fällen kann die bestimmte Adresse durch die mobile Vorrichtung 105 aus einem Menü von Adressen ausgewählt werden, die von mindestens einer der Social-Media-Plattform-Vorrichtungen bereitgestellt werden.
  • Ferner kann die Dienstautomatisierungsvorrichtung 140 als Teil der Generierung der Auftragsanfrage die Auftragsanfrage indizieren und verschlüsseln. Die Auftragsanfrage kann indiziert werden, indem ein eindeutiger Index oder eine andere Art von Kennung (ID) hinzugefügt wird, die die Auftragsanfrage eindeutig identifiziert. In einigen Konfigurationen kann der Auftragsanfrager 212 die Auftragsanfrage indizieren. Zusätzlich zum Indizieren der Auftragsanfrage kann die Dienstautomatisierungsvorrichtung 140 in einigen Ausführungsformen die Auftragsanfrage verschlüsseln. Die Kopie kann gemäß zahlreichen Kryptografieverfahren verschlüsselt werden, die Paare aus privaten und öffentlichen Schlüsseln verwenden, z. B. symmetrische Verschlüsselung oder asymmetrische Verschlüsselung. In einigen Ausführungsformen kann das Auftragsanfragemodul 212(2) die Auftragsanfrage verschlüsseln.
  • Durch Verschlüsseln der Auftragsanfrage kann die Dienstautomatisierungsvorrichtung 140 die Vertraulichkeit von Informationen aus dem Benutzerkonto 124, die in der Auftragsanfrage enthalten sein können, wahren. Somit kann eine verschlüsselte Auftragsanfrage Informationen des Anfragers (z. B. Benutzerdaten) wie etwa Benutzernamen, Kontaktinformationen, Zahlungsinformationen (z. B. Kreditkartennummer, Ablaufdatum und/oder Kartenprüfwert oder eine andere Art von Kartensicherheitscode), Standortinformationenoder beliebige andere Benutzerkontoinformationen, die in der Auftragsanfrage vorliegen, sichern.
  • Es ist anzumerken, dass neben der Verschlüsselung andere Mechanismen umgesetzt werden können, um Benutzerkontoinformationen innerhalb einer Auftragsanfrage privat zu halten. In einer Konfiguration kann die Dienstautomatisierungsvorrichtung 140 (zum Beispiel über das Auftragsanfragemodul 212 (2) einen Referenzcode erzeugen, der dem Benutzerkonto 124 zugeordnet ist, das zu einer Auftragsanfrage gehört. Der Referenzcode (numerisch oder alphanumerisch) kann die Auftragsanfrage anonym halten, während die entsprechenden Benutzerkontoinformationen mit der Auftragsanfrage verknüpft werden. Die Dienstautomatisierungsvorrichtung 140 kann Auftragsdaten und Benutzerdaten, die einer Auftragsanfrage entsprechen, in einer oder mehreren Speichervorrichtungen 224 (als Transaktionsdaten 224 (2) bezeichnet) speichern. Der Referenzcode kann auch in den Transaktionsdaten 224 gespeichert werden und in einigen Ausführungsformen kann der Referenzcode als Datenbankschlüssel für die Auftragsdaten und Benutzerdaten dienen. In einigen Konfigurationen kann die Dienstautomatisierungsvorrichtung 140 den Referenzcode mit der Verzeichnisvorrichtung 150 teilen.
  • Bei Erzeugen der Auftragsanfrage oder nachdem die Auftragsanfrage erzeugt wurde, kann die Dienstautomatisierungsvorrichtung 140 die Auftragsanfrage an die Verzeichnisvorrichtung 150 senden. Wie erwähnt, kann eine Auftragsanfrage eine Blockchain-Transaktion darstellen. In einem Aspekt kann die Verzeichnisvorrichtung 150 als Reaktion auf die Auftragsanfrage die Auftragsdaten mit Preisdaten (z. B. einem definierten Preis oder einer Preisspanne) für die Zieltransaktion, die der Auftragsanfrage zugeordnet ist, ergänzen. Zu diesem Zweck kann die Verzeichnisvorrichtung 150 in einigen Ausführungsformen Programmcode (z. B. eine API oder eine Bibliothek von Funktionen) ausführen, um auf die Preisdaten von mindestens einer der Drittanbietervorrichtungen 195 zuzugreifen. Zum Beispiel kann die Verzeichnisvorrichtung 150 zum Abrufen der Preisdaten einen Funktionsaufruf für eine Funktion einer API durchführen oder sie anderweitig abrufen. Zusätzlich oder in anderen Ausführungsformen kann die Verzeichnisvorrichtung 150 eine oder mehrere Speichervorrichtungen (in 1 nicht abgebildet) beinhalten, die Preisinformationen für verschiedene Auftragsanfragetypen speichern. Die Verzeichnisvorrichtung 150 kann die Preisinformationen verwenden, um die Auftragsanfrage um Preisdaten zu ergänzen. Die Preisinformationen können durch eine oder mehrere der Drittanbietervorrichtungen 195 bereitgestellt werden.
  • Um eine Entität zu identifizieren, die auf die Auftragsanfrage reagieren kann, kann die Verzeichnisvorrichtung 150 die Auftragsanfrage an eine Gruppe von Fahrzeugen in einem Fahrzeug-Peer-Netzwerk 160 senden. Jedes der Fahrzeuge in der Gruppe von Fahrzeugen ist bei der Dienstautomatisierungsvorrichtung 140 registriert, zum Beispiel als Mitglied des Fahrzeugnetzwerks 160 zum Zweck des Empfangens und Verarbeitens von Auftragsanfragen. Zum Zeitpunkt der Registrierung kann ein Fahrzeug Fahrzeugdaten senden, die das Fahrzeug identifizieren (z. B. Fahrzeugidentifikationsnummer (FIN), Marke und Modell, Baujahr und dergleichen). Solche Fahrzeugdaten können auch einen Verschlüsselungsschlüssel (z. B. einen öffentlichen Schlüssel) des Fahrzeugs beinhalten. Das Fahrzeug kann auch andere Fahrzeugdaten senden, die Präferenzen für bestimmte Auftragsanfragetypen oder bestimmte Zeiträume (Tageszeit, Wochenzeit, Zeit des Monats, konkrete Daten oder dergleichen) und/oder Standorte, an denen das Fahrzeug zum Verarbeiten von Auftragsanfragen verfügbar ist, übermitteln. Die Entität kann als Drittanbieterdienstvorrichtung ausgeführt sein oder diese beinhalten und kann auf die Auftragsanfrage reagieren, indem sie eine der Auftragsanfrage entsprechende Zieltransaktion umsetzt oder die Umsetzung der Zieltransaktion verwaltet. Das Fahrzeug-Peer-Netzwerk 160 beinhaltet mehrere Fahrzeuge, zu denen fahrerlose autonome Fahrzeuge und/oder fahrerbetriebene Fahrzeuge gehören. In einigen Ausführungsformen kann jedes der mehreren Fahrzeuge elektrisch sein. In anderen Ausführungsformen kann jedes der mehreren Fahrzeuge auf eine Brennkraftmaschine zur Fortbewegung angewiesen sein. In noch anderen Ausführungsformen können die mehreren Fahrzeuge Elektrofahrzeuge und andere Fahrzeuge mit entsprechenden Brennkraftmaschinen beinhalten. Wie in 1 veranschaulicht, kann das Fahrzeug-Peer-Netzwerk 160 ein erstes Fahrzeug 170a, ein zweites Fahrzeug 170b, ein drittes Fahrzeug 170c, ein viertes Fahrzeug 170d beinhalten. Das Fahrzeug-Peer-Netzwerk 160 kann auch Kommunikationsmedien 165 beinhalten, die einen drahtlosen Datenaustausch und/oder drahtlose Signalisierung zwischen Fahrzeugen im Fahrzeug-Peer-Netzwerk 160 ermöglichen. Die Kommunikationsmedien 165 können Kommunikationsverbindungen, eine Basisstation und/oder mehrere Netzwerkvorrichtungen (wie etwa Servervorrichtungen, Gatewayvorrichtungen und dergleichen) beinhalten.
  • Die Verzeichnisvorrichtung 150 kann konkrete Arten von Auftragsanfragen spezifischen Fahrzeugen im Fahrzeugnetzwerk 160 zuweisen, da einige Fahrzeuge dazu konfiguriert sein können, Auftragsanfragen zu empfangen, die spezifischen von Hashtag-Typen (z. B. Typ Lebensmittel, Typ Flotte, Typ Lieferung, Typ Standort usw.) zugeordnet sind. Ein Fahrzeug kann dazu konfiguriert sein, Auftragsanfragen zu empfangen, die einem oder mehreren Hashtag-Typen zugeordnet sind. Somit kann die Verzeichnisvorrichtung 150 Konfigurationsdaten führen, die ein Mapping zwischen Fahrzeugen in Hashtag-Typen angeben. Das Führen der Konfigurationsdaten kann zum Beispiel Aktualisieren (z. B. Erzeugen oder Ändern) von Datensätzen einer Zuordnung zwischen einem Fahrzeug in dem Fahrzeug-Peer-Netzwerk 160 und einem Hashtag-Typ sowie Entfernen von Datensätzen als Reaktion auf das Entfernen von Fahrzeugen aus dem Fahrzeug-Peer-Netzwerk 160 beinhalten. In einigen Ausführungsformen, wie in 3 veranschaulicht, kann die Verzeichnisvorrichtung 150 ein Knotenverwaltungsmodul 312 beinhalten, das die Konfigurationsdaten in einer oder mehreren Speichervorrichtungen (als Konfigurationsdaten 320 bezeichnet) führen kann. Die Konfigurationsdaten 320 können in die Verzeichnisvorrichtung 150 integriert oder funktionsfähig an die Verzeichnisvorrichtung 150 gekoppelt sein.
  • Dementsprechend kann die Verzeichnisvorrichtung 150 eine Auftragsanfrage eines definierten Typs einer spezifischen Gruppe von Fahrzeugen (z. B. Fahrzeug 170a, Fahrzeug 170b, Fahrzeug 170c und Fahrzeug 170d) innerhalb des Fahrzeug-Peer-Netzwerks 160 zuweisen. Unabhängig vom Auftragsanfragetyp kann jedes Fahrzeug in der Gruppe an einer Auftragsanfrage im Wesentlichen gleichzeitig mit anderen Fahrzeugen in der Gruppe arbeiten. Ein solcher Betriebsmodus für Auftragsanfragen kann als Spezifitätsmodus bezeichnet werden. Jedes Fahrzeug bearbeitet die Auftragsanfrage in einem Versuch, die Auftragsanfrage zu validieren. In einigen Ausführungsformen kann eine Auftragsanfrage durch ein Fahrzeug validiert werden, wenn das Bearbeiten der Auftragsanfrage oder einer iterativ modifizierten Version der Auftragsanfrage ein Ergebnis ergibt, das ein definiertes Validierungskriterium erfüllt. Zum Beispiel kann das definierte Validierungskriterium vorgeben, dass ein Hashwert, der durch das Bearbeiten von Daten erzeugt wird, die in der Auftragsanfrage enthalten sind, eine Gruppe von Zeichen beinhalten muss. In einer beispielhaften Konfiguration kann die Gruppe von definierten Zeichen eine Zeichenfolge zusammenhängender definierter Zeichen (z. B. ,,0000") beinhalten, die in einem bestimmten Abschnitt des Hashwerts angeordnet ist, z. B. am Anfang des Hashwerts oder am Ende des Hashwerts. In einer anderen beispielhaften Konfiguration kann die Gruppe definierter Zeichen eine bestimmte Zeichenfolge (z. B. „OlAB“) beinhalten, wobei zwei oder mehr der Zeichen in der Sequenz innerhalb des Hashwerts verschachtelt sind.
  • In einigen Ausführungsformen kann eine Auftragsanfrage durch ein Fahrzeug validiert werden, wenn (a) das Bearbeiten der Auftragsanfrage oder einer iterativ modifizierten Version der Auftragsanfrage ein Ergebnis ergibt, das ein erstes Validierungskriterium erfüllt, und (b) das Fahrzeug eines oder mehrere der zweiten Validierungskriterien erfüllt. Das erste Validierungskriterium kann zum Beispiel die Art des Hashwerts vorgeben, der erhalten werden muss (z. B. ein Hashwert, der eine definierte Gruppe von Zeichen beinhaltet, wie vorstehend in den unmittelbar vorangehenden beispielhaften Konfigurationen erörtert). In derartigen Ausführungsformen kann als Reaktion darauf, dass das Fahrzeug das eine oder die mehreren zweiten Kriterien nicht erfüllt, ein zweites Fahrzeug, das einen Hashwert erzeugt, der das erste Validierungskriterium erfüllt, in Bezug auf das eine oder die mehreren zweiten Validierungskriterien ausgewertet werden. Dementsprechend kann eine Gruppe von Fahrzeugen in dem Fahrzeug-Peer-Netzwerk 160 im Wesentlichen gleichzeitig mit der Auftragsanfrage fortfahren, bis ein geeignetes Fahrzeug in dem Fahrzeug-Peer-Netzwerk 160 das erste Validierungskriterium und das eine oder die mehreren zweiten Validierungskriterien erfüllt.
  • Das eine oder die mehreren zweiten Validierungskriterien, die von einem Fahrzeug erfüllt werden müssen, das eine Auftragsanfrage bearbeitet, kann zum Beispiel ein Standortkriterium, ein Leistungskriterium, ein Preisbildungskriterium, eine Kombination davon oder dergleichen beinhalten. Zur Veranschaulichung kann das Standortkriterium einen Schwellentoleranzabstand für die relative geografische Trennung zwischen einem Paar des Fahrzeugs, das eine Auftragsanfrage bearbeitet, der mobilen Vorrichtung 105, die die Auftragsanfrage über einen Hashtag erstellt hat; und einem Anbieterstandort, der einer Vorrichtung der Drittanbieterdienstvorrichtungen 195 zugeordnet ist, festlegen. In einem Beispiel kann der Schwellentoleranzabstand einen Lieferradius für ein Produkt darstellen. In einem Fall, in dem zum Beispiel das Fahrzeug und die mobile Vorrichtung 105 geografisch um weniger als den Schwellentoleranzabstand getrennt sind, kann das Standortkriterium erfüllt sein. In einem anderen Fall, in dem zum Beispiel die mobile Vorrichtung 105 und der Anbieterstandort geografisch um höchstens den Schwellentoleranzabstand getrennt sind, kann das Standortkriterium erfüllt sein. Als weitere Veranschaulichung kann das Leistungskriterium ein Schwellenzeitintervall zum Bereitstellen eines Produkts oder zum Durchführen eines Dienstessaufgabe festlegen. Somit kann das Fahrzeug das Leistungskriterium erfüllen, wenn das Fahrzeug oder ein auf das Fahrzeug bezogener Anbieter das Produkt bereitstellen oder die Dienstaufgabe innerhalb eines Schwellenzeitintervalls durchführen kann. In noch einer weiteren Veranschaulichung kann das Leistungskriterium einen Schwellenladeraum angeben, der für das Fahrzeug verfügbar sein muss. Ein solches Leistungskriterium kann in Szenarien konfiguriert sein, in denen die Auftragsanfrage das Befördern eines Produkts beinhaltet.
  • In weiteren Ausführungsformen kann eine Auftragsanfrage durch ein Fahrzeug validiert werden, wenn (a) das Bearbeiten der Auftragsanfrage oder einer iterativ modifizierten Version der Auftragsanfrage ein Ergebnis ergibt, das ein erstes Validierungskriterium erfüllt, und (b) das Fahrzeug relativ zu anderen Fahrzeugen eine zufriedenstellende Übereinstimmung zum Bereitstellen eines Produkts oder zum Durchführen eines Dienstessaufgabe, die der Auftragsanfrage entspricht, darstellt. In solchen Ausführungsformen können mehrere Fahrzeuge jeweilige Ergebnisse erzeugen, die das erste Validierungskriterium erfüllen. Jedes Fahrzeug der mehreren Fahrzeuge kann dann über die Kommunikationsmedien 165 Informationen senden, die Eigenschaften und/oder Betriebsbedingungen des Fahrzeugs spezifizieren. Jedes der mehreren Fahrzeuge kann mindestens solche Informationen verwenden, um ein Optimierungsproblem relativ zu einer Kostenfunktion zum Bereitstellen des Produkts oder zum Durchführen der Dienstaufgabe zu lösen. Zum Beispiel kann die Kostenfunktion einen Zeitpunkt für die Lieferung eines Produkts auswerten und/oder auswerten, ob ausreichend Laderaum oder andere Kapazitäten (temperaturgeregelter Laderaum) zum Befördern des Produkts verfügbar sind. Die Lösung des Optimierungsproblems kann ein bestimmtes Fahrzeug unter den mehreren Fahrzeugen identifizieren, das eine zufriedenstellende Übereinstimmung für das Bereitstellen des Produkts oder das Durchführen der Dienstaufgabe aufweist. Ein solches bestimmtes Fahrzeug ist dann das Fahrzeug, das die Auftragsanfrage validiert.
  • Ein Fahrzeug, das die Auftragsanfrage validiert, kann Benutzerdaten und/oder Auftragsdaten extrahieren, die in der Auftragsanfrage enthalten sind. Das Fahrzeug kann die Benutzerdaten und/oder die Auftragsdaten durch Entschlüsseln von mindestens einem Teil der Auftragsanfrage extrahieren. Zu diesem Zweck kann das Fahrzeug eine Entschlüsselungstechnik durchführen, die mit der kryptographischen Technik übereinstimmt, die zum Verschlüsseln der Benutzerdaten und der Auftragsdaten verwendet wird. In einem beispielhaften Fall, in dem die Dienstautomatisierungsvorrichtung 140 asymmetrische Verschlüsselung verwendet, kann das Fahrzeug den privaten Schlüssel des Fahrzeugs verwenden, um die Benutzerdaten und die Auftragsdaten zu entschlüsseln. In einem solchen Fall hat das Fahrzeug zuvor einen öffentlichen Schlüssel des Fahrzeugs zu Verschlüsselungszwecken an die Dienstautomatisierungsvorrichtung 140 gesendet. Ein solcher öffentlicher Schlüssel kann der Dienstautomatisierungsvorrichtung 140 zu einem Zeitpunkt bereitgestellt werden, zu dem sich das Fahrzeug bei der Dienstautomatisierungsvorrichtung als Mitglied des Fahrzeugnetzwerks 160 registriert. In Ausführungsformen, in denen die Auftragsanfrage einen Referenzcode anstelle von Auftrags- und Benutzerdaten beinhaltet, kann das Fahrzeug unter Verwendung des Referenzcodes eine Anfrage an die Dienstautomatisierungsvorrichtung 140 senden, um auf die Benutzerdaten und die Arbeitsdaten zuzugreifen. Die Dienstautomatisierungsvorrichtung 140 kann die Auftragsdaten und die Benutzerdaten in den Transaktionsdaten 224 speichern.
  • Eine andere spezifische Gruppe von Fahrzeugen kann auf Grundlage einer Region oder eines Standorts mit Auftragsanfragen arbeiten. Somit kann ein Fahrzeug in einer derartigen Gruppe Auftragsanfragen zu Zeiten verarbeiten, zu denen das Fahrzeug die Region durchquert oder sich anderweitig an dem Standort befindet. Zum Beispiel kann das Fahrzeug Auftragsanfragen vom Typ Taxi, Flotte, Lkw-Transport und/oder Mitfahrgelegenheit bearbeiten, wenn das Fahrzeug möglicherweise durch die Region des Standorts fährt. Ein solcher Betriebsmodus für Auftragsanfragen kann als Standortmodus bezeichnet werden. In einigen Situationen können Fahrzeuge, die im Standortmodus betrieben werden, einen opportunistischen standortbasierten Dienst bereitstellen, indem sie auf Auftragsanfragen reagieren, die kurierartigen Hashtags zugeordnet sind. Zum Beispiel können derartige Fahrzeuge Hashtags bearbeiten, die eine Anfrage zum Erhalten eines bestimmten Artikels darstellen (z. B. #BraucheLSATPowerScoreBook. Jedes Fahrzeug bearbeitet die Auftragsanfrage wiederum in einem Versuch, die Auftragsanfrage zu validieren. Die Auftragsanfrage kann validiert werden, wenn das Bearbeiten der Auftragsanfrage oder einer iterativ modifizierten Version der Auftragsanfrage ein Ergebnis ergibt, das eine oder mehrere definierte Validierungskriterien gemäß den hierin beschriebenen Aspekten erfüllt.
  • Noch eine weitere spezifische Gruppe von Fahrzeugen in dem Fahrzeug-Peer-Netzwerk 160 kann mindestens einige Auftragsanfragetypen bearbeiten, die durch die Verzeichnisvorrichtung 150 erzeugt werden. In einer Konfiguration können ein oder mehrere Fahrzeuge in der Gruppe in einem Vollzeitmodus Auftragsanfrage bearbeiten. Zum Beispiel kann/können ein solches Fahrzeug (eine) derartige Fahrzeuganfrage(n) bearbeiten, während das/die Fahrzeug(e) in Betrieb ist/sind, und ein anderes solches Fahrzeug kann/können ein/e derartige(n) Fahrzeuganfrage(n) bearbeiten, während eine Batterie an einer Ladestation geladen wird. In einer anderen Konfiguration können ein oder mehrere Fahrzeuge in der Gruppe Auftragsanfragen auf Teilzeitbasis bearbeiten, z B. während bestimmter Zeiträume während des Betriebs und/oder Ladens. Wie hierin offenbart bearbeitet jedes Fahrzeug die Auftragsanfrage in einem Versuch, die Auftragsanfrage zu validieren. Die Auftragsanfrage kann validiert werden, wenn das Bearbeiten der Auftragsanfrage oder einer iterativ modifizierten Version der Auftragsanfrage ein Ergebnis ergibt, das ein definiertes Validierungskriterium erfüllt.
  • Zu diesem Zweck kann die Verzeichnisvorrichtung 150 über verschiedene Hashtag-Typen verteilt werden, wobei unterschiedliche Verzeichnisvorrichtungen, die die Verzeichnisvorrichtung 150 bilden, entsprechende Auftragsanfragetypen erzeugen (z. B. ein Verzeichnis für Fast-Food und Dienste, ein anderes für Flottenaufträge, andere zur Paketzustellung usw.). Abhängig von der Art des Geschäfts kann dies auf viele Verzeichnisse erweitert werden, in denen Fahrzeuge in dem Fahrzeug-Peer-Netzwerk 160 enstprechend Rückmeldedaten bereitstellen können. Die Rückmeldedaten können das Abschließen einer Bestellung oder Dienstaufgabe ermöglichen, die der Auftragsanfrage entspricht. Somit definieren Rückmeldedaten mindestens ein Attribut eines Produkts oder der Dienstaufgabe. Die jeweiligen Arten des mindestens einen Attributs können für den Auftragsanfragetyp spezifisch sein. Die Rückmeldedaten können in einigen Fällen eine Anfrage für zusätzliche Informationen bezüglich der Bestellung oder Dienstaufgabe beinhalten. Zur Veranschaulichung kann das mindestens eine Attribut eine Liste von Lebensmittelallergenen beinhalten, die von einer angefragten Mahlzeit oder einem angefragten Getränk auszuschließen sind; eine Größe eines angefragten Getränks; Lieferanweisungen für ein angefragtes Paket; eine bestimmte Route zur Frachtbeförderung; und dergleichen.
  • Fahrzeuge, die dazu konfiguriert sind, mit einem spezifischen Hashtag-Typ (oder einem Auftragsanfragetyp) betrieben zu werden, können funktionell an die Verzeichnisvorrichtung gekoppelt sein, die einen solchen Hashtag-Typ verwaltet. Solche Fahrzeuge können auch funktionell an andere Fahrzeuge in dem Fahrzeug-Peer-Netzwerk 160 gekoppelt sein, die ebenfalls mit dem Hashtag-Typ arbeiten, um zum Beispiel Rückmeldungen zu senden und zu empfangen. In einigen Fällen kann eine Konfiguration eines Fahrzeugs zum Betreiben mit eines bestimmten Auftragsanfragetyps statisch sein und im Laufe der Zeit unverändert bleiben. In anderen Fällen kann eine derartige Konfiguration dynamisch sein, wobei das Fahrzeug dazu konfiguriert ist, während eines ersten definierten Zeitraums (z. B. tagsüber) einen ersten Auftragsanfragetyp und während eines zweiten definierten Zeitraums (z. B. an Wochenenden) einen zweiten Auftragsanfragetyp zu bearbeiten. Zum Beispiel kann das Fahrzeug tagsüber Auftragsanfragen, die den Flottendienst betreffen, und nachts Auftragsanfragen für den Mitfahrdienst bearbeiten.
  • Durch das Kategorisieren von Fahrzeugen nach Auftragsanfragetyp können zumindest einige der Drittanbieterdienstvorrichtungen auch nach einer spezifischen Branche (z. B. Lebensmittelindustrie, Transportindustrie, Mitfahrgelegenheitsindustrie und dergleichen) kategorisiert werden. Somit kann eine solche Kategorisierung vertikale Märkte für die Umsetzung einer automatisierten Konfiguration zur Produkt- und/oder Dienstbereitstellung schaffen. Zusätzlich können Fahrzeuge innerhalb einer Kategorie auf einen definierten Hashtag-Typ reagieren und können somit Lösungen akkurater finden sowie Drittanbietervorrichtungen 195, die in der Kategorie enthalten sind, eine fokussierte, strategischere Rückmeldung bereitstellen.
  • Unabhängig vom Bearbeitungsmodus für Auftragsanfragen - Spezifitätsmodus, vollständiger Mining-Modus, teilweiser Mining-Modus oder Standortmodus - kann ein Fahrzeug im Fahrzeug-Peer-Netzwerk 160 eine digitale Mining-Vorrichtung 180 beinhalten, um Auftragsanfragen zu bearbeiten und als Reaktion auf Ergebnisse der Auftragsanfragebearbeitung eine Rückmeldung bereitzustellen. Wie in 1 veranschaulicht, beinhaltet die digitale Mining-Vorrichtung 180 in einigen Ausführungsformen die Steuereinheit 181, um die Auftragsanfrage zu bearbeiten. Die Steuereinheit 181 kann ein Auftrag-Mining-Modul 182 beinhalten, das die Auftragsanfrage bearbeiten kann. Das Auftrag-Mining-Modul 182 kann einen Teil der Anfragedaten modifizieren, der für die Auftragsanfrage repräsentativ ist, und kann eine kryptographische Hashfunktion auf die modifizierten Anfragedaten anwenden. Die kryptographische Hashfunktion kann zum Beispiel eines von RIPEMD-160, Secure Hash Algorithm (SHA)-1, SHA-256 oder SHA-512 sein. Das Auftrag-Mining-Modul 182 kann dann bestimmen, ob ein resultierender Hashwert ein Validierungskriterium erfüllt, wie hierin beschrieben. Zum Beispiel kann das Validierungskriterium vorgeben, dass eine definierte Anzahl und Art von Anfangszeichen in dem Hashwert vorhanden sein muss. In einigen Ausführungsformen wird die Auftragsanfrage validiert, wenn die Anwendung der kryptographischen Hashfunktion einen Hashwert ergibt, der das Validierungskriterium erfüllt. In anderen Ausführungsformen, wie hierin beschrieben, kann die Auftragsanfrage validiert werden, wenn sowohl der Hashwert, der das Validierungskriterium erfüllt, als auch das Fahrzeug, das die digitale Mining-Vorrichtung 180 beinhaltet, ein oder mehrere zweite Validierungskriterien erfüllt, wie hierin beschrieben. Das Auftrag-Mining-Modul 182 kann die Anfragedaten iterativ modifizieren und die kryptographische Hashfunktion anwenden, während es nach Anfragedaten sucht, die die Auftragsanfrage validieren. Das Fahrzeug kann auf eine Auftragsanfrage reagieren, indem es die Auftragsanfrage validiert. Die Validierungskriterien, die entweder auf den Hashwert oder das Fahrzeug anwendbar sind, können in einer oder mehreren Speichervorrichtungen 186 (als Validierungsregel(n) 186 bezeichnet) gespeichert werden.
  • Als Reaktion auf das Validieren der Auftragsanfrage kann das Auftrag-Mining-Modul 182 die Benutzerdaten und/oder die in der Auftragsanfrage verschlüsselten Auftragsdaten extrahieren. Zusätzlich kann die Steuereinheit 181 auch ein Auftragsverwaltungsmodul 184 beinhalten, das eine Reaktion auf die Auftragsanfrage erzeugen kann. Die Reaktion kann eine Antwortnachricht beinhalten, die die extrahierten Benutzerdaten und/oder extrahierten Auftragsdaten beinhaltet. Die Antwortnachricht kann die Auftragsanfrage unter Verwendung eines eindeutigen Index (oder einer anderen Art von Auftrags-ID) identifizieren, der in der entschlüsselten Auftragsanfrage enthalten ist.
  • Als weitere Reaktion auf das Validieren einer Auftragsanfrage kann die digitale Mining-Vorrichtung 180 eine Benachrichtigung an jedes der anderen Fahrzeuge senden, die ebenfalls innerhalb des Fahrzeug-Peer-Netzwerks 160 die Auftragsanfrage bearbeiten. Die Benachrichtigung kann übermitteln, dass das Senderfahrzeug die Auftragsanfrage validiert hat. Die Benachrichtigung kann auch Transaktionsdaten beinhalten, die das Aktualisieren von Verzeichnisdaten ermöglichen, die in jedem der Fahrzeuge, die die Benachrichtigung empfangen, gespeichert werden. Das Auftragsverwaltungsmodul 184 kann die Benachrichtigung aussenden und kann in dem Fahrzeug, das die Auftragsanfrage erfolgreich entschlüsselt hat, gespeicherte Verzeichnisdaten aktualisieren. In einigen Ausführungsformen können die Verzeichnisdaten als Blockchain-Verzeichnis formatiert sein. Die Verzeichnisdaten können in einer oder mehreren Speichervorrichtungen (als Verzeichnisdaten 186 bezeichnet) gespeichert werden, die in die Steuereinheit 181 integriert sind oder anderweitig funktionell an die Steuereinheit 181 gekoppelt sind.
  • Es ist anzumerken, dass die offenbarten Technologien nicht auf das Aussenden einer solchen Benachrichtigung beschränkt sind. Tatsächlich kann die digitale Mining-Vorrichtung 180 die Benachrichtigung gemäß anderen Kommunikationsansätzen, wie etwa Unicast oder Multicast, an ein oder mehrere andere Fahrzeuge übertragen. Um die Benachrichtigung als Reaktion auf das Validieren der Auftragsanfrage zu übertragen oder anderweitig zu kommunizieren, kann die digitale Mining-Vorrichtung 180 eine Kommunikationseinheit 189 beinhalten. Die Kommunikationseinheit 189 kann eine oder viele Antennen und eine Kommunikationsverarbeitungsvorrichtung beinhalten, die eine drahtlose Kommunikation zwischen einem Fahrzeug und entweder einem anderen Fahrzeug oder einer externen Vorrichtung ermöglichen kann. Das andere Fahrzeug kann zum Beispiel eines der Fahrzeuge sein, die in dem Fahrzeug-Peer-Netzwerk 160 enthalten sind. Die externe Vorrichtung kann zum Beispiel eine von der Verzeichnisvorrichtung 150 oder der Dienstautomatisierungsvorrichtung 140 sein. Eine derartige Kommunikationsverarbeitungsvorrichtung kann Daten gemäß definierten Protokollen einer oder mehrerer Funktechnologien verarbeiten. Die Daten, die verarbeitet werden, können in einem drahtlosen Signal empfangen werden oder können durch die Steuereinheit 181 erzeugt werden. Die Funktechnologien können zum Beispiel 3G, Long Term Evolution (LTE), LTE-Advanced, 5G, IEEE 802.11, IEEE 802.16, Bluetooth, ZigBee, Nahfeldkommunikation (near-field communication - NFC) und dergleichen einschließen.
  • Ein Fahrzeug, das eine Auftragsanfrage validiert, kann die Antwortnachricht an die Verzeichnisvorrichtung 150 senden. Als Reaktion auf das Empfangen der Antwortnachricht kann die Verzeichnisvorrichtung 150 Transaktionsdaten aktualisieren, um eine Aufzeichnung der validierten Auftragsanfrage und in einigen Fällen Benutzerdaten und/oder Auftragsdaten, die in der Antwortnachricht empfangen wurden, aufzunehmen. Die Verzeichnisvorrichtung 150 kann Aufzeichnungen jeweiliger validierter Auftragsanfragen führen, die von einem oder mehreren Fahrzeugen innerhalb des Fahrzeug-Peer-Netzwerks 160 empfangen wurden. Aufzeichnungen von validierten Auftragsanfragen können in einer Konfiguration in Verzeichnisdaten geführt werden, die als Blockchain-Verzeichnis formatiert sind. In einigen Ausführungsformen, wie in 3 veranschaulicht, kann die Verzeichnisvorrichtung 150 ein Transaktionsverwaltungsmodul 308 beinhalten, das Antwortnachrichten empfangen kann, die validierte Auftragsanfragen identifizieren. Als Reaktion auf das Empfangen der Antwortnachrichten kann das Transaktionsverwaltungsmodul 308 Transaktionsdaten aktualisieren (z. B. erstellen oder erweitern), die die validierten Auftragsanfragen angeben. Die Transaktionsdaten können in einer oder mehreren Speichervorrichtungen (als Transaktionsdaten 324 bezeichnet) gespeichert werden, die in die Verzeichnisvorrichtung 150 integriert sind oder anderweitig funktionell an die Verzeichnisvorrichtung 150 gekoppelt sind.
  • Als weitere Reaktion auf das Empfangen der Antwortnachricht kann die Verzeichnisvorrichtung 150 eine Anbietervorrichtung identifizieren, die die Zieltransaktion durchführen kann, die den empfangenen Auftragsdaten entspricht. In einem Beispiel kann die Verzeichnisvorrichtung 150 ein oder mehrere Qualifizierungskriterien auf Dienstleisterdaten anwenden, um eine Drittanbieterdienstvorrichtung auszuwählen, die die Zieltransaktion durchführen oder die Durchführung der Zieltransaktion verwalten kann. Die ausgewählte Drittanbieterdienstvorrichtung kann in einer Gruppe von Drittanbieterdienstvorrichtungen 195 enthalten sein, die als Dienstleister bei der Verzeichnisvorrichtung 150 registriert werden können.
  • Die Verzeichnisvorrichtung 150 kann Auftragsdaten an die ausgewählte Vorrichtung eines Drittanbieters senden. Als Reaktion auf das Empfangen der Auftragsdaten kann die ausgewählte Vorrichtung eines Drittanbieters eine Bestellung für ein Produkt oder einen Auftrag für einen Dienst auf Grundlage der Zieltransaktion erstellen. Der Dienst kann zum Beispiel einen Taxidienst, einen Mitfahrdienst, einen Versandservice oder dergleichen beinhalten. Die Verzeichnisvorrichtung 150 kann Rückmeldedaten an die ausgewählte Vorrichtung eines Drittanbieters senden. Die Rückmeldedaten können das Abschließen einer Bestellung oder Dienstaufgabe ermöglichen. Somit definieren Rückmeldedaten mindestens ein Attribut eines Produkts oder der Dienstaufgabe. Rückmeldedaten können eine Anfrage für zusätzliche Informationen von der mobilen Vorrichtung 105 bezüglich der Bestellung oder Dienstaufgabe beinhalten.
  • Die Verzeichnisvorrichtung 150 kann die Rückmeldedaten an die mobile Vorrichtung 105 senden. Die Verzeichnisvorrichtung 150 kann die Rückmeldedaten an die mobile Vorrichtung 105 senden. Die zweiten Rückmeldedaten können zudem Informationen bereitstellen, um die Bestellung oder Dienstaufgabe auf Grundlage der Zieltransaktion abzuschließen. Die Verzeichnisvorrichtung 150 kann dann die zweiten Rückmeldedaten an die ausgewählte Vorrichtung eines Drittanbieters senden. In einigen Fällen kann das Empfangen der zweiten Rückmeldung dazu führen, dass die ausgewählte Drittanbieterdienstvorrichtung die Bestellung oder Aufgabe abschließt. In einem Fall, in dem die Bestellung oder Aufgabe nicht abgeschlossen ist, kann die Verzeichnisvorrichtung 150 einen weiteren Austausch von Rückmeldedaten zwischen der mobilen Vorrichtung 105 und der Anbietervorrichtung ermöglichen, bis die Bestellung oder Dienstaufgabe abgeschlossen werden kann. In einigen Ausführungsformen kann unter weiterer Bezugnahme auf 3 die Verzeichnisvorrichtung ein Rückmeldungsverwaltungsmodul 312 beinhalten, das den Austausch von Rückmeldedaten zwischen einer Drittanbieterdienstvorrichtung und der mobilen Vorrichtung 105 vermitteln kann.
  • Als ein Beispiel kann eine Zieltransaktion die Zustellung einer Pizza an einen bestimmten Standort der mobilen Vorrichtung 105 sein. Die Verzeichnisvorrichtung 150 kann ein erstes Qualifizierungskriterium anwenden, um mehrere Anbietervorrichtungen zu bestimmen, die in der Lage sind, die Lieferung der Pizza zu verwalten. Die mehreren Anbietervorrichtungen können in den Drittanbieterdienstvorrichtungen 195 enthalten sein. Das erste Qualifikationskriterium kann vorgeben, dass eine geeignete Anbietervorrichtung einer Pizzeria (einem Franchise-Pizzarestaurant oder einem Pizza-Restaurant-Kleinunternehmen) zugeordnet sein muss. Die Verzeichnisvorrichtung 150 kann auch ein zweites Qualifizierungskriterium anwenden, um eine definierte Anbietervorrichtung aus den mehreren Anbietervorrichtungen auszuwählen. Das zweite Qualifikationskriterium kann vorgeben, dass sich eine geeignete Anbietervorrichtung innerhalb einer definierten Entfernung (zum Beispiel zwei Meilen oder fünf Meilen) von dem Standort der mobilen Vorrichtung 105 befinden muss. Ein derartiger Standort kann in der validierten Auftragsanfrage angegeben werden, die der Zieltransaktion zugeordnet ist. Somit kann die Verzeichnisvorrichtung 150 durch Anwenden des ersten und zweiten Qualifikationskriteriums die definierte Anbietervorrichtung identifizieren, die die Zustellung der Pizza verwalten kann.
  • Ferner kann die Verzeichnisvorrichtung 150 dann Auftragsdaten, die für die Zieltransaktion repräsentativ sind, an die definierte Anbietervorrichtung senden. Als Reaktion auf das Empfangen der Auftragsdaten kann die definierte Anbietervorrichtung eine Pizzabestellung für die mobile Vorrichtung 105 erstellen. In einigen Fällen kann die definierte Drittanbietervorrichtung auch Rückmeldedaten an die Verzeichnisvorrichtung 150 senden. Die Rückmeldedaten können ermöglichen, die Pizzabestellung zu konkretisieren. Zum Beispiel können die Rückmeldedaten eine Gruppe von Fragen darstellen, die auf die Charakterisierung der gewünschten Pizza gerichtet sind, z. B. gewünschte Pizzabeläge, Größe, andere Präferenzen, zusätzliche gewünschte Lebensmittel oder Getränke usw.
  • Unter Fortführung des Beispiels kann die Verzeichnisvorrichtung 150 dann wiederum die Rückmeldedaten an die mobile Vorrichtung 105 senden. Die Verzeichnisvorrichtung 150 kann als Reaktion darauf andere Rückmeldedatenvon der mobilen Vorrichtung 105 empfangen. Solche Rückmeldedaten können Antworten auf die Fragen von der definierten Anbietervorrichtung bereitstellen. Die Verzeichnisvorrichtung 150 kann dann die anderen Rückmeldedaten, die von der mobilen Vorrichtung 105 empfangen wurden, an die definierte Anbietervorrichtung senden. Die Bestellung für die Pizza kann somit abgeschlossen werden. In einem Fall, in dem die Bestellung nicht abgeschlossen ist, kann die Verzeichnisvorrichtung 150 ferner den Austausch von Rückmeldedaten zwischen der mobilen Vorrichtung 105 und der definierten Anbietervorrichtung ermöglichen, bis die Bestellung abgeschlossen werden kann.
  • In einigen Ausführungsformen kann die Verzeichnisvorrichtung 150 zumindest einige der Fahrzeuge in dem Fahrzeug-Peer-Netzwerk 160 mit an die mobile Vorrichtung 105 gesendeten Rückmeldedaten und/oder von der mobilen Vorrichtung 105 empfangenen Rückmeldedaten aktualisieren. In einer Konfiguration kann das Rückmeldungsverwaltungsmodul 312 (3) ein Fahrzeug in dem Fahrzeug-Peer-Netzwerk 160 aktualisieren.
  • Gleichermaßen kann jedes Fahrzeug in dem Fahrzeug-Peer-Netzwerk 160 Rückmeldedaten an die Verzeichnisvorrichtung 150 und in einigen Fällen an die Dienstautomatisierungsvorrichtung 140 senden. Zu diesem Zweck kann das Auftragsverwaltungsmodul 184 in einigen Ausführungsformen die Rückmeldedaten senden. In einer Konfiguration kann das Auftragsverwaltungsmodul 184 eine Schnittstelle (wie etwa eine API) oder eine andere Art von Programmcode verwenden, um die Rückmeldedaten an die Verzeichnisvorrichtung 150 oder die Dienstautomatisierungsvorrichtung 140 zu senden. Die Rückmeldedaten können von dem Fahrzeug, das die Steuereinheit 181 beinhaltet, an die Verzeichnisvorrichtung 150 oder die Dienstautomatisierungsvorrichtung mittels der Kommunikationseinheit 189 gesendet werden.
  • Die Verzeichnisvorrichtung 150 kann eine Zahlung für die Durchführung einer Zieltransaktion in Bezug auf einen Hashtag (z. B. Hashtag 114) verarbeiten. Zu diesem Zweck kann die Verzeichnisvorrichtung 150 in einigen Fällen eine Genehmigung für die Zahlungsverarbeitung von dem Benutzerkonto 124 erhalten, und als Reaktion darauf kann die Verzeichnisvorrichtung 150 eine Zahlungstransaktion ausführen, die sich auf den Hashtag bezieht. Zum Beispiel kann eine Zahlungstransaktion als Reaktion auf die Lieferung eines Produkts (z. B. sobald die Pizza geliefert wurde), das Abschließen eines Dienstessaufgabe in Bezug auf den Hashtag ausgeführt wird, ausgeführt werden. In einigen Ausführungsformen, wie in 3 veranschaulicht, kann die Verzeichnisvorrichtung 150 ein Zahlungsverarbeitungsmodul 316 beinhalten, das eine Zahlungstransaktion in Bezug auf einen Hashtag ausführt. Die Verzeichnisvorrichtung 150 kann auch Statusdaten bereitstellen, die einen Leistungszustand der Zieltransaktion angeben (z. B. laufende Transaktion oder abgeschlossene Transaktion). Zu diesem Zweck kann die Verzeichnisvorrichtung 150 auf die Statusdaten von einer Drittanbieterdienstvorrichtung und/oder einem Fahrzeug zugreifen.
  • 4 stellt ein Beispiel für einen Prozess in einem Rechensystem zur automatisierten Konfiguration einer Produkt- oder Dienstbereitstellung gemäß einer oder mehreren Ausführungsformen dieser Offenbarung dar. Das Rechensystem kann verteilt sein und beinhaltet in einigen Ausführungsformen die Dienstautomatisierungsvorrichtung 140, die Verzeichnisvorrichtung 150 und das Fahrzeug-Peer-Netzwerk 160. Die Dienstautomatisierungsvorrichtung 140 kann Daten empfangen, die einen Hashtag 405 identifizieren. Der Hashtag 405 kann je nach gewünschter Produkt- oder Dienstaufgabe ein anderes Format aufweisen. Einfach als Veranschaulichung kann in einem Fall, in dem die Dienstaufgabe eine Taxifahrt ist, der Hashtag 405 einer von #BraucheFahrtzumFlughafen@ 130, #braucheFahrt, #BraucheHeimfahrtnachAbendessen, #SucheFahrtvonDT@2Uhr, #MusszurückinsHotel, #KannNichtFahrenBraucheHilfe oder dergleichen sein. Als weitere Veranschaulichung kann in einem Fall, in dem die Dienstaufgabe einer Entsendungssteueraufgabe für Flottenfahrzeuge entspricht, der Hashtag 405 einer von #AnNächsteStationLiefern, #ZurückZurBasis, #ZumNächstenAutohaus, #Fahrer12_Lieferung_an 432_Detroit_St_MI, #Fahrer4_Anhalten_Pause_machen, #Fahrer82_Auftanken_an_nächster_Tankstelle, #Fahrzeug9_zur_nächsten_Ladestation, #Fahrzeug43_nächster_Halt_Walmart_Adresse oder dergleichen. In einem anderen Fall, in dem die Dienstaufgabe einem Notfall entspricht, kann der Hashtag 405 einer von #HilfeNotfall, #BraucheBenzin, #BraucheAbschleppwagen, #BraucheReifenwechsel oder dergleichen sein. In anderen Fällen kann der Hashtag 405 einem opportunistischen standortbasierten Dienst entsprechen. Zum Beispiel kann der Hashtag 405 #BraucheLSATPowerScoreBook sein.
  • Dementsprechend kann die Dienstautomatisierungsvorrichtung 140 den Hashtag bei einem Block 410 konditionieren. Das Konditionieren des Hashtags 405 kann zu einem standardisierten Hashtag führen (in 4 nicht abgebildet). In einigen Ausführungsformen kann der Block 410 (und andere hier offenbarte Blöcke) dedizierte Hardware beinhalten, die Anweisungen ausführen kann, um die Funktionalität auszuführen, die dem Block 410 (oder den anderen Blöcken) zugeordnet ist. In weiteren Ausführungsformen können die maschinenlesbaren Anweisungen als Schaltung oder andere Arten von Hardwarekomponenten zusammengestellt sein.
  • Auf Grundlage des standardisierten Hashtags kann die Dienstautomatisierungsvorrichtung 140 bei Block 415 eine Auftragsanfrage erzeugen. Zu diesem Zweck kann die Dienstautomatisierungsvorrichtung 140 eine Auftragskategorie für den standardisierten Hashtag bestimmen und kann geeignete Benutzerdaten und Auftragsdaten erzeugen. Die Dienstautomatisierungsvorrichtung 140 kann auch die Auftragsdaten und oder die Benutzerdaten verschlüsseln.
  • Die Dienstautomatisierungsvorrichtung 140 kann eine Anfragenachricht 420 (der Nomenklatur halber als „Auftragsanfrage“ bezeichnet) erzeugen, die die verschlüsselten Auftragsdaten und/oder die verschlüsselten Benutzerdaten beinhaltet. Die Anfragenachricht stellt eine Zieltransaktion dar, die einer gewünschten Produkt- oder Dienstaufgabe entspricht. Die Anfragenachricht 420 kann die mit dem Hashtag 405 verbundene Auftragskategorie identifizieren.
  • Die Dienstautomatisierungsvorrichtung 140 kann die Anfragenachricht 420 an die Verzeichnisvorrichtung 150 senden. Als Reaktion auf das Empfangen der Anfragenachricht 420 kann die Verzeichnisvorrichtung 150 die Anfragenachricht 420 an mehrere Fahrzeuge senden, die im Fahrzeug-Peer-Netzwerk 160 enthalten sind. Somit können mehrere Anfragenachrichten 425 an jeweilige der mehreren Fahrzeuge gesendet werden. Die mehreren Fahrzeuge können die Auftragsanfrage bei Block 430 verarbeiten. Die Auftragsanfrage kann im Wesentlichen gleichzeitig über die mehreren Fahrzeuge hinweg verarbeitet werden. Infolgedessen kann eines dieser Fahrzeuge eine Antwortnachricht 435 an die Verzeichnisvorrichtung 150 senden. Die Antwortnachricht 435 ist lediglich der Nomenklatur halber als „Auftragsantwort“ bezeichnet.
  • Konkreter ausgedrückt, können in einigen Ausführungsformen, wie in 5 veranschaulicht die mehreren Anfragenachrichten 425 an N Fahrzeuge gesendet werden: Fahrzeug 510 (1); Fahrzeug 510 (2); ...; Fahrzeug 520 (J); ...; und Fahrzeug 510 (N). Hier sind J und N natürliche Zahlen, wobei J ≥ Nund N ≥ 2. Als Reaktion auf das Empfangen der Anfragenachrichten 425 bearbeiten die Fahrzeuge 510(1)-510 (N) bei Block 520 im Wesentlichen gleichzeitig die jeweiligen der Anfragenachrichten 425. Jedes der Fahrzeuge 510(1)-510(N) ist bei der Dienstautomatisierungsvorrichtung 140 registriert, zum Beispiel als Mitglied des Fahrzeugnetzwerks 160 zum Empfangen und Bearbeiten von Auftragsanfragen. In einigen Ausführungsformen können die Fahrzeuge 510(1)-510(N) im Standortmodus betrieben werden und einen opportunistischen kurierartigen Dienst bereitstellen. Zum Beispiel können die Fahrzeuge in der Nähe einer Bibliothek oder Buchhandlung betrieben werden und können bei Bedarf Bücher abholen und liefern. In anderen Ausführungsformen können die Fahrzeuge 510(1)-510(N) einen Teil einer Flotte bilden und können Anfragenachrichten 425 verarbeiten, die den durch die Entsendekoordinationsvorrichtung erzeugten Entsendungssteueraufgaben entsprechen. In einer dieser Ausführungsformen können eines oder mehrere der Fahrzeuge 510(1)-510(N) autonome Fahrzeuge sein. In noch anderen Ausführungsformen kann jedes der Fahrzeuge 510(1)-510(N) unabhängig in jemandes Eigentum (oder unter einem Leasing-Vertrag) stehen und eine bestimmte Art von Anfragenachricht 425 bearbeiten. Zum Beispiel kann mindestens eines der Fahrzeuge 510(1)-510(N) ein Lkw sein und kann Beförderungsdienste in einer Stadt oder Region ergänzen, in der eine gewerbliche Lkw-Transporteinheit keine angemessene Unterstützung hat.
  • Als Ergebnis eines derartigen Vorgangs kann das Fahrzeug 510(J) in einem Beispiel die in der Anfragenachricht 420 empfangene Auftragsanfrage validieren. Wie hierin offenbart, kann in einigen Ausführungsformen die Auftragsanfrage validiert werden, wenn das Bearbeiten der Auftragsanfrage oder einer iterativ modifizierten Version der Auftragsanfrage ein Ergebnis (wie etwa einen Hashwert) ergibt, das ein definiertes Validierungskriterium erfüllt. In einigen Ausführungsformen kann eine Auftragsanfrage validiert werden, wenn sowohl (a) das Bearbeiten der Auftragsanfrage oder einer iterativ modifizierten Version der Auftragsanfrage ein Ergebnis ergibt, das das erste Validierungskriterium erfüllt, als auch (b) das Fahrzeug eines oder mehrere der zweiten Validierungskriterien erfüllt.
  • Als Reaktion darauf kann das Fahrzeug 510(J) einen ersten Verzeichniseintrag mindestens auf Grundlage der validierten Auftragsanfrage bei Block 540 aktualisieren. Das Fahrzeug 510(J) speichert den ersten Verzeichniseintrag in einer oder mehreren Speichervorrichtungen (wie etwa den Verzeichnisdaten 186). In einigen Ausführungsformen kann der erste Verzeichniseintrag einen oder mehrere Datenblöcke beinhalten. Das Aktualisieren des ersten Verzeichniseintrags kann somit zum Beispiel das Hinzufügen eines Datenblocks, der der validierten Auftragsanfrage entspricht, zu dem ersten Verzeichniseintrag beinhalten. Eine solche Aktualisierung führt zu einem aktualisierten Verzeichniseintrag. In einigen Ausführungsformen kann das Aktualisieren des ersten Hauptdatensatzes das Verschlüsseln von mindestens einem von Auftragsdaten oder den Benutzerdaten, die der validierten Auftragsanfrage entsprechen, und Erzeugen eines derartigen Datenblocks beinhalten. Der Datenblock kann den Hashwert beinhalten, der sich aus der Bearbeitung der Auftragsanfrage ergibt und das erste Validierungskriterium erfüllt, der Datenblock kann zudem eines oder mehrere der verschlüsselten Auftragsdaten oder der verschlüsselten Benutzerdaten beinhalten.
  • Als weitere Reaktion auf die Validierung der Auftragsanfrage kann das Fahrzeug 510(J) die anderen Fahrzeuge in der Gruppe (z. B. Fahrzeug 510(1), Fahrzeug 510(2)..., Fahrzeug 510(J-1), Fahrzeug 510(J+1)... und Fahrzeug 510(N)) dazu veranlassen, jeweilige zweite Verzeichniseinträge bei Block 540 zu aktualisieren. Dazu kann das Fahrzeug 510 (J) eine Benachrichtigung an die anderen Fahrzeuge senden, um die entsprechenden zweiten Verzeichniseinträge zu aktualisieren. Die Benachrichtigung kann zum Beispiel Hashdaten und eine Anweisung zum Hinzufügen der Hashdaten zu den jeweiligen zweiten Verzeichnisdaten beinhalten. Das Aktualisieren jedes von dem/den zweiten Verzeichniseinträgen kann dazu führen, dass der aktualisierte Verzeichniseintrag von dem Fahrzeug 510(J) erzeugt und an diesem gespeichert wird. Zusätzlich kann das Fahrzeug 510 (J) die Antwortnachricht 435 an die Verzeichnisvorrichtung 140 senden.
  • Unter weiterer Bezugnahme auf 4 kann die Verzeichnisvorrichtung 150 eine zweite Anfragenachricht 450 an eine Drittanbietervorrichtung 440 (z. B. eine der Drittanbieterdienstvorrichtungen 195) senden. Die zweite Anfragenachricht 450 identifiziert eine Zieltransaktion (z. B. eine Pizzalieferung oder eine Haustierabholung). Somit wird die zweite Anfragenachricht 450 der Nomenklatur halber als „Transaktionsanfrage“ bezeichnet. Die zweite Anfragenachricht 450 kann Benutzerdaten beinhalten, die einen beabsichtigten Empfänger eines Zielprodukts oder Zieldiensts entsprechend der Zieltransaktion identifizieren. Die zweite Anfragenachricht 450 kann auch Auftragsdaten beinhalten, die ein solches Produkt oder einen solchen Dienst zumindest teilweise definieren.
  • Die Drittanbietervorrichtung 440 kann die Ausführung der Zieltransaktion verwalten. Die Verzeichnisvorrichtung 150 kann in einigen Ausführungsformen den Austausch von Rückmeldungen 455 zwischen der Drittanbietervorrichtung 440 und einer Benutzervorrichtung 460 (z. B. der mobilen Vorrichtung 105) ermöglichen. In anderen Ausführungsformen kann die Verzeichnisvorrichtung 150 optional den Austausch der Rückmeldungen 455 zwischen der Benutzervorrichtung 460 und dem Fahrzeug, das die Auftragsanfrage 425 validiert hat (z. B. wie das Fahrzeug 510(J) in dem in 5 gezeigten Beispiel) ermöglichen. Die Benutzervorrichtung 460 entspricht dem beabsichtigten Empfänger des Zielprodukts oder dem Empfänger der Zieldienstaufgabe. In Übereinstimmung mit hierin beschriebenen Aspekten können die Rückmeldungen 455 das Abschließen der Zielbestellung oder der Zieldienstaufgabe ermöglichen. Die Rückmeldungen 455 können eine oder mehrere Anfragen für zusätzliche Informationen in Bezug auf die Zielbestellung oder die Zieldienstaufgabe beinhalten. Mindestens eine der Rückmeldungen 455 kann ein oder mehrere Attribute des Zielprodukts oder der Zieldienstaufgabe definieren.
  • Ein Beispiel für Techniken, die sich aus den Prinzipien dieser Offenbarung ergeben und die gemäß dieser Offenbarung umgesetzt werden können, kann unter Bezugnahme auf die 6 besser verstanden werden. Zur Vereinfachung der Erklärung wird das beispielhafte Verfahren in 6 (und andere hierin offenbarte Techniken) als eine Reihe von Vorgängen dargestellt und beschrieben. Es wird jedoch angemerkt, dass das beispielhafte Verfahren und alle anderen Techniken dieser Offenbarung nicht durch die Reihenfolge der Vorgänge beschränkt sind. Einige Vorgänge können in einer anderen Reihenfolge als der hierin veranschaulichten und beschriebenen erfolgen. Zusätzlich oder alternativ können einige Vorgänge im Wesentlichen gleichzeitig mit anderen (veranschaulichten oder anderweitigen) Vorgängen durchgeführt werden. Ferner sind unter Umständen nicht alle veranschaulichten Vorgänge erforderlich, um ein beispielhaftes Verfahren oder eine beispielhafte Technik gemäß dieser Offenbarung umzusetzen. Ferner können in einigen Ausführungsformen zwei oder mehr der beispielhaften Verfahren und/oder anderen Techniken, die in dieser Schrift offenbart sind, in Kombination miteinander umgesetzt werden, um ein oder mehrere Elemente und/oder technische Verbesserungen, die in dieser Schrift offenbart sind, zu erzielen.
  • Techniken, die in der vorliegenden Schrift und den beigefügten Zeichnungen offenbart sind, können auf einem Herstellungsgegenstand gespeichert sein, um den Transport und die Übertragung solcher Methoden auf Computer oder anderen Arten von Informationsverarbeitungsmaschinen oder Verarbeitungsschaltungen zur Ausführung und somit zur Umsetzung durch einen Prozessor oder zur Speicherung auf einer Speichervorrichtung oder einer anderen Art von computerlesbaren Speichervorrichtung zu unterstützen. In einem Beispiel können ein oder mehrere Prozessoren, die ein Verfahren oder eine Kombination von Verfahren, die in dieser Schrift offenbart sind, durchführen, genutzt werden, um Programmiercodeanweisungen auszuführen, die auf einer Speichervorrichtung oder einer beliebigen computerlesbaren oder maschinenlesbaren Speichervorrichtung oder beliebigen nicht transitorischen Speichermedien gespeichert sind, um eine oder verschiedene der hierin offenbarten Techniken umzusetzen. Die Programmiercodeanweisungen können, wenn sie von einem oder mehreren Prozessoren ausgeführt werden, die verschiedenen Vorgänge in den beispielhaften Verfahren und/oder andere hierin offenbarte Technik umsetzen oder ausführen.
  • Die Programmiercodeanweisungen stellen daher ein computerausführbares oder maschinenausführbares Framework bereit, um die beispielhaften Verfahren und/oder anderen hierin offenbarten Techniken umzusetzen. Insbesondere, jedoch nicht ausschließlich, kann jeder Block der Ablaufdiagrammveranschaulichungen und/oder Kombinationen von Blöcken in den Ablaufdiagrammveranschaulichungen durch die Programmiercodeanweisungen umgesetzt werden.
  • 6 stellt ein Beispiel für ein Verfahren 600 zum Automatisieren der Konfiguration einer Produkt- oder Dienstbereitstellung gemäß einer oder mehreren Ausführungsformen dieser Offenbarung dar. Eine Rechenvorrichtung, die in einem Fahrzeug (z. B. Fahrzeug 170d) enthalten ist, kann das beispielhafte Verfahren 600 vollständig oder teilweise umsetzen. In einigen Ausführungsformen ist die Rechenvorrichtung in das Fahrzeug integriert. In anderen Ausführungsformen ist die Verarbeitungs- oder Rechenvorrichtung funktionell an das Fahrzeug gekoppelt. Die Rechenvorrichtung kann die digitale Mining-Vorrichtung 180 (1) verkörpern oder bilden.
  • Die Rechenvorrichtung weist eine Verarbeitungsvorrichtung auf, die einen oder mehrere Prozessoren, eine oder mehrere Speichervorrichtungen, andere Arten von Rechenressourcen, eine Kombination davon oder dergleichen beinhaltet oder funktionell an diese gekoppelt ist. Ein solcher Prozessor/solche Prozessoren, eine solche Speichervorrichtung/solche Speichervorrichtungen und eine solche Rechenressource/solche Rechenressourcen ermöglichen oder unterstützen anderweitig einzeln oder in einer bestimmten Kombination die Umsetzung des beispielhaften Verfahrens 600. Die Rechenressourcen können Folgendes einschließen: Betriebssysteme (operating systems - O/Ss); Software zur Konfiguration und/oder Steuerung einer virtualisierten Umgebung; Firmware; (einen) Hauptprozessor(en) (central processing unit(s) - CPU(s)); (einen) Grafikprozessor(en) (graphics processing unit(s) - GPU(s)); einen virtuellen Speicher; einen Festplattenspeicher; (eine) Schnittstelle(n) (E/A-Schnittstellenvorrichtungen, (eine) Programmierschnittstelle(n) (wie etwa Anwendungsprogrammierschnittstellen (application programming interfaces - APIs) usw.); (eine) Steuervorrichtung(en); Netzteile; eine Kombination des Vorangehenden; oder dergleichen. Die Rechenvorrichtung kann eine Kommunikationseinheit beinhalten oder funktionell an diese gekoppelt sein. Die Rechenvorrichtung gestattet den Austausch von Daten, Metadaten und/oder Signalisierung zwischen der Rechenvorrichtung (oder einer Komponente der Vorrichtung) und einer Rechenvorrichtung oder einer elektronischen Vorrichtung außerhalb der Rechenvorrichtung. Somit können die der Rechenvorrichtung zur Verfügung stehenden Rechenressourcen auch stromabwärtige Kommunikationsbandbreite und/oder stromaufwärtige Kommunikationsbandbreite beinhalten.
  • Bei Block 610 kann die in der Rechenvorrichtung enthaltene Verarbeitungsvorrichtung Anfragedaten von einem Rechensystem empfangen, wobei ein Teil der Anfragedaten eine Auftragsanfrage (z. B. Auftragsanfrage 420) definiert. Die Auftragsanfrage kann auf einem Hashtag (z. B. Hashtag 114) basieren, der auf einer Social-Media-Plattform gepostet wird. Ein SOLCHER Teil der Anfragedaten beinhaltet Auftragsdaten und/oder Benutzerdaten. In einigen Ausführungsformen kann die Auftragsanfrage eine Blockchain-Transaktion darstellen. Das Rechensystem kann relativ zu einem Fahrzeug entfernt angeordnet sein, das die Verarbeitungsvorrichtung beinhaltet. Das Rechensystem kann in der einen oder den mehreren Verzeichnisvorrichtungen 150 (1) ausgeführt sein oder diese beinhalten. Das Rechensystem kann das Umsetzen einer Transaktion oder das Verwalten der Umsetzung der Transaktion, die der Auftragsanfrage entspricht, ermöglichen.
  • Bei Block 620 kann die in der Rechenvorrichtung enthaltene Verarbeitungsvorrichtung Validierungsdaten unter Verwendung von mindestens den Anfragedaten in einem Versuch, die Auftragsanfrage zu validieren, erzeugen. Zu diesem Zweck kann die Verarbeitungsvorrichtung in einigen Ausführungsformen die Anfragedaten durch Anwenden einer kryptographischen Hashfunktion (z. B. RIPEMD-160, Secure Hash Algorithm (SHA)-1, SHA-256, SHA-512 oder dergleichen) auf die Anfragedaten bearbeiten, was zu Validierungsdaten führt, die einen bestimmten Hashwert beinhalten. Die Verarbeitungsvorrichtung kann die Anfragedaten zu definierten Zeiträumen und/oder innerhalb definierter Regionen (oder in einigen Fällen an definierten Standorten) bearbeiten.
  • Bei Block 630 kann die in der Rechenvorrichtung enthaltene Verarbeitungsvorrichtung bestimmen, ob die Auftragsanfrage validiert ist. In Übereinstimmung mit hierin beschriebenen Aspekten kann die Auftragsanfrage in einer Ausführungsform validiert werden, wenn die Validierungsdaten ein erstes Validierungskriterium erfüllen. In einigen Ausführungsformen kann eine Auftragsanfrage validiert werden, wenn sowohl die Validierungsdaten das erste Validierungskriterium erfüllen als auch das Fahrzeug, das die Rechenvorrichtung beinhaltet, eines oder mehrere der zweiten Validierungskriterien erfüllt.
  • Als Reaktion auf eine negative Bestimmung kann die Verarbeitungsvorrichtung weiterhin Validierungsdaten erzeugen. Als Reaktion auf eine bestätigende Bestimmung kann der Ablauf des beispielhaften Verfahrens 600 zu Block 640 übergehen, wo die Verarbeitungsvorrichtung einen Verzeichniseintrag mindestens auf Grundlage einer Kombination der Validierungsdaten und eines oder mehrerer der Auftragsdaten oder der Benutzerdaten aktualisieren kann. Der Verzeichniseintrag kann als Blockchain-Verzeichnisdaten formatiert sein. Somit kann das Aktualisieren des Hauptdatensatzes das Hinzufügen eines Datenblocks zu einer Sequenz (oder Kette) von Datenblöcken beinhalten, die den Hauptdatensatz bilden.
  • Bei Block 650 kann die in der Rechenvorrichtung enthaltene Verarbeitungsvorrichtung ein oder mehrere Fahrzeuge dazu veranlassen, einen zweiten oder zweite Verzeichniseinträge zu aktualisieren, und zwar mindestens auf Grundlage der Kombination aus den Validierungsdaten und einer oder mehreren der Auftragsdaten oder der Benutzerdaten. Dazu kann die Verarbeitungsvorrichtung eine Benachrichtigung senden, um die jeweiligen zweiten Verzeichniseinträge zu dem einen oder einigen Fahrzeugen zu aktualisieren. Die Benachrichtigung kann zum Beispiel die Validierungsdaten (z. B. einen kryptographischen Hash) und die Auftragsdaten oder die Benutzerdaten oder beides beinhalten. Die Benachrichtigung kann in einigen Konfigurationen auch eine Anweisung zum Hinzufügen der Validierungsdaten und der Auftragsdaten und/oder der Benutzerdaten zu dem/den entsprechenden zweiten Verzeichniseinträgen beinhalten. In einigen Umsetzungen können die Auftragsdaten und/oder die Benutzerdaten verschlüsselt werden, bevor sie zu dem/den entsprechenden zweiten Verzeichniseinträgen hinzugefügt werden. Solche Fahrzeuge können eine Gruppe von Fahrzeugen (z. B. Fahrzeuge 510(1)-510(N), 5) bilden, die die Anfragedaten im Wesentlichen gleichzeitig mit dem Fahrzeug, das die Verarbeitungsvorrichtung beinhaltet, verarbeiten. Dementsprechend kann das Veranlassen eines Fahrzeugs, einen zweiten Verzeichniseintrag zu aktualisieren, Senden einer Benachrichtigung an das Fahrzeug, die angibt, dass die Auftragsanfrage validiert wird, und Anweisen des Fahrzeugs, den Hashwert und eines oder mehrere von den Auftragsdaten oder den Benutzerdaten dem zweiten Verzeichniseintrag hinzuzufügen, beinhalten.
  • Bei Block 660 kann die in der Rechenvorrichtung enthaltene Verarbeitungsvorrichtung Antwortdaten an das Rechensystem (z. B. die eine oder mehreren Verzeichnisvorrichtungen 150) senden, wobei die Antwortdaten für eine Antwort auf die Auftragsanfrage repräsentativ sind. Die Antwortdaten können die Validierungsdaten und eines oder mehrere von den Auftragsdaten oder den Benutzerdaten beinhalten. Die Verarbeitungsvorrichtung kann die Antwortdaten mittels der Kommunikationseinheit (z. B. Kommunikationseinheit 189, 1) senden, die entweder in die Rechenvorrichtung integriert oder funktionell an diese gekoppelt ist.
  • Obwohl in 6 nicht veranschaulicht, kann das beispielhafte Verfahren 600 auch einen Block beinhalten, bei dem Rückmeldedaten, die der validierten Auftragsanfrage entsprechen, an das Rechensystem (oder eine Vorrichtung davon) gesendet, von diesem empfangen oder mit diesem ausgetauscht werden können. In einer Ausführungsform können die Rückmeldedaten mit der Verzeichnisvorrichtung 150 ausgetauscht werden.
  • 7 ist ein Blockdiagramm ein Beispiel für eine Vorrichtung 700 zur automatisierten Konfiguration einer Produkt- oder Dienstbereitstellung gemäß einer oder mehreren Ausführungsformen dieser Offenbarung. Die Vorrichtung 700 kann die digitale Mining-Vorrichtung 180 verkörpern oder bilden. Somit beinhaltet die Vorrichtung, wie veranschaulicht, eine Verarbeitungsvorrichtung 705 und eine Kommunikationseinheit 189. Die Verarbeitungsvorrichtung 705 kann die Steuereinheit 181 verkörpern oder ausmachen. In einigen Ausführungsformen können die Verarbeitungsvorrichtung 705 und die Kommunikationseinheit 189 in ein Fahrzeug integriert sein (z. B. eines der Fahrzeuge in dem Peer-Netzwerk 160, 1). In anderen Ausführungsformen können die Verarbeitungsvorrichtung 705 oder die Kommunikationseinheit 189 oder beide funktionell an ein derartiges Fahrzeug gekoppelt sein. In noch anderen Ausführungsformen kann die Verarbeitungsvorrichtung 705 in das Fahrzeug integriert sein und kann die Kommunikationseinheit 189 funktionell das Fahrzeug gekoppelt sein.
  • Die Verarbeitungsvorrichtung 705 kann einen oder mehrere Prozessoren 710 und eine oder mehrere Speichervorrichtung 730 (als Speicher 730 bezeichnet) beinhalten, die maschinenlesbare Anweisungen (z. B. computerlesbare und/oder computerausführbare Anweisungen) beinhalten, auf die durch zumindest einen der Prozessoren 710 zugegriffen werden kann oder die durch diesen ausgeführt werden können. Der Prozessor/die Prozessoren 710 kann/können zum Beispiel als Folgende ausgeführt sein oder diese beinhalten: eine GPU; mehrere GPUs; eine CPU; mehrere CPUs, eine anwendungsspezifische integrierte Schaltung (application-specific integrated circuit - ASIC); einen Mikrocontroller; eine programmierbare Logiksteuerung (programmable logic controller - PLC); ein feldprogrammierbares Gate-Array (FPGA); eine Kombination davon; oder dergleichen. In einigen Ausführungsformen kann/können der Prozessor/die Prozessoren 710 in einer einzigen Rechenvorrichtung (z. B. einer elektronischen Steuereinheit (electronic control unit - ECU), einem Auto-Infotainment-System (in-car infotainment system - ICI-System) oder dergleichen angeordnet sein. In weiteren Ausführungsformen kann/können der Prozessor/die Prozessoren 710 über zwei oder mehr Rechenvorrichtungen (z. B. mehrere ECUs; eine Kombination aus einem ICI-System und einer oder viele ECUs; oder dergleichen) verteilt sein.
  • Der Prozessor/die Prozessoren 710 kann/können mittels einer Kommunikationsarchitektur 720 funktionell an den Speicher 730 gekoppelt sein. Die Kommunikationsarchitektur 720 ist für die bestimmte (lokalisierte oder verteilte) Anordnung des Prozessors/der Prozessoren 710 geeignet. In einigen Ausführungsformen kann die Kommunikationsarchitektur 720 eine oder viele Busarchitekturen beinhalten, wie etwa einen Ethernet-basierte industriellen Bus, einen Controller-Area-Network(CAN)-Bus, einen Modbus, andere Arten von Feldbusarchitekturen, einer Kombination davon oder dergleichen.
  • Wie in 7 veranschaulicht beinhaltet der Speicher 730 das Auftrag-Mining-Modul 182 und das Auftragsverwaltungsmodul 184. Maschinenlesbare Anweisungen verkörpern jedes solcher Module oder machen dieses anderweitig aus. In einigen Ausführungsformen sind die maschinenlesbaren Anweisungen in den Speicher 730 kodiert und können in Komponenten angeordnet sein, die integriert (z. B. verbunden und zusammengestellt) und in computerausführbarer Form auf dem Speicher 730 (wie gezeigt) oder auf einem anderen maschinenlesbaren nicht transitorischen Speichermedium oder mehreren anderen maschinenlesbaren nicht transitorischen Speichermedien gespeichert sein können. In weiteren Ausführungsformen können die maschinenlesbaren Anweisungen als eine Schaltung oder andere Arten von Hardwarekomponenten zusammengestellt sein.
  • Mindestens einer der Prozessoren 710 kann das Auftrag-Mining-Modul 182 und das Auftragverwaltungsmodul 184 einzeln oder in Kombination ausführen, um die Verarbeitungsvorrichtung 705 dazu zu veranlassen, Funktionen zur automatisierten Steuerung einer Produkt- oder Dienstbereitstellung gemäß dieser Offenbarung durchzuführen. Der Speicher 730 beinhaltet außerdem die Validierungsregel(n) 186 und die Verzeichnisdaten 186, die einzeln oder in Kombination als Teil der Ausführung von einem oder mehreren solcher Module genutzt werden können.
  • Wenngleich in 7 nicht veranschaulicht, kann die Verarbeitungsvorrichtung 705 auch andere Arten von Rechenressourcen beinhalten, die die Ausführung von mindestens einem von dem Auftrag-Mining-Modul 182 oder dem Auftragverwaltungsmodul 184 ermöglichen oder anderweitig erleichtern können. Die Rechenressourcen können zum Beispiel mehrere Schnittstellen beinhalten (wie etwa E/A-Schnittstellen, APIs und/oder einen drahtlosen Kommunikationsadapter oder eine andere Art von drahtloser Kommunikationskomponente). Des Weiteren kann die Rechenressource/können die Rechenressourcen (eine) Steuerungsvorrichtung(en), Netzteile, ein O/S, Firmware, eine Kombination davon oder dergleichen beinhalten.
  • 8 stellt ein Beispiel für eine Rechenumgebung zur automatisierten Konfiguration einer Produkt- oder Dienstbereitstellung gemäß einer oder mehreren Ausführungsformen dieser Offenbarung dar. Die Rechenumgebung kann mehrere Rechenvorrichtungen 800 beinhalten, die gemäß Aspekten dieser Offenbarung verwendet werden können. Eine erste Kombination der Rechenvorrichtungen 800 kann die Dienstautomatisierungsvorrichtung 140 verkörpern und eine zweite Kombination der Rechenvorrichtungen 800 kann die Verzeichnisvorrichtung 150 verkörpern. Jede Rechenvorrichtung 800 beinhaltet mindestens einen Prozessor 802, der Anweisungen ausführt, die in einer oder mehreren Speichervorrichtungen (als Speicher 804 bezeichnet) gespeichert sind. Bei den Anweisungen kann es sich beispielsweise um Anweisungen zum Umsetzen von Funktionalität handeln, die als von einem oder mehreren vorstehend offenbarten Modulen und Systemen ausgeführt beschrieben sind, oder um Anweisungen zum Umsetzen eines oder mehrerer der vorstehend offenbarten Verfahren. Der/die Prozessor(en) 802 kann/können zum Beispiel in einer CPU, mehreren CPUs, einer GPU, mehreren GPUs, einem Mehrkernprozessor, einer Kombination davon und dergleichen ausgeführt sein. In einigen Ausführungsformen kann/können der/die Prozessor(en) 802 in einer einzelnen Rechenvorrichtung angeordnet sein. In anderen Ausführungsformen kann/können der/die Prozessor(en) 802 über zwei oder mehr Rechenvorrichtung (z. B. mehrere CPUs; mehrere GPUs; eine Kombination davon; oder dergleichen) verteilt sein.
  • Der/die Prozessor(en) 802 kann/können mittels einer Kommunikationsarchitektur 806 (z. B. einem Systembus) auf den Speicher 804 zugreifen. Die Kommunikationsarchitektur 806 ist für die bestimmte (lokalisierte oder verteilte) Anordnung und Art des Prozessors/der Prozessoren 802 geeignet. In einigen Ausführungsformen kann die Kommunikationsarchitektur 806 eine oder viele Busarchitekturen beinhalten, wie etwa einen Speicherbus oder eine Speichersteuerung; einen peripheren Bus; einen beschleunigten Grafikport; einen Prozessor oder lokalen Bus; eine Kombination davon; oder dergleichen. Zur Veranschaulichung können derartige Architekturen einen Industry-Standard-Architecture-Bus (ISA-Bus), einen Micro-Channel-Architecture-Bus (MCA-Bus), einen Enhanced-ISA-Bus (EISA-Bus), einen lokalen Video-Electronics-Standards-Association-Bus (VESA-Bus), einen Accelerated-Graphics-Port-Bus (AGP-Bus), einen Peripheral-Component-Interconnect-Bus (PCI-Bus, einen PCI-Express-Bus, einen Personal-Computer-Memory-Card-International-Association-Bus (PCMCIA-Bus), einen Universal Serial Bus (USB) und dergleichen beinhalten.
  • Zusätzlich zum Speichern von ausführbaren Anweisungen kann der Speicher 804 auch eine oder eine Kombination aus Hashtag-Aktivitätsdaten, Formatierungsregeln, Konfigurationsdaten, Transaktionsdaten usw. speichern. Die Datenart, die im Speicher 804 gespeichert wird, kann auf der Funktionalität der Rechenvorrichtung 800 basieren. Erste Arten von Daten können in Fällen, in denen die Rechenvorrichtung 800 die Dienstautomatisierungsvorrichtung 140 verkörpert oder bildet, in dem Speicher 804 gespeichert werden. Zweite Arten von Daten können in Fällen, in denen die Rechenvorrichtung 800 die Verzeichnisvorrichtung 150 verkörpert oder bildet, in dem Speicher 804 gespeichert werden.
  • Jede Rechenvorrichtung 800 kann zudem einen Massenspeicher 808 beinhalten, auf den der/die Prozessor(en) 802 mittels der Kommunikationsarchitektur 806 zugreifen kann/können. Der Massenspeicher 808 kann maschinenlesbare Anweisungen (z. B. computerlesbare Anweisungen und/oder computerausführbare Anweisungen) beinhalten. In einigen Ausführungsformen sind die maschinenlesbaren Anweisungen in den Massenspeicher 808 codiert und können in Komponenten angeordnet sein, die integriert (z. B. verbunden und kompiliert) und in computerausführbarer Form auf dem Massenspeicher 808 oder auf einem oder mehreren anderen in der Rechenvorrichtung 800 enthaltenen maschinenlesbaren nichttransitorischen Speichermedien gespeichert sein können. Derartige Komponenten können eines oder mehrere der verschiedenen hierin offenbarten Module verkörpern oder bilden. Derartige Module sind als automatisierte Aktualisierungsmodule 814 veranschaulicht. Dementsprechend können in einigen Ausführungsformen die automatisierten Konfigurationsmodule 814 das Erfassungsmodul 204, das Hashtag-Normalisierungsmodul 208 und das Auftragsanfragemodul 212 beinhalten. In anderen Ausführungsformen können die automatisierten Konfigurationsmodule 814 das Knotenverwaltungsmodul 304, das Transaktionsverwaltungsmodul 308, das Rückmeldemodul 312 und das Zahlungsprozessormodul 316 beinhalten.
  • Die Ausführung der automatisierten Konfigurationsmodule 814 einzeln oder in Kombination durch mindestens einen von dem/den Prozessor(en) 802 kann dazu führen, dass die Rechenvorrichtung 800 mindestens einen Teil der hierin offenbarten Funktionalität zur automatisierten Konfiguration eines Produkts oder eines Dienstes bereitstellt. Zum Beispiel kann die Ausführung der automatisierten Konfigurationsmodule 814 einzeln oder in Kombination bewirken, dass die Rechenvorrichtung 800 eine oder mehrere der hierin offenbarten Techniken umsetzt.
  • Der Massenspeicher 808 kann auch Daten speichern, die verwendet werden können, um die hierin offenbarte Funktionalität für die automatisierte Lieferung von Aktualisierungen an Fahrzeugprofilpakete umzusetzen, oder die sich aus der Umsetzung einer solchen Funktionalität ergeben können. Solche Daten sind als automatisierte Konfigurationsdaten 816 veranschaulicht und können zum Beispiel eine oder eine Kombination aus Hashtag-Aktivitätsdaten, Formatierungsregeln, Konfigurationsdaten, verschiedenen Arten von Transaktionsdaten und dergleichen beinhalten.
  • Jede Rechenvorrichtung 800 kann auch eine oder mehrere Eingabe-/Ausgabeschnittstellenvorrichtungen 810 (als E/A-Schnittstelle 810 bezeichnet) beinhalten, die es externen Vorrichtungen ermöglichen oder anderweitig erleichtern, mit der Rechenvorrichtung 800 zu kommunizieren. Zum Beispiel kann die E/A-Schnittstelle 810 verwendet werden, um Daten und/oder Anweisungen von einer externen Rechenvorrichtung zu empfangen und zu dieser zu senden. Die Rechenvorrichtung 800 beinhaltet außerdem eine oder mehrere Netzwerkschnittstellenvorrichtungen 812 (als Netzwerkschnittstelle(n) 812 bezeichnet), die das Koppeln der Rechenvorrichtung 800 mit einer oder mehreren externen Vorrichtungen ermöglichen oder anderweitig erleichtern können. Das funktionelle Koppeln der Rechenvorrichtung 800 an eine externe Vorrichtung kann das Herstellen einer drahtgebundenen Verbindung oder einer drahtlosen Verbindung zwischen der Rechenvorrichtung 800 und der externen Vorrichtung beinhalten. Zum Beispiel kann die Rechenvorrichtung 800 Daten, Metadaten und/oder Signalisierung drahtlos an ein oder mehrere Fahrzeuge in dem Fahrzeug-Peer-Netzwerk 160 mittels mindestens einer der Netzwerkschnittstelle(n) 812 senden.
  • Wie in dieser Anmeldung verwendet, beziehen sich die Begriffe „Umgebung“, „System“, „Einheit", „Modul“, „Architektur“, „Schnittstelle“, „Komponente“ und dergleichen auf eine computerbezogene Einheit oder eine Einheit in Bezug auf eine Betriebseinrichtung mit einer oder mehreren definierten Funktionen. Die Begriffe „Umgebung“, „System“, „Modul“, „Komponente“, „Architektur“, „Schnittstelle“ und „Einheit“ können austauschbar verwendet werden und können sich allgemein auf funktionale Elemente beziehen. Bei solchen Einrichtungen kann es sich entweder um Hardware, eine Kombination aus Hardware und Software oder ausgeführte Software handeln. Als ein Beispiel kann ein Modul in einem Prozess, der auf einem Prozessor ausgeführt wird, einem Prozessor, einem Objekt, einem ausführbaren Abschnitt von Software, einem Ausführungsablauf, einem Programm und/oder einer Rechenvorrichtung ausgebildet sein. Als ein weiteres Beispiel können sowohl eine Softwareanwendung, die auf einer Rechenvorrichtung ausgeführt wird, als auch die Rechenvorrichtung ein Modul verkörpern. Als noch ein weiteres Beispiel können sich ein oder mehrere Module in einem Prozess und/oder einem Ausführungsablauf befinden. Ein Modul kann auf einer Rechenvorrichtung lokalisiert oder zwischen zwei oder mehr Rechenvorrichtungen verteilt sein. Wie in dieser Schrift offenbart, kann ein Modul aus verschiedenen computerlesbaren nicht transitorischen Speichermedien ausgeführt werden, die verschiedene Datenstrukturen darauf gespeichert haben. Module können zum Beispiel gemäß einem (entweder analogen oder digitalen) Signal über lokale Prozesse und/oder Remote-Prozesse kommunizieren, das ein oder mehrere Datenpakete aufweist (z. B. Daten von einer Komponente, die über das Signal mit einer anderen Komponente in einem lokalen System, verteilten System und/oder über ein Netzwerk interagiert, wie etwa ein Weitverkehrsnetz mit anderen Systemen).
  • Als noch ein weiteres Beispiel kann ein Modul in einer Einrichtung mit einer definierten Funktionalität, die durch mechanische Teile bereitgestellt ist, die durch eine elektrische oder elektronische Schaltung betätigt werden, die durch eine durch einen Prozessor ausgeführte Software-Anwendung oder Firmware-Anwendung gesteuert wird, ausgebildet sein oder diese beinhalten. Ein solcher Prozessor kann intern oder extern zu der Einrichtung sein und kann zumindest einen Teil der Software- oder Firmware-Anwendung ausführen. In noch einem weiteren Beispiel kann ein Modul in einer Einrichtung, die eine definierte Funktionalität durch elektronische Komponenten ohne mechanische Teile bereitstellt, ausgebildet sein oder diese beinhaltet. Die elektronischen Komponenten können einen Prozessor beinhalten, um Software oder Firmware auszuführen, welche die Funktionalität der elektronischen Komponenten zumindest teilweise ermöglicht oder anderweitig unterstützt.
  • In einigen Ausführungsformen können Module zum Beispiel gemäß einem (entweder analogen oder digitalen) Signal über lokale Prozesse und/oder Remote-Prozesse kommunizieren, das ein oder mehrere Datenpakete aufweist (z. B. Daten von einer Komponente, die über das Signal mit einer anderen Komponente in einem lokalen System, verteilten System und/oder über ein Netzwerk interagiert, wie etwa ein Weitverkehrsnetz mit anderen Systemen). Des Weiteren können Module in weiteren Ausführungsformen über thermische, mechanische, elektrische und/oder elektromechanische Kopplungsmechanismen (wie etwa Schaltungen, Verbinder, Kombinationen davon oder dergleichen) kommunizieren oder anderweitig gekoppelt sein. Eine Schnittstelle kann Eingangs-/Ausgangskomponenten (E/A-Komponenten) sowie zugeordnete Prozessoren, Anwendungen und/oder andere Programmierkomponenten beinhalten.
  • Wie in dieser Offenbarung verwendet, kann sich der Begriff „Prozessor“ auf eine beliebige Art von Verarbeitungsschaltung oder -vorrichtung beziehen. Ein Prozessor kann als eine Kombination aus einer Verarbeitungsschaltung oder Rechenverarbeitungseinheiten (wie etwa CPUs, GPUs oder einer Kombination davon) umgesetzt sein. Daher kann sich ein Prozessor zu Veranschaulichungszwecken auf Folgendes beziehen: einen Einkernprozessor; einen einzigen Prozessor mit Software-Multithread-Ausführungsfähigkeit; einen Mehrkernprozessor; einen Mehrkernprozessor mit Software-Multithread-Ausführungsfähigkeit; einen Mehrkernprozessor mit Hardware-Multithread-Technologie; eine Parallelverarbeitungsplattform (oder Parallelrechenplattform); und Parallelrechenplattformen mit verteiltem geteiltem Speicher.
  • Des Weiteren oder als ein weiteres Beispiel kann sich ein Prozessor auf eine integrierte Schaltung (integrated circuit - IC), eine ASIC, einen digitalen Signalprozessor (DSP), ein FPGA, eine PLC, eine komplexe programmierbare Logikvorrichtung (complex programmable logic device - CPLD), eine diskrete Gate- oder Transistorlogik, diskrete Hardwarekomponenten oder eine beliebige Kombination davon beziehen, die ausgebildet oder anderweitig konfiguriert (z. B. gefertigt) ist, um die hierin beschriebenen Funktionen durchzuführen.
  • In einigen Ausführungsformen können Prozessoren Architekturen im Nanobereich nutzen, um den Platzverbrauch zu optimieren oder die Leistung von Systemen, Vorrichtungen oder anderer elektronischer Ausstattung gemäß dieser Offenbarung zu erweitern. Zum Beispiel kann ein Prozessor molekulare Transistoren und/oder quantenpunktbasierte Transistoren, Schalter und Gates beinhalten.
  • Ferner beziehen sich in der vorliegenden Beschreibung und den angehängten Zeichnungen Begriffe, wie etwa „speichern“, „Speicher“, „Datenspeicher“, „Datenspeicherung“, „Arbeitsspeicher“, „Ablage“ und im Wesentlichen jede beliebige andere Informationsspeicherkomponente, die für den Betrieb und die Funktionalität einer Komponente der Offenbarung relevant ist, auf Speicherkomponenten, in einer oder mehreren Speichervorrichtungen ausgebildete Einrichtungen oder Komponenten, die eine Speichervorrichtung bilden. Es ist anzumerken, dass die hierin beschriebenen Speicherkomponenten oder Speichervorrichtungen nicht transitorische Computerspeichermedien verkörpern oder beinhalten, die durch eine Rechenvorrichtung eingelesen werden können oder auf die diese anderweitig zugreifen kann. Solche Medien können bei beliebigen Verfahren oder einer beliebigen Technologie zur Speicherung von Informationen umgesetzt werden, wie etwa maschinenlesbare Anweisungen (z. B. computerlesbare Anweisungen), Informationsstrukturen, Programmmodule oder andere Informationsobj ekte.
  • In dieser Schrift offenbarte Speicherkomponenten oder Speichervorrichtungen können entweder in einem flüchtigen Speicher oder einem nicht flüchtigen Speicher ausgebildet sein oder können sowohl flüchtigen als auch nicht flüchtigen Speicher beinhalten. Des Weiteren können die Speicherkomponenten oder Speichervorrichtungen Wechselspeicher- oder Festwertspeichermedien und/oder zu einer Rechenvorrichtung oder Komponente intern oder extern sein. Zu Beispielen für verschiedene Arten von nicht transitorischen Speichermedien gehören Festplatten, Zip-Laufwerke, CD-ROMs, Digital Versatile Disks (DVDs) oder anderer optischer Speicher, Magnetkassetten, Magnetbänder, Magnetplattenspeicher oder andere Magnetspeichervorrichtungen, Flash-Speicherkarten und andere Arten von Speicherkarten, Kassetten oder ein beliebiges anderes nicht transitorisches Medium, das dazu geeignet ist, die erwünschten Informationen zu tragen, und auf das durch eine Rechenvorrichtung zugegriffen werden kann.
  • Als eine Veranschaulichung kann nicht flüchtiger Speicher Nur-Lese-Speicher (read only memory - ROM), programmierbaren ROM (PROM), elektrisch programmierbaren ROM (EPROM), elektrisch löschbaren, programmierbaren ROM (electrically erasable programmable ROM - EEPROM) oder Flash-Speicher einschließen. Flüchtiger Speicher kann Direktzugriffsspeicher (random access memory - RAM) einschließen, der als externer Zwischenspeicher fungiert. Zur Veranschaulichung ist RAM unter anderem in vielen Formen verfügbar, wie etwa synchroner RAM (SRAM), dynamischer RAM (DRAM), synchroner DRAM (SDRAM), SDRAM mit doppelter Datenrate (DDR SDRAM), erweiterter SDRAM (ESDRAM) Synchlink-DRAM (SLDRAM) und Direct-Rambus-RAM (DRRAM). Die in dieser Schrift beschriebenen offenbarten Speichervorrichtungen oder Speicher der Betriebs- oder Rechenumgebungen sollen eine oder mehreren von diesen und/oder beliebige andere geeignete Speicherarten einschließen.
  • Sprache, die konditionale Zusammenhänge ausdrückt, wie unter anderem „kann“, „könnte“, „können“ oder „könnten“, soll im Allgemeinen vermitteln, dass gewisse Ausführungsformen gewisse Merkmale, Elemente und/oder Vorgänge beinhalten könnten, wohingegen andere Umsetzungen diese nicht beinhalten, es sei denn, es ist konkret etwas Anderes angegeben oder es ergibt sich etwas Anderes aus dem jeweils verwendeten Kontext. Somit soll solche Sprache, die konditionale Zusammenhänge ausdrückt, im Allgemeinen nicht implizieren, dass Merkmale, Elemente und/oder Vorgänge in irgendeiner Weise für eine oder mehrere Umsetzungen erforderlich sind oder dass eine oder mehrere Umsetzungen notwendigerweise Logik zum Entscheiden mit oder ohne Benutzereingabe oder Eingabeaufforderung, ob diese Merkmale, Elemente und/oder Vorgänge in einer konkreten Umsetzung beinhaltet sind oder durchgeführt werden sollen, beinhalten.
  • Die Ablauf- und Blockdiagramme in den Figuren veranschaulichen die Architektur, Funktionalität und den Betrieb möglicher Umsetzungen von Beispielen für Systeme, Verfahren und Computerprogrammprodukte gemäß verschiedenen Ausführungsformen der vorliegenden Offenbarung. In dieser Hinsicht kann jeder Block in dem Ablaufdiagramm oder den Blockdiagrammen ein Modul, ein Segment oder einen Anweisungsabschnitt wiedergeben, das/der eine oder mehrere maschinen- oder computerausführbare Anweisungen zum Umsetzen der konkreten Vorgänge beinhaltet. Es ist anzumerken, dass jeder Block der Blockdiagramme und/oder Ablaufdiagrammveranschaulichung und Kombinationen aus Blöcken in den Blockdiagrammen und/oder der Ablaufdiagrammveranschaulichung durch Spezialsysteme auf Hardware-Basis umgesetzt werden können/kann, welche die konkreten Funktionen oder Vorgänge durchführen oder Kombinationen aus Spezialhardware und Computeranweisungen ausführen.
  • Die in dieser Schrift beschriebenen computerlesbaren Programmanweisungen können von einem computerlesbaren Speichermedium auf entsprechende Rechen-/Verarbeitungsvorrichtungen oder über ein Netzwerk, zum Beispiel das Internet, ein Lokalverkehrsnetz, ein Weitverkehrsnetz und/oder ein drahtloses Netzwerk, auf einen externen Computer oder eine externe Speichervorrichtung heruntergeladen werden. Das Netzwerk kann Kupferübertragungskabel, Übertragungsglasfaser, eine drahtlose Übertragung, Router, Firewalls, Schalter, Gateway-Computer und/oder Edge-Server beinhalten. Eine Netzwerkadapterkarte oder Netzwerkschnittstelle in jeder Rechen-/Verarbeitungsvorrichtung empfängt computerlesbare Programmanweisungen von dem Netzwerk und leitet die computerlesbaren Programmanweisungen zur Speicherung auf einem computerlesbaren nicht transitorischen Speichermedium in der entsprechenden Rechen-/Verarbeitungsvorrichtung weiter.
  • Das hierin in der vorliegenden Beschreibung und den angehängten Zeichnungen Beschriebene beinhaltet Beispiele für Systeme, Vorrichtungen, Techniken und Computerprogrammprodukte, die einzeln und in Kombination die automatisierte Konfiguration einer Produkt- oder Dienstbereitstellung ermöglichen. Selbstverständlich ist es nicht möglich, jede denkbare Kombination aus Komponenten und/oder Verfahren zum Zwecke der Beschreibung der verschiedenen Elemente der Offenbarung zu beschreiben; es versteht sich jedoch, dass viele weitere Kombinationen und Abwandlungen der offenbarten Elemente möglich sind. Dementsprechend wird ersichtlich, dass verschiedene Modifikationen an der Offenbarung vorgenommen werden können, ohne von dem Umfang oder Geist davon abzuweichen. Des Weiteren oder als eine Alternative können andere Ausführungsformen unter Berücksichtigung der Beschreibung und angehängten Zeichnungen und der Umsetzung der Offenbarung wie hierin dargestellt ersichtlich werden. Es wird beabsichtigt, dass die in der Beschreibung und den angehängten Zeichnungen dargelegten Beispiele in jeglicher Hinsicht als veranschaulichend und nicht als einschränkend betrachtet werden. Wenngleich konkrete Begriffe in dieser Schrift herangezogen werden, werden diese lediglich in ihrem allgemeinen und beschreibenden Sinne und nicht zum Zwecke der Einschränkung verwendet.
  • Gemäß einer Ausführungsform der vorliegenden Erfindung umfasst die Zieltransaktion die Durchführung eines Dienstessaufgabe, wobei die Vorgänge ferner Empfangen von Rückmeldedaten von dem Rechensystem umfassen, wobei die Rückmeldedaten mindestens ein Attribut der Dienstaufgabe definieren.
  • Gemäß der vorliegenden Erfindung ist eine Vorrichtung bereitgestellt, die mindestens eine Verarbeitungsvorrichtung aufweist, die Anweisungen ausführt, um die Vorrichtung dazu veranlassen, Vorgänge durchzuführen oder zu erleichtern, die Folgendes umfassen: Empfangen von Anfragedaten von einem Rechensystem, das relativ zu dem Fahrzeug entfernt angeordnet ist, wobei ein erster Teil der Anfragedaten eine Auftragsanfrage auf Grundlage eines Hashtags, der in einer Social-Media-Plattform gepostet ist, definiert, wobei der erste Teil der Anfragedaten Auftragsdaten, die eine Zieltransaktion identifizieren, die der Auftragsanfrage entsprechen, und Benutzerdaten, die einen Auftragsanfrager identifizieren, beinhaltet; Erzeugen eines Hashwerts unter Verwendung der Anfragedaten, um die Auftragsanfrage zu validieren; Bestimmen, dass die Auftragsanfrage validiert ist, unter Verwendung von mindestens dem Hashwert; Aktualisieren eines ersten Verzeichniseintrags mindestens basierend auf dem Hashwert, den Auftragsdaten und den Benutzerdaten; Veranlassen, dass ein zweites Fahrzeug einen zweiten Verzeichniseintrag mindestens auf Grundlage des Hashwerts, der Auftragsdaten und der Benutzerdaten aktualisiert; wobei der aktualisierte zweite Verzeichniseintrag dem aktualisierten ersten Verzeichniseintrag enspricht; und Senden von Antwortdaten an das zweite Rechensystem, wobei die Antwortdaten eine Antwort auf die Auftragsanfrage darstellen und den Hashwert, die Auftragsdaten und die Benutzerdaten beinhalten.
  • Gemäß einer Ausführungsform umfasst das Veranlassen Senden einer Benachrichtigung an das zweite Fahrzeug, die angibt, dass die Auftragsanfrage validiert wird, wobei die Benachrichtigung den Hashwert und eines oder mehrere von den Auftragsdaten oder den Benutzerdaten beinhaltet; und Anweisen des zweiten Fahrzeugs, den Hashwert und das eine oder die mehreren von den Auftragsdaten oder den Benutzerdaten dem zweiten Verzeichniseintrag hinzuzufügen.
  • Gemäß einer Ausführungsform der vorliegenden Erfindung umfasst die Zieltransaktion die Lieferung eines Produkts, wobei die Vorgänge ferner das Empfangen von Rückmeldedaten von dem Rechensystem umfassen, wobei die Rückmeldedaten mindestens ein Attribut des Produkts definieren.
  • Gemäß einer Ausführungsform umfasst die Zieltransaktion die Durchführung eines Dienstessaufgabe, wobei die Vorgänge ferner Empfangen von Rückmeldedaten von dem Rechensystem umfassen, wobei die Rückmeldedaten mindestens ein Attribut der Dienstaufgabe definieren.

Claims (15)

  1. Verfahren, umfassend: Empfangen von Anfragedaten von einem Rechensystem, das relativ zu dem Fahrzeug entfernt angeordnet ist, durch eine in ein Fahrzeug integrierte Verarbeitungsvorrichtung, wobei ein erster Teil der Anfragedaten eine Auftragsanfrage auf Grundlage eines Hashtags definiert, der in einer Social-Media-Plattform gepostet ist, wobei der erste Teil der Anfragedaten Auftragsdaten, die eine Zieltransaktion identifizieren, die der Auftragsanfrage entspricht, und Benutzerdaten, die einen Auftragsanfrager identifizieren, beinhaltet; Erzeugen eines Hashwerts unter Verwendung der Anfragedaten, um die Auftragsanfrage zu validieren; Bestimmen, dass die Auftragsanfrage validiert ist, unter Verwendung von mindestens dem Hashwert; Aktualisieren eines ersten Verzeichniseintrags mindestens auf Grundlage des Hashwerts, der Auftragsdaten und der Benutzerdaten; Veranlassen mehrerer zweiter Fahrzeuge, jeweilige zweite Verzeichniseinträge mindestens auf Grundlage des Hashwerts, der Auftragsdaten und der Benutzerdaten zu aktualisieren; wobei jeder der aktualisierten entsprechenden zweiten Verzeichniseinträge dem aktualisierten ersten Verzeichniseintrag entspricht; und Senden von Antwortdaten an das Rechensystem, wobei die Antwortdaten eine Antwort auf die Auftragsanfrage darstellen und den Hashwert, die Auftragsdaten und die Benutzerdaten beinhalten.
  2. Verfahren nach Anspruch 1, wobei das Aktualisieren des ersten Verzeichniseintrags Folgendes umfasst: Verschlüsseln mindestens eines von den Auftragsdaten oder den Benutzerdaten; Erzeugen eines Datenblocks, der den Hashwert und eines oder mehrere der verschlüsselten Auftragsdaten oder der verschlüsselten Benutzerdaten beinhaltet; und Hinzufügen des Datenblocks zu dem ersten Verzeichniseintrag.
  3. Verfahren nach Anspruch 1, wobei das Veranlassen Folgendes umfasst: Senden, an ein erstes der mehreren zweiten Fahrzeuge, einer Benachrichtigung, die angibt, dass die Auftragsanfrage validiert wird, wobei die Benachrichtigung den Hashwert und eines oder mehrere der Auftragsdaten oder der Benutzerdaten beinhaltet; und Anweisen des ersten der mehreren zweiten Fahrzeuge, den Hashwert und das eine oder die mehreren der Auftragsdaten oder der Benutzerdaten dem zweiten Verzeichniseintrag hinzuzufügen.
  4. Verfahren nach Anspruch 1, wobei die Auftragsanfrage einen definierten Typ aufweist, der einer Kategorie des Hashtags entspricht.
  5. Verfahren nach Anspruch 1, wobei das Bearbeiten Bearbeiten der ersten Daten in einem definierten Zeitraum während des Betriebs des Fahrzeugs umfasst.
  6. Verfahren nach Anspruch 1, wobei das Bearbeiten Bearbeiten der ersten Daten während mindestens einem von Betrieb des Fahrzeugs innerhalb einer definierten Region oder Betrieb des Fahrzeugs an einem definierten Standort umfasst.
  7. Verfahren nach Anspruch 1, wobei die Zieltransaktion die Lieferung eines Produkts umfasst, wobei das Verfahren ferner Empfangen von Rückmeldedaten von dem Rechensystem durch die Verarbeitungsvorrichtung umfasst, wobei die Rückmeldedaten mindestens ein Attribut des Produkts definieren.
  8. Verfahren nach Anspruch 1, wobei die Zieltransaktion Durchführen eines Dienstessaufgabe umfasst, wobei das Verfahren ferner Empfangen von Rückmeldedaten von dem Rechensystem durch die Verarbeitungsvorrichtung umfasst, wobei die Rückmeldedaten mindestens ein Attribut der Dienstaufgabe definieren.
  9. Fahrzeug, Folgendes umfassend: eine Vorrichtung, umfassend: mindestens einen Prozessor; und mindestens eine Speichervorrichtung, die funktionell an den mindestens einen Prozessor gekoppelt ist, wobei die mindestens eine Speichervorrichtung darin codierte Anweisungen aufweist, welche die Vorrichtung als Reaktion auf eine Ausführung durch den mindestens einen Prozessor dazu veranlassen, Vorgänge durchzuführen oder zu erleichtern, die Folgendes umfassen: Empfangen von Anfragedaten von einem Rechensystem, das relativ zu dem Fahrzeug entfernt angeordnet ist, wobei ein erster Teil der Anfragedaten eine Auftragsanfrage auf Grundlage eines Hashtags definiert, der in einer Social-Media-Plattform gepostet ist, wobei der erste Teil der Anfragedaten Auftragsdaten, die eine Zieltransaktion identifizieren, die der Auftragsanfrage entspricht, und Benutzerdaten, die einen Auftragsanfrager identifizieren, beinhaltet; Erzeugen eines Hashwerts unter Verwendung der Anfragedaten, um die Auftragsanfrage zu validieren; Bestimmen, dass die Auftragsanfrage validiert ist, unter Verwendung von mindestens dem Hashwert; Aktualisieren eines ersten Verzeichniseintrags mindestens auf Grundlage des Hashwerts, der Auftragsdaten und der Benutzerdaten; Veranlassen eines zweiten Fahrzeugs, einen zweiten Verzeichniseintrag mindestens auf Grundlage des Hashwerts, der Auftragsdaten und der Benutzerdaten zu aktualisieren; wobei der aktualisierte zweite Verzeichniseintrag dem aktualisierten ersten Verzeichniseintrag entspricht; und Senden von Antwortdaten an das Rechensystem, wobei die Antwortdaten eine Antwort auf die Auftragsanfrage darstellen und den Hashwert, die Auftragsdaten und die Benutzerdaten beinhalten.
  10. Fahrzeug nach Anspruch 9, wobei das Aktualisieren des ersten Verzeichniseintrags Folgendes umfasst: Verschlüsseln mindestens eines von den Auftragsdaten oder den Benutzerdaten; Erzeugen eines Datenblocks, der den Hashwert und eine oder mehrere von den verschlüsselten Auftragsdaten oder den verschlüsselten Benutzerdaten beinhaltet; und Hinzufügen des Datenblocks zu dem ersten Verzeichniseintrag.
  11. Fahrzeug nach Anspruch 10, wobei das Veranlassen Folgendes umfasst: Senden, an das zweite Fahrzeug, einer Benachrichtigung, die angibt, dass die Auftragsanfrage validiert wird, wobei die Benachrichtigung den Hashwert und eines oder mehrere der Auftragsdaten oder der Benutzerdaten beinhaltet; und Anweisen des zweiten Fahrzeuge, den Hashwert und das eine oder die mehreren der Auftragsdaten oder der Benutzerdaten dem zweiten Verzeichniseintrag hinzuzufügen.
  12. Fahrzeug nach Anspruch 9, wobei die Auftragsanfrage einen definierten Typ aufweist, der einer Kategorie des Hashtags entspricht.
  13. Fahrzeug nach Anspruch 9, wobei das Erzeugen Bearbeiten der Anfragedaten in einem definierten Zeitraum während des Betriebs des Fahrzeugs umfasst.
  14. Fahrzeug nach Anspruch 9, wobei das Erzeugen Bearbeiten der Anfragedaten während mindestens einem von Betrieb des Fahrzeugs innerhalb einer definierten Region oder Betrieb des Fahrzeugs an einem definierten Standort umfasst.
  15. Fahrzeug nach Anspruch 9, wobei die Zieltransaktion die Lieferung eines Produkts umfasst, wobei die Vorgänge ferner das Empfangen von Rückmeldedaten von dem zweiten Rechensystem umfassen, wobei die Rückmeldedaten mindestens ein Attribut des Produkts definieren.
DE102020123880.0A 2019-09-13 2020-09-14 Automatisierte konfiguration von produkt- und dienstbereitstellung Pending DE102020123880A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/571,005 2019-09-13
US16/571,005 US11636410B2 (en) 2019-09-13 2019-09-13 Automated configuration of provision of products and services

Publications (1)

Publication Number Publication Date
DE102020123880A1 true DE102020123880A1 (de) 2021-03-18

Family

ID=74686341

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102020123880.0A Pending DE102020123880A1 (de) 2019-09-13 2020-09-14 Automatisierte konfiguration von produkt- und dienstbereitstellung

Country Status (3)

Country Link
US (1) US11636410B2 (de)
CN (1) CN112512019A (de)
DE (1) DE102020123880A1 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11514093B2 (en) * 2020-02-04 2022-11-29 INSPIRD, Inc. Method and system for technical language processing
WO2023129749A2 (en) * 2021-12-30 2023-07-06 True John Gerard Systems, methods, and devices for generation of peer validated geospatial data and proof of reception of tracking data
CN116627081B (zh) * 2023-07-21 2023-11-14 小米汽车科技有限公司 车辆功能配置方法、装置、车辆、介质及芯片

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10110541B2 (en) 2013-10-17 2018-10-23 International Business Machines Corporation Optimization of posting in social networks using content delivery preferences comprising hashtags that correspond to geography and a content type associated with a desired time window
US20150227890A1 (en) 2014-02-07 2015-08-13 Kristin Kaye Bednarek Communications system and smart device apps supporting segmented order distributed distribution system
US10304147B2 (en) 2016-10-31 2019-05-28 Kevin Kelly Drive-thru / point-of-sale automated transaction technologies and apparatus
US10659477B2 (en) * 2017-12-19 2020-05-19 The Boeing Company Method and system for vehicle cyber-attack event detection
US11222061B2 (en) * 2019-03-28 2022-01-11 Facebook, Inc. Generating digital media clusters corresponding to predicted distribution classes from a repository of digital media based on network distribution history
US11488094B2 (en) * 2019-08-08 2022-11-01 Toyota Motor North America, Inc. Tracking of transport transfers

Also Published As

Publication number Publication date
CN112512019A (zh) 2021-03-16
US11636410B2 (en) 2023-04-25
US20210081849A1 (en) 2021-03-18

Similar Documents

Publication Publication Date Title
DE102020123880A1 (de) Automatisierte konfiguration von produkt- und dienstbereitstellung
DE102020106368A1 (de) Teilen von fahrzeugdaten mit interessierten parteien
DE102020122616A1 (de) Automatisierte bereitstellung eines fahrzeugprofilpakets
DE202017102431U1 (de) Crowdsourcing-Fahrzeugeinstellungsempfehlungen
DE102015110934A1 (de) Mehrziel-Fahrzeugschnittstelle
DE202017102495U1 (de) Teilen von Fahrzeugeinstellungsdaten
DE102021123067A1 (de) Sicherer Transportmittel-Datenaustausch
DE202016009103U1 (de) Cloud-integrierte Fahrzeugplattform
CH716091B1 (de) Verfahren zum Nachverfolgen von Objekten unter Benutzung von verteilten Computernetzen.
DE112016002395T5 (de) Zugriffskontrolle für Datenressourcen
DE112021002797T5 (de) Datenschutzerhaltende architektur für genehmigungspflichtige blockchains
DE102015107618A1 (de) Fahrzeug-generierte Aktualisierungen für soziale Netzwerke
DE202015002394U1 (de) Einstellen von Attributen für ein System für On-Demand-Dienste basierend auf Echtzeitinformation
Wedeniwski Mobilitätsrevolution in der Automobilindustrie
DE102021122298A1 (de) Systeme und verfahren zum fahrzeugplatooning
Seuwou et al. Actor-network theory as a framework to analyse technology acceptance model’s external variables: the case of autonomous vehicles
DE112021003364T5 (de) Bedarfsbasierte Energieverteilung
Kieviet Lean digital transformation
DE102019120601A1 (de) Über cloud abgefertigte validierung und ausführung betreffs diagnoseanfragen
EP3654222A1 (de) Fahrzeug, netzwerkkomponente, verfahren, computerprogramm und vorrichtung zum generieren einer kennung für einen ausrüstungszustand eines fahrzeugs
DE102017208219A1 (de) Erstellung elektronischer Musterdokumente unter Nutzung des semantischen Kontexts
DE112013001175T5 (de) Erzeugen von elektronischen Stammbäumen
Kolasińska-Morawska et al. New technologies in transport in the face of challenges of economy 4.0
DE102023101345A1 (de) Systeme und verfahren zum bereitstellen eines lieferunterstützungsdienstes mit einem digitalen augmented-reality-begleiter
DE102021109015A1 (de) Ladungsübertragungsmanagement für ein beförderungsmittel

Legal Events

Date Code Title Description
R082 Change of representative

Representative=s name: LORENZ SEIDLER GOSSEL RECHTSANWAELTE PATENTANW, DE

R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: G06Q0050300000

Ipc: G06Q0050400000