IT202000002140A1 - Metodo e sistema per il trattamento certificato di documentazione fotografica - Google Patents

Description

Descrizione dell?invenzione industriale dal titolo ?Metodo e sistema per il trattamento certificato di documentazione fotografica"

La presente invenzione si riferisce ad un metodo e ad un sistema per il trattamento di documentazione fotografica che garantisca l?originalit? della documentazione e la sua non alterazione successivamente al momento dell?acquisizione da parte dell?apparato fotografico.

Qui con documentazione fotografica si intender? sia una o pi? fotografie, sia uno o pi? filmati. Ugualmente con ?immagine fotografica? si intenderanno qui sia filmati sia fotografie e con ?ripresa fotografica? sia scatti di fotografie si riprese di filmati.

Sono noti molti casi per i quali ? necessario avere una documentazione fotografica che sia con certezza originale e non alterata, eventualmente anche associata ad informazioni aggiuntive quali il momento e il luogo nei quali la documentazione fotografica stessa ? stata prodotta.

Ad esempio, nel caso di pratiche assicurative avviate a seguito di eventi che comportano il danneggiamento di un bene assicurato (quali possono essere gli incidenti d?auto, i danni a strutture immobiliari, ad esempio provocati da perdite d?acqua, ecc.), ? necessaria una documentazione fotografica che permetta al perito dell?assicurazione di stimare l?entit? dei danni per fornire una valutazione dell?eventuale rimborso assicurativo da assegnare.

Solitamente ? lo stesso perito che realizza la documentazione fotografica e che si fa cos? garante della validit? di essa. Ci? per? comporta un costo per le assicurazioni e la necessit? per il perito di recarsi sul posto per realizzare la documentazione fotografica. Inoltre, a volte la valutazione dovrebbe essere eseguita confrontando fra loro lo stato del bene precedente al danneggiamento e lo stato del bene dopo il danneggiamento. Sarebbe in tale caso perci? utile avere una documentazione fotografia certificata che mostri il bene assicurato anche prima del danno, ma ci? non ? sempre possibile perch? un perito dovrebbe recarsi a visionare i beni al momento della stipula dell?assicurazione e realizzare la documentazione fotografica da mantenere in modo sicuro in un archivio fino a che non accada un danneggiamento da valutare.

Scopo generale della presente invenzione ? fornire un metodo e un sistema che permettano di produrre documentazione fotografica certificata, eventualmente associata a dati temporali e di luogo, senza che chi produce la documentazione debba anche certificarne l?originalit? e una inalterazione futura.

In tale modo, la documentazione fotografica pu? essere prodotta da chiunque e, ad esempio, dallo stesso assicurato.

In vista di tale scopo si ? pensato di realizzare, secondo l'invenzione, un metodo di generazione di documentazione fotografica certificata, comprendente:

-in un dispositivo portatile (11) dotato di una unit? di ripresa fotografica (15) per l?acquisizione di una immagine fotografica e una unit? (17) per la comunicazione remota, le fasi di:

a) acquisire dall?unit? di ripresa fotografica (15) una immagine fotografica e inserirla in un file;

b) calcolare l?hash del file e associarlo a tale file;

c) trasmettere il file con l?associato hash ad una entit? remota di elaborazione (12) mediante l?unit? (17) per la comunicazione remota;

-nella entit? remota di elaborazione, le fasi di:

d) generare un corrispondente URI per il file e memorizzare il file con tale corrispondente URI associato;

e) recuperare l?associato hash del file e associarlo al detto corrispondente URI del file;

f) firmare digitalmente l?URI e l?hash del file per produrre corrispondenti URI firmato e hash firmato e memorizzarli per usi futuri.

Si ? inoltre pensato di realizzare un metodo di recupero sicuro di documentazione fotografica certificata generata con il metodo precedente, comprendente le fasi di:

h) richiedere alla detta entit? remota di elaborazione, mediante un corrispondente URI, un file memorizzato dell?immagine fotografica che si desidera recuperare;

i) ricevere dall?entit? remota tale file e il corrispondente hash firmato memorizzato;

