IT202000023833A1

IT202000023833A1 - Location-based publication over a cellular network

Info

Publication number: IT202000023833A1
Application number: IT102020000023833A
Authority: IT
Inventors: Jean-Luc Descombes; Luca Ceva; Paolo Giuseppetti
Original assignee: Vodafone Automotive S P A
Priority date: 2020-10-09
Filing date: 2020-10-09
Publication date: 2022-04-09
Also published as: EP3982648C0; ES2972108T3; US11956325B2; EP3982648B1; EP3982648A1; US20220116465A1

Description

PUBBLICAZIONE BASATA SULLA LOCALIZZAZIONE SU UNA RETE CELLULARE

Campo dell'invenzione

Un metodo ed un sistema per l'uso in una rete cellulare che fornisce pubblicazioni basate sulla localizzazione utilizzando un protocollo di pubblicazione/abbonamento. Il metodo e il sistema utilizza un geohash all'interno dell'argomento per ogni abbonamento e pubblicazione, al fine di consegnare messaggi geograficamente rilevanti agli abbonati.

Sfondo dell'invenzione

Con l'aumento della prevalenza dei dispositivi mobili e dei dispositivi connessi ai dati, aumenta la necessit? di una geocasting efficiente ed efficace dei messaggi. Il geocasting descrive la consegna di informazioni o messaggi a una o pi? destinazioni in una rete, sulla base di quelle che hanno un interesse per una particolare posizione geografica. Il geocasting pu? essere desiderato in varie applicazioni, tra cui la fornitura di allarmi di sicurezza relativi a una specifica area geografica (allarmi per inondazioni o terremoti, ad esempio), la fornitura di informazioni locali (anche meteorologiche o commerciali), o in relazione ai trasporti (allarmi per la congestione del traffico stradale o perturbazioni dei trasporti, ad esempio). In un esempio particolare, l'applicazione del geocasting pu? essere particolarmente utile nell'era emergente dei veicoli autonomi (e dei nuovi servizi che accompagneranno questa rivoluzione tecnologica), e in cui la comunicazione tra veicoli geograficamente locali o tra veicoli e infrastrutture sulla base di una localit? rilevante ? un elemento chiave. A causa della natura di tali applicazioni, tuttavia, l'area geografica pi? rilevante locale per un utente pu? cambiare regolarmente.

I metodi di arte preventiva forniscono varie soluzioni per la messaggistica basata sulla localizzazione. Ad esempio, una soluzione relativa a "nodi e vie" (https://www.ericsson.com/en/blog/2020/5/geocasting-cellular-v2x-communication, accesso del 23 giugno 2020) pu? fornire messaggi agli utenti che si trovano in un segmento stradale specifico e che viaggiano in una direzione specifica. Tuttavia, la soluzione richiede un'infrastruttura complessa (in relazione all'application server, alle interfacce di programmazione delle applicazioni (API), alle regioni di interesse per il calcolo, alle mappe, ecc. ) con i messaggi che devono essere elaborati dall'application server, il che aumenterebbe i costi e i tempi per l'introduzione di tale servizio.

Altre proposte si avvalgono di un modello di pubblico/abbonamento per l'invio di messaggi. Ad esempio, la pubblicazione del brevetto europeo n. EP2893675 descrive un sistema e un metodo in cui un abbonamento viene ricevuto su un server, insieme alla posizione del centro di abbonamento e al raggio di ricezione delle pubblicazioni. Il server traduce questa area di ricezione in un geohash. Il server riceve inoltre una pubblicazione, inclusa la posizione della pubblicazione, e quindi utilizza il geohash determinato in relazione all'abbonamento per identificare gli abbonati a ricevere la pubblicazione, in base al fatto che la posizione della pubblicazione si trovi o meno nell'area geografica rappresentata dal geohash. Ci? richiede tuttavia la personalizzazione dell'application server e, in considerazione del ruolo dell'application server, pu? essere difficile da scalare in modo da geocastrare un gran numero di messaggi diversi ai singoli utenti. Una soluzione simile ? descritta nella pubblicazione del brevetto USA n. US 2016/165407.

Un sistema ideale per la geocasting dei messaggi sar? semplice da implementare e scalare all'interno di una rete cellulare. Inoltre, il sistema sar? efficiente, invier? i messaggi solo ai dispositivi dell'utente a cui sono pertinenti e dovrebbe essere in grado di instradare i messaggi senza analizzarli. Tuttavia, il sistema sar? potenzialmente in grado di supportare la multicasting di un gran numero di messaggi a pi? utenti. Pertanto, l'invenzione attualmente descritta sembra risolvere questi inconvenienti.

Sintesi dell'invenzione

Qui viene descritto un dispositivo client e un server che fa parte di un sistema (e che deve essere utilizzato all'interno di un metodo) per l'abbonamento e la pubblicazione di pubblicazioni basate sulla localizzazione su una rete cellulare. In particolare, c'? un dispositivo client per l'abbonamento a pubblicazioni basate sulla localizzazione, e un server per la ricezione e la gestione degli abbonamenti e per l'invio delle pubblicazioni agli abbonati corrispondenti. Il metodo e il sistema associa gli abbonati alle pubblicazioni abbinando il nome di un abbonamento al nome di una pubblicazione. Ognuno dei nomi di abbonamento e di pubblicazione comprende un geohash, in alcuni casi di lunghezza diversa, che pu? essere confrontato in modo da identificare se una pubblicazione si riferisce all'area geografica indicata in un abbonamento. Il dispositivo client pu? calcolare direttamente il geohash per un'area geografica rilevante per il suo utente, per il successivo utilizzo in uno o pi? abbonamenti. In alcuni casi, il geohash in abbonamento (e alcune delle sue caratteristiche) sono determinati in base alla velocit? e alla direzione del movimento del dispositivo client.

In un primo aspetto, viene descritto un dispositivo client per l'uso in una rete cellulare che fornisce pubblicazioni basate sulla localizzazione utilizzando un protocollo di pubblicazione/abbonamento, comprendente almeno un processore e almeno una memoria di memorizzazione delle istruzioni del codice di programma, in cui l'esecuzione delle istruzioni del codice di programma nel processore causa il dispositivo client:

determinare una posizione geografica significativa per il dispositivo client; determinare un geohash in abbonamento, per identificare un'area che comprenda la posizione geografica significativa per il dispositivo client;

inviare un abbonamento a un server, l'abbonamento che ha un nome di abbonamento che comprende il geohash di abbonamento.

Un dispositivo client pu? essere qualsiasi dispositivo adatto ad ospitare un client di un protocollo di messaggistica di pubblicazione/abbonamento. Il dispositivo client pu? essere, ad esempio, un dispositivo mobile o un'apparecchiatura utente. Pi? specificamente, il dispositivo client pu? essere un telefono cellulare o un laptop, o pu? far parte di un sistema di controllo per un altro strumento (ad esempio un veicolo). Sebbene il dispositivo client possa essere mobile (ad esempio, progettato per essere facilmente spostato o trasportato da un utente in luoghi diversi), il dispositivo client potrebbe anche essere fisso o non specificamente progettato per essere spostato facilmente e frequentemente (come un personal computer desktop).

Le pubblicazioni basate sulla localizzazione descrivono i messaggi che vengono inviati a uno o pi? dispositivi client in base alla posizione o alla posizione geografica associata al dispositivo. Le pubblicazioni basate sulla localizzazione possono anche essere conosciute come geocasting, che descrive la consegna di informazioni a una destinazione o a un gruppo di destinazioni in una rete, identificate dalla loro posizione geografica. Ad esempio, un primo messaggio pu? essere inviato ad un primo gruppo di utenti associati ad una prima posizione geografica, e un secondo messaggio pu? essere inviato ad un secondo gruppo di utenti associati ad una seconda, diversa posizione geografica. Alcuni, o addirittura tutti, il primo e il secondo gruppo di utenti possono essere uguali o diversi.

Il protocollo Publish/subscribe protocol (o publish/subscribe messaging o publish/subscribe pattern) ? un paradigma di messaggistica in cui i mittenti dei messaggi, chiamati publisher, non programmano i messaggi da inviare direttamente a specifici destinatari, chiamati subscribers. Al contrario, essi suddividono i messaggi pubblicati in classi, senza sapere quali abbonati, se ce ne sono, possono essere. Analogamente, gli abbonati esprimono interesse per una o pi? classi e ricevono solo messaggi di interesse, senza sapere quali siano gli eventuali editori. In quanto tale, ogni abbonamento e pubblicazione identifica una classe (o argomento) e, associando la classe (o argomento) della pubblicazione con quella di un abbonamento, il messaggio e l'abbonamento vengono abbinati. Esempi di protocolli di pubblicazione/abbonamento includono il Message Queuing Telemetry Transport (MQTT) e l'Advanced Message Queuing Protocol (AMQP).

Una posizione geografica significativa per il dispositivo client pu? essere determinata attraverso qualsiasi informazione di localizzazione inviata, ricevuta o generata sul dispositivo client. In particolare, la posizione geografica significativa per il dispositivo client pu? essere la posizione geografica del dispositivo client (ad esempio, identificata da un sistema di navigazione o di posizionamento all'interno del dispositivo, o immessa dall'utente, o ricevuta da una misurazione in altri elementi del sistema). Tuttavia, la posizione geografica significativa per il dispositivo client potrebbe anche essere un'altra posizione geografica di interesse per l'utente del dispositivo client, e l'input sul dispositivo client tramite qualsiasi altro mezzo. Ad esempio, il dispositivo client potrebbe essere un dispositivo mobile, e la posizione geografica significativa per il dispositivo client potrebbe essere l'indirizzo di casa dell'utente (come input dell'utente, o comunicato da applicazioni di navigazione in altre parti del dispositivo). Anche se la posizione geografica significativa per il dispositivo client non ? la posizione corrente del dispositivo mobile, pu? essere una posizione per la quale l'utente del dispositivo desidera ricevere messaggi o avvisi pubblicati.

Nell'esempio descritto, l'abbonamento inviato dal dispositivo client include un nome di abbonamento, che identifica la classe o l'argomento dell'abbonamento. Il nome dell'abbonamento comprende un geohash, qui etichettato come geohash dell'abbonamento. Il geohash ? una stringa di caratteri alfanumerici in grado di identificare una localit? con una precisione potenzialmente illimitata (a seconda della lunghezza del geohash). Il geohash in abbonamento utilizzato all'interno del nome dell'abbonamento ? calcolato dal dispositivo client per rappresentare un'area in cui si trova la posizione geografica significativa per il dispositivo client. Il geohash in abbonamento pu? essere calcolato sul dispositivo client utilizzando varie biblioteche disponibili al pubblico.

Vantaggiosamente, la presente invenzione fa parte di un sistema per la messaggistica basata sulla localizzazione che ? altamente scalabile (in quanto l'elaborazione per l'identificazione del geohash successivamente utilizzato per la messaggistica basata sulla localizzazione ? implementata sul dispositivo client) e che ? efficiente. Inoltre, l'utilizzo di un geohash direttamente all'interno della classe o dell'argomento dell'abbonamento permette di fare affidamento sulle tecniche di protocollo di pubblico/abbonamento esistenti, senza la necessit? di complesse personalizzazioni o l'implementazione di calcoli aggiuntivi sul server.

Preferibilmente, il geohash di abbonamento ? una struttura di dati gerarchica specificata a un livello di abbonamento. Come sar? inteso dalla persona competente, il geohash ? una stringa alfanumerica, che pu? includere (o essere specificata a) un numero qualsiasi di caratteri. Ogni carattere aggiuntivo del geohash denota un'ulteriore suddivisione di un'area geografica pi? ampia. Pertanto, un geohash pi? corto (con meno caratteri, o specificato ad un livello superiore nella struttura gerarchica) rappresenta un'area geografica pi? ampia rispetto ad una stringa di geohash pi? lunga (con pi? caratteri, o specificato ad un livello inferiore nella struttura gerarchica). In quanto tale, ogni carattere aggiuntivo all'interno del geohash pu? essere considerato come il geohash specificato ad un livello aggiuntivo (inferiore) della struttura gerarchica dei dati. Il livello di specificazione a cui viene specificato un geohash in abbonamento indica il numero totale di caratteri all'interno del geohash in abbonamento.

Preferibilmente, l'esecuzione delle istruzioni del codice di programma nel processore provoca ulteriormente il dispositivo client:

determinare una velocit? del dispositivo client; e

determinare il livello di abbonamento in base alla velocit?. In altre parole, il livello a cui viene specificato il geohash (e quindi la precisione a cui viene identificata la posizione geografica significativa per il dispositivo client nel nome dell'abbonamento) ? correlata alla velocit? del dispositivo client. La velocit? del dispositivo client pu? essere una velocit? istantanea misurata o una velocit? media, oppure pu? essere un parametro ricevuto al dispositivo (ad esempio, da una misurazione in un altro elemento del sistema). Il livello di specifica pu? essere determinato in base alla velocit? mediante una relazione predefinita. Ad esempio, si pu? determinare una velocit? all'interno di intervalli predeterminati, con ciascun intervallo associato ad un diverso livello di specifica. In un esempio particolare, una velocit? all'interno di una gamma di velocit? inferiori pu? essere associata ad un livello di abbonamento relativamente pi? basso (quindi avere pi? caratteri all'interno del geohash), rispetto ad una velocit? all'interno di una gamma di velocit? superiori che pu? essere associata ad un livello di abbonamento relativamente pi? alto (quindi avere relativamente meno caratteri all'interno del geohash). Vantaggiosamente, ci? significa che un dispositivo client che si muove a velocit? pi? elevata (e quindi che percorre una distanza maggiore entro un certo tempo) pu? essere abbonato a pubblicazioni relative a un'area relativamente pi? ampia rispetto a un dispositivo client che si muove a velocit? relativamente pi? bassa (e quindi percorre una distanza minore entro lo stesso periodo di tempo).

