DE112016004861T5 - System und Verfahren zum Geofencing - Google Patents

System und Verfahren zum Geofencing Download PDF

Info

Publication number
DE112016004861T5
DE112016004861T5 DE112016004861.0T DE112016004861T DE112016004861T5 DE 112016004861 T5 DE112016004861 T5 DE 112016004861T5 DE 112016004861 T DE112016004861 T DE 112016004861T DE 112016004861 T5 DE112016004861 T5 DE 112016004861T5
Authority
DE
Germany
Prior art keywords
location
management server
client
geofence
aware client
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
DE112016004861.0T
Other languages
English (en)
Inventor
Krishnakant M. Patel
Debabrata Dash
Ravi Ayyasamy
Pratap Chandana
Bharat Ram Setti
Sayyad Gaffar
Rohit Nerlikar
Ramu Kandula
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.)
Kodiak Networks Inc
Original Assignee
Kodiak Networks Inc
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 Kodiak Networks Inc filed Critical Kodiak Networks Inc
Publication of DE112016004861T5 publication Critical patent/DE112016004861T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/021—Services related to particular areas, e.g. point of interest [POI] services, venue services or geofences
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/29—Geographical information databases
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/021—Services related to particular areas, e.g. point of interest [POI] services, venue services or geofences
    • H04W4/022—Services related to particular areas, e.g. point of interest [POI] services, venue services or geofences with dynamic range variability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/023—Services making use of location information using mutual or relative location information between multiple location based services [LBS] targets or of distance thresholds
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/025—Services making use of location information using location based information parameters
    • H04W4/027—Services making use of location information using location based information parameters using movement velocity, acceleration information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W64/00—Locating users or terminals or network equipment for network management purposes, e.g. mobility management
    • H04W64/006—Locating users or terminals or network equipment for network management purposes, e.g. mobility management with additional information processing, e.g. for direction or speed determination

Abstract

Ein System und ein Verfahren zum Geofencing enthält ein Senden, durch den Ortsmanagementserver, von Ortsdatensammelkriterien und Ortsdatenberichtskriterien an einen ersten ortskennenden Client; und ein Empfangen, durch den Ortsmanagementserver, von Ortsdaten von dem ersten ortskennenden Client, wobei die Ortsdaten durch den ersten ortskennenden Client gemäß den Ortsdatensammelkriterien gesammelt werden und wobei die Ortsdaten von dem ersten ortskennenden Client gemäß den Ortsdatenberichtskriterien empfangen werden.