f) ricalcolare l?hash del file ricevuto;

g) confrontare l?hash firmato ricevuto e l?hash ricalcolato e decidere che il file ricevuto ? la voluta documentazione fotografica certificata se il confronto ? positivo.

Il metodo di generazione e il metodo di recupero sicuro secondo l?invenzione permettono di avere un efficace, pratico e sicuro sistema di gestione di documentazione fotografica.

Si ? anche pensato di realizzare un sistema computerizzato che applica tali metodi.

Per rendere pi? chiara la spiegazione dei principi innovativi della presente invenzione ed i suoi vantaggi rispetto alla tecnica nota si descriver? di seguito, con l'aiuto dei disegni allegati, una realizzazione esemplificativa applicante tali principi. Nei disegni:

-figura 1 rappresenta una vista schematica si un dispositivo di ripresa fotografica opportunamente programmabile e programmato, associato ad una struttura di gestione delle riprese fotografiche secondo la presente invenzione;

-figura 2 rappresenta una vista schematica a blocchi del funzionamento interno del dispositivo di ripresa fotografica secondo l?invenzione;

-figura 3 rappresenta una vista schematica a blocchi del funzionamento di una parte di gestione e certificazione della documentazione fotografica prodotta dal dispositivo di ripresa secondo le figure 1 e 2;

-figura 4 rappresenta una vista schematica a blocchi del funzionamento di una parte di verifica della originalit? della documentazione fotografica secondo l?invenzione.

Con riferimento alle figure, in figura 1 ? mostrato schematicamente il sistema di produzione e certificazione di documentazione fotografica secondo l?invenzione.

Il sistema, indicato genericamente con 10, comprende almeno un dispositivo portatile di ripresa fotografica 11 che comunica con una entit? remota 12 di elaborazione per la gestione della documentazione fotografica prodotta dal dispositivo, la quale a sua volta interagisce con una entit? 13 di certificazione e con una entit? 14 di verifica a richiesta della documentazione fotografica.

Il dispositivo 11 di ripresa fotografica ? un dispositivo programmabile, in s? noto, opportunamente programmato per funzionare secondo il metodo della presente invenzione. Il dispositivo comprende una unit? di ripresa fotografica 15, una unit? di controllo 16, una unit? 17 per la comunicazione remota senza fili ed, eventualmente, una unit? di geolocalizzazione 18 (ad esempio GPS) e un sistema di orologio 19 che fornisce data e ora correnti. Ad esempio, il dispositivo pu? essere realizzato con uno smartphone, un tablet o un computer portatile. In particolare, per i motivi che saranno maggiormente chiari dal seguito, ? stato trovato di particolare utilit? l?impiego di uno smartphone. Per semplicit?, nel seguito si far? perci? riferimento ad uno smartphone come dispositivo portatile 11.

La comunicazione fra il dispositivo portatile 11 e l?entit? remota 12 avverr? vantaggiosamente attraverso la rete internet. Le entit? remote 12 e 13 saranno vantaggiosamente realizzate con uno o pi? opportuni in s? noti servizi e/o server remoti. L?entit? di verifica 14 potr? essere in tutto o in parte realizzata ad esempio in un server al quale si accede attraverso la rete internet (ad esempio attraverso un browser) o in un altro dispositivo remoto (ad esempio un altro dispositivo remoto opportunamente programmato e che pu? essere anche simile o uguale al dispositivo remoto 11) o una combinazione delle due cose.

Solitamente i dispositivi 11 saranno una pluralit? di dispositivi 11, ciascuno a disposizione di un utente che quando necessario potr? produrre la documentazione fotografica secondo l?invenzione.

Tutto ci? sar? maggiormente chiarito dal seguito.