Preferibilmente, il dispositivo client che viene indirizzato per determinare un geohash in abbonamento comprende anche il dispositivo client che viene indirizzato per determinare un geohash in abbonamento specificato al livello di abbonamento, e in cui il nome dell'abbonamento include un numero predefinito di caratteri, in cui tutti i caratteri del numero predefinito di caratteri che non sono compilati dal geohash in abbonamento specificato al livello di abbonamento vengono riempiti con un carattere jolly. In altre parole, il geohash di abbonamento ? specificato per una data lunghezza (il "livello di abbonamento"). Tuttavia, la classe o la stringa di argomento richiesta all'interno di un abbonamento pu? essere di una lunghezza predefinita, che pu? essere diversa (in particolare, pi? lunga) dal geohash abbonamento. In questo caso, tutti i caratteri all'interno della classe o della stringa di argomento che superano il numero di caratteri del geohash di abbonamento possono essere riempiti con un carattere jolly (come '+' o un altro carattere, a seconda del protocollo particolare). Come tale, diversi geohash di abbonamento possono essere specificati a diversi livelli ed essere comunque inclusi all'interno di un abbonamento.

inviare una richiesta al server per annullare l'abbonamento con un nome di abbonamento comprendente il geohash di abbonamento. La posizione geografica precedentemente considerata rilevante per il dispositivo client potrebbe non essere pi? rilevante dopo un certo periodo di tempo. Ad esempio, se il dispositivo client cambia posizione. Come tale, l'utente del dispositivo client potrebbe voler annullare l'iscrizione alle pubblicazioni con il nome di abbonamento comprendente il nome di abbonamento precedentemente identificato. Per fare questo, il dispositivo client invia una richiesta di cancellazione che include il nome di abbonamento comprendente il geohash di abbonamento all'interno della classe o della stringa dell'argomento. Beneficiariamente, ci? fornisce al dispositivo client un meccanismo efficiente per gestire gli abbonamenti e per evitare la ricezione di pubblicazioni a "vecchi" abbonamenti (e relativi a regioni geografiche che non sono pi? di interesse) dopo che non sono pi? rilevanti.

determinare uno o pi? geohash aggiuntivi in abbonamento, che rappresentano una o pi? aree geografiche confinanti con l'area geografica rappresentata dal geohash in abbonamento; e

inviare una o pi? sottoscrizioni aggiuntive al server, ognuna delle quali ha un nome di sottoscrizioni aggiuntive con un rispettivo nome di sottoscrizioni che comprende uno diverso di uno o pi? geohash di sottoscrizioni aggiuntive. I geohash aggiuntivi in abbonamento rappresentano ciascuno aree adiacenti, vicine, limitrofe o confinanti con il geohash in abbonamento originale che ? stato determinato in azioni precedenti. ? stato possibile identificare un numero qualsiasi di geohash in abbonamento aggiuntivo. In un esempio particolare, sono stati determinati otto geohash in abbonamento aggiuntivi, uno per ciascuna delle aree di geohash a nord, nord-est, est, sud-est, sud-est, sud, sud-ovest, ovest e nord-ovest del geohash in abbonamento originale, in modo da formare una griglia di geohash con il geohash in abbonamento originale al centro. In questo modo, gli abbonamenti vengono effettuati in aree che circondano il geohash originale in abbonamento, garantendo cos? la ricezione delle pubblicazioni relative alle immediate vicinanze del dispositivo client e dell'area circostante. Ci? pu? essere particolarmente vantaggioso quando il dispositivo client ? in movimento, in quanto il cliente continuer? a ricevere le pubblicazioni pertinenti, anche dopo piccoli cambiamenti nella sua posizione geografica.

Preferibilmente, l'esecuzione delle istruzioni del codice di programma nel processore fa s? che il dispositivo client, prima di determinare uno o pi? geohash aggiuntivi in abbonamento, provochi ulteriormente il dispositivo client:

determinare una direzione di movimento del dispositivo client; e

in cui una o pi? aree geografiche confinanti con l'area geografica rappresentata dal geohash in abbonamento sono una o pi? aree geografiche in base alla direzione di movimento determinata del dispositivo client. La direzione del movimento pu? essere espressa come vettore e pu? rappresentare una direzione di movimento del dispositivo client tra una prima e una seconda volta, oppure pu? rappresentare una direzione istantanea misurata o ricevuta dal dispositivo client. In altre parole, l'una o pi? aree geografiche vicine all'area geografica rappresentata dal geohash originale in abbonamento sono aree allineate lungo un vettore nella direzione del movimento del dispositivo client. In un esempio, l'una o pi? aree geografiche vicine possono essere una prima area vicina che confina con l'area geografica rappresentata dal geohash originale in direzione del movimento, in modo tale che un vettore che si estende tra il centro dell'area geografica rappresentata dal geohash originale in abbonamento e il centro della prima area vicina ? un vettore che rappresenta la direzione del movimento. L'una o pi? aree geografiche limitrofe possono inoltre includere una seconda area limitrofa confinante con la prima area limitrofa in direzione del movimento, in modo tale che un vettore che si estende tra il centro dell'area geografica rappresentata dal geohash originale in abbonamento, il centro della prima area limitrofa e il centro della seconda area limitrofa sia un vettore in direzione del movimento. In questo modo si pu? determinare un numero qualsiasi di aree limitrofe. Beneficiariamente, questa azione estrapola efficacemente il percorso previsto per un dispositivo client in movimento, e quindi si abbona per ricevere le pubblicazioni relative alle aree che si trovano su quel percorso futuro. In questo modo, messaggi o avvisi utili basati sulla localizzazione possono essere ricevuti da un dispositivo client prima che il dispositivo client si trovi nelle immediate vicinanze a cui si riferiscono le pubblicazioni, e quindi il dispositivo client pu? ricevere un avviso preventivo di problemi relativi alle aree geografiche che si trovano nelle vicinanze (congestione del traffico, avvisi meteorologici, ecc.).

Opzionalmente, il dispositivo client pu? essere configurato su:

determinare una direzione di marcia del dispositivo client;

determinare uno o pi? geohash aggiuntivi in abbonamento, che rappresentino una o pi? aree geografiche in direzione di marcia del dispositivo client e/o confinanti con l'area geografica rappresentata dal geohash in abbonamento; e

inviare una o pi? sottoscrizioni aggiuntive al server, ognuna delle quali ha un nome di sottoscrizioni aggiuntive con un rispettivo nome di sottoscrizioni che comprende uno diverso di uno o pi? geohash di sottoscrizioni aggiuntive.

inviare al server una richiesta di disiscrizione dall'abbonamento con il nome di abbonamento comprendente il geohash di abbonamento, e/o di disiscrizione dall'abbonamento con almeno uno o pi? abbonamenti aggiuntivi aventi il rispettivo nome di abbonamento comprendente il diverso o pi? geohash di abbonamento aggiuntivo. Il dispositivo client pu? inviare una richiesta di cancellazione dall'abbonamento con un nome di abbonamento comprendente il geohash di abbonamento originale, o di cancellazione da uno o pi? degli abbonamenti aggiuntivi comprendenti i geohash aggiuntivi, e relativi ad aree limitrofe. In questo modo, poich? le aree geografiche non sono pi? rilevanti per un dispositivo client (ad esempio, perch? il dispositivo client si sta spostando e si allontana da un'area precedentemente rilevante), il dispositivo client pu? annullare l'abbonamento a questi "vecchi" abbonamenti.

Preferibilmente, l'esecuzione delle istruzioni del codice di programma sul processore fa s? che il dispositivo client ripeta ulteriormente i passi dopo lo scadere di un intervallo di tempo. In altre parole, ciascuna delle azioni sopra descritte, che si svolgono nel dispositivo client, pu? essere ripetuta (dopo lo scadere di un intervallo di tempo, o periodicamente), al fine di sottoscrivere un nuovo abbonamento comprendente un nuovo geohash di abbonamento relativo ad una nuova area geografica. Possono essere inviate anche nuove sottoscrizioni aggiuntive relative ad aree geografiche limitrofe all'area rappresentata dal nuovo geohash in abbonamento. Le azioni possono essere ripetute periodicamente, in modo che gli abbonamenti possano essere regolarmente aggiornati in modo da riferirsi alle aree geografiche pi? rilevanti per il dispositivo client in un determinato momento. Ci? pu? essere particolarmente vantaggioso quando il dispositivo client si sposta, in quanto consente di inviare nuovi abbonamenti dal dispositivo client man mano che il cliente si sposta in nuove aree geografiche.

Nel caso in cui le azioni si ripetano, pu? essere particolarmente vantaggioso che il dispositivo client invii sia nuove sottoscrizioni sia una richiesta di cancellazione delle "vecchie" sottoscrizioni che si riferiscono ad aree che non sono pi? di interesse per il dispositivo client. In un esempio particolare, l'esecuzione delle istruzioni del codice di programma presso l'elaboratore pu? indurre il dispositivo client a sottoscrivere nuove sottoscrizioni relative ad aree geografiche in avanti del dispositivo (cio? in avanti rispetto ad una posizione attuale del dispositivo client e seguendo una determinata direzione di movimento), e a cancellare le sottoscrizioni relative ad aree geografiche indietro del dispositivo (cio? indietro rispetto alla posizione attuale del dispositivo client e seguendo una determinata direzione di movimento). In questo modo, solo le pubblicazioni pi? rilevanti dovrebbero essere ricevute nel dispositivo client. Inoltre, il dispositivo client pu? gestire gli abbonamenti in base alla sua posizione in modo "automatico", senza l'intervento dell'utente.

determinare una velocit? del dispositivo client; e

determinare l'intervallo di tempo in funzione della velocit?. La velocit? pu? essere misurata sul dispositivo client, o altrimenti ricevuta come misura da un altro elemento del sistema, o con qualsiasi altro mezzo ragionevole. L'intervallo di tempo (ad esempio, tra le ripetizioni di ciascuna azione sul dispositivo client, come discusso in precedenza) pu? essere correlato alla velocit? da una relazione o da un algoritmo predeterminato. In un esempio particolare, l'intervallo di tempo pu? essere relativamente pi? breve per velocit? relativamente pi? elevate. Di conseguenza, il periodo di tempo che intercorre tra gli aggiornamenti della determinazione di una posizione geografica significativa per il dispositivo client, e quindi per la sottoscrizione delle relative sottoscrizioni, sar? pi? breve quando il dispositivo client si muove a velocit? pi? elevate. Ci? dovrebbe evitare che il dispositivo client percorra una distanza troppo grande tra un aggiornamento e l'altro, e quindi aiutare a mantenere solo gli abbonamenti rilevanti da parte del dispositivo client.

Preferibilmente, uno o pi? geohash aggiuntivi in abbonamento e il geohash in abbonamento sono una prima serie di uno o pi? geohash in abbonamento e, dopo la ripetizione dei passi sopra descritti dopo lo scadere di un intervallo di tempo, un determinato ulteriore geohash aggiuntivo in abbonamento e un ulteriore geohash in abbonamento sono una seconda serie di uno o pi? geohash in abbonamento, in cui l'esecuzione delle istruzioni del codice di programma nel processore fa ulteriormente s? che il dispositivo client:

confronti il primo set di uno o pi? geohash in abbonamento con il secondo set di uno o pi? geohash in abbonamento; e