Description

  • Bezug zu verwandten Anmeldungen
  • Diese Anmeldung beansprucht Unterstützung der U.S. Provisional Application Nr. 62/245,876 (vorläufige Anmeldung), eingereicht am 23. Oktober 2015, wobei diese Anmeldung hiermit durch Bezugnahme in vorliegendes aufgenommen wird.
  • Technisches Gebiet
  • Die vorliegende Erfindung bezieht sich allgemein auf Kommunikationen über ein Netzwerk und, in speziellen Ausführungsformen, auf ein System und ein Verfahren zum Geofencing.
  • Hintergrund
  • Geofencing ermöglicht es Software- oder Hardwareanwendungen, GPS („global positioning system“) oder RFID („radio frequency identification“, Funkfrequenzidentifikation) zu verwenden, um geografische Grenzen für zum Beispiel ein Netzwerk, einen oder mehrere Netzwerkdienste oder dergleichen zu definieren. Geofencing kann im Bereich der öffentlichen Sicherheit angewendet werden. Geofencing-Funktionen können durch einen oder mehrere Server ausgeführt werden, und Kommunikationen zwischen den Client-Geräten und den Servern können über ein Netzwerk ausgeführt werden (zum Beispiel ein Trägernetzwerk, Wi-Fi usw.). Da jedoch das Interesse an Geofencing zugenommen hat, werden im Hinblick auf Nachrichtenprotokolle, welche zum Austausch von Ortsdaten genutzt werden, neue Herausforderungen entdeckt.
  • Überblick
  • Gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung enthält ein Verfahren, durch einen Ortsmanagementserver: Senden, durch den Ortsmanagementserver, von Ortsdatensammelkriterien und Ortsdatenberichtskriterien an einen ersten ortskennenden Client; und Empfangen, durch den Ortsmanagementserver, von Ortsdaten von dem ersten ortskennenden Client, wobei die Ortsdaten durch den ersten ortskennenden Client gemäß den Ortsdatensammelkriterien gesammelt werden, wobei die Ortsdaten von dem ersten ortskennenden Client gemäß den Ortsdatenberichtskriterien empfangen werden.
  • In einigen Ausführungsformen sind die Ortsdatensammelkriterien und die Ortsdatenberichtskriterien dieselben. In einigen Ausführungsformen enthält das Senden der Ortsdatensammelkriterien und der Ortsdatenberichtskriterien: Speichern, durch den Ortsmanagementserver, der Ortsdatensammelkriterien und der Ortsdatenberichtskriterien in einem Datenbank-Cluster (DB-Cluster), das für den Ortsmanagementserver erreichbar ist, wobei die Ortsdatensammelkriterien und die Ortsdatenberichtskriterien jeweils in einem erkennbaren Datenfeld des DB-Clusters gespeichert sind. In einigen Ausführungsformen enthält das Empfangen der Ortsdaten von dem ersten ortskennenden Client: Erkennen, durch den Ortsmanagementserver, einer Synchronisation der Ortsdaten von einer ersten lokalen Datenbank an dem ersten ortskennenden Client in ein Datenbank-Cluster (DB-Cluster), das von dem Ortsmanagementserver erreichbar ist. In einigen Ausführungsformen spezifizieren die Ortsdatensammelkriterien eine Ortsdatensammlung als eine Funktion von wenigstens einem von folgendem: abgelaufene Zeit, durch den ersten ortskennenden Client zurückgelegte Strecke, Geschwindigkeit des ersten ortskennenden Client, Beschleunigung des ersten ortskennenden Client, Höhe des ersten ortskennenden Client, Zugriffsnetzwerkereignisse des ersten ortskennenden Client, Umgebungssensorereignisse des ersten ortskennenden Client und Gesundheitssensorereignisse des ersten ortskennenden Client. In einigen Ausführungsformen spezifizieren die Ortsdatenberichtskriterien einen Ortsdatenbericht als eine Funktion von wenigstens einem von folgendem: abgelaufene Zeit, durch den ersten ortskennenden Client zurückgelegte Strecke, Geschwindigkeit des ersten ortskennenden Client, Beschleunigung des ersten ortskennenden Client, Höhe des ersten ortskennenden Client, Zugriffsnetzwerkereignisse des ersten ortskennenden Client, Umgebungssensorereignisse des ersten ortskennenden Client und Gesundheitssensorereignisse des ersten ortskennenden Client. In einigen Ausführungsformen enthalten die Ortsdaten eine geografische Breite und Länge des ersten ortskennenden Client. In einigen Ausführungsformen enthalten die Ortsdaten weiterhin einen Zeitstempel der Ortsdaten, eine Anzeige von Ereignissen, die verursachen, dass die Ortsdaten durch den ersten ortskennenden Client gesammelt werden, Netzwerkinformation für den ersten ortskennenden Client oder eine Kombination davon. In einigen Ausführungsformen enthält das Verfahren weiterhin: Auswerten, durch den Ortsmanagementserver, der Ortsdaten, die von dem ersten ortskennenden Client empfangen werden, um einen aktuellen Ortszustand des ersten ortskennenden Client mit Bezug auf einen Geofence zu bestimmen, wobei der aktuelle Ortszustand anzeigt, ob der erste ortskennende Client in den Geofence eingetreten ist, den Geofence verlassen hat, sich innerhalb des Geofence befindet oder sich außerhalb des Geofence befindet; und Ausführen, durch den Ortsmanagementserver, einer oder mehrerer Handlungen gemäß dem aktuellen Ortszustand des ersten ortskennenden Client. In einigen Ausführungsformen enthalten die eine oder die mehrere Handlungen, die durch den Ortsmanagementserver ausgeführt werden: Senden, durch den Ortsmanagementserver, zu einem oder mehreren ortskennenden Clients, einschließlich dem ersten ortskennenden Client, einer Benachrichtigung zu jedem von dem einen oder den mehreren ortskennenden Clients, wobei die Benachrichtigung den aktuellen Ortszustand des ersten ortskennenden Client mit Bezug auf den Geofence oder einen aktuellen Ort des ersten ortskennenden Client anzeigt. In einigen Ausführungsformen enthält das Senden der Benachrichtigung: Speichern, durch den Ortsmanagementserver, eines Dokuments, das die Benachrichtigung in einem Datenbank-Cluster (DB-Cluster) anzeigt, das von dem Ortsmanagementserver erreichbar ist, wobei das Dokument in einem erkennbaren Datenfeld des DB-Clusters gespeichert wird, wobei der eine oder die mehreren ortskennenden Clients sich mit dem Ortsmanagementserver synchronisieren, in Reaktion darauf, dass das Dokument in dem erkennbaren Datenfeld gespeichert wird. In einigen Ausführungsformen ist der Geofence eine virtuelle Grenze, die mit Bezug auf einen Ankerpunkt aufgebaut wird, der von dem Ortsmanagementserver verfolgt wird, wobei der Ankerpunkt entweder stationär oder in Bewegung ist. In einigen Ausführungsformen enthält das Verfahren weiterhin: Empfangen, durch den Ortsmanagementserver, einer Anfrage von einem zweiten ortskennenden Client nach den Ortsdaten, die durch den ersten ortskennenden Client gesammelt wurden, wobei die Ortsdatensammelkriterien und die Ortsdatenberichtskriterien zu dem ersten ortskennenden Client in Reaktion auf das Empfangen der Anfrage gesendet werden. In einigen Ausführungsformen enthält das Empfangen der Anfrage von dem zweiten ortskennenden Client nach den Ortsdaten: Erkennen, durch den Ortsmanagementserver, einer Synchronisation der Anfrage von einer zweiten lokalen Datenbank an dem zweiten ortskennenden Client in ein Datenbank-Cluster (DB-Cluster), das von dem Ortsmanagementserver erreichbar ist. In einigen Ausführungsformen zeigt die Anfrage von dem zweiten ortskennenden Client die Ortsdatensammelkriterien und/oder die Ortsdatenberichtskriterien an. In einigen Ausführungsformen zeigt die Anfrage von dem zweiten ortskennenden Client eine Definition eines Geofence an, und sie zeigt weiterhin Anweisungen zum Filtern der Ortsdaten von dem ersten ortskennenden Client gemäß einem aktuellen Ortszustand des ersten ortskennenden Client mit Bezug auf den Geofence an, wobei der aktuelle Ortszustand anzeigt, ob der erste ortskennende Client in den Geofence eingetreten ist, den Geofence verlassen hat, sich innerhalb des Geofence befindet oder sich außerhalb des Geofence befindet. In einigen Ausführungsformen enthält das Verfahren weiterhin: Bestimmen, durch den Ortsmanagementserver, des aktuellen Ortszustands des ersten ortskennenden Client mit Bezug auf den Geofence; und Ausführen der Anweisungen, die durch die Anfrage von dem zweiten ortskennenden Client angezeigt werden. In einigen Ausführungsformen enthält das Verfahren weiterhin: Senden, durch den Ortsmanagementserver, der Definition des Geofence und der Anweisungen an den ersten ortskennenden Client.
  • Gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung enthält ein Verfahren, durch einen ersten ortskennenden Client: Empfangen, durch den ersten ortskennenden Client, von Ortsdatensammelkriterien und Ortsdatenberichtskriterien von einem Ortsmanagementserver; Sammeln, durch den ersten ortskennenden Client, von Ortsdaten gemäß Ortsdatensammelkriterien; Speichern, durch den ersten ortskennenden Client, der Ortsdaten in einer ersten lokalen Datenbank an dem ersten ortskennenden Client; und Berichten, durch den ersten ortskennenden Client, wenigstens eines Teils der Ortsdaten an den Ortsmanagementserver gemäß den Ortsdatenberichtskriterien.
  • In einigen Ausführungsformen enthält das Verfahren weiterhin: Empfangen, durch den ersten ortskennenden Client, einer Definition eines Geofence, wobei der Geofence eine virtuelle Grenze ist, die mit Bezug auf einen Ankerpunkt aufgebaut wird; und Bestimmen, durch den ersten ortskennenden Client, eines aktuellen Ortszustands des ersten ortskennenden Client mit Bezug auf den Geofence, indem die Ortsdaten ausgewertet werden, die durch den ersten ortskennenden Client gesammelt werden, wobei der aktuelle Ortszustand anzeigt, ob der erste ortskennende Client in den Geofence eingetreten ist, den Geofence verlassen hat, sich innerhalb des Geofence befindet oder sich außerhalb des Geofence befindet. In einigen Ausführungsformen enthält das Verfahren weiterhin: Empfangen, durch den ersten ortskennenden Client, eines Satzes von Anweisungen von dem Ortsmanagementserver, wobei jede aus dem Satz von Anweisungen mit einem vorbestimmten Ortszustand assoziiert ist; und Ausführen, durch den ersten ortskennenden Client, einer Anweisung aus dem Satz von Anweisungen in Reaktion auf den vorbestimmten Ortszustand der Anweisung entsprechend dem aktuellen Ortszustand des ersten ortskennenden Client nach dem Sammeln der Ortsdaten. In einigen Ausführungsformen enthält der Satz von Anweisungen eine Anordnung, den aktuellen Ortszustand des ersten ortskennenden Client an den Ortsmanagementserver zu berichten. In einigen Ausführungsformen enthält der Satz von Anweisungen eine Anordnung, wenigstens einen Teil der Ortsdaten gemäß den Ortsdatenberichtskriterien zu berichten. In einigen Ausführungsformen enthält der Satz von Anweisungen eine Anordnung, eine oder mehrere Handlungen auszuführen, wobei die eine oder die mehreren Handlungen ein Senden einer Nachricht zu dem Ortsmanagementserver oder ein Aufrufen eines Dienstes an dem ersten ortskennenden Client enthalten. In einigen Ausführungsformen, enthält das Empfangen des Satzes von Anweisungen von dem Ortsmanagementserver: Erkennen, durch den ersten ortskennenden Client, einer Synchronisation des Satzes von Anweisungen von einem DB-Cluster, das von dem Ortsmanagementserver erreichbar ist, in die erste lokale Datenbank. In einigen Ausführungsformen enthält das Empfangen des Satzes von Anweisungen von dem Ortsmanagementserver: Empfangen, durch den ersten ortskennenden Client, einer Multicast-Übertragung, die den Satz von Anweisungen enthält. In einigen Ausführungsformen ist die Multicast-Übertragung eine eMBMS-Übertragung („Evolved Multimedia Broadcast Multicast Services“). In einigen Ausführungsformen enthält das Empfangen der Definition des Geofence: Erkennen, durch den ersten ortskennenden Client, einer Synchronisation der Definition des Geofence von einem DB-Cluster, das von dem Ortsmanagementserver erreichbar ist, in die erste lokale Datenbank. In einigen Ausführungsformen enthält das Empfangen der Ortsdatensammelkriterien und der Ortsdatenberichtskriterien von dem Ortsmanagementserver: Erkennen, durch den ersten ortskennenden Client, einer Synchronisation der Ortsdatensammelkriterien und der Ortsdatenberichtskriterien von einem DB-Cluster, das von dem Ortsmanagementserver erreichbar ist, in die erste lokale Datenbank. In einigen Ausführungsformen enthält das Empfangen der Ortsdatensammelkriterien und der Ortsdatenberichtskriterien von dem Ortsmanagementserver: Empfangen, durch den ersten ortskennenden Client, einer Multicast-Übertragung einschließlich der Ortsdatensammelkriterien und der Ortsdatenberichtskriterien. In einigen Ausführungsformen ist die Multicast-Übertragung eine eMBMS-Übertragung („Evolved Multimedia Broadcast Multicast Services“). In einigen Ausführungsformen enthält das Verfahren weiterhin: Empfangen, durch den ersten ortskennenden Client, einer Aktualisierung für die Definition des Geofence. In einigen Ausführungsformen enthält die Aktualisierung für die Definition des Geofence eine Änderung von Ortskoordinaten des Ankerpunktes, der Form des Geofence, der Größe des Geofence oder einer Kombination davon. In einigen Ausführungsformen ist der Ankerpunkt des Geofence statisch. In einigen Ausführungsformen befindet sich der Ankerpunkt des Geofence in Bewegung. In einigen Ausführungsformen ist der Geofence von zweidimensionaler Form. In einigen Ausführungsformen ist der Geofence von dreidimensionaler Form.
  • Gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung enthält ein Ortsmanagementserver: einen Prozessor; und ein computerlesbares Speichermedium, das eine Programmierung zur Ausführung durch den Prozessor speichert, wobei die Programmierung Anweisungen enthält zum: Senden von Ortsdatensammelkriterien und Ortsdatenberichtskriterien an einen ersten ortskennenden Client; und Empfangen von Ortsdaten von dem ersten ortskennenden Client, wobei die Ortsdaten durch den ersten ortskennenden Client gemäß den Ortsdatensammelkriterien gesammelt werden, wobei die Ortsdaten von dem ersten ortskennenden Client gemäß den Ortsdatenberichtskriterien empfangen werden.
  • In einigen Ausführungsformen enthält die Programmierung Anweisungen zum: Auswerten der Ortsdaten zum Bestimmen eines aktuellen Ortszustands des ersten ortskennenden Client mit Bezug auf einen Geofence; und Ausführen einer Handlung gemäß dem aktuellen Ortszustand des ersten ortskennenden Client. In einigen Ausführungsformen enthält die Programmierung weiterhin Anweisungen zum: Anzeigen einer Definition eines Geofence und von Anweisungen an den ersten ortskennenden Client, wobei die Anweisungen von dem ersten ortskennenden Client in Reaktion auf eine Bestimmung eines aktuellen Ortszustands des ersten ortskennenden Client mit Bezug auf den Geofence ausgeführt werden. In einigen Ausführungsformen enthält die Anweisung zum Senden der Ortsdatensammelkriterien und der Ortsdatenberichtskriterien Anweisungen zum: Senden einer Multicast-Übertragung, die die Ortsdatensammelkriterien und die Ortsdatenberichtskriterien an eine Vielzahl von ortskennenden Clients, einschließlich den ersten ortskennenden Client, anzeigt. In einigen Ausführungsformen enthält die Anweisung zum Senden der Ortsdatensammelkriterien und der Ortsdatenberichtskriterien Anweisungen zum: Speichern, durch den Ortsmanagementserver, eines Dokuments, das Ortsdatensammelkriterien und die Ortsdatenberichtskriterien in einem Datenbank-Cluster (DB-Cluster) anzeigt, das für den Ortsmanagementserver erreichbar ist, wobei das Dokument in einem erkennbaren Datenfeld des DB-Clusters gespeichert ist, wobei sich der erste ortskennende Client mit dem Ortsmanagementserver in Reaktion darauf synchronisiert, dass das Dokument in dem erkennbaren Datenfeld gespeichert wird.
  • Gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung enthält ein erster ortskennender Client: einen Prozessor; und ein computerlesbares Speichermedium, das eine Programmierung zur Ausführung durch den Prozessor speichert, wobei die Programmierung Anweisungen enthält zum: Empfangen von Ortsdatensammelkriterien und Ortsdatenberichtskriterien von einem Ortsmanagementserver; Sammeln von Ortsdaten gemäß Ortsdatensammelkriterien; Speichern der Ortsdaten in einer ersten lokalen Datenbank an dem ersten ortskennenden Client; und Berichten von wenigstens einem Teil der Ortsdaten an den Ortsmanagementserver gemäß den Ortsdatenberichtskriterien.
  • In einigen Ausführungsformen enthält die Programmierung weiterhin Anweisungen zum: Empfangen einer Definition einer Geofence-Definition und von Anweisungen entsprechend einem aktuellen Ortszustand des ersten ortskennenden Client; und Ausführen der Anweisungen in Reaktion auf ein Bestimmen des aktuellen Ortszustands der ersten ortskennenden Client, wobei der aktuelle Ortszustand durch Auswerten der Ortsdaten bestimmt wird.
  • Figurenliste
  • Für ein vollständigeres Verständnis der vorliegenden Erfindung und deren Vorteile, wird nun auf die nachfolgende Beschreibung Bezug genommen, die zusammen mit den begleitenden Zeichnungen zu betrachten ist:
    • 1 ist ein Diagramm eines Kommunikationssystems;
    • 2 ist ein Blockdiagramm von Komponenten in dem Kommunikationssystem;
    • 3A und 3B zeigen Datensynchronisationspläne;
    • 4 ist ein Protokolldiagramm eines ersten Geofenceüberwachungsverfahrens;
    • 5 ist ein Protokolldiagramm eines zweiten Geofenceüberwachungsverfahrens;
    • 6 ist ein Protokolldiagramm eines Kartebetrachtungsverfahrens;
    • 7 ist ein Blockdiagramm eines Multicast-Telekommunikationssystems;
    • 8 ist ein Blockdiagramm eines Verarbeitungssystems; und
    • 9 ist ein Blockdiagramm eines Transceivers.
  • Detaillierte Beschreibung von veranschaulichenden Ausführungsformen
  • Die Erstellung und Nutzung von Ausführungsformen dieser Offenbarung werden nachfolgenden detailliert diskutiert. Es sollte jedoch erkannt werden, dass die hier offenbarten Konzepte in einer breiten Vielfalt spezifischer Zusammenhänge ausgeführt werden können, und dass die spezifischen hier diskutierten Ausführungsformen nur veranschaulichend sind und nicht dazu dienen, den Umfang der Ansprüche zu begrenzen. Weiterhin sollte erkannt werden, dass verschiedene Änderungen, Ersetzungen und Umbildungen hier durchgeführt werden können, ohne dass der Sinn und der Umfang dieser Offenbarung, wie durch die beigefügten Ansprüche definiert, verlassen würde.
  • Ein Geofence ist ein virtueller geografischer Umriss mit Koordinaten, die relativ zu einem Ankerpunkt fixiert sind. Der Ankerpunkt kann sich innerhalb, außerhalb oder auf einem Rand oder einem Eckpunkt des Umrisses befinden. Der Umriss kann zweidimensional oder dreidimensional sein. Der Geofence kann statisch sein (zum Beispiel unbeweglich), oder er kann dynamisch sein (zum Beispiel kann sich der Ankerpunkt in Bewegung befinden, oder die Form und/oder die Größe des Umrisses können sich mit der Zeit verändern). Einige ortsbasierte Dienstanwendungen können den Weg aufzeichnen, der von einem oder mehreren Zielen genommen wird, und den Weg auf einer Kartenansicht verfolgen. Solch ein Weg kann hier als eine „Brotkrumenansicht“ („breadcrump view“) bezeichnet werden. Die Brotkrumenansicht kann in Echtzeit dargestellt werden, so wie ein Ereignis auftritt, oder sie kann zum Zwecke einer späteren Betrachtung und/oder Analyse gespeichert werden. Einige Geofence-Anwendungen können eine Lokalisierung von Subjekten oder Personen innerhalb eines gewissen Abstands oder Bereiches von einem Ereignis enthalten, wie einem aktuellen Notfall. Zum Beispiel kann ein statischer Geofence in der Nähe eines Verkehrsunfalls aufgebaut werden, oder ein dynamischer Geofence kann durch Notfallhelfer bei der Verfolgung eines fahrenden Fahrzeugs aufgebaut werden.
  • Ein Geofence kann ein vollständig begrenztes Gebiet (zum Beispiel ein Vieleck, Kreis usw.), ein teilweise begrenztes Gebiet (zum Beispiel ein Korridor) oder ein vollständig unbegrenztes Gebiet (zum Beispiel überall) sein. In einem vollständig unbegrenzten Geofence wird ein Client-Gerät überall als innerhalb des Geofence betrachtet. Einige geografische Gebiete können von dem unbegrenzten Gebiet ausgeschlossen sein, so dass das Client-Gerät überall als innerhalb des Geofence betrachtet wird, außer wenn sich das Client-Gerät in einem ausgeschlossenen Gebiet befindet.
  • Ein System und ein Verfahren zum Geofencing werden gemäß verschiedenen Ausführungsformen zur Verfügung gestellt. Insbesondere sammeln ortskennende Clients in einer Gruppe Ortsdaten und berichten diese an einen Ortsmanagementserver gemäß Kriterien, die von dem Ortsmanagementserver spezifiziert werden. Die ortskennenden Clients sammeln und speichern Ortsdaten in einem lokalen Datenspeicher (zum Beispiel einem Datenspeicher an einem Client-Gerät, an dem der ortskennende Client arbeitet), gemäß den Sammelkriterien. Die gesammelten Ortsdaten werden genutzt, um zu bestimmen, ob sich der ortskennende Client innerhalb oder außerhalb eines Geofence befindet. In einigen Ausführungsformen werden die Ortsdaten an den Ortsmanagementserver mittels Datenbanksynchronisation übertragen, und der Ortsmanagementserver erstellt die Bestimmung für jeden der ortskennenden Clients. Die ortskennenden Clients berichten die gesammelten Ortsdaten an den Ortsmanagementserver gemäß den Berichtskriterien. In einigen Ausführungsformen können die Sammel- und Berichtskriterien dieselben sein, wodurch veranlasst wird, dass der Client die Ortsdaten berichtet, sobald diese gesammelt sind. In einigen Ausführungsformen werden den ortskennenden Clients Geofence-Definitionen zur Verfügung gestellt, und jeder ortskennende Client erstellt seine eigene Bestimmung im Hinblick darauf, ob sich ein Client-Gerät in einem Geofence befindet. Eine oder mehrere Handlungen können durch die ortskennenden Clients in Reaktion darauf vorgenommen werden, dass bestimmt wird, dass sich die ortskennenden Clients innerhalb oder außerhalb des Geofence befinden. In einigen Ausführungsformen kann eine Benachrichtigung zu einem oder mehreren Mitgliedern der Gruppe gesendet werden, welche ein Ereignis anzeigt, wie, dass ein ortskennender Client in den Geofence eintritt oder diesen verlässt. In einigen Ausführungsformen können die Kriterien zum Sammeln und/oder Berichten von Ortsdaten eingestellt werden. Die Handlungen, die durch die ortskennenden Clients vorgenommen werden, können mit den Sammel- und Berichtskriterien spezifiziert werden, die von dem Ortsmanagementserver spezifiziert sind.
  • Ausführungsformen können Vorteile erreichen. Ein Speichern von Ortsdaten in einem lokalen Datenspeicher und ein Senden dieser über eine Datensynchronisation kann die Zeitdomänenanordnung der Ortsdaten vereinfachen, womit der Prozess zum Bestimmen des aktuellen oder letzten Orts eines ortskennenden Client vereinfacht wird, insbesondere, wenn ein großer Satz an Ortsdaten analysiert wird. Ein Ausführen der Bestimmung an dem Ortsmanagementserver kann Hardware- und Softwarebeschränkungen an Nutzergeräten vereinfachen, wobei ermöglicht wird, dass Geofence-Management-Implementierungen plattformunabhängig werden, und wobei plattformspezifische Geofence-Beschränkungen vermieden werden. Ein Ausführen der Bestimmung an dem ortskennenden Client kann die Nutzung von Uplink-Funkzugriffsnetzwerk-Ressourcen („radio access networt“ (RAN)) optimieren, während ein höherer Grad an Granularität für einen Ortsdatenbericht aufrechterhalten wird; es kann genauere ortsbasierte Dienste durch die Nutzung von lokalisierter Entscheidungsfindung an den Randgeräten ermöglichen; und es kann eine Nutzung von Broadcast- oder Multicasttransportmechanismen ermöglichen, womit eine weitere Verbesserung der RAN-Ressourcennutzung erreicht wird.
  • 1 ist ein Diagramm eines Kommunikationssystems 100, das eine Architektur zum Unterstützen einer Telekommunikationslösung (zum Beispiel einer PTT-Kommunikationslösung („pusch-to-talk“)) gemäß einigen Ausführungsformen zur Verfügung stellt. Das Kommunikationssystem 100 enthält Client-Geräte 102, ein Kommunikationsnetzwerk 104 und eine Telekommunikationsdienstplattform 106. Wie hier verwendet, bezieht sich der Begriff „Client-Gerät“ auf irgendeine Komponente (oder eine Ansammlung von Komponenten), die in der Lage ist, eine Verbindung mit einem Kommunikationsnetzwerk aufzubauen, wie eine Nutzerausstattung („user equipment“ (UE)), eine Mobilstation (STA), ein zellulares Telefon, ein Tablet, ein Laptop und andere leitungsgebundene/drahtlosfähige Geräte. Anwendungen (die hier nachfolgend als „Clients“ bezeichnet werden) befinden sich auf den Client-Geräten 102, um auf verschiedene Funktionen zuzugreifen, wie Ortsfunktionen, die durch die Telekommunikationslösung zur Verfügung gestellt werden.
  • Die Client-Geräte 102 können mit der Telekommunikationsdienstplattform 106 über das Kommunikationsnetzwerk 104 kommunizieren, auf das von den Client-Geräten 102 über ein zellulares Netzwerk zugegriffen werden kann, was durch einen Träger, ein WiFi-Netzwerk, ein RAN oder andere drahtlose Netzwerke, ein leitungsgebundenes Internetprotokollnetzwerk („internet protocol“ (IP)), Kombinationen davon oder dergleichen eingesetzt werden kann. Das Kommunikationsnetzwerk 104 kann eine oder mehrere Komponenten enthalten, die konfiguriert sind, um drahtlosen oder leitungsgebundenen Netzwerkzugriff zur Verfügung zu stellen, wie einen „enhanced Node B“ (eNB), eine Makrozelle, eine Femtozelle, einen Wi-Fi-Zugangspunkt („Wi-Fi access point“ (AP)), Kombinationen davon oder dergleichen. Weiterhin kann das Kommunikationsnetzwerk 104 gemäß einem oder mehreren Drahtloskommunikationsprotokollen arbeiten, zum Beispiel „Open Mobile Alliance“ (OMA), LTE, LTE-advanced (LTE-A), „High Speed Packet Access“ (HSPA), Wi-Fi 802.11a/b/g/n/ac usw. In einigen Ausführungsformen kann das Kommunikationsnetzwerk 104 verschiedene andere Geräte enthalten, wie Relais, Niedrigleistungsknoten usw. Das Kommunikationsnetzwerk 104 kann weiterhin Backhaul-Netzwerkkomponenten enthalten, wie verschiedene Gateways, Router, Controller, Schedulers und dergleichen.
  • In einer Ausführungsform, bei der die Telekommunikationsdienstplattform 106 eine PoC-Plattform ist, können Teilnehmer einer PTT-Lösung (zum Beispiel Nutzer, die die Client-Geräte 102 bedienen) auf dem Kommunikationssystem 100 über Schnittstellen mit Trägern versorgt werden (zum Beispiel zellulare Träger). PTT-Kunden (zum Beispiel Unternehmen) können diese Teilnehmer verwalten, so dass sie geschlossene Gruppen für PTT-Kommunikationen bilden. Die PTT-Lösung kann eine Schnittstelle mit dem Träger bilden, zum Beispiel durch Einschließen einer Konnektivität zu dem Kernnetzwerk des Trägers, Abrechnungsschnittstellen, Vorhalteschnittstellen, gesetzlicher Abhörschnittstellen, Kundendienstschnittstellen und dergleichen. Die PTT-Plattform kann eine Vielzahl an PTT-Funktionen für die Client-Geräte 102 durch die PTT-Clients auf den Client-Geräten 102 zur Verfügung stellen, wie nachfolgend genauer beschrieben wird.
  • In einigen Ausführungsformen nutzt die Telekommunikationsdienstplattform 106 eine Container-Technologie zum Virtualisieren einer Telekommunikationssystemarchitektur, wie die Virtualisierung von bereitgestellten PTT-Diensten. Beispielhafte Container-Technologien können Docker, Rocket, LXD und dergleichen enthalten, wenngleich die Architektur nicht auf eine spezifische Container-Technologie beschränkt ist. Eine Virtualisierung unter Nutzung einer Container-Technologie kann es der Telekommunikationsdienstplattform 106 ermöglichen, ein Mikrodienstmodell anzunehmen, bei dem Dienstcluster als die Aufbaublöcke der Systemarchitektur angesehen werden. Zum Beispiel kann jede Funktion, die durch die Telekommunikationsdienstplattform 106 zur Verfügung gestellt wird, in einem eindeutigen Dienstcluster virtualisiert werden, und jedes Dienstcluster kann eine andere Funktion in der Telekommunikationsdienstplattform 106 ausführen. Dienstcluster werden auf virtuellen Maschinen einer Ausführungsform eines Cloud-Netzwerks gehostet. Eine Ausführungsform eines Cloud-Netzwerks kann eine Vielzahl geografischer diverser Nutzungsorte enthalten (zum Beispiel Datenzentren), wobei verschiedene virtuelle Maschinen physikalisch eingesetzt werden. Eine Aufteilung des Systems in einen Satz von Diensten gestattet jedem Dienst (zum Beispiel jeder Funktion, die durch die Telekommunikationsdienstplattform zur Verfügung gestellt wird), dass sie unabhängig eingesetzt und gemanagt wird. Somit kann eine Systembelastbarkeit verbessert werden, da Fehler in individuellen Diensten lokalisiert werden. Weiterhin kann ein schneller und agiler Einsatz von Diensten ebenso erreicht werden.
  • In einigen Ausführungsformen enthält die Telekommunikationsdienstplattform 106 verteilte Datenbanken, Cluster-Technologien, Datenanalysewerkzeuge und Benachrichtigungs-Middleware, um eine robuste skalierbare Plattform zur Verfügung zu stellen. Die Telekommunikationsdienstplattform 106 kann vollständig virtualisierte Komponenten mit einem Schichtansatz nutzen, um sich einer Dienstinstrumentierung zu nähern, wobei dies der Telekommunikationsdienstplattform 106 ermöglicht, in verschiedene Cloud-Umgebungen integriert zu werden, wie eine private Cloud-Infrastruktur eines Trägers, einer zugewiesenen PTT-Cloud-Infrastruktur, Kombinationen davon und dergleichen. Eine genauere Beschreibung einer Ausführungsform einer Telekommunikationsdienstplattform kann in der mitzugewiesenen U.S. Patentanmeldung Nr. 14/994,757 gefunden werden, die am 13. Januar 2016 eingereicht wurde und „System and Method for Elastic Scaling using a Container-Based Platform“ betitelt ist, wobei diese hiermit durch Bezugnahme mit aufgenommen wird. Andere Telekommunikationsdienstplattformen, einschließlich anderer PTT-Plattformen, können in anderen Ausführungsformen genutzt werden.
  • Ausführungsformen von Geofence-Techniken stellen einem oder mehreren Supervisorn einer Gruppe die Fähigkeit zur Verfügung, den Ort der Mitglieder in einer Gruppe zu verfolgen. Wie hier verwendet, bezieht sich der Begriff „Supervisor“ auf einen Nutzer der Gruppe mit höheren Privilegien, zum Beispiel auf einen Nutzer mit höheren Privilegien. Die Gruppe kann zum Beispiel eine Anrufgruppe sein, und die Mitglieder der Gruppe können zum Beispiel ortskennende Clients sein, die auf Client-Geräten eingesetzt werden. Der Geofence kann für Mitglieder der Gruppe angewendet werden. Der oder die Supervisor können Mitgliederorte einer Gruppe auf einer Karte verfolgen, den Geofence managen und Berichte über die Gruppe betrachten. In einigen Ausführungsformen kann der Ort von Gruppenmitgliedern auf Anfrage aktualisiert werden, zum Beispiel auf die Anfrage des Supervisors. Einige Ausführungsformen erlauben es dem Supervisor, ein Supervisor in mehreren Gruppen zu sein, wobei er zum Beispiel Orte auf einer Eins-zu-Viele-Basis anfragen und betrachten kann. Nutzer können ein Mitglied von mehreren Gruppen sein, und sie können eine Eins-zu-Viele-Beziehung zum Berichten und Geofencing haben. Ortsdaten können auf Anfrage gesammelt oder angefordert werden, und sie können außerhalb eines Bandes über Benachrichtigungen ausgelöst werden. In einigen Ausführungsformen kann der Anker eines Geofence dem Ort des Supervisors in einer Gruppe folgen. In einigen Ausführungsformen können Gruppen mehrere Supervisor haben, und somit kann eine Gruppe mehr als einen Geofence haben.
  • 2 ist ein Blockdiagramm von Komponenten in dem Kommunikationssystem 100, die ein Ortsmanagementsystem 200 bilden. Die Client-Geräte 102 betreiben einen ortskennenden Client 202, der ein Hardware- oder ein Softwareclient sein kann. Die Telekommunikationsdienstplattform 106 betreibt einen Ortsmanagementserver 204, welcher Software sein kann, und ein Datenbank-Cluster (DB-Cluster) 206. Das Ortsmanagementsystem 200 unterstützt Inhaltsbenachrichtigung zwischen den ortskennenden Clients 202.
  • Der Ortsmanagementserver 204 enthält einen Authentifizierungsdienst 208, Synchronisations-Handler 210, einen Mediationsdienst 212, einen eGLS („enhanced geolocation Service“) 214 und einen Benachrichtigungsdienst 216. Die verschiedenen Dienste und Handler des Ortsmanagementservers 204 stellen eine Plattform basierend auf einer unstrukturierten Datensynchronisation zur Verfügung, die genutzt wird, um Datenführungsinstrumentierungsdienste für eine Ortsmanagementplattform zu verbessern. Die ortskennenden Clients 202 greifen auf einen mobilen Datenspeicher oder eine lokale Datenbank (DB) an den Client-Geräten 102 zu, und Datensynchronisation wird genutzt für eine Dateninstrumentierung zwischen den ortskennenden Clients 202 und dem Ortsmanagementserver 204, wodurch eine Netzwerkabhängigkeit gemanagt wird und eine überflüssige Kodierung während der Entwicklung reduziert wird. Die Daten und der Datenspeicher können unstrukturiert oder planlos sein, wodurch neue Merkmalen entwickelt werden können und in dem Ortsmanagementsystem 200 eingesetzt werden können, ohne aktuelle Frameworks zu beeinflussen, und sie können mit aktuellen Frameworks koexistieren, wodurch die Zeit zur Vermarktung neuer Merkmale und Verbesserungen reduziert wird. Eine Datensynchronisation kann genutzt werden, anstelle von Benachrichtigungsprotokollen, wie XCAP („XML Configuration Access Protocol“) oder XQuery und XDM („XPath Data Model“), wodurch die Beschränkungen solcher Protokolle vermieden werden und die Implementierungen auf sowohl dem ortskennenden Client 202 als auch dem Ortsmanagementserver 204 vereinfacht werden. Da die lokale DB für den ortskennenden Client 202 stets verfügbar ist, kann der ortskennende Client 202 die lokale DB lesen, in diese schreiben und von dieser Daten abfragen, selbst wenn er nicht mit dem Ortsmanagementserver 204 verbunden ist.
  • Der ortskennende Client 202 speichert Inhalt (wie Nachrichten) in der lokalen DB, die mit dem DB-Cluster 206 an dem Ortsmanagementserver 204 synchronisiert wird. Der ortskennende Client 202 nutzt die lokale DB-für einen Basisnachrichteninhaltsspeicher, wobei die Datenbankoperationen, wie Erzeugen, Lesen, Aktualisieren und Löschen („create, read, update and delete“ (CRUD)) an der Client-Schicht genutzt werden. Inhaltssynchronisation wird zu einer locker verbundenen DB-Schicht abgeladen, die die Synchronisation über die Synchronisations-Handler 210 ausführt. Die Datensynchronisation kann ein Kopieren von Records von der lokalen DB zu dem DB-Cluster 206 enthalten; ein Zusammenführen von Daten in der lokalen DB und dem DB-Cluster 206; ein Lösen von Synchronisationskonflikten; und ein Aktualisieren und/oder Löschen von Records in der lokalen DB und/oder dem DB-Cluster 206. Ein Ausführen einer Synchronisation an der DB-Schicht kann die Menge an Netzwerkaufwand reduzieren, der in dem ortskennenden Client 202 implementiert ist. Der Ortsmanagementserver 204 unterstützt Änderungsbenachrichtigungen über Webhooks, was native Verfahren zum Hören oder Erkennen von Änderungen auslösen kann. Dieses Auslösen basiert auf Datenaustauschereignissen und einer Ereignisverarbeitung unter Nutzung von Ereignisroutern, wie dem Mediationsdienst 212 (nachfolgend diskutiert). Eine ereignisbasierte Verarbeitung ermöglicht eine asynchrone Verarbeitung von Inhaltsnachrichten basierend auf Datenverfügbarkeit. Die ortskennenden Clients 202 und/oder der Ortsmanagementserver 204 erkennen die Änderungen in den in dem DB-Cluster 206 gespeicherten Daten, welche durch die Synchronisation verursacht werden. Ein Erkennen kann ausgeführt werden, indem eine Ereignisbenachrichtigung empfangen wird, auf die die ortskennenden Clients 202 und/oder der Ortsmanagementserver 204 antworten.
  • Wenngleich die veranschaulichten Ausführungsformen im Zusammenhang mit dem Liefern von Ortsdaten dargestellt sind, sollte erkannt werden, dass eine große Vielfalt von Diensten unter Verwendung von Ausführungsformen von Inhaltsbenachrichtigungstechniken geliefert werden können.
  • Das DB-Cluster 206 kann ein strukturierter oder ein unstrukturierter Datenspeicher sein. In einer Ausführungsform ist das DB-Cluster 206 eine NoSQL-Datenbank, wenngleich irgendein Datenspeicher genutzt werden könnte. Daten für das Ortsmanagementsystem 200 werden in dem DB-Cluster 206 gespeichert. In einigen Ausführungsformen ist das DB-Cluster 206 ein einziges Cluster (oder mehrere Cluster von DBs), und alle von den lokalen DBs können ihre Kopie von Daten replizieren, wobei diese eine Teilmenge des Datensatzes in dem einzigen Cluster bilden. In einigen Ausführungsformen enthält das DB-Cluster 206 mehrere getrennte Datenbänke (oder getrennte Cluster von Datenbänken), und die verschiedenen lokalen DBs können die gesamten Daten in einer der getrennten Datenbanken replizieren.
  • Der Authentifizierungsdienst 208 stellt Authentifizierungsfunktionen zur Verfügung, und er authentifiziert die ortskennenden Clients 202, wenn sie eine Verbindung mit dem Ortsmanagementserver 204 eingehen. Der Authentifizierungsdienst 208 prüft Nutzerzugangsdaten im Hinblick auf Daten in dem DB-Cluster 206. Wenn die Authentifizierung erfolgreich ist, wird den ortskennenden Clients 202 erlaubt, auf den Ortsmanagementserver 204 zuzugreifen.
  • Die Synchronisations-Handler 210 stellen eine nahtlose und sichere Datensynchronisation zwischen der lokalen DB auf den ortskennenden Clients 202 und dem DB-Cluster 206 zur Verfügung. Die Synchronisations-Handler 210 managen die Lieferung von Inhalt zu/von den ortskennenden Clients 202 und dem DB-Cluster 206 über eine abstrahierte Datenmanagementschicht. Die Synchronisations-Handler 210 können die gesamten Daten in dem DB-Cluster 206 mit den ortskennenden Clients 202 synchronisieren, oder sie können eine Teilmenge der Daten in dem DB-Cluster 206 synchronisieren. Zum Beispiel können die Synchronisations-Handler 210 eine fein gekörnte, filterbasierte Datensynchronisation unterstützen und zu den ortskennenden Clients 202 liefern. Die Synchronisations-Handler 210 können die ortskennenden Clients 202 und das DB-Cluster 206 auf Anfrage synchronisieren, oder sie können dies auf einer Basis vornehmen, die durch den Ortsmanagementserver 204 gemanagt wird. In einigen Ausführungsformen kann die Synchronisation ereignisbasiert sein. Wenngleich sie als Teil des Ortsmanagementservers 204 gezeigt sind, sollte erkannt werden, dass die Synchronisations-Handler 210 Teil eines anderen Systems sein können. Zum Beispiel können die Synchronisations-Handler 210 Teil des DB-Clusters 206 sein.
  • Es kann mehr als einen von den Synchronisations-Handlern 210 geben. Zum Beispiel kann es verschiedene Synchronisations-Handler 210 für jede unterstützte mobile Hauptplattform geben. Somit kann der Ortsmanagementserver 204 eine mobile plattformübergreifende Unterstützung aufweisen, und eine plattformübergreifende mobile Entwicklung kann mit einer gemeinsamen Code-Basis erreicht werden.
  • Die Synchronisations-Handler 210 können mit den ortskennenden Clients 202 durch einen Lastausgleicher (nicht gezeigt) kommunizieren, wie einen Reverse Proxy. Eine Kommunikation mit den ortskennenden Clients 202 kann über einen sicheren Transport, zum Beispiel Transportschichtsicherheit („transport layer security“ (TLS)), SSL („secure sockets layer“) usw. erfolgen. Die ortskennenden Clients 202 können einen sicheren lokalen Speicher unterstützen, und sie können die lokale DB verschlüsseln.
  • Der Mediationsdienst 212 interagiert mit den Synchronisations-Handlern 210 und führt eine Anwendungsniveaufunktionalität aus, wenn Daten zwischen den ortskennenden Clients 202 und dem DB-Cluster 206 synchronisiert werden. In einigen Ausführungsformen wird der Mediationsdienst 212 durch die Synchronisations-Handler 210 gemäß Datenänderungen über ein Webhook nach erfolgreicher Synchronisation benachrichtigt. Nach einer Datenänderung kann der Mediationsdienst 212 als ein Anwendungs-Broker agieren, und er kann den verbesserten Geo-Ortsdienst 214 abfertigen.
  • Der verbesserte Geo-Ortsdienst 214 unterstützt Ortsdienste, wie Geofencing. Zum Beispiel können die mehreren ortskennenden Clients 202 ihren Ort an den Ortsmanagementserver 204 über eine Datensynchronisation senden. Der Ortsdienst wird durch den Mediationsdienst 212 abgefertigt, um Geofencing-Regeln auf die empfangenen Orte anzuwenden, Änderungen an dem Anruf gemäß den angewendeten Regeln vorzunehmen und die ortskennenden Clients 202 bezüglich Änderungen zu benachrichtigen, indem das DB-Cluster 108 aktualisiert wird. Die ortskennenden Clients 202 können sich die Änderungen dann durch die Datensynchronisation holen.
  • Der Benachrichtigungsdienst 216 wird durch den verbesserten Geo-Ortsdienst 214 basierend auf Anwendungslogik abgefertigt. Zum Beispiel kann nach dem Bestimmen des Ortszustands eines ortskennenden Clients 202 der Geo-Ortsdienst 214 den Benachrichtigungsdienst 216 aufrufen, um eine Benachrichtigung an den empfangenden ortskennenden Client 202 zu liefern. Die Benachrichtigung löst den empfangenden ortskennenden Client 202 aus, womit er veranlasst wird, die neue Nachricht in Reaktion auf das Empfangen der Benachrichtigung zu holen. In einigen Ausführungsformen kann der Benachrichtigungsdienst 216 ein Push-Benachrichtigungs-Provider 218 sein, um Benachrichtigungen zu liefern. Bei Ausführungsformen, in denen der ortskennende Client 202 zum Beispiel ein Apple-Gerät ist, kann der Pusch-Benachrichtigungs-Provider 218 der „Apple Push Notification Service“ (APNS) sein, der genutzt wird, um den ortskennenden Client 202 zu benachrichtigen. Ähnlich kann der Push-Benachrichtigungs-Provider 218 „Google Cloud Messaging“ (GCM) bei Ausführungen sein, in denen der ortskennende Client 202 ein Android-Gerät ist.
  • Die ortskennenden Clients 202 sammeln Ortsdaten über ihre Orte und geben diese dem Ortsmanagementserver 204 bekannt. Eine Datenbanksynchronisation kann genutzt werden, um die Ortsdaten auszutauschen. Die Ortsdaten können auf verschiedene Arten durch die Ortsdienste genutzt werden. Ortsdaten werden gemäß Ortsdatensammelkriterien und Ortsdatenberichtskriterien gesammelt und berichtet, die durch den Ortsmanagementserver 204 spezifiziert sind.
  • Die Sammelkriterien spezifizieren, wie die ortskennenden Clients 202 Ortsdaten in ihrer lokalen DB sammeln und halten sollten. Die Berichtskriterien spezifizieren, wie häufig die ortskennenden Clients 202 die gesammelten Ortsdaten an den Ortsmanagementserver 204 berichten sollten. Die Ortsdatensammel- und -berichtskriterien können eine Vielfalt von Elementen enthalten. Beispiele von Kriterien enthalten: abgelaufene Zeit (Frequenz); zurückgelegte Strecke; Höhenänderungen. Kriterien können auch auf das Zugriffsnetzwerk bezogene Ereignisse sein, wie Zellenänderung, Änderungen des PLMN („public land mobile network“), Änderungen des Wi-Fi-Zugangspunktes, Änderungen des Wi-Fi-SSID („service set identifier“), Änderungen des MBMS-Dienstbereichs („multimedia broadcast mulitcast services“), Änderungen des MBSFN-Bereichs („multicast-broadcast single-frequency network“), Änderungen des Verfolgungsbereichs und dergleichen. Kriterien können auch Ereignisse enthalten, die von einem Umgebungssensor erfasst werden, wie Bewegungserfassung, Änderungen bezüglich Temperatur, Geschwindigkeit, Beschleunigung, Feuchtigkeit, Richtung und dergleichen. Schließlich können Kriterien auch Ereignisse enthalten, die von einem Gesundheitssensor erfasst werden, wie Herzfrequenz, Blutdruck und dergleichen.
  • Die Sammel- und Berichtskriterien können dynamisch während der Laufzeit geändert werden. Verschiedene Ereignisse können eine Änderung auslösen. Die ortskennenden Clients 202 können neue Sammel- und/oder Berichtskriterien von dem Ortsmanagementserver 204 empfangen. Die Kriterien können sich gemäß einer Regel ändern. Zum Beispiel kann sich die Ortsdatenberichtshäufigkeit als eine Funktion der Geschwindigkeit erhöhen. Ähnlich kann sich die Ortsdatenberichtshäufigkeit erhöhen, wenn der ortskennende Client 202 an einem Anruf teilnimmt.
  • Wenngleich die hier beschriebenen Ausführungsformen eine Datensynchronisation nutzen, um Geofence-Definitionen und Ortsdatenberichte zu kommunizieren, sollte erkannt werden, dass eine Vielzahl von Protokollen verwendet werden könnte. Zum Beispiel können die Geofence-Definitionen unter Verwendung eines gleichen beziehungsweise ähnlichen oder eines anderen Protokolls gesendet werden, als oder wie demjenigen, das zum Senden der Ortsdatenberichte genutzt wird. In einer Ausführungsform kann ein Teilnahmebenachrichtigungs-Framework genutzt werden, um Geofence-Definitionen zu senden, wobei die ortskennenden Clients 202 ein Geofence-Definitionsdokument abonnieren und der Ortsmanagementserver 204 die Teilnehmer bezüglich Dokumentenaktualisierungen benachrichtigt. SIP-Nachrichten („session initiation protocol“), wie die Nachrichten SIP SUBSCRIBE und SIP NOTIFY können genutzt werden, um ein solches Teilnahmebenachrichtigungs-Framework zu implementieren. In einer anderen Ausführungsform kann der Ortsmanagementserver 204 Geofence-Definitionsdokumente an die ortskennenden Clients 202 unter Verwendung nicht angeforderter SIP-Nachrichten senden, wie SIP PUBLISH und/oder SIP MESSAGE. Die Ortsdatenberichte können auch mit einer Vielzahl von Protokollen gesendet werden. In einer Ausführungsform können HTTP-basierte Schnittstellen, wie REST API-Anrufe genutzt werden. In einer anderen Ausführungsform können SIP-basierte Schnittstellen, wie SIP PUBLISH-Nachrichten, genutzt werden.
  • In einer ersten Ausführungsform wertet der Ortsmanagementserver 204 Ortsdaten aus und bestimmt einen Ortszustand eines ortskennenden Client 202. Der Ortszustand zeigt an, ob der ortskennende Client 202 in den Geofence eingetreten ist, den Geofence verlassen hat, sich innerhalb des Geofence befindet oder sich außerhalb des Geofence befindet. In solchen Ausführungsformen veröffentlichen die ortskennenden Clients 202 ihre Ortsdaten kontinuierlich an den Ortsmanagementserver 204, zum Beispiel, immer nachdem ein neuer Ortsdatenpunkt gesammelt wurde. Die Ortsdaten werden in der lokalen DB gesammelt und gespeichert. Die Ortsdaten in der lokalen DB werden mit dem DB-Cluster 206 an dem Ortsmanagementserver 204 zur Nutzung durch die Gruppensupervisor synchronisiert. Parameter für den Geofence werden an dem Ortsmanagementserver 204 gespeichert, und der Ortsdienst verfolgt die sich ändernden Ortsdaten von den ortskennenden Clients 202 und wendet Anwendungslogik und räumliche Ansichten auf die Ortsdaten an, um zu bestimmen, ob sich die ortskennenden Clients 202 innerhalb oder außerhalb des Geofence befinden (oder ob sie eingetreten oder ausgetreten sind). Der Ortsdienst benachrichtigt den Nutzer und/oder die Gruppensupervisor, dass ein ortskennender Client 202 in den Geofence eingetreten ist oder diesen verlassen hat. Die Benachrichtigung kann eine bandinterne oder bandexterne Benachrichtigung sein. Wenn eine Gruppe mehr als einen Supervisor/Geofence enthält, können die Ortsdaten gegen die Vielzahl von Geofences in der Gruppe ausgewertet werden. In einigen Ausführungsformen kann der Ortsdienst historische Daten von den ortskennenden Clients 202 nutzen, die in dem DB-Cluster 206 gespeichert sind, um Brotkrumenansichten zu erzeugen.
  • In einer zweiten Ausführungsform werten die ortskennenden Clients 202 ihre eigenen Ortsdaten aus und bestimmen ihren Ortszustand. In solchen Ausführungsformen werden die Geofence-Parameter zu den ortskennenden Clients 202 gesendet. Die ortskennenden Clients 202 sammeln ihre Ortsdaten kontinuierlich und speichern sie in ihren lokalen DBs. Die Ortsdaten werden dann von den ortskennenden Clients 202 genutzt, um Geofence-Eintritts-Ereignisse/Geofence-Austritts-Ereignisse unter Verwendung der Fence-Parameter zu bestimmen. In Reaktion auf die Eintrittsereignisse/Austrittsereignisse, benachrichtigen die ortskennenden Clients 202 die Mitglieder und/oder die Supervisor bezüglich der Position des Mitglieds mit Bezug auf einen bezeichneten Geofence. In einigen Ausführungsformen müssen die Ortsdaten nur in der lokalen DB gespeichert werden, und sie müssen nicht zu dem Ortsmanagementserver 204 übertragen werden, wodurch Uplink-Bandbreitennutzung eingespart wird und es den ortskennenden Clients 202 erlaubt wird, Eintrittsereignisse/Austrittsereignisse zu bestimmen, wenn eine Netzwerkkonnektivität unzuverlässig ist.
  • Die von den ortskennenden Clients gesammelten Ortsdaten können in verschiedenen Formaten vorliegen, und sie können verschiedene Informationen enthalten. Mindestens enthalten die Ortsdaten den geografischen Ort, wie die Breite und die Länge. Andere Informationen können die Höhe; einen Zeitstempel; Information darüber welches oder welche Ereignisse die Datensammlung ausgelöst haben; und Drahtlosnetzwerkinformation enthalten, wie Zellenidentifizierer, Ortsbereichcode, Verfolgungsbereichcode, Wi-Fi-SSID, MBSFN-Bereich („multicast-broadcast single-frequency network“) und dergleichen.
  • 3A und 3B zeigen Datensynchronisationspläne. 3A zeigt eine Ausführungsform, bei der das DB-Cluster 206 ein einzelnes Cluster ist. Jeder der ortskennenden Clients 202 repliziert eine Teilmenge der Daten von der einzelnen Datenbank in seine lokale DB. 3B zeigt eine Ausführungsform, bei der das DB-Cluster 206 mehrere getrennte Datenbänke enthält (oder getrennte Cluster von Datenbänken). Jeder der ortskennenden Clients 202 repliziert die gesamten Daten von einer der getrennten Datenbänke in seine lokale DB.
  • 4 ist ein Protokolldiagramm eines ersten Geofence-Überwachungsverfahrens 400 gemäß einer Ausführungsform. Das erste Geofence-Überwachungsverfahren 400 ist ein beispielhaftes Verfahren, das in Ausführungsformen verwendet werden kann, bei denen der Ortsmanagementserver 204 Ortsdaten auswertet und den Ortszustand eines ortskennenden Client 202 bestimmt. Die ortskennenden Clients 202 können von einem Gruppensupervisor 202A und einem Gruppenmitglied 202B genutzt werden.
  • Ein ortskennender Client 202, wie der Gruppensupervisor 202A, gibt Ortsdaten für einige oder alle der ortskennenden Clients 202 in der Geoortsgruppe frei oder fordert diese an (Schritt 402). Es sollte erkannt werden, dass ein anderer ortskennender Client 202 neben dem Gruppensupervisor 202A die Ortsdaten anfordern kann. Ein Anfordern der Ortsdaten kann einen oder mehrere Geofences aufbauen. Die Anforderung kann unter Verwendung des Datensynchronisationsmechanismus gesendet werden, der oben diskutiert ist. Eine Steuerung und eine Signalisierung ist durch Datensätze implementiert, die in der lokalen DB des Gruppensupervisors 202A gespeichert sind sowie dem DB-Cluster 202, welche synchronisiert sind. In einigen Ausführungsformen fordert der Gruppensupervisor 202A die Ortsdaten an, indem er Ortsdatensammelkriterien erzeugt und diese in der lokalen DB bei dem Gruppensupervisor 202A speichert. Nach Synchronisation mit dem Ortsmanagementserver 204 fertigt der Mediationsdienst 212 den Ortsdienst ab, um damit zu beginnen, Ortsdaten von den ortskennenden Clients 202 zu sammeln.
  • Der Ortsmanagementserver 204 sendet die Ortsdatensammelkriterien und die Ortsdatenberichtskriterien an das Gruppenmitglied 202B (Schritt 404). Die Sammel- und Berichtskriterien können gleich oder unterschiedlich sein. In Ausführungsformen, bei denen sie gleich sind, sammelt das Gruppenmitglied 202B Ortsdaten und berichtet diese mit derselben Häufigkeit. Die Granularität der Ortsdaten kann erhöht oder erniedrigt werden, indem die Kriterien entsprechend eingestellt werden. In Ausführungsformen, bei denen sie unterschiedlich sind, sammelt das Gruppenmitglied 202B Ortsdaten mit einer konfigurierten Häufigkeit, berichtet diese jedoch mit einer anderen Häufigkeit. Das Gruppenmitglied 202B sammelt Ortsdaten mit einer größeren Häufigkeit als mit der Berichtshäufigkeit. Alle oder eine Teilmenge der gesammelten Ortsdaten können zum Zeitpunkt des Berichtens berichtet werden, gemäß den Berichtskriterien.
  • Das Gruppenmitglied 202B kann benachrichtigt werden, dass es seinen Ort über ein Datenbankauslösedokument von dem Ortsmanagementserver 204 veröffentlicht. Das Auslösedokument stellt die konfigurierten Werte für den Fence und die Sammel-/Berichtskriterien für den Client zur Verfügung. Der Ortsmanagementserver 204 erzeugt das Ortsauslösedokument, verbleibend in dem DB-Cluster 206, und führt dann eine Synchronisation mit der lokalen DB bei dem Gruppenmitglied 202B aus.
  • Das Gruppenmitglied 202B zeichnet seinen Ort auf, wobei die Ortsdaten in seiner lokalen DB gespeichert werden (Schritt 406). Das Gruppenmitglied 202B liest, nach dem Empfangen des Auslösedokuments, die Konfiguration, und es speichert und veröffentlicht die Ortsdaten kontinuierlich. Eine kontinuierliche Veröffentlichung des Orts enthält ein Senden der Ortsdaten an den Ortsmanagementserver 204 nach jeder Aktualisierung, die gemäß den Sammelkriterien ausgeführt wird. Die Ortsdaten werden in der lokalen DB des Gruppenmitglieds 202B mit Metadaten gespeichert. Die Ortsdaten werden in einem Industriestandartformat gesammelt und gespeichert, wie GeoJSON oder XML. Die gespeicherten Ortsdaten können in einem strukturierten oder unstrukturierten Datenformat vorliegen, und die Formatierung kann von dem Auslösedokument spezifiziert sein. Aktualisierungen der Ortsdaten werden als eine Versionsänderung der Ortsdaten registriert (zum Beispiel durch Erzeugen eines Metadateneintrags), und sie werden über die Version des Ortsdatendokuments verfolgt.
  • Das Gruppenmitglied 202B sendet die gespeicherten Ortsdaten an den Ortsmanagementserver 204 (Schritt 408). Die Daten werden gemäß den Berichtskriterien gesendet. Die Ortsdaten werden durch Synchronisation der lokalen DB des Gruppenmitglieds 202B mit dem DB-Cluster 206 des Ortsmanagementservers 204 gesendet. Das Senden von Ortsdaten über eine Datensynchronisation kann den Signalisierungs-Overhead reduzieren, wodurch RAN-Uplink-Ressourcen eingespart werden. In einigen Ausführungsformen werden die Ortsdaten in einem erkennbaren Datenformat gespeichert, und Änderungen dieser Daten können asynchron eine Aktualisierungsübertragung der aktualisierten Daten auslösen. In einigen Ausführungsformen wird der Ortsdatensatz zwischen mehreren interessierten Parteien geteilt, zum Beispiel mit sowohl dem Ortsmanagementserver 204 als auch dem Gruppensupervisor 202A, indem mit diesen Datenbanken in einer Peer-to-Peer-Art synchronisiert wird, wodurch die Ausbreitung der Daten optimiert wird. Die Ortsdaten sind zeitlich über einen Zeitraum, durch die Nutzung einer Versionsverfolgung der Datenbankelemente geordnet (oben diskutiert). Das Ortsdatendokument wird mit dem Server zu einem vordefinierten Veröffentlichungsintervall synchronisiert, wenn das Gruppenmitglied 202B online ist, und das Veröffentlichungsintervall wird durch die Berichtskriterien spezifiziert. Wenn das Gruppenmitglied 202B offline ist, aktualisiert es die Ortsdaten an der lokalen DB, wobei die Aktualisierungen verfolgt werden, bis das Netzwerk zur Synchronisation verfügbar ist.
  • Der Ortsmanagementserver 204 wendet die Geofencing-Grenze sowie die Regeln auf die empfangenen Ortsdaten an (Schritt 410). Eine Verarbeitung kann ausgeführt werden, einschließlich einer Berechnung der Orte des Gruppenmitglieds 202B innerhalb der Geofence-Grenze, unter Nutzung räumlicher Ansichten von Daten in dem DB-Cluster 206 und des Ortes des Gruppensupervisors 202A als das Geofence-Zentrum. Andere Geofence-Regeln können auf die Ortsdaten zu diesem Zeitpunkt auch angewendet werden, wie Benachrichtigungsregeln. Der Ortsmanagementserver 204 empfängt einen Datenänderungsübertragungsauslöser für die Ortsdaten über Erkennbares in der Datenbankschicht während der Synchronisation, und er verarbeitet die Regeln in Reaktion darauf. Der Ortsmanagementserver 204 bestimmt Geofence-Eintritts-Ereignisse/Geofence-Austritts-Ereignisse für das Gruppenmitglied 202B unter Nutzung der Fence-Parameter und der empfangenen Ortsdaten.
  • Der Ortsdatenmanagementserver 204 benachrichtigt den Gruppensupervisor 202A und das Gruppenmitglied 202B in Reaktion darauf, dass der Ortszustand des Gruppenmitglieds 202B bestimmt wird (Schritt 412). Die Benachrichtigung wird durch den Ortsdienst in Reaktion auf das Ergebnis der Eintrittsauswertung/Austrittsauswertung abgefertigt. Die Benachrichtigung kann unter Nutzung eines bandinternen oder eines bandexternen Benachrichtigungskanal gesendet werden, abhängig davon, welche Kanäle von dem Gruppenmitglied 202B unterstützt werden.
  • Wenngleich das erste Geofence-Überwachungsverfahren 400 mit Bezug auf einen einzelnen Supervisor und einen einzelnen Geofence diskutiert ist, sollte erkannt werden, dass eine Gruppe mehr als einen Supervisor haben kann und dass ein Mitglied in mehr als einer Gruppe teilnehmen kann. Somit kann der Ortsmanagementserver 204 Ortsdaten von dem Gruppenmitglied 202B für alle Geofences verarbeiten, die auf das Gruppenmitglied 202B anwendbar sind, und er kann alle relevanten Gruppensupervisor 202A über die Geofence-Eintritts-Ereignisse/Geofence-Austritts-Ereignisse benachrichtigen.
  • In einigen Ausführungsformen (in 4 nicht gezeigt) kann der Gruppensupervisor 202A eine angefragte Ortsaktualisierung von dem Gruppenmitglied 202B anfordern. Eine solche Anforderung kann bandextern ausgeführt werden, zum Beispiel zwischen den normalen Ortsdatensammelintervallen, die von den Sammel- und/oder Berichtskriterien spezifiziert sind. In solchen Ausführungsformen sendet der Gruppensupervisor 202A eine angeforderte Ortsaktualisierungsanforderung an den Ortsmanagementserver 204, welcher die Anfrage an das Gruppenmitglied 202B weiterleitet. Das Gruppenmitglied 202B beantwortet die Anforderung dann, indem es seinen Ort in der lokalen DB aktualisiert und die Aktualisierung mit dem DB-Cluster 206 synchronisiert. In einigen Ausführungsformen kann die angeforderte Ortsaktualisierungsanforderung auch eine Anforderung enthalten, Ortsdaten mit einer anderen Häufigkeit für eine definierte Zeitdauer zu berichten. Die Anforderung kann in der Form neuer temporärer Sammel- und/oder Berichtskriterien vorliegen. Das Gruppenmitglied 202B nutzt dann die neuen Kriterien, wenn es Ortsdaten an den Ortsmanagementserver 204 berichtet. Der Ortsmanagementserver 204 leitet die Ortsdaten zurück zu dem Gruppensupervisor 202A. Ähnlich zu dem ersten Geofence-Überwachungsverfahren 400, welches oben diskutiert ist, nutzt jede Datenübertragung (zum Beispiel Anforderung, Kriterien, Ortsdaten usw.) einen Änderungsbenachrichtigungsmechanismus, um die Datensynchronisation zwischen dem DB-Cluster 206 und den lokalen DBs auszulösen. Für den Gruppensupervisor 202A und das Gruppenmitglied 202B kann der Änderungsbenachrichtigungsmechanismus zum Beispiel ein erkennbares Ereignis in den lokalen DBs sein.
  • 5 ist ein Protokolldiagramm eines zweiten Geofence-Überwachungsverfahrens 500 gemäß einer Ausführungsform. Das zweite Geofence-Überwachungsverfahren 500 ist ein beispielhaftes Verfahren, das in Ausführungsformen genutzt werden kann, in denen die ortskennenden Clients 202 ihre eigenen Ortsdaten auswerten und ihren Ortszustand bestimmen.
  • Ein ortskennender Client 202, wie der Gruppensupervisor 202A, gibt Ortsdaten für einen ortskennenden Client 202 frei oder fordert diese an (Schritt 502). Die Ortsdaten können von einigen oder allen ortskennenden Clients 202 in der Geoortsgruppe angefordert werden, oder von ortskennenden Clients, die sich nicht in der Gruppe befinden. Es sollte erkannt werden, dass ein anderer ortskennender Client 202 neben dem Gruppensupervisor 202A die Ortsdaten anfordern kann. Das Anfordern der Ortsdaten kann einen oder mehrere Geofences aufbauen. Die Anforderung kann in einer Weise gleich oder ähnlich zum obigen Schritt 402 gesendet werden. Einzelheiten darüber, wie die Anforderung gesendet wird und was die Anforderung umfasst, werden hier nicht wiederholt.
  • Der Ortsmanagementserver 204 sendet die Geofence-Definitionen an das Gruppenmitglied 202B zusammen mit Ortsdatensammelkriterien und Ortsdatenberichtskriterien, die mit jedem definierten Geofence assoziiert sind (Schritt 504). Die Geofence-Definitionen können unter Nutzung einer Datensynchronisation gesendet werden. Wie bei dem ersten Geofence-Überwachungsverfahren 400 können die Sammel- und Berichtskriterien gleich oder unterschiedlich sein. Somit sammelt das Gruppenmitglied 202B Ortsdaten mit einer konfigurierten Häufigkeit, berichtet sie jedoch mit einer anderen Häufigkeit. In einer Ausführungsform sammelt das Gruppenmitglied 202B Ortsdaten mit einer größeren Häufigkeit als mit der Berichtshäufigkeit. Das Gruppenmitglied 202B kann benachrichtigt werden, einen Ort über eine Unicast-, Multicast- oder Broadcast-Technik zu veröffentlichen. In einigen Ausführungsformen Broadcast-überträgt der Ortsmanagementserver 204 die Geofence-Definitionen an alle ortskennenden Clients 202 in einem Gruppenanruf. In einigen Ausführungsformen können die Sammel- und/oder Berichtskriterien für einen Geofence Anweisungen enthalten, die gewisse Handlungen für das Gruppenmitglied 202B spezifizieren, die auf ein Eintreten oder ein Verlassen des Geofence auszuführen sind. Die Handlungen werden durch das Gruppenmitglied 202B auf ein Bestimmen seines Ortszustands ausgeführt, und in einigen Ausführungsformen hängen die auszuführenden Handlungen von dem Ortszustand ab.
  • Das Gruppenmitglied 202B zeichnet seinen Ort auf und speichert die Ortsdaten in seiner lokalen DB, basierend auf den Sammelkriterien für jeden Geofence (Schritt 506). Die Ortsdaten werden in der lokalen DB mit Metadaten gespeichert, wobei Techniken genutzt werden die gleich oder ähnlich zu jenen sind, die oben mit Bezug auf Schritt 406 diskutiert sind, und daher werden Einzelheiten hier nicht wiederholt.
  • Das Gruppenmitglied 202B sendet die gespeicherten Ortsdaten an den Ortsmanagementserver 204 basierend auf den Berichtskriterien für jeden Geofence (Schritt 508). Die gespeicherten Ortsdaten können periodisch oder in Reaktion auf gewisse Ereignisse gesendet werden. Die Ortsdaten werden durch ein Synchronisieren der lokalen DB des Gruppenmitglieds 202B mit dem DB-Cluster 206 des Ortsmanagementservers 204 gesendet. Der Ortsdatenbericht, welcher an den Ortsmanagementserver 204 gesendet wird, kann mehr als einen Punkt von Ortsdaten enthalten. In Ausführungsformen, in denen die Sammel- und Berichtskriterien dieselben sind, enthält jeder Bericht einen Punkt von Ortsdaten. Insbesondere enthält er alle Ortsdaten, die seit dem vorhergehenden Ortsdatenbericht angesammelt wurden. Zum Beispiel kann das Gruppenmitglied 202B Ortsdatenpunkte mit der dreifachen Häufigkeit der Berichtshäufigkeit aufzeichnen, und somit kann jeder Ortsdatenbericht drei Ortsdatenpunkte enthalten. Zusätzlich zu den Berichtskriterien können andere Ereignisse das Gruppenmitglied 202B veranlassen, den Ortsbericht zu senden. Zum Beispiel kann das Gruppenmitglied 202B den Bericht in Reaktion auf eine ausdrückliche bandexterne Anforderung von dem Gruppensupervisor 202A senden, oder in Reaktion auf eine manuelle Anforderung durch den Nutzer.
  • Das Gruppenmitglied 202B verarbeitet Grenzen und Regeln für jeden Geofence unter Nutzung der Geofence-Definitionen und der gesammelten Ortsdaten (Schritt 510). Für jede der Geofence-Definitionen bestimmt das Gruppenmitglied 202B, ob es sich innerhalb oder außerhalb des Geofence befindet. Basierend auf der Bestimmung führt das Gruppenmitglied 202B die spezifizierten Handlungen für den Geofence auf eine Bestimmung aus, dass in den Geofence eingetreten wurde oder dieser Verlassen wurde (Schritt 512).
  • In einigen Ausführungsformen ist die spezifizierte Handlung eine Ortsdatensammelhandlung, die ein Ändern der Sammel- und/oder Berichtskriterien enthalten kann. Zum Beispiel kann das Gruppenmitglied 202B die Sammel- und/oder Berichtshäufigkeit erhöhen, wenn es in den Geofence eintritt, und es kann die Sammel- und/oder Berichtshäufigkeit erniedrigen, wenn es den Geofence verlässt. In einigen Ausführungsformen kann die spezifizierte Handlung für ein Geofence Sammel- und/oder Berichtshäufigkeiten spezifizieren, die zu nutzen sind, wenn sich das Gruppenmitglied 202B innerhalb oder außerhalb des Geofence befindet.
  • In einigen Ausführungsformen enthält die spezifizierte Handlung ein Senden einer Benachrichtigung, dass das Gruppenmitglied 202B in den Geofence eingetreten ist oder diesen verlassen hat. Die Benachrichtigung kann an den Ortsmanagementserver 204 unter Nutzen einer Datensynchronisation gesendet werden. Alternativ kann die Benachrichtigung direkt an den Gruppensupervisor 202A auf eine Peer-to-Peer-Art gesendet werden.
  • Der Ortsmanagementserver 204 sendet aktuelle Geofence-Definitionen an das Gruppenmitglied 202B (Schritt 514). Die aktualisierten Definitionen können aktualisierte Sammel- und/oder Berichtskriterien enthalten. Die aktualisierten Definitionen können unter Nutzung einer Unicast-, Multicast- oder Broadcast-Technik gesendet werden. In einigen Ausführungsformen können die anfänglichen Geofence-Definitionen an alle ortskennenden Clients 202 unter Nutzung eines Broadcast-Mechanismus gesendet werden, und dann kann ein spezielles Gruppenmitglied 202B aktualisiert werden, unter Nutzung eines Unicast-Mechanismus. Eine Aktualisierung der Geofence-Definition kann ein Übertragen eines neuen Orts des Geofence-Anker- oder -Bezugspunktes enthalten, oder eine Übertragen einer neuen Form/Größe des eingeschlossenen Gebiets.
  • Eine Bestimmung von Geofence-Eintritts-Ereignissen/Geofence-Austritts-Ereignissen und eine Änderung von Sammel-/Berichtskriterien durch das Gruppenmitglied 202B kann die Genauigkeit der Ortsverfolgung verbessern und die RAN-Ressourcennutzung vermindern.
  • In Anwendungen, in denen die Sicherheit von öffentlichem Personal kritisch ist, können Ortsdaten häufiger für Personen gesammelt werden, die sich näher an einem stattfindenden Notfall befinden, und weniger häufig für Personen, die weiter von dem Notfall entfernt sind. Eine Verfolgung kann somit für jene genauer sein, die sich näher an dem Notfall befinden. Weiterhin können RAN-Ressourcen für jene eingespart werden, die sich näher an dem Notfall befindet, wodurch die Verlässlichkeit während des häufigeren Berichtens verbessert wird.
  • In einigen Ausführungsformen kann der an den Ortsmanagementserver 204 in Schritt 508 gesendete Ortsdatenbericht zur Nachverarbeitung von Operationen genutzt werden. Zum Beispiel können die Ortsdaten analysiert werden, um den zurückgelegten Abstand, den genommenen Weg und dergleichen für einen ortskennenden Client 202 zu bestimmen. Diese Daten können auch zum Optimieren von Dingen genutzt werden, wie Operationsverfahren für die Nutzer der Anrufgruppe.
  • In einigen der obigen Ausführungsformen kann eine Broadcast- oder Multicast-Technologie genutzt werden, wie LTE eMBMS („Evolved Multimedia Broadcast Multicast Services“). eMBMS kann zum Beispiel für die anfängliche Übertragung der Geofence-Definitionen genutzt werden (Schritt 504), und die Übertragung von aktualisierten Geofence-Definitionen (Schritt 514). Die Nutzung von eMBMS kann ein Erzeugen von Multicast-Trägern in dem RAN enthalten, womit ermöglicht wird, dass die Geofence-Definitionen auf einmal an einige oder alle ortskennenden Clients 202 per Multicast übertragen werden.
  • 6 ist ein Protokolldiagramm eines Kartenbetrachtungsverfahrens 600. Das Kartenbetrachtungsverfahren 600 wird genutzt, um eine Karte zur Betrachtung zu erzeugen, nachdem der Supervisor benachrichtigt ist, dass ein ortskennender Client 202 in den Geofence eingetreten ist oder diesen verlassen hat. Das Kartenbetrachtungsverfahren 600 kann durch den Gruppensupervisor 202A als Teil des ersten Geofence-Überwachungsverfahrens 400 oder des zweiten Geofence-Überwachungsverfahrens 500 ausgeführt werden.
  • Der Gruppensupervisor 202A öffnet die Kartenansicht und fordert aktuelle Ortsinformation für die Gruppenmitglieder 202B an (Schritt 602). Der Ortsmanagementserver 204 sendet die aktuelle Ortsinformation für den Gruppensupervisor 202A (Schritt 604). Die aktualisierte Ortsinformation kann Mitgliederortsdatendokumente für jeden Nutzer enthalten, und sie kann an den Gruppensupervisor 202A mittels Datensynchronisation gesendet werden. Der Gruppensupervisor 202A führt die Kartenansicht aus, einschließlich Plots der Wege und Orte der Gruppenmitglieder 202B (Schritt 606). In einigen Ausführungsformen kann der Gruppensupervisor 202A eine aktualisierte Kartenansicht anfordern (Schritt 608). Die Aktualisierung kann durch einen Nutzer manuell angefordert werden. In Reaktion auf die Aktualisierungsanforderung kann eine aufgeforderte Ortsaktualisierung mit den Gruppenmitgliedern 202B ausgeführt werden (Schritt 610). Die Kartenansicht wird dann mit den aktualisierten Ortsdaten aktualisiert (Schritt 612).
  • 7 ist ein Blockdiagramm eines Multicast-Telekommunikationssystems 700. Das Multicast-Telekommunikationssystem 700 kann zum Beispiel ein eMBMS-System sein. Das Multicast-Telekommunikationssystem 700 kann zum Beispiel für die anfängliche Übertragung von Geofence-Definitionen an eine Gruppe genutzt werden, und die Übertragung von aktualisierten Geofence-Definitionen an die Gruppe. Das Multicast-Telekommunikationssystem 700 enthält die ortskennenden Clients 202, die sich mit dem Ortsmanagementserver 204 in Kommunikation befinden. Das Multicast-Telekommunikationssystem 700 enthält auch ein Kernnetzwerk 702, das Merkmale wie ein EPS („evolved packet system“) 704, einen SIP/IP-Multimedia-Teilsystem-Kern („SIP/IP Multimedia Subsystem (IMS) core“) 706, ein MBMS-GW („multimedia broadcast multicast services gateway“) 708 und ein BM-SC („broadcast multicast-service center“) 710 enthält.
  • 8 ist ein Blockdiagramm eines Verarbeitungssystems 800 zum Ausführen von hier beschriebenen Verfahren, die in einem Host-Gerät installiert sein können. Wie gezeigt ist, enthält das Verarbeitungssystem 800 einen Prozessor 802, einen Speicher 804 und Schnittstellen 806 bis 810, die so angeordnet sein können, wie in 8 gezeigt, aber nicht müssen. Der Prozessor 802 kann irgendeine Komponente oder eine Ansammlung von Komponenten sein, die geeignet ist, um Berechnungen und/oder andere verarbeitungsbezogene Aufgaben auszuführen, und der Speicher 804 kann irgendeine Komponente oder eine Ansammlung von Komponenten sein, die geeignet ist, eine Programmierung und/oder Anweisungen zur Ausführung durch den Prozessor 802 zu speichern. In einer Ausführungsform enthält der Speicher 804 ein nichttransitorisches computerlesbares Medium. Die Schnittstellen 806, 808, 810 können irgendeine Komponente oder eine Ansammlung von Komponenten sein, die es erlaubt, dass das Verarbeitungssystem 800 mit anderen Geräten/Komponenten und/oder einem Nutzer kommuniziert. Zum Beispiel können die eine oder die mehreren Schnittstellen 806, 808, 810 geeignet sein, Daten-, Steuerungs- oder Management-Nachrichten von dem Prozessor 802 an Anwendungen zu kommunizieren, die auf dem Host-Gerät und/oder einem entfernten Gerät installiert sind. In einem anderen Beispiel können die eine oder die mehreren Schnittstellen 806, 808, 810 geeignet sein, einem Nutzer oder einem Nutzergerät zu ermöglichen (zum Beispiel einem Personal Computer (PC) usw.), mit dem Verarbeitungssystem 800 zu interagieren/kommunizieren. Das Verarbeitungssystem 800 kann zusätzliche Komponenten enthalten, die in 8 nicht dargestellt sind, wie einen Langzeitspeicher (zum Beispiel einen nichtflüchtigen Speicher usw.).
  • In einigen Ausführungsformen ist das Verarbeitungssystem 800 in einem Netzwerkgerät enthalten, das auf ein Telekommunikationsnetzwerk zugreift oder in anderer Weise ein Teil davon ist. In einer Ausführungsform befindet sich das Verarbeitungssystem 800 in einem netzwerkseitigen Gerät in einem drahtlosen oder einem leitungsgebundenen Telekommunikationsnetzwerk, wie einer Basisstation, einer Relais-Station, einem Scheduler, einem Controller, einem Gateway, einem Router, einem Anwendungsserver oder irgendeinem anderen Gerät in dem Telekommunikationsnetzwerk. In anderen Ausführungsformen befindet sich das Verarbeitungssystem 800 in einem nutzerseitigen Gerät, das auf ein drahtloses oder leitungsgebundenes Telekommunikationsnetzwerk zugreift, wie einer mobilen Station, einer Nutzerausstattung („user equipment“ (UE)) einem Personal Computer (PC), einem Tablet, einem tragbaren Kommunikationsgerät (zum Beispiel einer Smartwatch usw.) oder irgendeinem anderen Gerät, das geeignet ist, auf ein Telekommunikationsnetzwerk zuzugreifen.
  • In einigen Ausführungsformen verbinden die eine oder die mehreren Schnittstellen 806, 808, 810 das Verarbeitungssystem 800 mit einem Transceiver, der geeignet ist, eine Signalisierung über das Telekommunikationsnetzwerk zu senden und zu empfangen. 9 ist ein Blockdiagramm eines Transceivers 900, der geeignet ist, eine Signalisierung über ein Telekommunikationsnetzwerk zu senden und zu empfangen. Der Transceiver 900 kann in einem Host-Gerät installiert sein. Wie gezeigt ist, umfasst der Transceiver 900 eine netzwerkseitige Schnittstelle 902, einen Koppler 904, einen Sender 906, einen Empfänger 908, einen Signalprozessor 910 und eine geräteseitige Schnittstelle 912. Die netzwerkseitige Schnittstelle 902 kann irgendeine Komponente oder eine Ansammlung von Komponenten enthalten, die geeignet ist, eine Signalisierung über ein drahtloses oder ein leitungsgebundenes Telekommunikationsnetzwerk zu senden. Der Koppler 904 kann irgendeine Komponente oder eine Ansammlung von Komponenten enthalten, die geeignet ist, eine bidirektionale Kommunikation über die netzwerkseitige Schnittstelle 902 zu ermöglichen. Der Sender 906 kann irgendeine Komponente oder eine Ansammlung von Komponenten enthalten (zum Beispiel einen Aufwärtskonverter, einen Leistungsverstärker usw.), die geeignet ist, ein Basisbandsignal in ein moduliertes Trägersignal zu konvertieren, das geeignet ist zur Übertragung über die netzwerkseitige Schnittstelle 902. Der Empfänger 908 kann irgendeine Komponente oder eine Ansammlung von Komponenten enthalten (zum Beispiel einen Abwärtskonverter, einen Niedrigrauschverstärker usw.), die geeignet ist, ein Trägersignal, das über die netzwerkseitige Schnittstelle 902 empfangen wurde, in ein Basisbandsignal zu konvertieren. Der Signalprozessor 910 kann irgendeine Komponente oder eine Ansammlung von Komponenten enthalten, die geeignet ist, ein Basissignal in ein Datensignal zu konvertieren, das für eine Kommunikation über die geräteseitige Schnittstelle(n) 912 geeignet ist, oder umgekehrt. Die geräteseitige Schnittstelle(n) 912 kann/können irgendeine Komponente oder eine Ansammlung von Komponenten enthalten, die geeignet ist, Datensignale zwischen dem Signalprozessor 910 und Komponenten innerhalb des Host-Gerätes zu kommunizieren (zum Beispiel dem Verarbeitungssystem 800, den LAN-Ports („local area network“) usw.).
  • Der Transceiver 900 kann eine Signalisierung über irgendeinen Typ eines Kommunikationsmediums senden und empfangen. In einigen Ausführungsformen sendet und empfängt der Transceiver 900 eine Signalisierung über ein drahtloses Medium. Zum Beispiel kann der Transceiver 900 ein drahtloser Transceiver sein, der geeignet ist, gemäß einem drahtlosen Telekommunikationsprotokoll zu kommunizieren, wie einem zellularen Protokoll (zum Beispiel LTE („long-term evolution“) usw.), einem WLAN-Protokoll („wireless local area network“) (zum Beispiel Wi-Fi usw.) oder über irgend einen anderen Typ eines drahtlosen Protokolls (zum Beispiel Bluetooth, NFC („near field communication“) usw.). In solchen Ausführungsformen umfasst die netzwerkseitige Schnittstelle 902 ein oder mehrere Antennenelemente/Strahlungselemente. Zum Beispiel kann die netzwerkseitige Schnittstellt 902 eine einzelne Antenne, mehrere getrennte Antennen oder eine Mehrfachantennenanordnung enthalten, die für eine Mehrschichtkommunikation konfiguriert sind, zum Beispiel SIMO („single input multiple output“, einzelne Eingabe, mehrfache Ausgabe), MI-SO („multiple input single output“, mehrfache Eingabe, einzelne Ausgabe), MIMO („multiple input multiple output“, mehrfache Eingabe, mehrfache Ausgabe) usw. In anderen Ausführungsformen sendet und empfängt der Transceiver 900 eine Signalisierung über ein Leitungsmedium zum Beispiel ein Twisted-Pair-Kabel, ein Koaxialkabel, eine optische Faser usw. Spezifische Verarbeitungssysteme und/oder Transceiver können alle gezeigten Komponenten nutzen oder nur eine Teilmenge der Komponenten, und die Integrationsniveaus können von Gerät zu Gerät variieren.
  • Wenngleich diese Erfindung mit Bezug auf veranschaulichte Ausführungsformen beschrieben ist, soll die Beschreibung nicht in einem beschränkenden Sinne aufgefasst werden. Verschiedene Änderungen und Kombinationen der veranschaulichenden Ausführungsformen sowie andere Ausführungsformen der Erfindung sind Fachleuten auf der Grundalge einer Bezugnahme auf die Beschreibung offensichtlich. Es ist daher beabsichtigt, dass die beigefügten Ansprüche alle diese Änderungen und Ausführungsformen umfassen.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • US 62245876 [0001]
    • US 14994757 [0022]