Con riferimento alla figura 2, il dispositivo 11 ha l?unit? di ripresa fotografica 15 (ad esempio una fotocamera integrata) che a comando dell?utente permette di inviare alla unit? di controllo 16 riprese fotografiche o di filmati 20 (secondo quanto desiderato). All?unit? di controllo possono anche essere inviati cosiddetti ?metadati? 21, ricavati nel dispositivo e che sono ritenuti importanti per lo specifico uso delle riprese fotografiche secondo la presente invenzione. Ad esempio, i metadati 21 possono comprendere una geolocalizzazione del dispositivo e/o una indicazione di ora e data nel momento della ripresa fatta tramite l?unit? di ripresa 15, un identificativo del dispositivo impiegato e/o dell?utente, ecc. Tali metadati possono essere prodotti dalle unit? GPS, di orologio, ecc. eventualmente presenti nell?hardware del dispositivo 11. I metadati possono inoltre contenere ad esempio anche un identificativo UUID del dispositivo, un token di accesso dell?utente (ad esempio un Oauth token), specifiche tecniche della fotocamera e del dispositivo e anche tutti gli altri dati ritenuti utili allo scopo e disponibili ed accessibili grazie ai sensori del dispositivo (ad esempio, barometro, giroscopio, accelerometro, sensore di prossimit?, sensore di luce ambientale, impronta digitale, Face ID, ecc.).

Come sar? chiaro dal seguito, i metadati scelti diverranno parte integrante del file di immagine, consentendo, fra le altre cose, di determinarne la provenienza ossia i dati dell'utente e del dispositivo 11.

Nell?unit? di controllo 16 ? in esecuzione una applicazione software che realizza la parte di metodo secondo l?invenzione che ? assegnata al dispositivo remoto 11. Vantaggiosamente, tale applicazione software (o APP) ? in elaborazione all?interno di una sandbox che evita che altre applicazioni software possano interferire con le operazioni secondo il metodo. L?APP nella sandbox prender? vantaggiosamente il controllo esclusivo dell?unit? di ripresa 15 e delle unit? di produzione e memorizzazione dei metadati, per evitarne una loro alterazione fraudolenta. Vantaggiosamente, nella sandbox possono essere eseguite le fasi del metodo o parti delle fasi del metodo associate al dispositivo portatile, cos? da evitare interferenze esterne e possibili frodi.

L?APP dell?invenzione in esecuzione nel dispositivo 11 riceve la ripresa 20 e i metadati 21 e, in un primo blocco 22, li unisce in un file 23, detto ?exlf?. In un ulteriore blocco 24 viene poi calcolato (con un qualsiasi metodo noto) il cosiddetto valore di hash 25 del file 23 e il file 23 e il suo valore di hash vengono uniti in un ulteriore blocco 26 cos? da produrre un file composito 27, detto file FCD. Come noto, il valore di hash (o, in breve, hash) di un file ? una stringa di lunghezza fissa che viene prodotta mediante una opportuna nota funzione matematica partendo dal file in modo che qualsiasi modifica al file produca un differente valore di hash. In altre parole, non ? praticamente possibile modificare il file senza che il valore di hash del file cambi. Ad esempio, pu? essere usato il noto algoritmo di hashing MD5. Il file composito 27 cos? prodotto viene trasmesso dal dispositivo 11, per mezzo della unit? di comunicazione remota 17, all?unit? remota 12 che prender? in carico il file composito 27 per permetterne la certificazione e il successivo uso certificato.

In figura 3 ? mostrato uno schema a blocchi che rappresenta il funzionamento del sistema remoto secondo l?invenzione.

Come si vede in figura 3, il file FCD 27 (o tutti i file FCD 27) prodotto da un dispositivo 11 (o da tutti i dispositivi 11) viene ricevuto dall?unit? remota 12. Tale unit? remota 12 eseguir? elaborazioni sul file FCD 27 per implementare il metodo dell?invenzione, come di seguito descritto con l?aiuto dello schema a blocchi mostrato in figura 3. L?unit? remota potr? essere realizzata vantaggiosamente con uno o pi? server sui quali ? in esecuzione un opportuno software di elaborazione che implementa la specifica parte del metodo secondo l?invenzione.