invii una richiesta al server per la cancellazione di uno o pi? abbonamenti aventi il nome dell'abbonamento comprendente uno o pi? geohash di abbonamento che si trovano all'interno del primo set di uno o pi? geohash di abbonamento ma non all'interno del secondo set di uno o pi? geohash di abbonamento. In altre parole, ad ogni ripetizione delle azioni sul dispositivo client descritto sopra, un nuovo set di uno o pi? abbonamenti viene inviato al server dal dispositivo client. Il dispositivo client pu? confrontare un nuovo set di abbonamenti con un precedente set di abbonamenti e mantenere solo gli abbonamenti che si trovano in entrambi i set di abbonamenti o solo nel nuovo set di abbonamenti. Eventuali abbonamenti che si trovano solo all'interno del precedente set di abbonamenti possono essere cancellati (inviando una richiesta di cancellazione dell'abbonamento dal dispositivo client al server). In questo modo, vengono mantenute solo le sottoscrizioni pi? rilevanti e aggiornate.

Preferibilmente, l'esecuzione delle istruzioni del codice di programma nel processore fa s? che il dispositivo client riceva inoltre, dal server, un messaggio corrispondente all'abbonamento. In tal modo, una pubblicazione da parte del server ad un abbonamento associato al dispositivo client, sar? ricevuta dal dispositivo client. Il dispositivo client pu? quindi analizzare il carico utile della pubblicazione. In questo modo, il messaggio del carico utile pu? essere visualizzato all'utente sul dispositivo client, o in altro modo attivato.

In un secondo aspetto, viene descritto un server per l'uso in una rete cellulare che fornisce pubblicazioni basate sulla localizzazione utilizzando un protocollo di pubblicazione/abbonamento, comprendente almeno un processore e almeno una memoria che memorizza le istruzioni del codice di programma, in cui l'esecuzione delle istruzioni del codice di programma nel processore causa il server:

ricevere un abbonamento da un dispositivo client, l'abbonamento con un nome di abbonamento comprendente un geohash di abbonamento. Il server pu? ricevere un abbonamento dal dispositivo client con un geohash di abbonamento composto da un nome di abbonamento come parte della classe o della stringa di argomenti della richiesta di abbonamento. Il server non ? tenuto ad effettuare ulteriori calcoli in relazione alla posizione del dispositivo client o alla determinazione di eventuali geohash aggiuntivi relativi al dispositivo client. Di conseguenza, le fasi di calcolo per ottenere l'instradamento basato sulla posizione sono intraprese principalmente come azioni sul dispositivo client, piuttosto che sul server.

Preferibilmente, l'esecuzione delle istruzioni del codice di programma nel processore provoca ulteriormente il server:

ricevere un messaggio per la pubblicazione ad un abbonamento corrispondente, il messaggio con il nome della pubblicazione comprendente un geohash di pubblicazione; determinare se l'abbonamento ? un abbonamento corrispondente; e

se l'abbonamento ? un abbonamento corrispondente, inviare il messaggio al dispositivo client;

in cui il geohash di sottoscrizione e il geohash di pubblicazione sono strutture di dati gerarchiche specificate ad un rispettivo livello, e la sottoscrizione ? una sottoscrizione corrispondente quando, ad ogni livello che sia il geohash di pubblicazione che il geohash di sottoscrizione sono specificati, il geohash di pubblicazione ad un dato livello corrisponde al geohash di sottoscrizione allo stesso livello. Ogni pubblicazione ricevuta sul server include un geohash di pubblicazione compreso all'interno del nome della pubblicazione che costituisce la classe o la stringa di argomenti del pacchetto del messaggio di pubblicazione. Il geohash di pubblicazione ? un'indicazione dell'area geografica in cui il messaggio deve essere consegnato. In linea di principio, il geohash di pubblicazione pu? essere specificato a qualsiasi livello (in altre parole, con qualsiasi numero di caratteri) a seconda della dimensione dell'area geografica richiesta per la distribuzione. Tuttavia, in particolare nell'ambito di un'implementazione di esempio in MQTT, il geohash di pubblicazione ha un numero predefinito di caratteri ed ? specificato a un livello predeterminato.

In qualsiasi implementazione, una volta ricevuta una pubblicazione sul server, il server confronta il geohash della pubblicazione all'interno del nome della pubblicazione con il geohash della sottoscrizione all'interno del nome della sottoscrizione di ogni sottoscrizione registrata. Se il geohash corrisponde, l'abbonamento ? considerato corrispondente alla pubblicazione e il server invia la pubblicazione al dispositivo client associato all'abbonamento corrispondente.

Una corrispondenza tra il geohash di pubblicazione e quello di sottoscrizione non richiede necessariamente che siano identici (anche se il geohash di pubblicazione e quello di sottoscrizione sarebbero identici). In particolare, il server confronta ogni livello (ogni carattere) nei due geohash. Nella misura in cui sia il geohash delle pubblicazioni che quello delle sottoscrizioni sono specificati a un determinato livello, il carattere deve essere lo stesso a quel determinato livello sia nel geohash delle pubblicazioni che in quello delle sottoscrizioni perch? i due geohash corrispondano. Se uno dei due geohash di pubblicazione o di sottoscrizione ? specificato ad un livello pi? lungo dell'altro (in altre parole, un geohash ? pi? lungo dell'altro), allora i caratteri extra specificati nel geohash pi? lungo non sono considerati nel confronto.

Come gi? detto, in un'implementazione specifica di esempio all'interno di MQTT, il geohash di pubblicazione sarebbe sempre composto da un numero predefinito di caratteri. Il numero di caratteri predefinito sarebbe pari al numero massimo possibile di caratteri nel georash di abbonamento. In altre parole, il geohash in abbonamento pu? comprendere lo stesso numero di caratteri del geohash di pubblicazione, o un numero inferiore di caratteri. In questo caso, l'abbonamento ? un abbonamento corrispondente quando, ad ogni livello che il geohash di abbonamento ? specificato, il carattere del geohash di pubblicazione corrisponde al carattere del geohash di abbonamento allo stesso livello.