Claims (44)

  1. Verfahren, durch einen Ortsmanagementserver, umfassend: Senden, durch den Ortsmanagementserver, von Ortsdatensammelkriterien und Ortsdatenberichtskriterien an einen ersten ortskennenden Client; und Empfangen, durch den Ortsmanagementserver, von Ortsdaten von dem ersten ortskennenden Client, wobei die Ortsdaten durch den ersten ortskennenden Client gemäß den Ortsdatensammelkriterien gesammelt werden, wobei die Ortsdaten von dem ersten ortskennenden Client gemäß den Ortsdatenberichtskriterien empfangen werden.
  2. Verfahren nach Anspruch 1, wobei die Ortsdatensammelkriterien und die Ortsdatenberichtskriterien dieselben sind.
  3. Verfahren nach Anspruch 1, wobei das Senden der Ortsdatensammelkriterien und der Ortsdatenberichtskriterien umfasst: Speichern, durch den Ortsmanagementserver, der Ortsdatensammelkriterien und der Ortsdatenberichtskriterien in einem Datenbank-Cluster (DB-Cluster), das von dem Ortsmanagementserver erreichbar ist, wobei die Ortsdatensammelkriterien und die Ortsdatenberichtskriterien jeweils in einem erkennbaren Datenfeld des DB-Clusters gespeichert werden.
  4. Verfahren nach Anspruch 1, wobei das Empfangen der Ortsdaten von dem ersten ortskennenden Client umfasst: Erkennen, durch den Ortsmanagementserver, einer Synchronisation der Ortsdaten von einer ersten lokalen Datenbank an den ersten ortskennenden Client in ein Datenbank-Cluster (DB-Cluster), das von dem Ortsmanagementserver erreichbar ist.
  5. Verfahren nach Anspruch 1, wobei die Ortsdatensammelkriterien eine Ortsdatensammlung als eine Funktion von wenigstens einem von Folgendem spezifizieren: abgelaufene Zeit, durch den ersten ortskennenden Client zurückgelegte Strecke, Geschwindigkeit des ersten ortskennenden Client, Beschleunigung des ersten ortskennenden Client, Höhe des ersten ortskennenden Client, Zugriffsnetzwerkereignisse des ersten ortskennenden Client, Umgebungssensorereignisse des ersten ortskennenden Client und Gesundheitssensorereignisse des ersten ortskennenden Client.
  6. Verfahren nach Anspruch 1, wobei die Ortsdatenberichtskriterien einen Ortsdatenbericht als eine Funktion von wenigstens einem von Folgendem spezifizieren: abgelaufene Zeit, durch den ersten ortskennenden Client zurückgelegte Strecke, Geschwindigkeit des ersten ortskennenden Client, Beschleunigung des ersten ortskennenden Client, Höhe des ersten ortskennenden Client, Zugriffsnetzwerkereignisse des ersten ortskennenden Client, Umgebungssensorereignisse des ersten ortskennenden Client und Gesundheitssensorereignisse des ersten ortskennenden Client.
  7. Verfahren nach Anspruch 1, wobei die Ortsdaten eine geografische Breite und Höhe des ersten ortskennenden Client umfassen.
  8. Verfahren nach Anspruch 7, wobei die Ortsdaten weiterhin einen Zeitstempel der Ortsdaten, eine Anzeige von Ereignissen, die veranlassen, dass die Ortsdaten von dem ersten ortskennenden Client gesammelt werden, Netzwerkinformation für den ersten ortskennenden Client oder eine Kombination davon umfassen.
  9. Verfahren nach Anspruch 1, weiterhin umfassend: Auswerten, durch den Ortsmanagementserver, der Ortsdaten, die von dem ersten ortskennenden Client empfangen wurden, um einen aktuellen Ortszustand des ersten ortskennenden Client mit Bezug auf einen Geofence zu bestimmen, wobei der aktuelle Ortszustand anzeigt, ob der erste ortskennende Client in den Geofence eingetreten ist, den Geofence verlassen hat, sich innerhalb des Geofence befindet oder sich außerhalb des Geofence befindet; und Ausführen, durch den Ortsmanagementserver einer oder mehrerer Handlungen gemäß dem aktuellen Ortszustand des ersten ortskennenden Client.
  10. Verfahren nach Anspruch 9, wobei die eine oder die mehreren Handlungen, die von dem Ortsmanagementserver ausgeführt werden, umfassen: Senden, durch den Ortsmanagementserver, zu einem oder mehreren ortskennenden Clients einschließlich dem ersten ortskennenden Client einer Benachrichtigung zu jedem von dem einen oder den mehreren ortskennenden Clients, wobei die Benachrichtigung den aktuellen Ortszustand des ersten ortskennenden Client mit Bezug auf den Geofence oder einen aktuellen Ort des ersten ortskennenden Client anzeigt.
  11. Verfahren nach Anspruch 10, wobei das Senden der Benachrichtigung umfasst: Speichern, durch den Ortsmanagementserver, eines Dokuments, das die Benachrichtigung anzeigt, in einem Datenbank-Cluster (DB-Cluster), das von dem Ortsmanagementserver erreichbar ist, wobei das Dokument in einem erkennbaren Datenfeld des DB-Clusters gespeichert wird, wobei sich der eine oder die mehreren ortskennenden Clients mit dem Ortsmanagementserver in Reaktion darauf synchronisieren, dass das Dokument in dem erkennbaren Datenfeld gespeichert wird.
  12. Verfahren nach Anspruch 10, wobei der Geofence eine virtuelle Grenze ist, die mit Bezug auf einen Ankerpunkt ausgebildet wird, der von dem Ortsmanagementserver verfolgt wird, wobei der Ankerpunkt entweder stationär oder in Bewegung ist.
  13. Verfahren nach Anspruch 1, weiterhin umfassend: Empfangen, durch den Ortsmanagementserver, einer Anfrage von einem zweiten ortskennenden Client nach den Ortsdaten, die von dem ersten ortskennenden Client gesammelt werden, wobei die Ortsdatensammelkriterien und die Ortsdatenberichtskriterien zu dem ersten ortskennenden Client in Reaktion auf das Empfangen der Anfrage gesendet werden.
  14. Verfahren nach Anspruch 13, wobei das Empfangen der Anfrage von dem zweiten ortskennenden Client nach den Ortsdaten umfasst: Erkennen, durch den Ortsmanagementserver, einer Synchronisation der Anfrage von einer zweiten lokalen Datenbank an dem zweiten ortskennenden Client in ein Datenbank-Cluster (DB-Cluster), das von dem Ortsmanagementserver erreichbar ist.
  15. Verfahren nach Anspruch 13, wobei die Anfrage von dem zweiten ortskennenden Client die Ortsdatensammelkriterien und/oder die Ortsdatenberichtskriterien anzeigt.
  16. Verfahren nach Anspruch 13, wobei die Anfrage von dem zweiten ortskennenden Client eine Definition eines Geofence anzeigt und weiterhin Anweisungen anzeigt, um die Ortsdaten von dem ersten ortskennenden Client gemäß einem aktuellen Ortszustand des ersten ortskennenden Client mit Bezug auf den Geofence zu filtern, wobei der aktuelle Ortszustand anzeigt, ob der erste ortskennende Client in den Geofence eingetreten ist, den Geofence verlassen hat, sich innerhalb des Geofence befindet oder sich außerhalb des Geofence befindet.
  17. Verfahren nach Anspruch 16, weiterhin umfassend: Bestimmen, durch den Ortsmanagementserver, des aktuellen Ortszustands des ersten ortskennenden Client mit Bezug auf den Geofence; und Ausführen der Anweisungen, die durch die Anfrage von dem zweiten ortskennenden Client angezeigt werden.
  18. Verfahren nach Anspruch 16, weiterhin umfassend: Senden, durch den Ortsmanagementserver, der Definition des Geofence und der Anweisungen an den ersten ortskennenden Client.
  19. Verfahren, durch einen ersten ortskennenden Client, umfassend: Empfangen, durch den ersten ortskennenden Client, von Ortsdatensammelkriterien und Ortsdatenberichtskriterien von einem Ortsmanagementserver; Sammeln, durch den ersten ortskennenden Client, von Ortsdaten gemäß Ortsdatensammelkriterien; Speichern, durch den ersten ortskennenden Client, der Ortsdaten in einer ersten lokalen Datenbank an dem ersten ortskennenden Client; und Berichten, durch den ersten ortskennenden Client, wenigstens eines Teils der Ortsdaten an den Ortsmanagementserver gemäß den Ortsdatenberichtskriterien.
  20. Verfahren nach Anspruch 19, weiterhin umfassend: Empfangen, durch den ersten ortskennenden Client, einer Definition eines Geofence, wobei der Geofence eine virtuelle Grenze ist, die mit Bezug auf einen Ankerpunkt ausgebildet wird; und Bestimmen, durch den ersten ortskennenden Client, eines aktuellen Ortszustands des ersten ortskennenden Client mit Bezug auf den Geofence durch Auswerten der Ortsdaten, die durch den ersten ortskennenden Client gesammelt werden, wobei der aktuelle Ortszustand anzeigt, ob der erste ortskennende Client in den Geofence eingetreten ist, den Geofence verlassen hat, sich innerhalb des Geofence befindet oder sich außerhalb des Geofence befindet.
  21. Verfahren nach Anspruch 20, weiterhin umfassend: Empfangen, durch den ersten ortskennenden Client, eines Satzes von Anweisungen von dem Ortsmanagementserver, wobei jede aus dem Satz von Anweisungen mit einem vorbestimmen Ortszustand assoziiert ist; und Ausführen, durch den ersten ortskennenden Client, einer Anweisung aus dem Satz von Anweisungen in Reaktion auf den vorbestimmten Ortszustand der Anweisungen entsprechend dem aktuellen Ortszustand des ersten ortskennenden Client nach Sammeln der Ortsdaten.
  22. Verfahren nach Anspruch 21, wobei der Satz von Anweisungen eine Anordnung enthält, den aktuellen Ortszustand des ersten ortskennenden Client an den Ortsmanagementserver zu berichten.
  23. Verfahren nach Anspruch 21, wobei der Satz von Anweisungen eine Anordnung enthält, wenigstens einen Teil der Ortsdaten gemäß den Ortsdatenberichtskriterien zu berichten.
  24. Verfahren nach Anspruch 21, wobei der Satz von Anweisungen eine Anordnung enthält, eine oder mehrere Handlungen auszuführen, wobei die eine oder die mehreren Handlungen ein Senden einer Nachricht an den Ortsmanagementserver und/oder ein Aufrufen eines Dienstes an dem ersten ortskennenden Client enthalten.
  25. Verfahren nach Anspruch 21, wobei das Empfangen des Satzes von Anweisungen von dem Ortsmanagementserver umfasst: Erkennen, durch den ersten ortskennenden Client, einer Synchronisation des Satzes von Anweisungen von einem DB-Cluster, das von dem Ortsmanagementserver erreichbar ist, in die erste lokale Datenbank.
  26. Verfahren nach Anspruch 21, wobei das Empfangen des Satzes von Anweisungen von dem Ortsmanagementserver umfasst: Empfangen, durch den ersten ortskennenden Client, einer Multicast-Übertragung, die den Satz von Anweisungen enthält.
  27. Verfahren nach Anspruch 26, wobei die Multicast-Übertragung eine eMBMS-Übertragung („Evolved Multimedia Broadcast Multicast Services“) ist.
  28. Verfahren nach Anspruch 20, wobei das Empfangen der Definition des Geofence umfasst: Erkennen, durch den ersten ortskennenden Client, einer Synchronisation der Definition des Geofence von einem DB-Cluster, das für den Ortsmanagementserver erreichbar ist, in die erste lokale Datenbank.
  29. Verfahren nach Anspruch 20, wobei das Empfangen der Ortsdatensammelkriterien und der Ortsdatenberichtskriterien von dem Ortsmanagementserver umfasst: Erkennen, durch den ersten ortskennenden Client, einer Synchronisation der Ortsdatensammelkriterien und der Ortsdatenberichtskriterien von einem DB-Cluster, das für den Ortsmanagementserver erreichbar ist, in die erste lokale Datenbank.
  30. Verfahren nach Anspruch 20, wobei das Empfangen der Ortsdatensammelkriterien und der Ortsdatenberichtskriterien von dem Ortsmanagementserver umfasst: Empfangen, durch den ersten ortskennenden Client, einer Mulitcast-Übertragung, die die Ortsdatensammelkriterien und die Ortsdatenberichtskriterien enthält.
  31. Verfahren nach Anspruch 30, wobei die Mulitcast-Übertragung eine eMBMS-Übertragung („Evolved Mulitmedia Broadcast Mulitcast Services“) ist.
  32. Verfahren nach Anspruch 20, weiterhin umfassend: Empfangen, durch den ersten ortskennenden Client, einer Aktualisierung für die Definition des Geofence.
  33. Verfahren nach Anspruch 32, wobei die Aktualisierung für die Definition des Geofence eine Änderung von Ortskoordinaten des Ankerpunkts, der Form des Geofence, der Größe des Geofence oder eine Kombination davon enthält.
  34. Verfahren nach Anspruch 20, wobei der Ankerpunkt des Geofence statisch ist.
  35. Verfahren nach Anspruch 20, wobei sich der Ankerpunkt des Geofence in Bewegung befindet.
  36. Verfahren nach Anspruch 20, wobei der Geofence von zweidimensionaler Form ist.
  37. Verfahren nach Anspruch 20, wobei der Geofence von dreidimensionaler Form ist.
  38. Ortsmanagementserver, umfassend: einen Prozessor; und ein computerlesbares Speichermedium, das eine Programmierung zur Ausführung durch den Prozessor speichert, wobei die Programmierung Anweisungen enthält zum: Senden von Ortsdatensammelkriterien und Ortsdatenberichtskriterien an einen ersten ortskennenden Client; und Empfangen von Ortsdaten von dem ersten ortskennenden Client, wobei die Ortsdaten von dem ersten ortskennenden Client gemäß den Ortsdatensammelkriterien gesammelt werden, wobei die Ortsdaten von dem ersten ortskennenden Client gemäß den Ortsdatenberichtskriterien empfangen werden.
  39. Ortsmanagementserver nach Anspruch 38, wobei die Programmierung weiterhin Anweisungen enthält zum: Auswerten der Ortsdaten zum Bestimmen eines aktuellen Ortszustands des ersten ortskennenden Client mit Bezug auf einen Geofence; und Ausführen einer Handlung gemäß dem aktuellen Ortszustand des ersten ortskennenden Client.
  40. Ortsmanagementserver nach Anspruch 38, wobei die Programmierung weiterhin Anweisungen enthält zum: Anzeigen einer Definition eines Geofence und von Anweisungen an den ersten ortskennenden Client, wobei die Anweisungen durch den ersten ortskennenden Client in Reaktion darauf ausgeführt werden, dass ein aktueller Ortszustand des ersten ortskennenden Client mit Bezug auf den Geofence bestimmt wird.
  41. Ortsmanagementserver nach Anspruch 38, wobei die Anweisungen zum Senden der Ortsdatensammelkriterien und der Ortsdatenberichtskriterien Anweisungen umfassen zum: Senden einer Multicast-Übertragung, die die Ortsdatensammelkriterien und die Ortsdatenberichtskriterien an eine Vielzahl ortskennender Clients einschließlich dem ersten ortskennenden Client anzeigt.
  42. Ortsmanagementserver nach Anspruch 38, wobei die Anweisung zum Senden der Ortsdatensammelkriterien und der Ortsdatenberichtskriterien Anweisungen umfasst zum: Speichern, durch den Ortsdatenmanagementserver, eines Dokuments, das die Ortsdatensammelkriterien und die Ortsdatenberichtskriterien anzeigt, in einem Datenbank-Cluster (DB-Cluster), das für den Ortsmanagementserver erreichbar ist, wobei das Dokument in einem erkennbaren Datenfeld des DB-Cluster gespeichert wird, wobei sich der erste ortskennende Client mit dem Ortsmanagementserver in Reaktion darauf synchronisiert, dass das Dokument in dem erkennbaren Datenfeld gespeichert wird.
  43. Erster ortskennender Client, umfassend: einen Prozessor; und ein computerlesbares Speichermedium, das eine Programmierung zur Ausführung durch den Prozessor speichert, wobei die Programmierung Anweisungen enthält zum: Empfangen von Ortsdatensammelkriterien und Ortsdatenberichtskriterien von einem Ortsmanagementserver; Sammeln von Ortsdaten gemäß Ortsdatensammelkriterien; Speichern der Ortsdaten in einer ersten lokalen Datenbank des ersten ortskennenden Client; und Berichten wenigstens eines Teils der Ortsdaten an den Ortsmanagementserver gemäß den Ortsdatenberichtskriterien.
  44. Erster ortskennender Client nach Anspruch 43, wobei die Programmierung weiterhin Anweisungen enthält zum: Empfangen einer Definition einer Geofencedefintion und von Anweisungen entsprechend einem aktuellen Ortszustand des ersten ortskennenden Client; und Ausführen der Anweisungen in Reaktion auf ein Bestimmen des aktuellen Ortszustands des ersten ortskennenden Client, wobei der aktuelle Ortszustand durch Auswerten der Ortsdaten bestimmt wird.