Come si vede in figura 3, il file FCD 27 viene trattato da un blocco 28 che genera (secondo un qualsiasi metodo noto) un identificativo unico per il file. Tale identificativo ? indicato come URI (Uniform Resource Identifier). Come noto nel campo, un URI ? in sostanza una stringa che identifica una risorsa disponibile nella rete, in modo universale ed univoco. Nel caso specifico, ciascun URI identificher? in modo univoco il corrispondente file FCD 27. Il file FCD 27 e il suo corrispondente URI 29, vengono cos? memorizzati in una opportuna tabella 30 che permetter? al sistema secondo l?invenzione di recuperare un qualsiasi file FCD 27, una volta che se ne conosca il corrispondente URI. L?URI calcolato pu? anche essere ritrasmesso al dispositivo 11 che ha prodotto e inviato il file FCD 27, in modo che il dispositivo 1 e/o l?utente del dispositivo possa recuperare, o indicare a terzi come recuperare, il file FCD 27 attraverso il solo URI corrispondente.

Ci? semplifica la gestione dei file FCD 27, che in genere possono essere di dimensioni alquanto grandi, mentre il corrispondente URI ? in genere una stringa di dimensioni relativamente limitate e perci? pi? facile da maneggiare e memorizzare con poco dispendio di memoria e di risorse.

L?URI consente agli applicativi in cloud di localizzare il file FCD sui server mantenuti nel cloud stesso e di recuperarlo in qualsiasi momento.

Un ulteriore blocco 31 estrae dal file FCD 27 l?hash 25 in esso contenuto e il valore di hash e l?URI del file FCD27 vengono inviati ad un blocco 32 di memorizzazione di essi in una opportuna tabella 33 che permetter? di recuperare il valore di hash di un qualsiasi file FCD 27 di cui si conosce il corrispondente URI.

Gli URI con gli associati hash vengono poi inviati alla entit? 13 di certificazione che li firma digitalmente. Tale entit? 13 pu? essere ad esempio realizzata da un qualsiasi noto sistema certificatore che firma digitalmente URI e gli hash per renderli non alterabili in modo occulto. In altre parole, la certificazione rende impossibile che gli URI e gli hash firmati possano essere alterati senza che sia evidente tale alterazione. Il sistema di certificazione pu? ad esempio valersi di server certificati, blockchain certificata, ecc. L?operazione di ?firma? di file ? comunque una operazione ben nota al tecnico e non ? perci? necessario qui descriverla o mostrarla ulteriormente.

L?entit? di certificazione pu? essere ad esempio un ente terzo certificatore autorizzato che appone una marcatura temporale garantendo in tal modo la corrispondenza tra l?identificativo (URI) del file caricato e la sua impronta digitale o hash.

Gli URI e gli associati hash firmati (indicati per comodit? in figura 3 come URIf e hashf) sono mantenuti in una opportuna struttura dati 34 locale o distribuita. Come ora chiaro al tecnico esperto, la struttura dati 34 pu? essere ad esempio una opportuna tabella memorizzata localmente in un server oppure essere una struttura distribuita nella rete. Nel caso di certificazione mediante blockchain, la struttura stessa della blockchain distribuita potr? essere la struttura di memorizzazione degli URI e hash firmati.

Dopo che un utente ha prodotto la documentazione fotografica con il dispositivo 11 e il sistema ha generato gli URIf e gli hashf firmati, nell?uso del sistema ? possibile fare una richiesta 35 di un qualsiasi file FCDx attraverso la conoscenza della sua URIx. A partire dall?URIx, il sistema secondo l?invenzione sar? in grado di fornire al richiedente sia il desiderato file FCDx sia il corrispondente hashf firmato, come indicato rispettivamente con 36 e 37 in figura 3.

Il richiedente avr? a sua volta a disposizione la parte del sistema secondo l?invenzione destinata alla verifica della originalit? della documentazione fotografica FCDx ricevuta. Tale parte di verifica ? realizzata dalla entit? di verifica 14 come schematicamente mostrato nello schema a blocchi di figura 4. Come sar? chiaro dalla descrizione qui fatta, l?entit? di verifica pu? essere implementata con un server di verifica al quale l?utente che desidera verificare la documentazione pu? accedere da remoto (ad esempio attraverso una interfaccia web) oppure anche essere inserita come programma in un opportuno dispositivo in possesso dell?utente (ad esempio uno smartphone, un tablet, o un computer opportunamente programmati). In ogni caso, dopo che ? stata emessa la richiesta 35 di un file FCDx associato all?URIx, l?entit? 14 riceve tale file e il corrispondente hashf firmato 37.

A partire dal file FCDx 36 ricevuto, l?entit? 14 calcola da esso l?hash 38 mediante un blocco 39 che implementa una funzione matematica di calcolo degli hash corrispondente a quella inizialmente impiegata dal dispositivo 11, cosicch? se il file FCDx ricevuto ? identico a quello inizialmente inviato dal dispositivo 11 allora l?hashx 38 ottenuto dal blocco 39 sar? uguale all?hash 25 a suo tempo ottenuto sul file FCD 27 originario.

L?hashx 28 e l?hashfx 37 vengono infine confrontati in un blocco 40 che produce un risposta 41 positiva (il file FCDx ricevuto non ? stato alterato rispetto all?originario file FCD 27) se gli hash 37 e 38 sono uguali, oppure un risposta 41 negativa (il file FCDx ricevuto ? stato alterato rispetto all?originario file FCD 27) se gli hash 37 e 38 sono differenti.

Si realizza cos? il metodo di recupero sicuro di documentazione fotografica certificata e che ? stata generata con il metodo di generazione sopra descritto.

E? a questo punto chiaro come si siano raggiunti gli scopi dell?invenzione. Grazie ai principi dell?invenzione, un utente in possesso di un dispositivo 11 pu? autonomamente produrre la documentazione fotografica (con foto, filmati e metadati aggiunti) e un altro utente, con accesso al sistema di verifica 14, quando lo desidera pu? ricevere tale documentazione fotografica con la certezza che sia rimasta inalterata rispetto a quella inizialmente prodotta.

Si elimina quindi la necessit? di impiegare una persona terza che certifichi la documentazione fotografica al momento della acquisizione.

In tale modo, ? ad esempio possibile che lo stesso cliente che stipula una assicurazione pu? anche fornire la documentazione fotografica del danno subito dal suo bene assicurato (ed eventualmente, preventivamente, dello stato del bene prima del danno) senza necessit? che un perito si rechi sul posto al solo scopo di procurarsi da s? la necessaria documentazione fotografica.

Naturalmente, come ora chiaro al tecnico sulla base della descrizione qui fatta dell?invenzione, oltre ai metadati descritti sopra, altri metadati ritenuti utili possono essere associati alle riprese fotografiche. Inoltre, nel file FCD trasmesso dal dispositivo 11 possono anche essere inserite ulteriori informazioni utili come ad esempio, ulteriori file (ad esempio file di testo descriventi una polizza assicurativa associata al danno mostrato nella documentazione fotografica). Gli utenti dell?APP sul dispositivo 11 possono, oltre che produrre immagini attraverso la fotocamera dello dispositivo anche, ad esempio, leggere, attivare ed archiviare codici a barre, QR code, smart tags o altri marcatori che possono venire associati come metadati alle immagini e certificate con esse.

Le immagini riprese, gli eventuali metadati e gli eventuali eventi ed attivazioni legate alla lettura dei codici o altro, vengono abbinati in modo univoco ai dati rilevati dai sensori del dispositivo 11 utilizzato, nel momento e nel luogo in cui vengono attuate le procedure dell?APP sul dispositivo 11. Tali files e tali dati sono controllati dalla APP, eventualmente taggati con i dati dell?utente e con data, ora e luogo indicati dai sensori del dispositivo 11 e salvati in appositi files, che il sistema dell?invenzione rende inaccessibili e immodificabili.

Le immagini fotografiche contenute nei files FCD prodotti dal sistema possono cos? testimoniare in modo sicuro lo stato, l?alterazione o cambiamento di stato, un evento, le condizioni di un bene o la sua stessa reale esistenza, la relativa entit? di alterazione, in un determinato luogo e momento temporale. Naturalmente, il bene pu? essere di un qualsiasi tipo (un immobile, un oggetto, una automobile, un documento, ecc.).