Beneficiariamente, ci? consente al server di utilizzare i meccanismi tipici del protocollo di pubblicazione/abbonamento (confrontando la classe o la stringa di argomenti di una pubblicazione e l'abbonamento), ma senza calcoli aggiuntivi relativi alla posizione geografica prevista o al raggio di una pubblicazione o di un abbonamento. In quanto tale, un messaggio pu? essere geocastato sul server senza significativi oneri aggiuntivi rispetto alla tipica messaggistica di pubblicazione/abbonamento.

Preferibilmente, il livello di pubblicazione definisce l'area geografica per la pubblicazione del messaggio e il livello di abbonamento definisce l'area geografica per l'abbonamento. Il numero di caratteri inclusi nel geohash di pubblicazione, e il numero di caratteri inclusi nel geohash di abbonamento, determinano la precisione del geohash, e quindi la dimensione dell'area geografica identificata dal geohash. Il livello di specificazione ? legato al numero di caratteri, per cui un livello superiore della struttura gerarchica dei dati del geohash ? rappresentato da un numero inferiore di caratteri nella stringa del geohash. In quanto tale, l'impostazione del livello di specifica per il geohash di abbonamento o di pubblicazione fornisce una tecnica semplice per impostare l'area geografica di un abbonamento o di una pubblicazione corrispondente.

Preferibilmente, il livello di pubblicazione ? diverso dal livello di abbonamento.

Generalmente, sia il geohash di pubblicazione che quello di sottoscrizione possono essere specificati ad un livello inferiore o superiore, anche se in un'implementazione specifica di esempio all'interno di MQTT, il geohash di pubblicazione sar? specificato allo stesso livello o ad un livello inferiore rispetto al geohash di sottoscrizione. In alternativa, il livello di pubblicazione e di sottoscrizione pu? essere lo stesso.

Preferibilmente, il nome dell'abbonamento comprende un numero predefinito di caratteri, e in cui tutti i caratteri del numero predefinito di caratteri che non sono compilati dal geohash dell'abbonamento specificato al livello di abbonamento vengono riempiti con un carattere jolly e/o;

in cui il nome della pubblicazione include il numero predefinito di caratteri, e in cui tutti i caratteri del numero predefinito di caratteri che non sono compilati dal geohash di pubblicazione specificato al livello di abbonamento vengono riempiti con un carattere jolly. I nomi di abbonamento e di pubblicazione possono avere lo stesso numero predefinito di caratteri. Come indicato sopra, il geohash di pubblicazione e di sottoscrizione pu? essere specificato a qualsiasi livello, e pu? essere specificato a livelli diversi. All'interno di un dato sistema, la stringa della classe o dell'argomento (in cui il nome della pubblicazione o dell'abbonamento ? incluso nel pacchetto del messaggio) pu? avere un numero fisso di caratteri. Questo determina la lunghezza prevista per il nome della pubblicazione o dell'abbonamento. In questo caso, tutti i caratteri del nome della pubblicazione o dell'abbonamento che non sono pieni di caratteri del geohash della pubblicazione o dell'abbonamento possono includere un carattere jolly predefinito (incluso, ma non limitato a '+'). Come tale, il server pu? gestire e confrontare gli abbonamenti e le pubblicazioni con un rispettivo nome di abbonamento o di pubblicazione comprendente geohash di lunghezza diversa.

In un esempio specifico di implementazione in MQTT, il nome della pubblicazione non pu? includere caratteri jolly. In questo caso, il geohash di pubblicazione includer? sempre un certo numero di caratteri, in modo da "riempire" i caratteri del nome della pubblicazione. Tuttavia, il nome dell'abbonamento pu? includere caratteri jolly all'interno di questa specifica implementazione di esempio in MQTT.

ricevere una richiesta dal dispositivo client per annullare l'abbonamento con il nome dell'abbonamento;

annullare l'iscrizione del dispositivo client all'abbonamento con il nome dell'abbonamento. In altre parole, al ricevimento di una richiesta da un dispositivo client che include un nome di abbonamento, il server cancella il client associato a quel dispositivo client dall'abbonamento di quel nome. In quanto tale, il server non invia pi? al dispositivo client associato alcuna pubblicazione ricevuta sul server e avente un nome di pubblicazione corrispondente al nome di abbonamento dell'abbonamento non sottoscritto.

In un terzo aspetto, viene descritto un sistema che comprende:

il dispositivo client, come descritto; e

il server, come descritto.

In si intende che ciascuna delle azioni sopra descritte come avvenute sul dispositivo client e sul server pu? anche essere considerata per descrivere i passi corrispondenti di un metodo. In quanto tale, la descrizione dei vantaggi di ciascuna delle azioni sopra descritte deve essere considerata in relazione ai passi corrispondenti del metodo qui di seguito.

In un quarto aspetto, viene descritto un metodo per l'uso in una rete cellulare che fornisce pubblicazioni basate sulla localizzazione utilizzando un protocollo di pubblicazione/abbonamento, il metodo che comprende:

determinare, in un dispositivo client, una posizione geografica significativa per il dispositivo client;

determinare, nel dispositivo client, un geohash in abbonamento, per identificare un'area che comprenda la posizione geografica significativa per il dispositivo client;

l'invio, dal dispositivo client, di un abbonamento ad un server, l'abbonamento con un nome di abbonamento comprendente il geohash di abbonamento.

Preferibilmente, la determinazione, sul dispositivo client, di un geohash in abbonamento comprende la determinazione del geohash in abbonamento specificato a un livello di abbonamento.

Preferibilmente, il metodo comprende inoltre:

determinare, al dispositivo client, una velocit? del dispositivo client; e determinare, sul dispositivo client, il livello di abbonamento in base alla velocit?. Preferibilmente, il nome dell'abbonamento comprende un numero predefinito di caratteri, e in cui tutti i caratteri del numero predefinito di caratteri che non sono compilati dal geohash dell'abbonamento specificato al livello di abbonamento vengono riempiti con un carattere jolly.

Preferibilmente, il metodo comprende inoltre:

determinare una direzione di movimento del dispositivo client;

determinare, nel dispositivo client, uno o pi? geohash aggiuntivi, che rappresentino una o pi? aree geografiche in direzione del movimento del dispositivo client e/o confinanti con l'area geografica rappresentata dal geohash in abbonamento; e

l'invio di uno o pi? abbonamenti aggiuntivi al server, ognuno dei quali ha un nome di abbonamento con un rispettivo nome di abbonamento che comprende uno diverso di uno o pi? geohash aggiuntivi.

Preferibilmente, il metodo comprende inoltre:

l'invio, dal dispositivo client al server, di una richiesta di disiscrizione dall'abbonamento con un nome di abbonamento comprendente il geohash di abbonamento;

disiscrivere, presso il server, il dispositivo client dall'abbonamento con un nome di abbonamento comprendente il geohash di abbonamento.

Preferibilmente, il metodo comprende anche la ripetizione dei passi del metodo dopo lo scadere di un intervallo di tempo. In alternativa, il metodo potrebbe comprendere la ripetizione dei passi del metodo dopo l'identificazione che la posizione del dispositivo client ? cambiata (ad esempio, che la posizione del dispositivo client si ? spostata al di fuori di un raggio predefinito di una posizione misurata immediatamente prima).

Preferibilmente, il metodo comprende inoltre:

ricevere, sul server, l'abbonamento dal dispositivo client, l'abbonamento con il nome di abbonamento comprendente il geohash di abbonamento;

ricevere, sul server, un messaggio per la pubblicazione ad un abbonamento corrispondente, il messaggio con un nome di pubblicazione comprendente un geohash di pubblicazione;

determinare, sul server, se l'abbonamento ? un abbonamento corrispondente; e se l'abbonamento ? un abbonamento corrispondente, inviare il messaggio al dispositivo client;

in cui il geohash di sottoscrizione e il geohash di pubblicazione sono strutture di dati gerarchiche specificate ad un rispettivo livello, e la sottoscrizione ? una sottoscrizione corrispondente quando, ad ogni livello che sia il geohash di pubblicazione che il geohash di sottoscrizione sono specificati, il geohash di pubblicazione ad un dato livello corrisponde al geohash di sottoscrizione allo stesso livello.

Preferibilmente, il metodo comprende inoltre:

ricevere, sul dispositivo client, il messaggio dal server.

In un quinto aspetto c'? un dispositivo client configurato per eseguire i passi del metodo come descritto sopra.

In un sesto aspetto c'? un server configurato per eseguire i passi del metodo come descritto sopra.

In un settimo aspetto, esiste un programma per computer che comprende istruzioni che, quando il programma viene eseguito da un computer, fanno s? che il computer esegua le fasi del metodo sopra descritto. In particolare, un primo computer pu? eseguire le fasi identificate come avvenute in un dispositivo client e un secondo computer pu? eseguire le fasi identificate come avvenute presso il server. Un'interfaccia di comunicazione pu? essere predisposta tra detto primo e secondo computer.

In un ottavo aspetto, esiste un supporto leggibile dal computer che comprende le istruzioni che, quando vengono eseguite da un computer, fanno s? che il computer esegua le fasi del metodo sopra descritto. In particolare, un supporto leggibile dal computer su un primo computer pu? eseguire le fasi identificate come avvenute su un dispositivo client, e un supporto leggibile dal computer su un secondo computer pu? eseguire le fasi identificate come avvenute sul server.

Elenco delle cifre

La presente invenzione sar? ora descritta, a titolo puramente esemplificativo, con riferimento ai disegni allegati, nei quali:

La FIGURA 1 ? una rappresentazione schematica di un sistema da utilizzare in una rete cellulare che fornisce pubblicazioni basate sulla localizzazione utilizzando un protocollo di pubblicazione/abbonamento;

La FIGURA 2 mostra un esempio di formato di pacchetto pubblico/abbonamento;

La FIGURA 3 mostra un esempio di pacchetto di pubblicazione da utilizzare nel protocollo di pubblicazione/abbonamento;

FIGURA 4 ? una mappa di esempio che identifica una posizione geografica utilizzando un geohash;

FIGURA 5 ? un diagramma di flusso che mostra i passi di un metodo di esempio che si svolge in un dispositivo client per l'abbonamento a pubblicazioni basate sulla localizzazione;

La FIGURA 6 ? un diagramma di flusso per un ulteriore metodo di esempio che si svolge in un dispositivo client per l'abbonamento a pubblicazioni basate sulla localizzazione; FIGURA 7 ? un diagramma di flusso per un ulteriore metodo di esempio che si svolge in un dispositivo client per l'abbonamento a pubblicazioni basate sulla localizzazione; La FIGURA 8 mostra un albero decisionale per associare una velocit? di misura per il dispositivo client ad un livello al quale deve essere specificato un geocash in abbonamento;

La FIGURA 9 ? un diagramma di flusso per un ulteriore metodo di esempio che si svolge in un dispositivo client per l'abbonamento a pubblicazioni basate sulla localizzazione; La FIGURA 10 ? un diagramma schematico che mostra il cambiamento nell'area del geohash rilevante in un dispositivo client in movimento; e

La FIGURA 11 mostra una serie di esempi di abbonamento e pubblicazione di geohash.

Nei disegni, come i pezzi sono indicati da numeri di riferimento. I disegni non sono disegnati in scala.

Descrizione dettagliata delle forme realizzative preferite

Alcuni esempi saranno ora descritti in modo pi? completo con riferimento ai disegni allegati. La descrizione dettagliata che segue descrive gli aspetti di una rete cellulare che fornisce pubblicazioni basate sulla localizzazione utilizzando un protocollo di pubblicazione/abbonamento. Tale protocollo di pubblicazione/abbonamento pu? essere un qualsiasi protocollo che fornisce un meccanismo di pubblicazione e sottoscrizione tra un broker su un server (come un server di rete) e un client su un dispositivo mobile o un dispositivo utente (descritto di seguito come un dispositivo client). Esempi comunemente usati di protocolli di pubblicazione/abbonamento includono il Message Queuing Telemetry Transport (MQTT), che ? un protocollo di messaggistica Internet of Things (IoT). Questo protocollo, cos? come altri protocolli noti di pubblico/abbonamento, possono essere utilizzati nell'ambito dell'invenzione descritta. Dettagli specifici dell'implementazione in MQTT sono discussi pi? avanti nella descrizione.

Il protocollo di pubblico/abbonamento ? un sistema di messaggistica ampiamente utilizzato nelle reti cellulari. I mittenti di messaggi, chiamati editori, non programmano messaggi da inviare direttamente a specifici destinatari, chiamati abbonati, ma classificano i messaggi per la pubblicazione in classi (o argomenti). Analogamente, gli abbonati esprimono interesse per (o si abbonano a) una o pi? classi (o argomenti), e quindi ricevono solo messaggi classificati dall'editore come appartenenti a una classe a cui l'abbonato si ? abbonato.

La FIGURA 1 mostra gli elementi di base all'interno di una rete cellulare per l'utilizzo all'interno di un meccanismo di messaggistica di pubblicazione/abbonamento. In particolare, un client di un primo dispositivo client (come un dispositivo mobile di un primo utente) 100 invia una richiesta 130 a un server di rete 110 per abbonarsi a una particolare classe di messaggi. La classe di abbonamento pu? essere specificata in un'intestazione della richiesta di abbonamento.

Un client presso un secondo dispositivo client (ad esempio un dispositivo mobile di un altro utente) 120 invia un messaggio 140 per la pubblicazione da parte del server 110 a tutti gli abbonati interessati. Pi? specificamente, una classe (o argomento) per il messaggio pu? essere fornita all'interno di un'intestazione del messaggio per la pubblicazione.

Una volta ricevuto il messaggio 140 per la pubblicazione sul server 110 (o un broker sul server), il server riferisce il messaggio per la pubblicazione a qualsiasi abbonamento corrispondente. Il server identifica le sottoscrizioni corrispondenti confrontando la classe che fa parte della richiesta di sottoscrizione con la classe che fa parte del messaggio per la pubblicazione. Se la stessa classe ? specificata sia nel messaggio che nella sottoscrizione, la sottoscrizione ? considerata una sottoscrizione corrispondente. Il server 110 trasmette quindi il messaggio 150 per la pubblicazione a ciascun client (ad esempio, al primo dispositivo client 100) associato a un abbonamento corrispondente. In questo modo, una pubblicazione pu? essere facilmente distribuita ad un certo numero di destinatari diversi, mentre viene distribuita solo ai destinatari a cui la pubblicazione ? pertinente.

In FIGURA 2 ? mostrato uno schema che mostra i componenti di un tipico pacchetto per lo scambio tra un client e un server in un protocollo di pubblicazione/abbonamento. L'esempio specifico mostrato in FIGURA 2 ? per un pacchetto all'interno del protocollo MQTT, ma si capir? che formati simili saranno presenti in altri protocolli di pubblicazione/abbonamento.

In particolare, il pacchetto comprende un'intestazione fissa 210, un'intestazione variabile 220 e un carico utile 230. L'intestazione fissa 210 comprende un'intestazione di controllo 240 (compreso il tipo di comando 260 e la lanterna di controllo 250), nonch? l'indicazione 270 della lunghezza totale della successiva intestazione variabile 220 e del carico utile 230. L'intestazione fissa 210 sar? generalmente composta da due byte, mentre il numero di byte nell'intestazione variabile 220 e nel carico utile 230 non ? necessariamente fisso. L'intestazione fissa 210 sar? presente in tutti i pacchetti, mentre l'intestazione variabile 220 e il carico utile 230 non devono essere sempre inclusi. Ad esempio, in un pacchetto per l'abbonamento al server, il pacchetto di abbonamento pu? non includere il payload 230.

La FIGURA 3 mostra un esempio specifico di un pacchetto MQTT, che fornisce un messaggio da pubblicare agli abbonati che corrispondono al nome della classe o dell'argomento del messaggio. Un pacchetto MQTT ? mostrato qui solo come esempio, e si intende che altri protocolli possono includere pacchetti con una struttura simile e analoga. Nell'esempio di FIGURA 3, l'intestazione fissa 310 comprende un campo di controllo 340, e anche la lunghezza restante 370 (espressa come numero di byte successivi nel pacchetto). L'intestazione variabile 320 ? formata da un primo paio di byte che denota la lunghezza 322 di un nome di argomento (o classe) da utilizzare nel meccanismo di abbonamento/pubblicazione. Come gi? detto, l'argomento o la classe ? il nome o l'etichetta della classe di abbonamento a cui il messaggio deve essere pubblicato. L'intestazione variabile 320 include inoltre il nome dell'argomento (o della classe) 324. Infine, il payload 330 fornisce il messaggio 332 per la pubblicazione, anche se anche in questo caso i primi due byte del payload indicano la lunghezza 334 del messaggio che segue.

Di conseguenza, nell'esempio di FIGURA 3, il pacchetto pubblica il messaggio "CIAO" agli abbonati all'argomento "OPENLABPRO", secondo l'uso di un valore di comando "3" per la pubblicazione del pacchetto.

La presente descrizione fa uso di geohashes per l'uso in un protocollo di pubblicazione/abbonamento per la messaggistica basata sulla localizzazione. I geohashes sono un sistema di geocodice di pubblico dominio che codifica una posizione geografica in una breve stringa di caratteri (lettere e/o cifre). Diverse biblioteche di pubblico dominio possono essere utilizzate per associare una data posizione geografica al suo geohash. A titolo di esempio, la FIGURA 4 mostra un geohash di dodici caratteri ('u0nkb02qt4xg') corrispondente ad una posizione su una mappa per gli uffici di Vodafone Automotive S.p.A..

Ogni geohash ? una struttura gerarchica di dati spaziali che suddivide lo spazio in aree simili a griglie. Ogni carattere aggiuntivo all'interno del geohash rappresenta un'ulteriore suddivisione dell'area geografica che ? stata rappresentata dal livello immediatamente superiore del geohash. In quanto tali, i geoash offrono una precisione arbitraria. Un esempio della precisione delle aree geografiche offerte per i geohahash di diversa lunghezza dei caratteri ? mostrato nella tabella 1, qui di seguito. La natura della struttura del geohash significa che quanto pi? lungo ? il prefisso condiviso tra due geohah, tanto pi? vicini sono spazialmente tra loro. Per il geohash si pu? utilizzare un numero qualsiasi di caratteri per ottenere la precisione richiesta per la determinazione della posizione, ma per ragioni di efficienza il numero massimo di caratteri indicato nella Tabella 1 ? di nove.

TABELLA 1: Precisione del geohash di diverse lunghezze di esempio

Come gi? osservato in precedenza, il geohash ? una struttura dati gerarchica. Nella presente descrizione, la lunghezza o il numero di caratteri del geohash ? descritto come specificato ad un determinato livello. In particolare, un geohash di livello superiore ha meno caratteri (e rappresenta un'area pi? grande), mentre un geohash di livello inferiore ha pi? caratteri (e rappresenta un'area pi? piccola).

La FIGURA 5 mostra un diagramma di flusso con i passi di un metodo per l'abbonamento ad un protocollo di pubblicazione/abbonamento al fine di ricevere le pubblicazioni basate sulla localizzazione. I passi di FIGURA 5 si svolgono su un dispositivo client (ad esempio, un dispositivo mobile o un'apparecchiatura utente), che invia l'abbonamento ad un server corrispondente all'interno della rete. In quanto tali, le fasi di FIGURA 5 si svolgono su un dispositivo client come parte di un rapporto client/server. Un cliente in un dispositivo client inizia il processo di sottoscrizione determinando 510 una posizione geografica significativa per il dispositivo client. In un esempio specifico, si tratta della determinazione della posizione del dispositivo client in un determinato momento tramite un sistema di navigazione o di posizionamento (come il Global Navigation Satellite System (GNSS), ad esempio il Global Positioning System (GPS), Galileo, Beidou o Glonass). Tuttavia, in altri esempi, potrebbe trattarsi di una posizione geografica inserita da un utente nel dispositivo client (ad esempio, utilizzando un software di navigazione), o di una posizione predefinita per essere rilevante per il client (ad esempio, una posizione "di casa" per il dispositivo client).

Successivamente, il dispositivo client determina 520 un geohash che rappresenta un'area che include la posizione geografica significativa per il dispositivo client. In un esempio particolare, il geohash rappresenta un'area che ha al suo interno una posizione specifica del dispositivo client (come identificato dal sistema di posizionamento). Nella presente descrizione, questo geohash ? etichettato come "il geohash in abbonamento" (in quanto associato ad un particolare abbonamento inviato dal cliente al dispositivo client). Tuttavia, questa notazione non indica alcuna caratteristica particolare per il geohash stesso.

In una fase successiva, una richiesta di sottoscrizione viene inviata 530 a un server (o pi? specificamente a un broker sul server) dal dispositivo client. La richiesta di sottoscrizione ? un pacchetto come discusso in precedenza rispetto alle FIGURE 2 e 3, e comprende il geohash di sottoscrizione all'interno della stringa di caratteri che identifica la classe o l'argomento del protocollo di sottoscrizione/pubblicazione. In un esempio specifico, la stringa della classe o dell'argomento comprende un numero predeterminato di caratteri, costituito dal geohash della sottoscrizione e/o dai caratteri jolly. In particolare, il geohash di sottoscrizione pu? essere formato fino al numero di caratteri predefinito, o se il geohash di sottoscrizione ? pi? corto del numero di caratteri predefinito, gli eventuali caratteri rimanenti della classe o della stringa di argomento sono costituiti da caratteri 'jolly' (come '+', anche se a seconda del protocollo utilizzato, qualsiasi altro tipo di carattere pu? essere utilizzato per distinguere i caratteri jolly dai caratteri non jolly).

Ad esempio, la classe o la stringa di argomenti del protocollo subscribe/publish pu? sempre essere composta da nove caratteri (anche se si pu? utilizzare un numero qualsiasi di caratteri). In una prima richiesta di sottoscrizione di esempio, la classe o la stringa dell'argomento pu? comprendere un geohash lungo nove caratteri (ad es. u0nkb02qt). Tuttavia, in una seconda richiesta di sottoscrizione di esempio alternativa, il geohash pu? essere fornito con meno precisione e avere meno caratteri (ad esempio, solo sei caratteri). In questo secondo esempio, i caratteri della classe o della stringa dell'argomento che non sono riempiti con i caratteri del geohash saranno ripresi con caratteri jolly (ad es. u0nkb0++++). In questo modo, nella stringa della classe o dell'argomento possono essere inclusi geoash di diversa lunghezza (o livelli) e quindi possono essere utilizzati geoash di diversa precisione e relativi a diverse dimensioni dell'area geografica.

In una specifica implementazione del sistema descritto che viene implementato in MQTT, la struttura del nome dell'abbonamento (o del nome dell'argomento) pu? essere la seguente:

ClientID/ Categoria/ Sottocategoria/Sottocategoria/Geohash[1-3]/Geohash4/Geohash4/Geohash5/Geohash6/Geohash6/Geohash7/Geohash8/Geohash9 In questo caso, ogni carattere di geohash numerato (ad esempio, Geohash4) ? il carattere del geohash al livello dato (quindi, ad esempio, Geohash4 ? il carattere al quarto livello del geohash in abbonamento). Uno qualsiasi dei caratteri del geohash numerato, e quindi qualsiasi carattere del geohash numerato successivo, pu? essere sostituito da un carattere jolly nell'abbonamento, come descritto sopra.

Beneficiariamente, le fasi del metodo illustrato in FIGURA 5 si svolgono nel dispositivo client. Pertanto, il geohash di sottoscrizione che rappresenta un'area geografica per una richiesta di sottoscrizione viene calcolato sul dispositivo client, piuttosto che su un server. Ci? rende meno intensiva la gestione di un gran numero di abbonamenti sul server e aumenta la scalabilit? del sistema nel suo complesso. Inoltre, gli inventori hanno riconosciuto che il calcolo del geohash sul dispositivo client consente di utilizzare la struttura tipica di un pacchetto di richiesta di abbonamento nel protocollo di pubblicazione/abbonamento, con il geohash incluso nell'intestazione del pacchetto. In questo modo, il server non ha bisogno di analizzare alcuna porzione del carico utile.

Secondo il metodo sopra descritto in relazione alla FIGURA 5, un dispositivo client sottoscrive una classe di messaggi con un nome di abbonamento comprendente un geohash in abbonamento, al fine di ricevere dal server le pubblicazioni rilevanti per l'area geografica indicata dal geohash in abbonamento. Tuttavia, come sar? inteso dalla persona competente, la posizione geografica significativa per il dispositivo client pu? cambiare nel tempo, ad esempio se la posizione geografica del dispositivo client cambia. Come tale, possono essere desiderate nuove sottoscrizioni, e alcune sottoscrizioni esistenti possono diventare irrilevanti (e quindi l'utente pu? desiderare di disdire la sottoscrizione esistente) e sottoscriverne una nuova.

La FIGURA 6 illustra le fasi per l'aggiornamento di un abbonamento e la cancellazione di un abbonamento esistente. In particolare, come gi? discusso in precedenza per quanto riguarda la FIGURA 5, il dispositivo client determina 610 una prima posizione geografica significativa per il dispositivo client. In un esempio particolare, questa ? la posizione del dispositivo client in una prima volta, t0, secondo un sistema di navigazione o posizionamento (Global Navigation Satellite System, GNSS), ma potrebbe anche essere un input di posizione rilevante per il dispositivo da parte di un utente, ad esempio. Il dispositivo client determina o calcola un primo geohash in abbonamento per identificare un'area che include la prima posizione geografica significativa per il dispositivo client, come discusso in precedenza. Il primo geohash in abbonamento viene quindi utilizzato all'interno del nome dell'abbonamento incluso nella stringa di classe (o argomento) di un abbonamento inviato 630 dal dispositivo client al server.

Il cliente determina quindi 640 una seconda posizione geografica significativa per il dispositivo del cliente. In un esempio particolare, questa ? la posizione del dispositivo client in una seconda volta, t1, secondo un sistema di navigazione o di posizionamento, dopo che ? trascorso un intervallo di tempo da una seconda volta. In particolare, l'apparecchio client pu? essere in movimento (o pu? essersi spostato rispetto alla prima posizione), e quindi l'utente pu? desiderare di ricevere pubblicazioni rilevanti per la sua nuova posizione. Il dispositivo client determina o calcola 650 un secondo geohash per la seconda posizione geografica significativa per il dispositivo client. Questo secondo geohash (il secondo geohash di abbonamento) viene quindi utilizzato all'interno di un nome di abbonamento incluso nella stringa di classe (o argomento) di un secondo abbonamento inviato 660 dal dispositivo client al server. Come tale, il dispositivo client ? quindi abbonato a due sottoscrizioni separate sul server, relative a due aree geografiche diverse (anche se eventualmente sovrapposte).

Tuttavia, una volta ricevute le pubblicazioni relative a una posizione geografica attuale, pu? essere auspicabile smettere di ricevere pubblicazioni per una localit? precedente. Di conseguenza, il dispositivo client invia ora al server 670 una richiesta di disiscrizione dal primo abbonamento con il nome dell'abbonamento che comprende il primo geohash di abbonamento. Questa richiesta di disiscrizione assumer? la forma di un pacchetto pi? o meno come discusso in precedenza per quanto riguarda le FIGURE 2 e 3, anche se con un appropriato valore di comando nell'intestazione del controllo.

In un esempio ancora pi? vantaggioso, oltre ai passi di FIGURA 6 si pu? determinare una velocit? del dispositivo client. Questa pu? essere, ad esempio, una velocit? presente, istantanea, o una velocit? media su un periodo di tempo predefinito. Una volta determinata la velocit?, l'intervallo di tempo tra il primo, t0, e il secondo, t1, tempo sopra menzionato pu? essere determinato in base alla velocit?. Ad esempio, si pu? utilizzare una relazione o un algoritmo predeterminato per determinare l'intervallo di tempo in base alla velocit? di movimento del dispositivo client.

In questo modo, un intervallo di tempo tra l'invio di un primo e di un secondo abbonamento pu? essere correlato alla velocit? di movimento del dispositivo client. Come tale, l'intervallo di tempo ? effettivamente correlato ad una "frequenza di campionamento" per la posizione del dispositivo client e ad un successivo aggiornamento del relativo abbonamento . Ad esempio, la velocit? e la durata dell'intervallo di tempo possono essere correlate in modo inverso, in modo che l'intervallo di tempo sia pi? breve quando la velocit? di spostamento ? pi? veloce. In questo modo, gli abbonamenti vengono "aggiornati" per rispondere alle nuove posizioni del dispositivo client ad intervalli di tempo appropriati. Inoltre, in modo analogo a quanto sopra descritto, l'apparecchio cliente pu? disdire in modo tempestivo gli abbonamenti relativi a localit? precedenti o vecchie che non sono pi? rilevanti. In quanto tale, solo le pubblicazioni rilevanti vengono ricevute presso l'apparecchio client, e in particolare un apparecchio client in movimento.

Un ulteriore esempio delle fasi che si svolgono in un dispositivo client ? mostrato nella FIGURA 7. In questo caso, il dispositivo client ? in movimento. Dopo aver determinato 710 una posizione geografica significativa per il dispositivo client (ad esempio una posizione identificata da un sistema di navigazione o di posizionamento), si determina la velocit? di movimento del dispositivo client 720. La velocit? pu? essere determinata in base alla distanza tra una posizione del cliente in un primo momento e una posizione del cliente in un secondo momento (in cui velocit? = ?distanza/?tempo), ad esempio. In alternativa, la velocit? pu? essere ricevuta da misurazioni effettuate altrove (ad esempio, da una misurazione al tachimetro in un veicolo in cui ? compreso il dispositivo client).

Una volta determinata, la velocit? pu? essere utilizzata sul dispositivo client per impostare 730 il livello (qui indicato come "livello di abbonamento") a cui ? specificato il geohash di abbonamento. In particolare, secondo una relazione predefinita, la velocit? determinata del dispositivo client all'interno di determinati intervalli predefiniti corrisponde ad un numero specifico di caratteri da specificare nel geohash di abbonamento (e quindi il livello di abbonamento). Come sopra indicato, il livello di abbonamento definisce la dimensione dell'area individuata dal geohash, e quindi in questo modo la dimensione dell'area geografica per l'abbonamento ? determinata dalla velocit? di movimento del dispositivo client. In particolare, una velocit? pi? veloce per il dispositivo client pu? essere associata ad un geohash specificato ad un livello pi? alto (quindi con meno caratteri), e quindi rappresentare un'area geografica pi? ampia (e quindi abbonarsi a pubblicazioni dirette all'interno di un'area geografica pi? ampia). Al contrario, una velocit? pi? lenta per il dispositivo client pu? essere associata ad un geohash specificato ad un livello inferiore (quindi con un numero di caratteri maggiore), e quindi rappresentare un'area geografica pi? piccola (e quindi abbonarsi a pubblicazioni dirette all'interno di un'area geografica pi? piccola). La particolare relazione tra la velocit? determinata del dispositivo client e il livello di specifica viene discussa pi? avanti con riferimento alla FIGURA 8.

Facendo riferimento alla FIGURA 7, una volta determinato il livello di abbonamento 730, il dispositivo client determina 740 il geohash di abbonamento, specificato al livello di abbonamento, identificando la posizione geografica significativa per il dispositivo client. Quindi, come descritto in relazione alle FIGURE 5 e 6 di cui sopra, il dispositivo client invia 750 un abbonamento al server, in cui il nome dell'abbonamento comprende il geohash di abbonamento specificato al livello di abbonamento.

Il dispositivo client descritto si abbona quindi a ricevere pubblicazioni trasmesse in aree geografiche rilevanti di diverse dimensioni senza calcoli complessi o costosi dal punto di vista dei calcoli sul server o senza un input specifico da parte dell'utente. La dimensione dell'area geografica rilevante pu? essere correlata alla velocit? di spostamento del dispositivo, per cui l'abbonamento viene effettuato per ricevere pubblicazioni dirette ad un'area pi? ampia quando il dispositivo si muove pi? rapidamente.

Come gi? detto, la velocit? del dispositivo client pu? essere utilizzata per determinare il livello a cui ? specificato il geohash in abbonamento. Questa associazione tra la velocit? determinata e il livello di specificazione del geocash in abbonamento ? illustrata pi? dettagliatamente nella FIGURA 8. In particolare, la velocit? pu? essere suddivisa in una pluralit? di intervalli contigui. Ogni intervallo pu? quindi essere associato ad un livello al quale il geocash in abbonamento deve essere specificato. Ad esempio, la velocit? prevista misurata pu? essere separata in tre intervalli di: minore o uguale a 20 km/s; maggiore di 20 km/s e minore o uguale a 160 km/s; maggiore di 160 km/s. Quando la velocit? determinata o misurata rientra nel primo intervallo, quello pi? lento, allora questo ? associato ad un livello di specifica di 7 per il geohash in abbonamento (cio? un geohash a 7 caratteri). In alternativa, quando la velocit? determinata o misurata rientra nel secondo, medio raggio, questo ? associato ad un livello di specifica di 6 per il georiferimento in abbonamento (cio? un georiferimento a 6 caratteri). Infine, quando la velocit? determinata o misurata cade nella terza fascia pi? veloce, questo ? associato ad un livello di specificazione di 5 per il georiferimento in abbonamento (cio? un georiferimento a 5 caratteri). Pertanto, il livello di specifica ? inversamente correlato alla velocit? misurata per il dispositivo client, e l'area geografica indicata dalla scala del geohash con la velocit?.

Ulteriori vantaggi possono essere ottenuti dal dispositivo client che si abbona per ricevere pubblicazioni relative a una o pi? aree geografiche aggiuntive intorno o nelle vicinanze della posizione geografica significativa per un dispositivo client. A tal fine, il cliente esegue inizialmente i passi secondo la FIGURA 5 come sopra discusso, al fine di inviare un abbonamento ad un server, l'abbonamento che ha un nome di abbonamento che comprende il geohash di abbonamento. Tuttavia, successivamente o in parallelo alla determinazione del geohash in abbonamento che identifica l'area, compresa la posizione geografica significativa per il dispositivo client, viene determinato almeno un ulteriore geohash in abbonamento nel dispositivo client.

In particolare, almeno un geohash in abbonamento aggiuntivo identifica una rispettiva regione geografica confinante con la posizione geografica significativa per il dispositivo client. Le regioni confinanti possono essere adiacenti all'area del geohash, inclusa la posizione geografica significativa per il dispositivo client, ad esempio, e in alcuni esempi possono essere confinanti con l'area del geohash, inclusa la posizione geografica significativa per il dispositivo client. Il geohash aggiuntivo in abbonamento pu? identificare aree che sono in qualche modo sovrapposte all'area del geohash, inclusa la posizione geografica significativa per il dispositivo client, o che si sovrappongono l'una all'altra. In un esempio, le regioni geografiche a nord, nord-est, est, sud-est, sud-est, sud, sud-ovest, ovest e nord-ovest dell'area geohash, compresa la posizione geografica significativa per il dispositivo client, possono essere identificate ciascuna in un geohash aggiuntivo in abbonamento. In questo modo, una pluralit? di geohash in abbonamento aggiuntivo rappresenta le regioni che circondano la posizione geografica significativa per il dispositivo client.

Ciascuno dei geohash in abbonamento aggiuntivo pu? quindi costituire la base di un abbonamento aggiuntivo, inviato dal dispositivo client al server. In particolare, il dispositivo client pu? inviare uno o pi? abbonamenti aggiuntivi, ciascuno con un nome di abbonamento comprendente un diverso geocash aggiuntivo. Di conseguenza, il dispositivo client ? abbonato a una "griglia" di localit? nelle vicinanze o intorno alla localit? geografica identificata come rilevante per il dispositivo client.

Come sar? inteso dalla persona competente, il geohash aggiuntivo in abbonamento pu? essere specificato ad un livello di abbonamento diverso rispetto al geohash in abbonamento che rappresenta un'area che include la posizione geografica significativa per il dispositivo del cliente. In ogni caso, la fornitura di tali abbonamenti aggiuntivi fornisce una copertura pi? completa di qualsiasi area rilevante per il dispositivo client e i suoi dintorni.

In un ulteriore esempio, gli abbonamenti aggiuntivi menzionati possono riferirsi a regioni geografiche in una direzione di movimento (o direzione di marcia) del dispositivo client. Ci? pu? essere utile per fornire abbonamenti a pubblicazioni o avvisi relativi ad aree nel percorso di un dispositivo client in movimento. Un esempio di questo tipo pu? avere particolari vantaggi quando il dispositivo client fa parte di un veicolo in movimento e le pubblicazioni si riferiscono, ad esempio, ad avvisi sul traffico.

I passi eseguiti su un dispositivo client in relazione a questo esempio sono mostrati in FIGURA 9. In primo luogo, una posizione geografica significativa per un dispositivo client ? determinata 910 nel dispositivo client. Successivamente, viene determinata una direzione di movimento del dispositivo client 920 nel dispositivo client. Questo pu? essere determinato da una misurazione della velocit?, per esempio, o semplicemente come calcolo del vettore tra due punti misurati del dispositivo client.

Successivamente, un geohash in abbonamento viene determinato 930 dal dispositivo client, il geohash in abbonamento che rappresenta un'area che include la posizione geografica significativa per il dispositivo client. Opzionalmente, il livello di specifica del geohash in abbonamento pu? essere determinato dalla velocit? (in altre parole, la parte scalare della velocit?), come descritto sopra rispetto alle FIGURE 7 e 8. Dopo aver determinato il geohash in abbonamento, il dispositivo client invia al server 940 un abbonamento, con un nome di abbonamento che comprende il geohash in abbonamento.

Poi, in modo simile a quello descritto sopra, il dispositivo client determina 950 uno o pi? geohash aggiuntivi in abbonamento. In questo caso, l'uno o pi? geohash in abbonamento identificano le regioni geografiche in direzione del movimento del dispositivo client. In un esempio specifico, tre geohash in abbonamento aggiuntivi sono determinati in modo da rappresentare aree allineate lungo un vettore nella direzione di movimento del cliente e confinanti tra loro. Pertanto, in questo esempio i tre geohash aggiuntivi comprendono un primo geohash aggiuntivo in abbonamento che confina, in direzione del movimento, il geohash in abbonamento che identifica l'area comprendente la posizione geografica significativa per il dispositivo client, un secondo geohash aggiuntivo in abbonamento che confina, in direzione del movimento, con l'area rappresentata dal primo geohash in abbonamento e un terzo geohash aggiuntivo in abbonamento che confina, in direzione del movimento, con l'area rappresentata dal secondo geohash in abbonamento.

Una volta determinato il geohash di abbonamento aggiuntivo, gli abbonamenti vengono inviati 960 dal dispositivo client al server. Ogni abbonamento ha un nome di abbonamento che comprende un rispettivo geohash di abbonamento aggiuntivo. In questo modo, vengono inviati gli abbonamenti a pubblicazioni dirette ad aree allineate lungo il percorso prospettico di un dispositivo client.

Sebbene sopra siano descritti tre geohash aggiuntivi in abbonamento, resta inteso che ? possibile determinare un numero qualsiasi di geohash aggiuntivi in abbonamento. Il numero di geohash aggiuntivi in abbonamento pu? dipendere da una determinata velocit? del dispositivo del cliente, in modo tale che un numero maggiore di geohash aggiuntivi in abbonamento relativi ad aree allineate nella direzione del movimento siano determinati quando la velocit? di spostamento ? pi? veloce. In questo modo, gli abbonamenti possono essere inviati al server per le regioni in cui ? probabile che il dispositivo client si sposti nel prossimo futuro. In questo modo si possono "anticipare" gli abbonamenti in base alla posizione specifica del dispositivo client. In un esempio specifico in cui il dispositivo client fa parte di un veicolo o si trova all'interno di un veicolo, ci? consente, ad esempio, di abbonarsi ad avvisi sul traffico relativi alla strada da percorrere.

La FIGURA 10(a) mostra una rappresentazione schematica di una griglia di geohash di abbonamento aggiuntivo (scatole con tratteggio incrociato, 1030) che circonda l'area del geohash (scatola con tratteggio orizzontale, 1040), inclusa la posizione rilevante per il dispositivo client e determinata in un momento t0. Il dispositivo client 1010 ? mostrato come una stella e la direzione del movimento del dispositivo client ? contrassegnata da una freccia 1020. Ogni casella all'interno della griglia rappresenta un'area di geohash separata, in questo caso ciascuna rappresenta lo stesso livello di precisione (quindi ogni geohash ? specificato allo stesso livello).

Dopo lo scadere di un intervallo di tempo, al momento t1 il dispositivo client si ? spostato in avanti nella direzione della direzione di movimento illustrata. Nella FIGURA 10(b) viene mostrata una nuova griglia di geohash aggiuntivi in abbonamento che circonda la nuova area geohash (boccaporto orizzontale, 1040) rilevante per il dispositivo client. Si pu? notare che cinque delle regioni di geohash (scatole con tratteggio incrociato, 1030) sono comuni (o si sovrappongono) tra entrambe le FIGURE 10(a) e 10(b).

Tuttavia, la FIGURA 10(b) mostra tre "vecchie" regioni (boccaporti diagonali, 1050), che sono ora ridondanti - in quanto questi abbonamenti non sono pi? di interesse per il dispositivo client (e sono "dietro" il dispositivo client nella sua direzione di marcia). Di conseguenza, una richiesta di disiscrizione dai messaggi pubblicati in queste aree pu? essere inviata al server dal dispositivo client, sotto forma di tre richieste di disiscrizione, ognuna delle quali include un nome di sottoscrizione comprendente un diverso geohash di sottoscrizione relativo a queste 'vecchie' regioni.

Analogamente, la FIGURA 10(b) mostra tre "nuove" regioni (caselle tratteggiate, 1060), che sono ora confinanti con la regione del geohash in cui si trova il dispositivo client. In quanto tali, le pubblicazioni inviate a queste "nuove" aree possono essere di interesse per l'utente del dispositivo client. Di conseguenza, gli abbonamenti possono essere inviati dal dispositivo client relativi a queste "nuove" aree e includere come nome di abbonamento uno di ciascuno dei geohash in abbonamento che identificano le "nuove" regioni.

Come sar? inteso dalla persona esperta in materia, il dispositivo client pu? controllare periodicamente la sua posizione e, dopo aver identificato una nuova posizione, procedere all'identificazione del geohash in abbonamento relativo alla sua nuova posizione, e di qualsiasi altro geohash in abbonamento relativo a regioni vicine alla nuova posizione del dispositivo client. Il dispositivo client pu? quindi confrontare il geohash in abbonamento appena identificato con il geohash utilizzato in abbonamenti precedenti e attuali. In questo modo, il dispositivo client pu? identificare la "sovrapposizione" tra il geohash appena identificato e il geohash precedentemente identificato. Il dispositivo client pu? quindi procedere solo ad abbonamenti con un nome di abbonamento comprendente un nuovo geohash in abbonamento che non si riferisce gi? ad un abbonamento "live" o "corrente".

In ogni caso, ciascuna delle fasi sopra descritte pu? essere ripetuta periodicamente, al fine di iscriversi alle aree "nuove" e di annullare l'iscrizione alle aree "vecchie" mentre il dispositivo client percorre un percorso. Il periodo o l'intervallo di tempo tra gli aggiornamenti pu? dipendere dalla velocit? di viaggio del dispositivo client, con aggiornamenti che si svolgono pi? regolarmente quando il dispositivo client si muove a velocit? pi? elevate.

I componenti del sistema, tra cui un primo dispositivo client e un server, nonch? un secondo dispositivo client opzionale, sono stati discussi sopra con riferimento alla FIGURA 1. Le FIGURE da 5 a 10, con la relativa descrizione, si concentrano per lo pi? sulle operazioni sul dispositivo client, al fine di inviare uno o pi? abbonamenti, ognuno con un nome di abbonamento comprendente un geohash di abbonamento. Il dispositivo client e la sua configurazione, come sopra descritto, pur presentando una serie di caratteristiche e caratteristiche vantaggiose, fa parte di un sistema che, a sua volta, presenta una serie di vantaggi.

Il server gestisce gli abbonamenti ricevuti da ogni dispositivo client, oltre a gestire l'invio delle pubblicazioni agli abbonamenti corrispondenti. In particolare, il server riceve, da un dispositivo client (ad esempio, il secondo dispositivo client di FIGURA 1) un pacchetto contenente un messaggio per la pubblicazione ad abbonamenti corrispondenti. Il pacchetto pu? avere il formato sopra descritto rispetto all'esempio di FIGURA 3. In particolare, il pacchetto pu? includere nell'intestazione variabile una stringa di argomento o di classe e il carico utile comprende il messaggio per la pubblicazione. Nel sistema attualmente descritto, questa stringa di topic o di classe comprende un geohash di pubblicazione. Il geohash della pubblicazione identifica una localit? geografica per la quale la pubblicazione ? rilevante. Ad esempio, questa localit? potrebbe essere una localit? rilevante come identificata dal mittente del messaggio per la pubblicazione.

Al ricevimento del pacchetto contenente un messaggio per la pubblicazione, il server identifica gli abbonamenti corrispondenti, quindi invia o trasmette il messaggio ai dispositivi client associati agli abbonamenti corrispondenti. Il server identifica gli abbonamenti corrispondenti confrontando la classe o la stringa di argomenti del messaggio da pubblicare con la classe o la stringa di argomenti di ogni abbonamento. Se sia una pubblicazione che un abbonamento si riferiscono alla stessa classe o argomento, sono considerati corrispondenti.

In quanto tale, nel sistema attualmente descritto, il server confronta il geohash di pubblicazione compreso nel nome della pubblicazione del messaggio da pubblicare con il geohash di abbonamento compreso nel nome dell'abbonamento per ogni abbonamento registrato sul server. Se il geohash di pubblicazione e quello di abbonamento corrispondono, allora la pubblicazione ? considerata corrispondente.

Non ? necessario che il geohash di pubblicazione e quello di abbonamento siano identici per poter corrispondere (anche se i geohash identici sarebbero considerati corrispondenti). In particolare, il geohash di pubblicazione e quello di sottoscrizione possono essere specificati ciascuno a un livello diverso (cio? avere un numero di caratteri diverso). In questo caso, il geohash di pubblicazione e quello di sottoscrizione sono considerati corrispondenti se, al livello pi? basso che entrambi i geohash sono specificati, hanno gli stessi caratteri all'interno della classe o della stringa di argomenti.

Come gi? detto, ogni carattere della classe o della stringa di argomento che non include un carattere di geohash (cio? che supera il numero di caratteri a cui il geohash ? specificato) pu? contenere un carattere jolly, ad esempio '+', nell'intestazione variabile del pacchetto. In quanto tale, la classe o la stringa di argomento di un abbonamento e di una pubblicazione pu? essere della stessa lunghezza (con un numero di caratteri predefinito), ma comprendere geohash di lunghezza diversa.

Ad esempio, se il geohash di abbonamento ha cinque caratteri (in altre parole, ? specificato al quinto livello, per l'abbonamento ad un'area relativamente pi? grande), ma un geohash di pubblicazione ha sette caratteri (in altre parole, ? specificato al settimo livello, che rappresenta un'area relativamente pi? piccola), allora il geohash di abbonamento e quello di pubblicazione corrispondono se i primi cinque caratteri del geohash di pubblicazione sono identici ai cinque caratteri del geohash di abbonamento. L'inclusione di caratteri aggiuntivi ai livelli sei e sette del geocash di pubblicazione non ? rilevante, in quanto la corrispondenza dei primi cinque caratteri in entrambi i geocash indica che l'area rappresentata dal geocash di pubblicazione si trova all'interno dell'area rappresentata dal geocash di abbonamento. Pertanto, la pubblicazione ? rilevante per questo abbonamento. Di conseguenza, si ritiene che l'abbonamento di questo esempio corrisponda alla pubblicazione.

Considerando gli stessi esempi per la pubblicazione e il geohash di abbonamento, se solo i primi quattro caratteri dei due geohash sono uguali, ma il quinto carattere ? diverso, allora questo sarebbe considerato non corrispondente. In questo caso, l'area geografica rappresentata dal geohash della pubblicazione non si trova all'interno delle aree geografiche rappresentate dal geohash in abbonamento, ma ogni geohash rappresenta un sottoinsieme diverso di un'area pi? ampia. In quanto tale, il messaggio per la pubblicazione non ? considerato rilevante per il dispositivo client associato all'abbonamento. Poich? in questo caso il messaggio per la pubblicazione non corrisponde all'abbonamento, il server non invierebbe il messaggio al dispositivo client associato all'abbonamento.

Notiamo che, sebbene in questo esempio il geohash della pubblicazione sia specificato ad un livello inferiore rispetto al geohash della sottoscrizione (in altre parole, il geohash della pubblicazione comprende pi? caratteri del geohash della sottoscrizione), questo non ? necessariamente il caso. In un esempio generale, entrambi i geohash possono essere specificati ad un determinato livello, in modo che uno dei due geohash di sottoscrizione o di pubblicazione possa essere specificato ad un livello inferiore rispetto all'altro. In alternativa, entrambi i geohash possono essere specificati allo stesso livello. Tuttavia, nell'implementazione specifica all'interno di MQTT, il geohash delle pubblicazioni sar? specificato o allo stesso livello o ad un livello inferiore, rispetto al geohash in abbonamento, come descritto pi? avanti, ma non sar? specificato ad un livello superiore rispetto al geohash in abbonamento. In quanto tale, in MQTT un abbonamento e una pubblicazione corrispondenti indicano che l'area rappresentata dal geohash di pubblicazione ? all'interno (o uguale) all'area rappresentata dal geohash in abbonamento.

Come ulteriori esempi generali, la FIGURA 11 mostra una serie di geohash in abbonamento (S1, S2, S3) e geohash di pubblicazione (P1, P2, P3). Si noti che ognuno di questi geohash fa parte di una stringa della stessa lunghezza (ognuno di sette caratteri). Se il geohash non ? specificato al livello richiesto per riempire la stringa, viene invece incluso un carattere jolly, '+'.

Il confronto di questi geohash da parte del server per identificare un abbonamento corrispondente a una pubblicazione darebbe risultati diversi. La TABELLA 2, qui di seguito, mostra un '?' dove il geohash di pubblicazione o abbonamento sarebbe considerato corrispondente, e un '?' dove il geohash di pubblicazione o abbonamento sarebbe considerato non corrispondente.

TABELLA 2: Corrispondenza del geocash di pubblicazione e di abbonamento mostrato in

FIGURA 11.

L'utilizzo del geohash all'interno del nome dell'abbonamento e del nome della pubblicazione offre una serie di vantaggi. In primo luogo, fornendo un geohash direttamente all'interno della classe o della stringa di argomenti di un abbonamento o di un pacchetto di pubblicazione in un protocollo di pubblicazione/abbonamento, non sono necessarie modifiche significative al server o alla sua configurazione. In particolare, il confronto della stringa della classe o dell'argomento in un messaggio per la pubblicazione e in un abbonamento segue i processi tipici di un protocollo di pubblicazione/abbonamento. Poich? il geohash viene calcolato sul dispositivo client che invia l'abbonamento o la pubblicazione, il server non ? tenuto a compiere ulteriori passi per calcolare il geohash sulla base, ad esempio, di una posizione del sistema di navigazione o di posizionamento e di un raggio fornito da un dispositivo client. Inoltre, non sono necessari ulteriori fasi per identificare se una specifica posizione fornita in relazione a una pubblicazione rientra in un'area rappresentata da un geohash per un abbonamento. Il confronto si limita invece ai soli caratteri della stringa dell'argomento o della classe. In quanto tale, il sistema e il metodo sono scalabili per inviare un gran numero di messaggi basati sulla localizzazione senza richiedere risorse di calcolo drasticamente maggiori sul server rispetto a quanto richiesto dai tipici sistemi di pubblicazione/abbonamento. Il sistema e il metodo descritti riducono anche la complessit?.

Nell'esempio generale del sistema di cui sopra, si osserva che il geohash di abbonamento e il geohash di pubblicazione possono essere specificati a qualsiasi livello (o lunghezza) desiderato. Nell'esempio generale, se il geohash di abbonamento e il geohash di pubblicazione contengono meno caratteri del numero di caratteri necessari per riempire rispettivamente il nome dell'abbonamento o il nome della pubblicazione, gli eventuali caratteri rimanenti possono essere riempiti con un carattere jolly. Nonostante questo esempio generale, in una specifica implementazione del sistema descritto all'interno di MQTT, i caratteri jolly non possono essere utilizzati all'interno di un nome di pubblicazione, ma solo nel nome di abbonamento (per le operazioni di sottoscrizione e di cancellazione dell'abbonamento). Come tale, in un'implementazione MQTT il geohash di pubblicazione sar? sempre specificato con il numero predefinito di caratteri necessari per "riempire" il nome della pubblicazione. In un'implementazione MQTT, il geohash di sottoscrizione sar? specificato allo stesso livello (e quindi avr? lo stesso numero di caratteri) del geohash di pubblicazione, o sar? specificato ad un livello pi? alto (e quindi avr? meno caratteri rispetto al geohash di pubblicazione). In considerazione di ci?, guardando agli esempi di FIGURA 11, verr? utilizzato solo un georash di pubblicazione del tipo indicato come P1 in FIGURA 11. In tal caso, S1 o S2 sarebbero considerati abbonamenti corrispondenti, mentre S3 non sarebbe considerato un abbonamento corrispondente.

Si considera un'applicazione specifica dell'invenzione, relativa alla fornitura di notifiche di trasporto. Ad esempio, il dispositivo client pu? trovarsi all'interno di un veicolo o farne parte, e il sistema pu? essere predisposto per fornire avvisi sul traffico. In un esempio specifico, tutti i messaggi vengono scambiati utilizzando MQTT come protocollo di pubblicazione/abbonamento client/server. Ogni utente (veicolo, operatore stradale, pedone o ciclista, ecc. ) ? associato ad un dispositivo client configurato per fornire un client MQTT associato ad un broker MQTT su un server di rete.

In questo esempio, ogni utente pu? inviare messaggi dal dispositivo del cliente al broker e specificare un argomento o una classe per il messaggio. Inoltre, ogni utente pu? ricevere messaggi sottoscrivendo uno o pi? argomenti sul broker. Quando un messaggio viene pubblicato da un cliente su un argomento specifico, il broker lo inoltra a tutti i clienti che hanno sottoscritto l'argomento specifico (o che hanno sottoscritto un argomento di pattern matching, ad esempio se nell'argomento sottoscritto ? stato utilizzato un carattere jolly). Nel caso della presente invenzione, gli argomenti sono costituiti da geohash, come descritto sopra.

Secondo questo specifico esempio, i messaggi possono essere pubblicati in relazione ad una specifica posizione geografica, e poi trasmessi (o inoltrati) ad un dispositivo client (e ai loro utenti) che si sono abbonati per ricevere messaggi rilevanti per quella posizione geografica. In questo modo, gli utenti possono ricevere avvisi sul traffico nel loro veicolo, ad esempio, quando gli avvisi sono stati pubblicati come messaggi da un dispositivo client all'interno di un'altra parte della rete di trasporto.

Inoltre, con questa soluzione i veicoli ricevono solo messaggi rilevanti (ad esempio, messaggi relativi alla loro posizione attuale o futura). Questa soluzione ? poco costosa perch? l'infrastruttura richiede solo un server (ad esempio, ospitando un broker MQTT) e un dispositivo client (ad esempio, ospitando un client MQTT). Non ? necessario alcuno sviluppo significativo dal punto di vista del server, in quanto tutte le pubblicazioni basate sulla localizzazione sono realizzate attraverso le procedure di routing gi? disponibili nei protocolli di pubblicazione/abbonamento (ad esempio, in MQTT), dalla specifica struttura tematica utilizzata e dal meccanismo di sottoscrizione automatica descritto. In sintesi, la soluzione descritta ?:

? rapido da implementare (soprattutto per la prova del concetto) in quanto solo un broker deve essere implementato su un server;

? altamente scalabile;

? efficiente con bassa latenza in quanto i messaggi non vengono analizzati dal broker;

? miglioramenti nelle prestazioni (riduzione dell'unit? centrale di elaborazione, della CPU, del tempo) e nella privacy, in quanto il sistema pu? instradare i messaggi senza analizzarne il contenuto;

? ha la capacit? di supportare un gran numero di messaggi (MQTT ? uno standard IoT, ad esempio);

? facile da integrare sul lato del dispositivo client (ad esempio, su un veicolo), in quanto sono disponibili diverse librerie client di pubblico/abbonamento per diversi linguaggi di programmazione e per l'integrazione in diversi sistemi operativi (ad esempio, la libreria client Paho MQTT ? disponibile per i linguaggi C e Java);

? alcuni protocolli come MQTT sono in grado di supportare messaggi pi? grandi (fino a 65KB) rispetto a una soluzione basata su un protocollo di datagramma utente, UDP; e

? Le classi o gli argomenti per i messaggi possono essere creati al volo dal cliente, sul dispositivo client.

La persona competente capir? che il sistema descritto potrebbe essere utilizzato in varie implementazioni in cui gli allarmi basati sulla localizzazione sarebbero vantaggiosi. Ad esempio, anche se il sistema ? descritto sopra in relazione alla telematica dei veicoli, potrebbe essere applicato ad una serie di altri campi e funzioni. Tra questi figurano: allarmi in caso di calamit? naturali (ad esempio, allarmi per tsunami e terremoti); allarmi meteorologici (ad esempio, uragano, neve, inondazioni, vento forte); allarmi antincendio; allarmi sanitari (ad esempio, allarmi per pandemie o prevalenza di virus); allarmi per l'inquinamento; allarmi per l'alto numero di pollini; allarmi per la radioattivit?; promozioni commerciali o commerciali; e/o notifiche di attrazioni turistiche o punti di interesse. Si pu? prevedere un numero qualsiasi di implementazioni.

Nella descrizione di cui sopra, il dispositivo client utilizzato per l'abbonamento o la pubblicazione pu? essere qualsiasi dispositivo configurato per comunicare su una rete, e pi? specificamente su una rete cellulare. Il dispositivo client pu? essere qualsiasi tipo di dispositivo mobile o utente o apparecchiatura utente, inclusi, a titolo esemplificativo ma non esaustivo, un terminale mobile, un telefono cellulare, un assistente digitale personale (PDA), un computer portatile, un tablet computer, un personal computer, un qualsiasi dispositivo di comunicazione portatile o personale, un dongle per bus seriale universale (USB) o una scheda dati, ad esempio. Si prevede che il dispositivo client possa essere anche un dispositivo fisso o non mobile, come un server o un altro dispositivo informatico.

Il dispositivo client sar? configurato per ospitare il client del protocollo di pubblicazione/abbonamento. Di conseguenza, il dispositivo client sar? composto almeno da una memoria e da un processore, in cui l'esecuzione delle istruzioni del programma memorizzate in memoria ed eseguite sul processore fa s? che il dispositivo client intraprenda determinati passi ed esegua determinate funzioni. Il dispositivo client comprende inoltre almeno un'interfaccia di comunicazione per la trasmissione di un abbonamento e/o la ricezione di una pubblicazione. Il dispositivo client pu? includere varie altre caratteristiche hardware e software, come un ricetrasmettitore del sistema di navigazione o di posizionamento (ad esempio un ricetrasmettitore per l'uso in un sistema globale di navigazione satellitare (GNSS)).

Il server per il sistema sopra descritto ? un server all'interno di una rete cellulare. Il server ? configurato per ospitare un broker del protocollo di pubblicazione/abbonamento. Di conseguenza, il server comprende almeno una memoria e un processore, in cui l'esecuzione delle istruzioni del programma memorizzate in memoria ed eseguite sul processore fa s? che il server intraprenda determinati passi e svolga determinate funzioni. Il server comprende inoltre almeno un'interfaccia di comunicazione per la ricezione di un abbonamento e/o la trasmissione di una pubblicazione. Il server pu? includere varie altre caratteristiche hardware e software.

All'interno delle cifre sopra descritte sono inclusi alcuni diagrammi di flusso, a cui si fa riferimento in relazione ai metodi descritti. Resta inteso che ogni blocco del diagramma di flusso (e/o ogni passo dei metodi sopra descritti), e combinazioni di blocchi nel diagramma di flusso (e/o combinazioni di passi nei metodi sopra descritti), possono essere implementati con vari mezzi, come hardware, firmware, processore, circuiti, e/o altri dispositivi associati all'esecuzione di software, comprese una o pi? istruzioni di programmi informatici.

Ad esempio, una o pi? delle procedure sopra descritte possono essere realizzate da istruzioni di programma per computer. A questo proposito, le istruzioni del programma per computer che incorporano le procedure sopra descritte possono essere memorizzate da una memoria all'interno del server o del dispositivo client ed eseguite da un processore presso lo stesso apparecchio. Tali istruzioni di programma possono essere caricate su un computer o su un altro apparecchio programmabile (ad esempio, hardware) per produrre una macchina, in modo che il computer o l'altro apparecchio programmabile risultante implementi le funzioni specificate nei blocchi del diagramma di flusso o nei passi del metodo sopra descritto. Queste istruzioni del programma per computer possono anche essere memorizzate in una memoria leggibile dal computer che pu? dirigere o far funzionare un computer o un altro apparecchio programmabile in un modo particolare. Le istruzioni del programma per computer possono anche essere caricate su un computer o su un altro apparecchio programmabile per far s? che una serie di operazioni siano eseguite sul computer o su un altro apparecchio programmabile per produrre un processo implementato dal computer in modo tale che le istruzioni eseguite sul computer o su un altro apparecchio programmabile forniscano operazioni per l'esecuzione delle funzioni specificate nei blocchi del diagramma di flusso e/o nelle fasi del metodo sopra descritto.

Come discusso nel presente documento, un supporto di memorizzazione o una memoria leggibile dal computer si riferisce ad un supporto di memorizzazione fisico (ad esempio, un dispositivo di memoria volatile o non volatile) all'interno di un dispositivo di calcolo.

Nel caso in cui il metodo sopra descritto indichi "nel dispositivo del cliente" o "nel server", la persona esperta comprender? che ci? pu? indicare rispettivamente "nel cliente ospitato nel dispositivo del cliente" o "nel broker ospitato presso il server".

Anche se ora sono state descritte specifiche forme realizzative, la persona esperta si render? conto che sono possibili varie modifiche e alterazioni. Tutte le caratteristiche qui descritte possono essere combinate in qualsiasi combinazione, ad eccezione delle combinazioni in cui almeno alcune di queste caratteristiche e/o fasi si escludono a vicenda. In particolare, le caratteristiche preferite dell'invenzione sono applicabili a tutti gli aspetti dell'invenzione e possono essere utilizzate in qualsiasi combinazione ragionevole. Allo stesso modo, le caratteristiche descritte in combinazioni non essenziali possono essere usate separatamente (non in combinazione).

Claims

RIVENDICAZIONI

1. Un dispositivo client per uso in una rete cellulare che fornisce pubblicazioni basate sulla localizzazione utilizzando un protocollo di pubblicazione/abbonamento, comprendente almeno un processore ed almeno una memoria che memorizza le istruzioni del codice di programma, in cui l'esecuzione delle istruzioni del codice di programma nel processore fa s? che il dispositivo client:

determini una posizione geografica significativa per il dispositivo client; determini un geohash in abbonamento, per identificare un'area che comprenda la posizione geografica significativa per il dispositivo client;

invii un abbonamento ad un server, l'abbonamento avendo un nome per l?abbonamento comprendente il geohash di abbonamento.

2. Il dispositivo client della rivendicazione 1, in cui il geohash di abbonamento ? una struttura di dati gerarchica specificata ad un livello di abbonamento.

3. Il dispositivo client della rivendicazione 2, in cui l'esecuzione delle istruzioni del codice di programma nel processore fa ulteriormente s? che il dispositivo client:

determini una velocit? del dispositivo client; e

determini il livello di abbonamento in base alla velocit?.

4. Il dispositivo client della rivendicazione 2 o della rivendicazione 3, in cui il dispositivo client indirizzato per determinare un geohash in abbonamento comprende anche il dispositivo client indirizzato per determinare un geohash in abbonamento specificato al livello di abbonamento, ed in cui il nome dell'abbonamento include un numero predefinito di caratteri, in cui tutti i caratteri del numero predefinito di caratteri che non sono compilati dal geohash in abbonamento specificato al livello di abbonamento sono riempiti con un carattere jolly.

5. Il dispositivo client di una qualsiasi rivendicazione precedente, in cui l'esecuzione delle istruzioni del codice di programma nel il processore fa ulteriormente s? che il dispositivo client:

invii una richiesta al server per annullare l'abbonamento con un nome dell?abbonamento comprendente il geohash di abbonamento.

6. Il dispositivo client di una qualsiasi rivendicazione precedente, in cui l'esecuzione delle istruzioni del codice di programma nel processore fa ulteriormente s? che il dispositivo client:

determini uno o pi? geohash aggiuntivi in abbonamento, che rappresentano una o pi? aree geografiche confinanti con l'area geografica rappresentata dal geohash in abbonamento; e

invii uno o pi? abbonamenti aggiuntivi al server, ciascuno degli uno o pi? abbonamenti aggiuntivi avendo un nome di abbonamento aggiuntivo con un rispettivo nome di abbonamento che comprende uno diverso di uno o pi? geohash di abbonamento aggiuntivo.

7. Il dispositivo client della rivendicazione 6, in cui l'esecuzione delle istruzioni del codice di programma nel processore fa ulteriormente s? che il dispositivo client, prima di determinare l?uno o pi? geohash di abbonamento aggiuntivo:

determini una direzione di movimento del dispositivo client; ed

in cui una o pi? aree geografiche confinanti con l'area geografica rappresentata dal geohash in abbonamento siano una o pi? aree geografiche basate sulla direzione di movimento determinata del dispositivo client.

8. Il dispositivo client di una qualsiasi rivendicazione precedente, in cui l'esecuzione delle istruzioni del codice di programma nell'elaboratore fa s? che il dispositivo client ripeta ulteriormente le fasi dopo lo scadere di un intervallo di tempo; e/o

determini una velocit? del dispositivo client; e

determini l'intervallo di tempo in funzione della velocit?.

9. Un server per uso in una rete cellulare che fornisce pubblicazioni basate sulla localizzazione utilizzando un protocollo di pubblicazione/abbonamento, comprendente almeno un processore ed almeno una memoria che memorizza le istruzioni del codice di programma, in cui l'esecuzione delle istruzioni del codice di programma nel processore fa s? che il server:

riceva un abbonamento da un dispositivo client, l'abbonamento avendo un nome per l?abbonamento comprendente un geohash di abbonamento.

10. Il server della rivendicazione 9, in cui l'esecuzione delle istruzioni del codice di programma nel il processore fa ulteriormente s? che il server:

riceva un messaggio per la pubblicazione in un abbonamento abbinato, il messaggio con il nome della pubblicazione comprendendo un geohash di pubblicazione;

determini se l'abbonamento ? un abbonamento abbinato; e

se l'abbonamento ? un abbonamento abbinato, invii il messaggio al dispositivo client;

in cui il geohash di abbonamento ed il geohash di pubblicazione sono strutture di dati gerarchiche specificate ad un rispettivo livello, e l'abbonamento ? un abbonamento abbinato quando, ad ogni livello in cui sia il geohash di pubblicazione sia il geohash di abbonamento sono specificati, il geohash di pubblicazione ad un dato livello corrisponde al geohash di abbonamento allo stesso livello.

11. Un sistema comprendente:

il dispositivo client di una qualsiasi delle rivendicazioni da 1 a 8; ed

il server della rivendicazione 9 o della rivendicazione 10.

12. Un metodo per uso in una rete cellulare che fornisce pubblicazioni basate sulla localizzazione utilizzando un protocollo di pubblicazione/abbonamento, il metodo comprendendo:

determinare, su un dispositivo client, una posizione geografica significativa per il dispositivo client;

determinare, sul dispositivo client, un geohash in abbonamento, per identificare un'area che comprenda la posizione geografica significativa per il dispositivo client;

inviare, dal dispositivo client, un abbonamento ad un server, l'abbonamento con un nome per l?abbonamento comprendendo il geohash di abbonamento.

13. Il metodo della rivendicazione 12, in cui la determinazione, sul dispositivo client, di un geohash in abbonamento comprende la determinazione del geohash in abbonamento specificato ad un livello di abbonamento.

14. Il metodo della rivendicazione 13 comprendente inoltre:

determinare, sul dispositivo client, una velocit? di spostamento del dispositivo client; e

determinare, sul dispositivo client, il livello di abbonamento in base alla velocit?.

15. Il metodo della rivendicazione 13 o 14, in cui il nome dell'abbonamento include un numero predefinito di caratteri, ed in cui tutti i caratteri del numero predefinito di caratteri che non sono compilati dal geohash dell'abbonamento specificato al livello di abbonamento, vengono riempiti con un carattere jolly.

16. Il metodo di una qualsiasi delle rivendicazioni da 12 a 15, che comprende inoltre:

determinare una direzione di movimento del dispositivo client;

determinare, sul dispositivo client, uno o pi? geohash aggiuntivi, che rappresentino una o pi? aree geografiche nella direzione del movimento del dispositivo client e/o confinanti con l'area geografica rappresentata dal geohash in abbonamento; e

inviare uno o pi? abbonamenti aggiuntivi al server, ognuno dei quali ha un nome di abbonamento con un rispettivo nome di abbonamento che comprende uno diverso di uno o pi? geohash aggiuntivi.

17. Il metodo di una qualsiasi delle rivendicazioni da 12 a 16, comprendente inoltre: ricevere, sul server, l'abbonamento dal dispositivo client, l'abbonamento con il nome di abbonamento comprendendo il geohash di abbonamento;

ricevere, sul server, un messaggio per la pubblicazione ad un abbonamento abbinato, il messaggio avente un nome di pubblicazione comprendendo un geohash di pubblicazione;

determinare, sul server, se l'abbonamento ? un abbonamento abbinato; e se l'abbonamento ? un abbonamento abbinato, inviare il messaggio al dispositivo client;