DE112016004861.0T 2015-10-23 2016-10-21 System und Verfahren zum Geofencing Pending DE112016004861T5 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201562245876P 2015-10-23 2015-10-23
US62/245,876 2015-10-23
US15/331,559 US9973891B2 (en) 2015-10-23 2016-10-21 System and method for geofencing
US15/331,559 2016-10-21
PCT/US2016/058269 WO2017070574A1 (en) 2015-10-23 2016-10-21 System and method for geofencing

Publications (1)

Publication Number Publication Date
DE112016004861T5 true DE112016004861T5 (de) 2018-07-19

Family

ID=58558094

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112016004861.0T Pending DE112016004861T5 (de) 2015-10-23 2016-10-21 System und Verfahren zum Geofencing

Country Status (4)

Country Link
US (1) US9973891B2 (de)
DE (1) DE112016004861T5 (de)
GB (2) GB2598068B (de)
WO (1) WO2017070574A1 (de)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9723439B2 (en) * 2015-01-26 2017-08-01 Intel IP Corporation Apparatus, system and method of neighbor awareness networking (NAN) geo-fencing
WO2017070551A1 (en) * 2015-10-23 2017-04-27 Kodiak Networks Inc. System and method for content messaging
WO2017171908A1 (en) * 2016-04-01 2017-10-05 Intel Corporation Geo-information reporting for vehicle-to-vehicle sidelink communications
WO2018040007A1 (zh) * 2016-08-31 2018-03-08 华为技术有限公司 构建无线定位特征库的方法及装置
US10536921B1 (en) * 2017-04-04 2020-01-14 Mbit Wireless, Inc. Method and apparatus for providing location information
WO2019117766A1 (en) * 2017-12-12 2019-06-20 Telefonaktiebolaget Lm Ericsson (Publ) First communication device, third communication device, and methods performed thereby to monitor a second communication device comprised in a group of communication devices
US10136296B1 (en) * 2018-03-22 2018-11-20 Coolfire Solutions, Inc. Situational awareness systems and methods
US10743169B2 (en) 2018-03-22 2020-08-11 Coolfire Solutions, Inc. Situational awareness systems and methods
CN108900976A (zh) * 2018-07-10 2018-11-27 宇龙计算机通信科技(深圳)有限公司 一种位置信息上报方法和装置
US11297068B2 (en) 2018-12-18 2022-04-05 At&T Intellectual Property I, L.P. Anchoring client devices for network service access control
US11037450B2 (en) * 2019-01-04 2021-06-15 Ford Global Technologies, Llc Using geofences to restrict vehicle operation
US10803728B1 (en) 2019-04-15 2020-10-13 International Business Machines Corporation Dynamically networked integrated swarm sensor tracking
JP2023533002A (ja) * 2020-07-10 2023-08-01 テレフオンアクチーボラゲット エルエム エリクソン（パブル） ロケーションサービスのための方法及び装置

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6643669B1 (en) 2000-03-14 2003-11-04 Telefonaktiebolaget Lm Ericsson (Publ) Method for optimization of synchronization between a client's database and a server database
EP1490770A4 (de) 2002-02-25 2007-02-28 Siebel Systems Inc Verfahren und system für servergestützte operationen, server-synchronisiert mit einer datenverarbeitungseinrichtung
US7788382B1 (en) 2002-03-26 2010-08-31 Good Technology, Inc. Server initiated synchronization
US20060008256A1 (en) 2003-10-01 2006-01-12 Khedouri Robert K Audio visual player apparatus and system and method of content distribution using the same
KR100678142B1 (ko) * 2004-08-31 2007-02-02 삼성전자주식회사 위치기반 서비스를 제공하는 푸시투토크 방식을 채용한이동통신 시스템 및 그 서비스 구현 방법
FI120165B (fi) 2004-12-29 2009-07-15 Seven Networks Internat Oy Tietokannan synkronointi matkaviestinverkon kautta
EP1708095A1 (de) 2005-03-31 2006-10-04 Ubs Ag Rechnernetzwerksystem zum Aufbauen, Synchronisieren und/oder Betreiben einer zweiten Datenbank aus/mit einer ersten Datenbank sowie Vorgehensweisen hierfür
US7353034B2 (en) * 2005-04-04 2008-04-01 X One, Inc. Location sharing and tracking using mobile phones or other wireless devices
US9154907B2 (en) * 2005-06-21 2015-10-06 Qualcomm Incorporated Efficient periodic location reporting in a radio access network
US8600410B2 (en) * 2005-07-28 2013-12-03 Unwired Planet, Llc Wireless network with adaptive autonomous location push
US7525425B2 (en) 2006-01-20 2009-04-28 Perdiem Llc System and method for defining an event based on relationship between an object location and a user-defined zone
CN101227710B (zh) * 2007-01-18 2012-04-25 华为技术有限公司 定位触发信息的同步方法和设备
US8676242B2 (en) * 2007-02-16 2014-03-18 Qualcomm Incorporated Method and apparatus for registration of location information of wireless devices in a wireless communication network supporting multicast calls
KR20080081665A (ko) * 2007-03-06 2008-09-10 삼성전자주식회사 Ｐｔｔ 이동 단말기와 ｐｔｔ 통신 서비스 시스템 및 그의발신자 위치 표시 방법
CN101355726A (zh) 2007-07-25 2009-01-28 国际商业机器公司 基于多媒体消息传递服务的数据库同步方法和系统
KR101430517B1 (ko) 2008-01-31 2014-08-19 삼성전자주식회사 복수의 데이터 통신장치들 간의 데이터 동기 방법
US8170988B2 (en) 2008-04-17 2012-05-01 The Boeing Company System and method for synchronizing databases
US8750915B2 (en) * 2010-01-05 2014-06-10 Qualcomm Incorporated Exchange of location information using a wireless communication device
US8509806B2 (en) * 2010-12-14 2013-08-13 At&T Intellectual Property I, L.P. Classifying the position of a wireless device
US9654816B2 (en) 2011-11-04 2017-05-16 Cisco Technology, Inc. Synchronizing a video feed with internet content displayed on a second device
US20130194999A1 (en) * 2011-12-28 2013-08-01 Qualcomm Incorporated Client-assisted target multicast area detection
US20160029224A1 (en) * 2014-07-23 2016-01-28 Qualcomm Incorporated Determination of environment characteristics from mobile device-based sensor measurements
US10560814B2 (en) * 2017-02-10 2020-02-11 Harris Corporation Wireless PTT communication system with enhanced location reporting and related devices and methods