Il metodo secondo l?invenzione permette di rendere anche gli elementi probanti contenuti negli FCD opponibili verso terzi in termini legali in quanto ne garantisce sia la genuinit? sia l'inalterabilit? e la provenienza.

Il fatto che l?APP sia vantaggiosamente eseguita in una sandbox non accessibile dall?esterno della stessa applicazione consente di evitare ulteriormente il rischio di possibili manipolazioni illecite.

L?APP descritta secondo l?invenzione pu? essere sviluppata facilmente in codice nativo per i dispositivi smartphone che sfruttano i vari sistemi operativi (ad esempio Android e iOS). Con una APP nativa (che si interfaccia in maniera diretta con tutti gli elementi interni dello smartphone e sfrutta le solide infrastrutture software su cui si basano questi sistemi operativi) ? ancora pi? facile realizzare una sandbox che isoli le funzioni critiche dell?APP da possibili interferenze esterne, anche fraudolente.

Infatti, l?unica interazione critica tra l?APP e il sistema operativo avviene nel momento in cui l?immagine acquisita viene allocata nella memoria volatile del dispositivo, prima di essere elaborata nei successivi passaggi.

Una manomissione dell?immagine dovrebbe perci? prevedere dei meccanismi che intercettino le allocazioni di memoria in cui ? posizionata l?immagine una volta acquisita e, in particolare, le informazioni ExIf, insieme alle allocazioni di memoria relative alla firma dell?immagine. Inoltre, ogni elaborazione di tali informazioni dovrebbe modificare tali dati in maniera coerente.

Le informazioni sulle allocazioni di memoria sono per? presenti solo nella sandbox in cui opera l?algoritmo critico dell?APP e non ? possibile accedervi durante l?esecuzione dell?APP stessa.

Inoltre, ? possibile fare in modo che la sequenza di operazioni critiche dell?APP non possa essere interrotta dal momento in cui viene generata l'immagine fino al momento in cui vengono inviate le informazioni al server. Pertanto, qualsiasi interruzione forzosa di tale flusso, finalizzata ad esempio all'alterazione dei dati, non consentirebbe all'algoritmo di concludersi. In tal caso quindi il file verrebbe scartato e l'algoritmo ricomincerebbe dall'inizio, ossia sarebbe necessario procedere con l'acquisizione di una nuova immagine.

Naturalmente, la descrizione sopra fatta di realizzazioni applicanti i principi innovativi della presente invenzione ? riportata a titolo esemplificativo di tali principi innovativi e non deve perci? essere presa a limitazione dell'ambito di privativa qui rivendicato.

Ad esempio, per comodit? l?unit? 12 pu? essere suddivisa in un primo server 42 di gestione degli FCD e in un secondo server 43 di gestione degli hash, oppure pu? essere impiegato un unico server per entrambe le funzioni o anche si possono suddividere ulteriormente le varie funzioni su pi? di due server. I server possono anche essere collegati in cloud attraverso la rete o con altri sistemi di comunicazione.

La produzione di URI e hash firmati pu? avvenire ad ogni nuovo URI e has che entra nel sistema oppure l?entit? 12 che li genera pu? accumularli per un certo lasso temporale (ad esempio 12 o 24 ore) per poi inviarli in blocco all?ente certificatore 13 per la firma.

Per garantire la sicurezza del trasferimento dei dati tra i sistemi pu? essere utilizzato un noto protocollo cifrato sicuro (ad esempio il protocollo HTTPS con chiave di cifratura delle comunicazioni 2.048 bit) attraverso il certificato rilasciato da apposito ente certificatore autorizzato.

Sebbene il calcolo dell?hash iniziale 25 sia stato sopra descritto come eseguito nel dispositivo 11, pu? anche essere pensato che il dispositivo 11 invii il file senza hash e l?hash venga calcolato direttamente dall?entit? 12, invece che estratto dal file ricevuto.

Claims (12)

1. Rivendicazioni 1. Metodo di generazione di documentazione fotografica certificata, comprendente: -in un dispositivo portatile (11) dotato di una unit? di ripresa fotografica (15) per l?acquisizione di una immagine fotografica e una unit? (17) per la comunicazione remota, le fasi di: a) acquisire dall?unit? di ripresa fotografica (15) una immagine fotografica e inserirla in un file; b) calcolare l?hash del file e associarlo a tale file; c) trasmettere il file con l?associato hash ad una entit? remota di elaborazione (12) mediante l?unit? (17) per la comunicazione remota; -nella entit? remota di elaborazione, le fasi di: d) generare un corrispondente URI per il file e memorizzare il file con tale corrispondente URI associato; e) recuperare l?associato hash del file e associarlo al detto corrispondente URI del file; f) firmare digitalmente l?URI e l?hash del file per produrre corrispondenti URI firmato e hash firmato e memorizzarli per usi futuri.
2. 2. Metodo secondo rivendicazione 1, caratterizzato dal fatto che l?entit? remota di elaborazione comprende almeno un primo server (42) di esecuzione delle fasi d) ed e) e almeno una separata entit? di certificazione (13) per l?esecuzione della firma di URI e hash della fase f).
3. 3. Metodo secondo rivendicazione 2, caratterizzato dal fatto che l?entit? remota di elaborazione comprende almeno un secondo server (43), il primo server inviando hash e URI delle fasi d) e f) al secondo server che le memorizza per inviarle in momenti prestabiliti alla entit? di certificazione (13).
4. 4. Metodo secondo rivendicazione 1, caratterizzato dal fatto di comprendere nel dispositivo portatile (11) l?ulteriore fase di: g) introdurre metadati nel file.
5. 5. Metodo secondo rivendicazione 4, caratterizzato dal fatto che i metadati sono scelti fra uno o pi? fra dati temporali, dati di geolocalizzazione del dispositivo, dati identificativi del dispositivo e/o dell?utente impiegante il dispositivo, dati barometrici, giroscopici, di accelerazione, di orientamento, di prossimit?, di luce ambientale, di impronta digitale, Face ID.
6. 6. Metodo secondo rivendicazione 4, caratterizzato dal fatto che il dispositivo contiene una unit? GPS e/o una unit? di orologio per fornire i metadati di geolocalizzazione e/o temporali.
7. 7. Metodo secondo rivendicazione 1 e/o 4, caratterizzato dal fatto che il dispositivo portatile (11) esegue le sue fasi del metodo o parti delle sue fasi del metodo in una sandbox.
8. 8. Metodo secondo rivendicazione 1, caratterizzato dal fatto che gli URI firmati e gli associati hash firmati sono memorizzati in una opportuna struttura dati (34) locale o distribuita nella rete, preferibilmente, in forma di blockchain.
9. 9. Metodo di recupero sicuro di documentazione fotografica certificata generata con il metodo secondo una qualsiasi delle rivendicazioni precedenti, comprendente le fasi di: h) richiedere alla detta entit? remota di elaborazione, mediante un corrispondente URI, un file memorizzato dell?immagine fotografica che si desidera recuperare; i) ricevere dall?entit? remota tale file e il corrispondente hash firmato memorizzato; f) ricalcolare l?hash del file ricevuto; g) confrontare l?hash firmato ricevuto e l?hash ricalcolato e decidere che il file ricevuto ? la voluta documentazione fotografica certificata se il confronto ? positivo.
10. 10. Metodo secondo rivendicazione 9, caratterizzato dal fatto che le fasi da h) a g) sono realizzate in una entit? remota di verifica (14).
11. 11. Metodo secondo rivendicazione 10, caratterizzato dal fatto che l?entit? di verifica (14) ? in tutto o in parte realizzata in un altro dispositivo remoto e/o in un server al quale si accede da remoto attraverso una rete internet.
12. 12. Sistema computerizzato applicante il metodo di una o pi? delle rivendicazioni precedenti.