Also Published As

Publication number Publication date
GB2564517B (en) 2022-04-20
US20170118592A1 (en) 2017-04-27
GB2598068A (en) 2022-02-16
WO2017070574A1 (en) 2017-04-27
US9973891B2 (en) 2018-05-15
GB201806380D0 (en) 2018-06-06
GB2598068B (en) 2022-05-11
GB202116496D0 (en) 2021-12-29
GB2564517A (en) 2019-01-16

Similar Documents

Publication Publication Date Title
DE112016004861T5 (de) System und Verfahren zum Geofencing
EP3533210B1 (de) Verfahren und gerät zur überwachung eines objekts mit einer hub-cloud-plattform
DE102022202872A1 (de) Neuronales graphennetzwerk und bestärkendes-lernen-techniken zur verbindungsverwaltung
DE112017006109T5 (de) Ptx-kommunikation mit datenanalytikmaschine
DE602004003558T2 (de) Verfahren und Vorrichtung zur Erzeugung einer dynamischen Gruppe - Adresse
DE102019209546A1 (de) Intelligentes Edge-Rechensystem für das Internet of Everything (IoE) für hochzuverlässigen Dienst für das Internet of Things (IoT)
DE112018006458T5 (de) Kommunikationsvorrichtung, kommunikationsverfahren und kommunikationssystem
DE112018003350T5 (de) Vorrichtung und Verfahren zur Echtzeit-Sammlung von beweiserheblichen Daten im Bereich der öffentlichen Sicherheit
DE112017006694B4 (de) Verfahren für Direktmodus-Push-to-Talk-Kommunikationsprotokolle
CN104641690B (zh) 当csg标识符被用于接入控制以外的目的时避免基于csg的接入控制
DE202013012429U1 (de) Erstellen und Teilen von privaten Lokalisierungsdatenbanken
DE112017006603T5 (de) System und verfahren zum bestimmen des timings einer antwort in einer gruppenkommunikation unter verwendung künstlicher intelligenz
US10951497B2 (en) System and method for a service-based interface architecture
DE102014014687A1 (de) Verfahren und Vorrichtung zur Bereitstellung von Diensten an einen geographischen Bereich
Wang et al. Edge intelligence for mission cognitive wireless emergency networks
EP2622896A1 (de) Verfahren zum schutz von persönlichkeitsdaten bei netzmonitoring mit kunden-terminals.
DE102012203463B4 (de) Verfahren zur Bereitstellung von Web Services eines mobilen Web Service Providers
DE202016007834U1 (de) Erfassen des Benutzerkontexts unter Verwendung drahtloser Signalmerkmale
DE102021114298B4 (de) Konfiguration von Funkressourcen-Parametern
EP2779744A1 (de) Verfahren zur Veränderung der einem Telekommunikationsendgerät zugeordneten Dienstqualität und System, umfassend ein Telekommunikationsendgerät und ein Telekommunikationsnetz, zur Veränderung der dem Telekommunikationsendgerät zugeordneten Dienstqualität
DE112021002671T5 (de) Ki-basierte mobilfunknetzverwaltung und -orchestrierung
CN109784680A (zh) 外业现场访点行为与应急调度管理系统
Wang et al. An application-driven heterogeneous internet of things integration architecture
Piedrafita et al. The digital ‘connected’earth: Open technology for providing location-based services on degraded communication environments
Owais et al. On Accommodating VR Traffic for mHealth Applications in Rural Areas with Limited Impact on IoT Traffic

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication