ITTO20091055A1 - "procedimento e dispositivi per la distribuzione di contenuti mediali e relativo prodotto informatico" - Google Patents

Description

“Procedimento e dispositivi per la distribuzione di contenuti mediali e relativo prodotto informaticoâ€

* ;;TESTO DELLA DESCRIZIONE ;;Campo dell’invenzione ;La presente descrizione si riferisce alle tecniche per la distribuzione di contenuti mediali. ;La descrizione à ̈ stata messa a punto con particolare attenzione al possibile impiego nel contesto delle cosiddette reti Peer-to-Peer (nel seguito indicate come reti P2P). ;;Descrizione della tecnica relativa ;Le reti Peer-to-Peer (P2P) sono un particolare tipo di ambiente creato a livello applicativo da un’applicazione software locale con la capacità di comunicare con altri utilizzatori della rete che eseguono lo stesso software in modo da creare una rete in sovrapposizione (overlay) a livello applicativo in cui ciascun utilizzatore terminale condivide i suoi contenuti e le risorse con i peer della sovrapposizione. ;Questo aspetto cooperativo rappresenta il principale pregio dei sistemi P2P, in quanto permette alla comunità di scaricare/caricare contenuti in un rapporto di mutua cooperazione con la capacità di crescere in modo indefinito senza dover far ricorso ad alcun server dedicato con le relative potenzialità. Questa caratteristica à ̈ correntemente denominata “scalabilità†della rete. ;Esiste da tempo un marcato interesse per la possibilità di sfruttare le potenzialità delle reti P2P nel contesto mediale, in particolare per quanto riguarda lo streaming di segnali audio e video, per applicazioni di web TV, facilitate dalla crescente penetrazione delle reti di distribuzione a larga banda. Ciò vale sia per la possibilità di erogare contenuto “professionale†, sia per la possibile distribuzione di contenuti generati dagli utilizzatori, tale da far sì che ciascun utilizzatore possa essere allo stesso tempo produttore e consumatore di contenuti, assumendo quindi il profilo di “prosumer†(producer/consumer). ;La figura 1 rappresenta sotto forma di uno schema a blocchi funzionali i principali componenti di un sistema P2P. ;In particolare, nello schema della figura 1, i riferimenti P0 e P1 indicano schematicamente i terminali (fissi/mobili) di due utilizzatori finali (end-user) che cooperano in un sistema P2P appoggiandosi ad un cosiddetto tracker T (inseguitore), ad un terminale con funzione di client C0 e ad un server di rete (web server) WS. ;La condivisione di file nei sistemi P2P si basa sull’impiego di programmi utilizzati per creare e mantenere una rete che permette la trasmissione dei file fra gli utilizzatori. Gli utilizzatori hanno così la possibilità sia di scaricare file a partire da altri utilizzatori della rete P2P sia di indicare insiemi di file nel file system del proprio terminale suscettibili di essere condivisi con altri, ossia di essere resi disponibili ad altri utilizzatori della rete P2P. ;Un protocollo di condivisione dei file in una rete Peer-to-Peer di impiego corrente in grado di distribuire quantità rilevanti di dati à ̈ quello noto come BitTorrent. Oltre che nella versione client originale, tale protocollo à ̈ disponibile in numerose implementazioni sostanzialmente affini fra le quali si possono citare, ad esempio aria2, ABC, BitComet, BitTornado, Deluge, Shareaza, Transmission, µTorrent, Vuze (già Azureus). ;Al momento attuale ci sono numerosi client disponibili per una varietà di piattaforme di calcolo in grado di preparare, richiedere e trasmettere ogni tipo di file su una rete utilizzando tale protocollo. ;In sostanza, il sistema schematicamente rappresentato nella figura 1 si basa sull’impiego di file .torrent contenenti meta-informazione (metadata information) sul file originale destinato ad essere condiviso dagli utilizzatori della rete P2P e dal tracker T destinato a tenere traccia dei peer che condividono il contenuto. Il tracker T gioca il ruolo di entità centrale con la quale i peer come P0 e P1 nella figura 1 comunicano periodicamente (sostanzialmente tramite un meccanismo di registrazione periodica) così da poter essere a conoscenza l’uno dell’altro. Il tracker T trasmette e riceve l’informazione sui peer e mantiene anche le relative statistiche. Si apprezzerà peraltro che, mentre lo schema della figura 1 si riferisce ad un tracker T di tipo centralizzato, à ̈ anche possibile far ricorso a soluzioni distribuite (come quella nota come DHT – Distributed Hash Table) così da tener traccia dei peer che stanno condividendo un certo contenuto in un certo momento. Si apprezzerà che quanto detto nel seguito di questa descrizione prescinde dal fatto che si ricorra ad un approccio centralizzato oppure ad un approccio distribuito. Per quanto riguarda i client BitTorrent che condividono e scaricano i contenuti, almeno uno (ad esempio il client indicato con C0 nella figura 1) accede all’intero file reso disponibile dal web server WS in vista dello scaricamento. Secondo l’approccio corrente, il server WS à ̈ quanto l’utilizzatore finale vede come prima cosa all’atto della scelta del file .torrent. Il web server WS costituisce quindi uno degli attori complementari suscettibili di essere preso in conto nell’implementazione di una rete P2P. Per essere più precisi, il server WS e’ una delle possibili entità che distribuiscono il metadato, il file .torrent. Tutti i peer della rete ricuperano tale file per poter accedere al contenuto mediale vero e proprio. Il modo in cui il metadato à ̈ ricuperato non à ̈ predefinito. Il caso tipico à ̈ che i peer lo scarichino appunto da WS (o da un altro web server equivalente) tramite normale protocollo client/server; à ̈ però possibile che il recupero del metadato avvenga in altro modo (via chat, Facebook, email, chiavetta USB, ecc.). In tutti i casi il metadato viene distribuito fuori dalla rete P2P. La struttura complessiva di un file torrent (ad esempio MyFile.torrent) à ̈ la seguente: ;- identificazione (announce) dell’URL del tracker T - un dizionario (info) contenente le chiavi che seguono ;- nome (name): un nome suggerito per salvare l’entità informativa. Se l’entità à ̈ un singolo file, questa chiave rappresenta un nome di file. Se l’entità comprende più file, la chiave in questione fornisce una mappa rispetto ad un nome in una directory ;- lunghezza pezzi (piece length): la dimensione di ciascun “pezzo†dell’entità ;- una stringa (denominata “Pieces(*)†) contenente la concatenazione di tutti gli hash SHA1 di ciascun pezzo dell’entità

- lunghezza (length): la lunghezza del file in byte. Se à ̈ presente questa chiave, essa significa che l’entità à ̈ un singolo file, altrimenti sarà presente la chiave “files†con la relativa lista dell’insieme dei files. Se l’entità da scaricare à ̈ una directory di più file, al posto della lunghezza (length) sarà presente la chiave “files†con le relative meta-informazioni.

- file: un elenco di file e directory con le seguenti chiavi:

- lunghezza: la lunghezza dei file in byte,

- cammino (path): un elenco di stringhe contenenti nomi di sotto-directory con l’ultima stringa che rappresenta il nome del file. Nel caso di un’insieme di file, sarà presente il nome della directory.

I file .torrent con questa struttura sono dei file di meta-informazione (nel seguito per brevità, file di metadati) creati prima che il file o i file (ossia la “entità†) siano condivisi.

Pur non costituendo l’entità stessa, i file .torrent contengono meta-informazione necessaria per permettere ad un client BitTorrent di scaricare un’entità (ad esempio, come già si à ̈ visto, l’URL del tracker, il filename, il numero di pezzi ecc. del contenuto). Un vantaggio legato all’impiego dei file .torrent à ̈ che gli stessi presentano dimensioni di gran lunga inferiori rispetto alle dimensioni dell’entità originaria, che nel caso ad esempio di contenuti mediali in alta definizione può raggiungere dimensioni nell’ordine del Gigabyte. I peer che desiderano scaricare un file di entità devono quindi dapprima ottenere un file .torrent corrispondente e collegarsi al tracker specificato, che dice loro da quali altri peer possono scaricare i pezzi del file. Gli utilizzatori navigano nella rete per trovare un torrent che interessi loro, scaricarlo ed aprirlo con un client BitTorrent. Il client si collega al tracker o ai tracker specificati nel file .torrent, dal quale ricevono un elenco di peer che al momento stanno trasferendo pezzi del file o dei file specificati nel torrent. A questo punto può cominciare il procedimento di scaricamento vero e proprio con ciascun peer che condivide nella rete in sovrapposizione le sue risorse di caricamento ed i suoi contenuti scambiando blocchi o “chunk†del file.

Il peer che distribuisce un file (che sia dati o rappresentante un contenuto multimediale) tratta lo stesso come una serie di pezzi con le stesse dimensioni. Il peer crea una somma di controllo (checksum) per ciascun pezzo utilizzando un qualunque algoritmo utilizzabile a tale scopo, ad esempio l’algoritmo di hash SHA1, e lo registra nel file .torrent dei metadati. La dimensione del pezzo à ̈ la stessa per ciascun pezzo e può essere configurata dall’utilizzatore quando decide di creare il file metadati. Nel caso di un carico utile (payload) molto grande, à ̈ possibile ridurre le dimensioni di un file metadati ricorrendo a pezzi di grandi dimensioni, ad esempio maggiori di 512 Kbyte, ma questo riduce l’efficienza del protocollo.

Quando un altro peer più tardi riceve un particolare pezzo, la checksum del pezzo à ̈ confrontata con una checksum registrata per verificare che il pezzo sia esente da errori. Nel caso del protocollo BitTorrent, le informazioni di uscita prodotte dell’algoritmo SHA1 (info_hash) sono lunghe 20 byte e sono elencate nel file torrent in corrispondenza del campo “pieces†, per cui a questo campo à ̈ demandata la verifica dell’integrità dei pezzi dei dati e dunque dell’integrità del contenuto stesso.

In numerosi contesti che prevedono l’impiego di contenuti mediali (computer vision, riconoscimento del parlato, information retrieval) ed anche in nuovi standard come MPEG-7, P/META, à ̈ noto ricorrere a tecniche di estrazione delle caratteristiche semantiche (semantic feature extraction) così da facilitare l’identificazione di un certo contenuto mediale, ad esempio a fini di classificazione e di archiviazione, con possibili vantaggi anche sul lato dell’utilizzatore terminale.

Nel caso di un contenuto multimediale, il cosiddetto “storyboard†à ̈ un esempio di estrazione delle caratteristiche semantiche utilizzabili per facilitare il “browsing†del contenuto video.

I contenuti semantici possono essere presentati sotto forma di linee di testo o di cosiddetti “thumbnail†, così come accade ad esempio per l’interfaccia di YouTube®.

Nel caso di file video (ad esempio come film o videoclip) à ̈ noto ricorrere a varie tecniche di stima del moto, etichettatura (tagging o labeling), analisi degli istogrammi dei colori, rivelazione di bordi e forme, analisi dell’audio, analisi del parlato, riconoscimento del parlatore, ecc. quali tecniche di estrazione delle caratteristiche semantiche utili per identificare frame chiave che, presentate all’interessato, danno un’idea sufficientemente precisa del contenuto di un determinato file.

Questo può avvenire ad esempio presentando uno storyboard di un file video come sequenza di frame. Un esempio dell’applicazione di queste tecniche à ̈ il browser VideoBAY®.

La presentazione dello storyboard à ̈ una tecnica già utilizzata nell’ambito delle reti P2P al fine di aiutare l’utilizzatore a richiamare il contenuto semantico del contenuto prima di cominciare il processo di scaricamento di un file, in particolare quando lo stesso sia un file piuttosto grosso. La verifica dello storyboard tende anzi a diventare un’abitudine pressoché costante, anche per evitare l’inquinamento del processo di disseminazione da parte di contenuti non desiderati. Di conseguenza, numerosi file .torrent vengono creati a partire da file di archivio compressi contenenti tanto un video quanto i relativi dati semantici quali, ad esempio, uno storyboard, le canzoni contenute, o vari altri tipi di informazione semantica relativa al contenuto. Questi dati semantici sono archiviati in un package compresso insieme al film originale sotto forma di file addizionali e separati.

Gli Inventori hanno peraltro osservato che questo modo di procedere:

- impone all’utilizzatore, al fine di poter accedere ai dati semantici, di accedere alla rete P2P e di scaricare (quanto meno parzialmente) il package ed almeno una parte del contenuto dello stesso;

- la presenza dello storyboard non offre necessariamente protezione contro atteggiamenti malevoli, quali ad esempio l’intervento di un soggetto che crea un archivio fasullo contenente una diversa associazione storyboard/contenuto e crea un nuovo file .torrent corrispondente.

Nel caso del client .torrent noto come Vuze (noto anche come Azureus) à ̈ previsto che il web server centralizzato WS fornisca, oltre ai file di metadato .torrent, informazioni relative al contenuto, reperito sulla rete BitTorrent. L’applicazione client ha al suo interno un browser in grado di accedere al server centralizzato così da ottenere un’anteprima dei contenuti disponibili. Facendo clic sull’anteprima del contenuto il client scarica il file .torrent associato che viene utilizzato per accedere alla rete P2P. In questo caso l’associazione fra il contenuto ed i metadati associati à ̈ garantita dalla banca dati centralizzata fornita dal web server ufficiale Vuze.

Gli inventori hanno osservato che questa soluzione presenta due inconvenienti fondamentali:

- in primo luogo, centralizza la distribuzione dei contenuti e dei metadati P2P associati, costringendo il client a collegarsi ad uno specifico server di rete per reperire i metadati di interesse, il che riduce lo spettro dei possibili canali di distribuzione dei metadati;

- in secondo luogo, questa soluzione non risulta applicabile nel caso di dispositivi semplici (ad esempio terminali mobili), le cui capacità di esplorazione della rete sono di necessità ridotte. Va ancora osservato che l’approccio tradizionale BitTorrent à ̈ di per sé tale da non impedire la distribuzione dei file .torrent tramite altri mezzi quali posta elettronica, chiavette USB, FTP, chat, Facebook, ecc., il che può essere utile nel contesto dei contenuti generati dall’utilizzatore nel caso in cui il produttore del contenuto desideri controllare e limitare la distribuzione di un certo contenuto. Così come già detto, la distribuzione dei metadati può avvenire al di fuori della rete P2P e può essere pubblica (ad. es. su un web server senza restrizioni) oppure ristretta ad una comunità di peer. Per fare un esempio, se un utilizzatore vuole condividere il filmato del suo matrimonio solo con i parenti attraverso la rete P2P, non distribuirà il metadato (file .torrent) che rappresenta quel contenuto pubblicamente, ma solo ai parenti, magari spedendo loro una email con allegato il file .torrent.

Dal punto di vista brevettuale, documenti quali US2007/033170 descrivono la possibilità di fare una ricerca di contenuti mediante una ricerca sui metadati associati , anche in ambiente P2P, senza peraltro fornire alcuna indicazione relativa a procedimenti per associare e proteggere informazioni semantiche legate al contenuto stesso.

Analogamente, il documento US 2007/0038612 A1 fa riferimento all’impiego di un cosiddetto segnalibro o bookmark multimediale contenente informazioni relative ad un segmento in corrispondenza di un punto intermedio nell’ambito di un procedimento di indicizzazione, ricerca, identificazione e rielaborazione di porzioni di un certo contenuto. Qui non si fa riferimento a possibili applicazioni in un contesto P2P.

Ancora, il documento US-B-5646997 fa riferimento a una soluzione applicabile nell’ambito di sistemi digitali di distribuzione con la possibilità di ottenere informazioni in relazione a un certo contenuto mediale e da formattarle utilizzando una porzione di una struttura dati così da creare una formazione mediale con successiva cifratura o crittazione dello stesso e memorizzazione in vista di un trasferimento su un supporto di memorizzazione. Tutto questo al fine di consentire poi un’interpretazione delle stesse in vista della creazione di informazioni per l’uso di tale supporto. Il documento si riferisce dunque a soluzioni di “Watermarking†per la protezione dei contenuti multimediali, non trattandosi peraltro di scenari “peer to peer†.

Scopo e sintesi dell’invenzione

Le soluzioni cui si à ̈ fatto riferimento in precedenza non sono in grado di soddisfare le esigenze di un utilizzatore finale che desidera scegliere con un livello sufficiente di confidenza (in termini di ragionevole certezza del contenuto e sicurezza sull’origine) un contenuto da condividere in modalità P2P.

In particolare, à ̈ tuttora avvertita l’esigenza di disporre di soluzioni tali da permettere all’utilizzatore di evitare di dover scaricare anche solo in parte l’entità (ossia i contenuti mediali) per poter avere l’anteprima del contenuto, tenendo in conto, se del caso, anche il fatto che i) il contenuto può essere danneggiato (corrotto) e/o ii) proprio i primi chunk utilizzabili per avere l’anteprima possono essere fra i più difficili da ottenere da peer nella rete in sovrapposizione, ad esempio perché certi peer hanno appena lasciato la rete.

Al riguardo, va tenuto in conto il fatto che lo scaricamento, seppur parziale, del contenuto (anche al solo fine di accedere ad un’anteprima) può richiedere del tempo, in funzione della necessità di stabilire un numero sufficiente di collegamenti con peer. Questo anche perché, affinché un nodo possa diventare una fonte di caricamento (uploader) efficace à ̈ necessario che lo stesso riceva una certa quantità di dati. Oltre a questo, le funzioni di streaming P2P richiedono che, al fine di consentire all’utilizzatore di avviare il suo player e vedere anche solo la prima parte del video per cercare di capire se questo corrisponde a quanto sta cercando, un peer rimane in attesa per un certo periodo di tempo richiesto per riempire un pre-buffer in grado di garantire una riproduzione senza interruzioni.

Ancora, ogni errore nella sequenza di operazioni relative alla scelta del contenuto può comportare un ritardo apprezzabile per l’utilizzatore finale, dovendosi altresì notare che la disconnessione di un peer dalla rete di overlay P2P può creare un “churn rate†piuttosto elevato, riducendo le prestazioni globali della rete P2P, in particolare nel gruppo di utilizzatori che stanno condividendo quello stesso contenuto.

Toccando gli aspetti di sicurezza e di autenticazione, l’inquinamento dei contenuti à ̈ un problema sentito nella comunità P2P dal momento che le entità distribuite sono normalmente identificate dal loro nome e da una breve descrizione. Può quindi succedere che utenti malevoli disseminino nella rete in sovrapposizione file (o anche solo parti degli stessi) con una descrizione fuorviante, facendo finta di condividere un contenuto quando in realtà vogliono distribuire un “falso†(fake) non corrispondente a questo contenuto. Così come già detto, possono ad esempio modificare in modo intenzionale l’associazione fra il contenuto da scaricare e i metadati ad esso associati così da far sì che i metadati non corrispondano al contenuto.

A questo proposito, gli inventori hanno notato che, pur essendo disponibili protocolli in grado di realizzare forme di verifica dell’integrità del contenuto e/o di adottare strategie di comunicazione per verificare l’affidabilità di ciascun peer nella comunità, à ̈ tuttora avvertita l’esigenza di forme di verifica suscettibili di essere condotte direttamente dall’utilizzatore terminale esaminando semplicemente i metadati che descrivono il contenuto evitando (anche se il file di per sé non à ̈ corrotto, in quanto i vari test di integrità sono stati tutti superati) di dover scaricare pezzi del contenuto per verificare l’entità del contenuto stesso.

Al riguardo si può ancora osservare che, ricorrendo alle soluzioni note, l’utilizzatore terminale à ̈ completamente ignaro del contenuto effettivo del file di metadati in corso di scaricamento sino a quando non comincia a esaminare l’anteprima dell’entità vera e propria.

Nelle soluzioni attuali, il file metadati del protocollo BitTorrent contiene infatti soltanto alcuni dati sulle dimensioni, sul numero di chunk e in generale informazioni di interesse per il livello di rete. Tutto questo in condizioni in cui l’utilizzatore finale può essere fuorviato (anche perché può capitare che l’utente non ricordi esattamente il titolo preciso del contenuto che intende scaricare) oppure può non rendersi conto che il contenuto effettivo non gli interessa, con l’ulteriore possibilità che utenti malevoli possano ulteriormente intervenire nel processo. Anche dopo aver scelto il file metadati l’utilizzatore deve aspettare e il ritardo necessario per avere una quantità sufficiente di informazioni per poter valutare il contenuto può essere abbastanza lungo. Può anche capitare che utenti non particolarmente esperti non siano in grado di attivare la funzione di anteprima e siano indotti a scaricare completamente il file prima di poter vedere se il contenuto corrisponde alle loro esigenze. Anche nel caso di utilizzatori esperti, per i quali l’aspetto del tempo perso à ̈ in ogni caso significativo, può benissimo succedere che l’anteprima non sia soddisfacente o indicativa (si pensi al caso in cui l’utilizzatore sia interessato ad una scena che compare soltanto dopo mezz’ora dall’inizio di un film).

Insieme a questi fattori di incertezza legati all’azione di “cliccare†l’avvio dello scaricamento del contenuto non vanno poi trascurati gli inconvenienti legati al fatto che un determinato utilizzatore riconosca, anche in termini ragionevolmente brevi, l’assenza di interesse per il contenuto provvisoriamente scelto. In tal caso si ha uno spreco di risorse di rete (larghezza di banda e potenza di calcolo, non trascurabile) utilizzate soltanto per verificare che un certo contenuto non interessa.

Assume poi un indubitabile rilievo l’aspetto psicologico di frustrazione suscettibile di essere maturata dall’utente rendendosi conto di avere a disposizione uno strumento tecnologico non particolarmente sofisticato. Ancora una volta nell’apprezzamento di questi aspetti entra in gioco il possibile ruolo dell’inquinamento (pollution) della rete P2P messo in atto con azioni deliberate di operatori malevoli interessati a disseminare falsi contenuti. Tutto questo anche senza alterare di per sé i dati puri e semplici, ma cambiando le associazioni fra contenuti e le loro descrizioni a livello di metadati, in altre parole, facendo sì che il file metadati destinato a fornire l’anteprima contenga informazioni non corrispondenti al contenuto. Questo aspetto può assumere un certo rilievo anche per quanto riguarda l’indesiderata diffusione di contenuti pornografici: si pensi - come esempio scontato - all’associazione, ad un video con contenuti “per adulti†, di metadati relativi ad una favola per bambini.

Un tale comportamento à ̈ suscettibile di influenzare in modo negativo la reputazione di chi fornisce il contenuto, sia esso un operatore di livello professionale oppure un prosumer privato, con impatto anche di natura economica nel caso dell’operatore professionale ed impatto sociale negativo nel caso del soggetto privato.

Emerge quindi l’esigenza di disporre di soluzioni tali da permettere di fornire in modo efficiente l’informazione semantica e/o relativa alla sorgente (ossia al producer) in relazione a contenuti condivisi su una rete P2P e – di preferenza - siano anche in grado di assicurare l’integrità di tali metadati scongiurando il possibile ricorrere dei fenomeni negativi delineati in precedenza.

La presente invenzione si prefigge lo scopo di fornire una tale soluzione.

Secondo la presente invenzione, tale scopo à ̈ raggiunto grazie ad un procedimento avente le caratteristiche richiamate in modo specifico nelle rivendicazioni che seguono. L’invenzione riguarda anche corrispondenti dispositivi, nonché ad un prodotto informatico, caricabile nella memoria di almeno un elaboratore e comprendente parti di codice software suscettibili di realizzare le fasi del procedimento quando il prodotto à ̈ eseguito su almeno un elaboratore. Così come qui utilizzato, il riferimento ad un tal prodotto informatico à ̈ inteso essere equivalente al riferimento ad un mezzo leggibile da elaboratore contenente istruzioni per il controllo del sistema di elaborazione per coordinare l’attuazione del procedimento secondo l'invenzione. Il riferimento ad "almeno ad un elaboratore" à ̈ evidentemente inteso a mettere in luce la possibilità che la presente invenzione sia attuata in forma modulare e/o distribuita. Le rivendicazioni formano parte integrante dell’insegnamento tecnico qui somministrato in relazione all’invenzione.

Varie forme di attuazione forniscono una funzione di creazione, e, in modo complementare, di estrazione, di metadati a partire da un contenuto mediale (audio, video etc…) suscettibile di essere distribuito su una rete P2P.

In varie forme di attuazione, l’informazione semantica può comprendere informazione scelta fra frame video, parole derivanti dalla conversione del parlato in testo, commenti, file mp3, estratti eventualmente in modo automatico dal contenuto oppure aggiunti manualmente, di preferenza in unione ad un identificatore di chi ha prodotto il contenuto.

In varie forme di attuazione, i metadati “di scaricamento†(quali quelli già oggi presenti, ad esempio, in un file .torrent al fine di permettere l’accesso ai contenuti mediali condivisi su una rete P2P) sono arricchiti con informazioni di tenore più profondamente semantico relativo al contenuto stesso (metadati “semantici†) e/o al produttore (metadati “di sorgente†) così da aumentare il grado di soddisfazione e ragionevole certezza permettendo all’utilizzatore di avere una anteprima completa ed efficace del contenuto prima di accedere effettivamente al contenuto tramite la rete P2P.

In varie forme di attuazione, i metadati in questione possono essere convalidati tramite una firma elettronica così da verificare la loro integrità, ad esempio sotto forma di una stringa hash sottoposta a crittografia tramite una chiave pubblica generata e associata al produttore di contenuti.

In varie forme di attuazione, il controllo di integrità garantisce che l’informazione inserita dal produttore del contenuto non sia alterata durante tutta la fase di distribuzione.

In varie forme di attuazione, contrariamente a quanto avviene in soluzioni note (dove l’utilizzatore deve cominciare a scaricare il contenuto prima di avere un’idea dello stesso), varie forme di attuazione prevedono di fornire informazioni significative ed effettivamente utilizzabili in grado di dare all’utilizzatore finale un’idea del contenuto di un certo oggetto mediale prima di accedere effettivamente allo stesso.

Varie forme di attuazione consentono di avere un’efficace ricerca e reperimento di un determinato contenuto mediale migliorando la soddisfazione dell’utilizzatore, aumentando nel contempo l’efficienza di tutto il sistema di rete.

Varie forme di attuazione forniscono strumenti di controllo di sicurezza tali da proteggere l’informazione fornita dal produttore del contenuto, in aggiunta alle soluzioni tradizionali dove si verifica unicamente l’integrità del contenuto.

Varie forme di attuazione si prestano ad un impiego da parte di comunità di produttori/consumatori (prosumer) anche nell’ambito di reti di ridotte dimensioni.

Varie forme di attuazione forniscono tecniche che permettono di creare e/o estrarre un nuovo formato di metadati utilizzabile per la distribuzione di contenuti mediali in ambienti P2P utilizzando ad esempio un protocollo di tipo BitTorrent.

Si apprezzerà peraltro che il riferimento a questo particolare tipo di protocollo ha finalità puramente esemplificativa, in quanto varie forme di attuazione si prestano ad essere utilizzate anche in unione a protocolli P2P di tipo diverso (ad esempio i protocolli affini già citati in precedenza).

Varie forme di attuazione permettono di integrare un qualsiasi tipo di informazione semantica (audio/visiva/testuale) relativa al contenuto stesso ed al produttore di tale contenuto.

Varie forme di attuazione permettono di utilizzare algoritmi di tipo diverso per estrarre l’informazione semantica da un contenuto audio e/o visivo.

In varie forme di attuazione, all’operazione di estrazione dell’informazione semantica si accompagna una verifica dell’integrità dell’insieme dei metadati.

Varie forme di attuazione permettono di migliorare, arricchendola, l’esperienza di browsing video da parte degli utilizzatori P2P con effetto deterrente nei confronti di manipolazioni malevole.

Varie forme di attuazione si basano su una funzione di creazione e di estrazione di metadati (metadata) suscettibile di manipolare informazione semantica ai fini di migliorare i formati metadati tradizionali tramite la creazione, l’incorporazione e l’elaborazione dell’informazione semantica tratta dal contenuto. Questa operazione à ̈ suscettibile di essere condotta per via software (sia tramite software di tipo embedded, sia tramite software di terzi).

Si apprezzerà che questo modo di operare à ̈ applicabile tanto a formati già esistenti quanto a formati futuri utilizzabili in un contesto P2P o in generale in un sistema distribuito client-server al fine di minimizzare le risorse che vanno sprecate nel caso di una decisione erronea in relazione al contenuto da scaricare.

Tutto questo al fine di rendere la scelta da parte dell’utilizzatore finale più utile e piacevole, aumentando il livello di confidenza nella comunità dei prosumer e della rete sociale, nonché naturalmente nei confronti delle reti di distribuzione operanti a livello professionale.

Breve descrizione delle rappresentazioni annesse L’invenzione sarà ora descritta, a puro titolo di esempio non limitativo, con riferimento alla rappresentazioni annesse, in cui:

- la figura 1 à ̈ già stata descritta in precedenza, - la figura 2 à ̈ uno schema a blocchi funzionali di una forma di attuazione di un modulo di creazione di file, - le figure 3 e 4 sono ulteriori schemi a blocchi funzionali rappresentativi di forme di attuazione,

- la figura 5 pone a confronto diversi formati di protocollo,

- la figura 6 illustra schematicamente criteri di autenticazione del contenuto, e

- la figura 7 Ã ̈ uno schema a blocchi funzionale di un estrattore di metadati secondo una forma di attuazione.

Descrizione particolareggiata di esempi di attuazione Nella seguente descrizione sono illustrati vari dettagli specifici finalizzati ad un’approfondita comprensione delle forme di attuazione. Le forme di attuazione possono essere realizzate senza uno o più dei dettagli specifici, o con altri metodi componenti materiali, etc. In altri casi, strutture, materiali o operazioni noti non sono mostrati o descritti in dettaglio per evitare di rendere oscuri i vari aspetti delle forme di attuazione.

Il riferimento ad “una forma di attuazione†nell’ambito di questa descrizione sta ad indicare che una particolare configurazione, struttura o caratteristica descritta in relazione alla forma di attuazione à ̈ compresa in almeno una forma di attuazione. Quindi, frasi come “in una forma di attuazione†, eventualmente presenti in diversi luoghi di questa descrizione non sono necessariamente riferite alla stessa forma di attuazione. Inoltre, particolari conformazioni, strutture o caratteristiche possono essere combinate in ogni modo adeguato in una o più forme di attuazione.

I riferimenti qui utilizzati sono soltanto per comodità e non definiscono dunque l’ambito di tutela o la portata delle forme di attuazione.

Lo schema della figura 2 riassume in termini generali la struttura di un modulo 100 che ha la funzione di estrarre da un contenuto C, tramite un estrattore semantico 102, metadati “semantici†(nel seguito indicati con 1002) relativi al contenuto a cui vengono sommati, in un nodo indicato con 104:

- metadati relativi alla identità della “sorgente†(nel seguito indicati con 1004) relativi al produttore del contenuto e costituiti ad esempio un identificatore ID del produttore, in unione a metadati semantici opzionali OM preventivamente addizionati all’identificatore ID in un nodo 106, e

- metadati “di scaricamento†(nel seguito indicati con 1000) relativi alla rete P2P oggetto dell’applicazione e sostanzialmente corrispondenti ai metadati, di cui si à ̈ già detto estesamente in precedenza, che permettono all’utilizzatore di scaricare i contenuti mediali dalla rete.

I metadati semantici relativi al contenuto possono corrispondere, così come meglio si vedrà nel seguito, all’informazione audio/video che rappresenta/riassume il corrispondente contenuto.

L’informazione relativa al produttore dei contenuti risulta utile in particolare in vista del possibile impiego nell’ambito di una comunità di prosumer, dove gli utilizzatori del sistema sono in grado di caricare nella rete rispettivi contenuti. Tale meccanismo può essere anche sfruttato da provider di tipo professionale vuoi per aumentare il grado di confidenza degli utilizzatori, vuoi per convogliare informazioni generali ed anche informazioni di tipo pubblicitario o parapubblicitario (brand).

Così come meglio si vedrà nel seguito, l’identificatore ID à ̈ anche inviato verso un nodo 108 in cui a tale identificatore à ̈ associata anche una chiave pubblica PK destinata ad essere distribuita attraverso un canale 110 in generale diverso rispetto ai canali utilizzati per il contenuto distribuito sulla rete P2P. Per esempio, il canale 110 può essere un server centralizzato che garantisce l’associazione tra ID del produttore e chiave pubblica, oppure anche un canale di distribuzione diretta dal produttore alle sue controparti (caso dei parenti citato in una nota precedente).

In un nodo 112, il carico utile di metadati generato dal nodo 104, ossia l’insieme dei metadati semantici (quali essi siano) provenienti dall’estrattore 102, dei metadati relativi alla sorgente o produttore (quali essi siano) e dei metadati di scaricamento 1000 (ad esempio un file .torrent o simile), à ̈ sottoposto ad un’azione di “hashing†e la relativa stringa di hash così ottenuta viene inviata verso un modulo di cifratura (criptazione) 114 destinato a generare una firma elettronica. In un nodo 116, la firma elettronica viene aggiunta ai metadati in uscita da 104 e distribuita insieme ad essi, mentre attraverso la rete P2P viene unicamente distribuito il contenuto. Metadati, firma e chiave pubblica possono essere distribuiti tramite il medesimo canale oppure a loro volta attraverso canali diversi.

La previsione della firma elettronica fa sì che un utilizzatore che voglia “consumare†un certo contenuto abbia modo di verificare la validità di tale firma secondo modalità semplici, tali da facilitare l’impiego nell’ambito di reti sociali in cui la confidenza/fiducia nei confronti di un certo prosumer assume rilievo per assicurare relazioni amichevoli e consentire anche il riconoscimento del contributo del singolo utilizzatore alla rete sociale.

In varie forme di attuazione, gli aspetti sopra considerati sono fra loro correlati in quanto, così come nell’esempio qui considerato, la firma elettronica dipende dall’insieme dell’informazione espressa dal carico utile in termini di meta-data. Questa dipendenza ha un effetto benefico sulla trasparenza del processo di disseminazione nell’ambito della rete permettendo a ciascun utilizzatore di accorgersi se qualcuno ha inquinato l’insieme di metadati.

Varie forme di attuazione permettono infatti di proteggere l’informazione contenuta nel file metadati nei confronti di chi voglia condurre in modo malevolo un’attività di generazione di falsi (fake) o di inquinamento.

Questa soluzione à ̈ applicabile nelle reti sociali, dove il singolo utilizzatore ha modo di scegliere e identificare facilmente utilizzatori amici tramite identificatori semantici, etichette, avatar, nei confronti dei quali si nutre fiducia e che, in varie forme di attuazione, sono semplicemente integrati nel file di metadati.

Varie forme di attuazione qui considerate permettono tanto di creare quanto di decodificare un formato metadati semantico di tipo affidabile (trusted). Il file metadati che ne deriva à ̈ esteso in modo da contenere un certo numero di metadati semantici rappresentativi del contenuto e del produttore. In particolare à ̈ possibile inserire informazione relativa all’autenticità del contenuto, all’autenticità del produttore ed una sintesi dell’informazione multimediale nel file o in qualunque altro formato informativo impiegato per l’immagazzinamento (ad esempio formati di file) oppure distribuiti su reti client/server (ad esempio protocolli SDP) o reti P2P (ad esempio file .torrent).

Con riferimento allo schema della figura 2, il contenuto C à ̈ fornito all’ingresso dell’estrattore semantico 102 e il motore semantico embedded dell’estrattore à ̈ in grado di generare metadati semantici così come meglio dettagliato negli esempi che seguono.

Anche l’informazione relativa al producer (fondamentalmente un suo identificativo ID) à ̈ costituita da dati d’ingresso al sistema, che si attende anche di ricevere alcune informazioni, rappresentate appunto dai metadati 1000, sostanzialmente corrispondenti al file .torrent tradizionale indicato con il riferimento 1000.

La chiave privata KP à ̈ di solito derivata da una sorgente protetta (ad esempio un file criptato sul disco rigido del terminale dell’utilizzatore, ad esempio protetto da una parola chiave).

Per quanto riguarda l’identificatore ID si può trattare di qualunque informazione/formato che consente di identificare in modo univoco un utilizzatore.

In varie forme di attuazione l’identificatore ID costituisce un meta-dato che permette di associare e reperire la chiave pubblica corretta nella fase di estrazione. Si apprezzerà peraltro che l’associazione fra l’identificatore ID e la chiave pubblica PK non costituisce parte del processo di creazione e la chiave pubblica PK non à ̈ di per sé inclusa nel formato metadati. In questo modo à ̈ possibile realizzare una distribuzione di tipo “trusted†della chiave pubblica attribuendo alla stessa un’associazione univoca con chi produce i contenuti. Per contenuti di tipo professionale questo collegamento può essere garantito da una parte terza di tipo “trusted†, quale un’autorità di certificazione in grado di certificare che una determinata chiave pubblica à ̈ associata in modo univoco ad un determinato produttore di contenuti.

Nel caso di contenuti generati da un utilizzatore, in cui à ̈ comunque importante riconoscere l’identità (anche virtuale) del producer (prosumer), l’associazione fra la chiave pubblica PK e l’identificatore ID può essere garantita ad esempio dal provider di servizi nel caso di una rete sociale (ad esempio come chiave pubblica intesa come parte di informazione di account per Facebook, MSN ecc.). Un’altra possibilità à ̈ far sì che la chiave sia fornita direttamente da parte del produttore ai soggetti interessati attraverso vari sistemi di consegna noti (ad esempio posta elettronica, chiavetta USB, chat).

Nel seguito verranno forniti alcuni esempi di possibili criteri utilizzabili per l’aggiunta di metadati semantici sia con relazione al contenuto, sia con relazione al produttore di tale contenuto.

Tale presentazione ha carattere puramente esemplificativo: al riguardo, gli esperti del settore apprezzeranno infatti che la presente descrizione non riguarda in modo specifico quali metadati semantici siano utilizzati ed i criteri con cui tali metadati semantici sono generati (a questo fine à ̈ possibile ricorrere a qualunque tecnica nota), quanto piuttosto i criteri con cui tali metadati, quali essi siano e comunque siano generati, vengono resi disponibili, ad esempio associando ad essi una firma digitale.

Per quanto riguarda il contenuto, l’informazione estratta a livello di metadati semantici può essere costituita ad esempio da:

- una o più immagini,

- una o più sequenze video (ad esempio un cosiddetto trailer),

- uno o più elementi di informazione audio quali musica, titoli di canzoni, testi ecc, relativi alla colonna sonora di un file video, e

- uno o più elementi di testo quali ad esempio una descrizione di un contenuto multimediale, l’autore, gli attori, la trama, recensioni, ecc.

Queste immagini, video, contenuti audio e/o di testo sono estratti dal contenuto destinato ad essere caricato sulla rete in vista dello scaricamento tramite una analisi, condotta secondo criteri noti, ed in generale tale da dare origine ad un file di dati semantici di dimensioni variabili.

Sempre a titolo di esempio, nel caso di immagini statiche, à ̈ possibile pensare all’inserimento di un cosiddetto storyboard (una sequenza di frame che rappresentano lo sviluppo dell’intera sequenza video) nel file di metadati creato secondo qualunque algoritmo in grado di operare su singole frame. Nel caso di un contenuto audio/video à ̈ possibile pensare all’incorporazione di testi, di storyboard audio (ad esempio frammenti di canzoni se non intere canzoni dalla colonna sonora), frammenti di dialoghi o interi dialoghi oppure tag di testo semantico anche in questo caso ottenuti tramite un’analisi e l’elaborazione eventuale di sottotitoli ricorrendo a tecniche note, eventualmente compresi algoritmi di riconoscimento del parlato.

Nel caso particolare di contenuti video à ̈ possibile pensare ad utilizzare brevi sequenze video ad esempio sotto forma di trailer, ancora una volta ottenuti ricorrendo a tecniche note di analisi del contenuto video.Sempre per quanto riguarda i contenuti video à ̈ possibile pensare all’incorporazione di riferimenti di chunk così da essere in grado di ritrovare preventivamente quegli specifici chunk che contengono la parte più significativa della sequenza così da poter costruire lo storyboard nell’applicazione d’utente. Questo può di per sé comportare di accedere alla rete P2P per recuperare la storyboard, ma compatibile con la possibilità che la storyboard sia già tutta contenuta nel file di metadati (e quindi l’applicazione utente possa mostrarla senza accedere alla rete P2P).

Nel caso di un testo si può pensare ad esempio ad un testo che descrive un film, il suo contenuto, gli attori, la trama, ecc.

Il corrispondente formato metadati esteso può contenere un blocco demandato a estrarre i metadati semantici dal contenuto.

Per quanto riguarda invece i metadati relativi al produttore, identificato dall’identificativo ID, l’informazione aggiunta a livello di metadati può essere costituita, ad esempio, da un messaggio di benvenuto e/o una rappresentazione multimediale del produttore stesso, sia esso un provider professionale, oppure un prosumer. Si può trattare, ad esempio, di immagini quali un segno distintivo aziendale o un avatar (un piccolo ritratto, un’icona, un simbolo generico che rappresenta l’utilizzatore), oppure di uno o più video (ad esempio un trailer di presentazione del producer del contenuto, tratto ad esempio da suoi precedenti lavori oppure semplicemente dalla presentazione della persona al pubblico come autore del contenuto che viene disseminato). Anche in questo caso si può far ricorso a un contenuto di tipo audio (musica, titoli di canzoni, testi relativi ad una colonna sonora corrispondente al file di contenuto).

In varie forme di attuazione questi metadati possono essere generati in modo diverso, ad esempio tramite file di configurazione, domande interattive all’utilizzatore, il reperimento del profilo da una rete sociale, ecc.

Ancora una volta si rammenta che tale presentazione ha carattere puramente esemplificativo: al riguardo, gli esperti del settore apprezzeranno infatti che la presente descrizione non riguarda in modo specifico quali metadati relativi al producer siano utilizzati ed i criteri con cui tali metadati sono generati (a questo fine à ̈ possibile ricorrere a qualunque tecnica nota), quanto piuttosto i criteri con cui tali metadati relativi al producer, quali essi siano e comunque siano generati, vengono resi disponibili, ad esempio associando ad essi una firma digitale.

Anche per quanto riguarda la funzione di verifica della firma digitale ai fini della verifica dell’integrità dei metadati à ̈ possibile ricorrere a qualunque soluzione di per sé nota. Gli esempi qui considerati fanno riferimento ad una funzione di hash sottoposta a cifratura tramite la chiave pubblica PK detenuta dal produttore dei contenuti (il tutto secondo le modalità già illustrate con riferimento allo schema della figura 2).

La parte superiore della figura 3, indicata con a), fa vedere come un file di metadati “di scaricamento†1000 corrispondente al formato tradizionale (ad esempio ad un file .torrent del tipo correntemente in uso, che di per sé include già i metadati 1000 della figura 2, relativi ai criteri di accesso alla rete) possa essere integrato secondo varie forme di attuazione con i metadati 1002 di contenuto e con i metadati 1004 relativi al produttore.

In 1006 à ̈ rappresentata l’applicazione all’insieme dei (meta)dati 1000, 1002, 1004 di un algoritmo quale SHA1 con successiva generazione di hash, rappresentata dal blocco 1008, il quale à ̈ sottoposto alla funzione della cifratura, rappresentata dal blocco 1010, attuata ricorrendo alla chiave privata KP. Il prodotto di uscita dell’intera catena à ̈ un hash criptato, rappresentato dal blocco 1012.

La parte inferiore della figura 3, indicata con b), esemplifica il fatto che l’insieme dei metadati 1000, 1002, 1004 e della stessa firma digitale rappresentata dal blocco 1012 sostituisce di fatto, negli esempi qui considerati, i file 1000 (ad esempio il file .torrent tradizionale).

Si apprezzerà che nell’esempio considerato nella figura 3, l’insieme dei metadati di scaricamento 1000 e semantici 1002 (che include l’informazione relativa al contenuto) à ̈ arricchito aggiungendo i metadati relativi al produttore 1004. Al nuovo corpo dei metadati si applica la funzione SHA-1, in pratica il motore che genera una stringa hash. Tale stringa à ̈ poi sottoposta a cifratura con la chiave privata KP – a disposizione del solo produttore del contenuto – così da formare una firma elettronica, che non à ̈ altro che una stringa hash criptata.

La parte superiore della figura 4, indicata con a), ripropone ancora la sequenza delle operazioni descritte in precedenza facendo riferimento all’azione svolta sui metadati 1000, 1002, 1004 al fine di pervenire ad una firma digitale - DS.

La parte inferiore della figura 4, indicata con b), illustra le operazioni svolte in modo complementare a livello di un utilizzatore che riceve i suddetti metadati 1000, 1002, 1004 e la firma elettronica DS.

Dal lato dell’utilizzatore, i metadati 1000, 1002, 1004 sono sottoposti alla stessa funzione SHA-1 del blocco 1006 utilizzata dalla parte della sorgente: il risultato ottenuto, rappresentato dal blocco 2008, identifica una “potenziale†hash che viene allocata in un buffer di memoria in attesa di validazione. D’altra parte la firma elettronica DS à ̈ invece decifrata in 2010 con la chiave pubblica PK. Se la firma digitale non à ̈ stata contraffatta, il blocco 2012 ottenuto a seguito della decrittazione della firma digitale DS deve essere uguale al blocco 2008 ottenuto applicando l’algoritmo di SHA-1 sui metadati. Se esiste uguaglianza fra i due blocchi 2008 e 2012 allora la firma digitale viene convalidata positivamente.

Nel caso dell’esempio qui considerato, il terminale dell’utilizzatore “consumatore†svolge tre funzioni:

- calcola un hash (blocco 2008) dell’informazione di metadati (blocco 1000, 1002, 1004) che di per sé può essere anche informazione trasparente (esattamente come ha fatto il produttore dei contenuti) tramite la funzione 1006, - decifra la firma elettronica DS attraverso la chiave pubblica PK ottenuta dalla rete (tramite chat, forum o anche direttamente) così da ottenere il dato hash 2012, - verifica (tramite comparazione degli hash, così come illustrato in figura 4) che i metadati non siano stati alterati in qualche modo.

Si apprezzerà che la verifica non ha in via primaria lo scopo di verificare che il produttore sia trusted o meno. L’alterazione, se avviene, à ̈ opera di altri soggetti: lo stesso ID del produttore in quanto parte dei metadati potrebbe essere stato modificato (nel qual caso la chiave pubblica recuperata à ̈ presumibilmente sbagliata e la verifica comunque fallisce).

Se si trae la conclusione che i metadati sono stati in qualche modo alterati, per cui l’applicazione dovrebbe in generale rifiutare di scaricare/reperire il contenuto.

Nell’esempio qui considerato l’utilizzatore “ricevente†attua una funzione di decifratura (decrittazione 2010) delle firma elettronica mirante a verificare l’integrità dei metadati, questo sfruttando la firma elettronica DS ed operando con la chiave pubblica PK (diffusa in rete secondo le modalità già descritte con riferimento alla figura 2 e recuperata a partire dall’ID del produttore).

Così come già si à ̈ detto che l’informazione semantica relativa al contenuto e al produttore del contenuto (metadati 1002 e 1004) non richiede di per sé di essere sottoposta a crittazione. La soluzione qui descritta risulta quindi flessibile, ammette una compatibilità a ritroso con formati tradizionali (in chiaro, non cifrati) che non incorporano l’informazione semantica relativa al contenuto e al produttore ma che contengono tuttavia altri metadati quali ad esempio il nome del file, le dimensioni del file.

Un tale meccanismo di verifica dell’integrità dei metadati contribuisce ad aumentare il grado di fiducia dell’utilizzatore nella rete sociale, arricchendo altresì la sua esperienza lasciando l’informazione semantica trasparente per l’utilizzatore finale. Inoltre aumenta il grado di fiducia del produttore, il quale da un lato à ̈ garantito che il suo nome (o meglio il suo ID) non venga arbitrariamente associato a contenuti diversi da quelli da lui effettivamente generati, dall’altro e’ sicuro di essere riconosciuto come produttore dei suoi contenuti.

La figura 5, ancora una volta ripartita in due porzioni indicate rispettivamente con a) e b), pone a confronto la struttura di un file .torrent secondo l’impostazione tradizionale descritta in precedenza (con i campi: announce, info, name, piece length, pieces, length, files list, length path) con il formato qui considerato, dove il file in questione viene “arricchito†con i metadati semantici 1002 e con i metadati relativi al producer 1004 e con la firma digitale DS.

In particolare la porzione inferiore della figura 5, indicata con b), illustra una possibile organizzazione dei due campi 1002 e 1004 che prevede, ad esempio:

- nel caso dei metadati semantici 1002, la presenza di immagini 10021, di un trailer video 10022, di una colonna sonora 10023, di testo 10024, in unione ad eventuali ulteriori metadati semantici 10025; e

- nel caso dei metadati 1004 relativi al producer, la possibile presenza di un identificativo ID 10041, di un avatar o informazioni similari 10042, e di ancora ulteriori informazioni a livello di metadati indicati con 10043.

Ancora una volta si rammenta che tale presentazione ha carattere puramente esemplificativo: al riguardo, gli esperti del settore apprezzeranno infatti che la presente descrizione non riguarda in modo specifico quali metadati 1002, 1004 siano utilizzati ed i criteri con cui tali metadati sono generati (a questo fine à ̈ possibile ricorrere a qualunque tecnica nota), quanto piuttosto i criteri con cui tali metadati 1002, 1004, quali essi siano e comunque siano generati, vengono resi disponibili, ad esempio associando ad essi una firma digitale.

La figura 6, anch’essa suddivisa in due parti indicate con a) e b), illustra un esempio di azione di scaricamento di contenuti da una rete P2P, nel caso di un contenuto “professionale†- parte a) della figura 6 - e nel caso di un contenuto generato in un contesto non professionale (ad esempio da un prosumer) – parte b) della figura 6.

In entrambi i casi il blocco 300 rappresenta l’azione di reperimento del file con i metadati (ad es. un file .torrent) da parte dell’utilizzatore a partire dall’ID del produttore contenuto nei metadati, mentre la fase 302 rappresenta l’azione di reperimento della chiave pubblica.

Nel caso del contenuto erogato a livello professionale, la chiave può essere ottenuta presso un’organizzazione di certificazione indicata dal blocco 303.

Nel caso di un contenuto generato da un prosumer, il blocco 303’ indica varie possibilità di reperimento della chiave pubblica, ossia tramite chiavi memorizzate a livello locale in modo trusted (ad esempio a livello di personal computer), oppure l’ottenimento tramite amici “fidati†all’interno di social network online (ad esempio, ricorrendo a Facebook® o MySpace®) ovvero ancora attraverso un ottenimento diretto.

Si apprezzerà che può essere la stessa social network a garantire l’associazione: ad esempio all’atto dell’iscrizione all’utente potrebbe essere chiesta la sua chiave pubblica, l’associazione nickname-chiave pubblica verrebbe da lì in poi conservata nei server del social network, cui si dovrebbe rivolgere un secondo utente per recuperare la chiave del primo (per poi verificare l’autenticità di un contenuto da quest’ultimo prodotto) Comunque ottenuta, la chiave pubblica à ̈ utilizzata in una fase 304 per la verifica della firma digitale.

Il blocco 306 indica l’esito positivo della verifica, mentre il passo 308 indica l’esito negativo della verifica. L’esito positivo porta in una fase 310 all’avviamento della funzione di scaricamento, mentre l’esito negativo 308 fa sì che il processo si interrompa, senza ulteriore allocazione/occupazione di risorse.

Lo schema della figura 7 rappresenta una possibile struttura di un modulo 500 dedicato all’estrazione dei metadati 1002 e 1004 secondo le modalità descritte in precedenza.

Nella figura 7 il riferimento 502 indica un blocco demandato a separare l’insieme dei metadati 1000, 1002 dai metadati riferiti al producer, indicati con 1004, e alla firma digitale che viene inviata al modulo 506.

Questi ultimi dati vengono inviati verso una cache locale 504 per il reperimento della chiave pubblica destinata ad essere utilizzata, in un blocco 506 per la funzione di decifratura della firma digitale DS già descritta in precedenza. L’uso della cache non à ̈ obbligatorio, ma permette di non dover recuperare più volte la chiave nel caso di contenuti dello stesso produttore.

Secondo le modalità già descritte in precedenza con riferimento alla figura 4b), l’insieme dei metadati 1000, 1002, 1004, à ̈ inviato ad un modulo di hash 508, la cui uscita à ̈ inviata ad modulo di confronto 510. Il modulo 510 confronta lo hash generato dal modulo 508 e quello ottenuto dalla decrittazione della firma digitale in 506. Il modulo 510 effettua la verifica sull’integrità dei metadati 1000, 1002, 1004, da cui segue la linea 512a in caso di esito negativo e l’interruzione del processo di scaricamento del file, o l’inizio del processo di scaricamento in caso di esito positivo. L’esito positivo della verifica svolta nel modulo 510 viene comunicata ad un modulo 512 che invia i metadati indicati con 1000 nella figura 2 (che, per quanto qui interessa, possono essere di fatto visti come coincidenti con i metadati 1000) verso un motore P2P 514 in grado di collegarsi alla rete P2P per procedere allo scaricamento del contenuto C.

Ancora una volta si apprezzerà che tale operazione di scaricamento ha inizio solo dopo che sono state condotte le operazioni descritte in precedenza ed in particolare non viene svolta nel caso in cui la funzione di verifica svolta nel modulo 510 dia esito negativo. Tutto questo evita gli effetti negativi descritti nella parte introduttiva della presente descrizione.

Ancora, i dati semantici 1002 possono essere inviati (di preferenza insieme ai dati sul producer 1004) verso un modulo di presentazione 516 che provvede a presentare questi metadati all’utilizzatore U consentendo l’interazione dell’utilizzatore con il sistema.

In particolare, così come schematicamente indicato dalla linea a tratti indicata con 518, tale interazione può assumere la forma di un consenso dato dall’utilizzatore al motore P2P 514 secondo modalità tali per cui lo scaricamento viene avviato non già in modo automatico (così come si à ̈ implicitamente assunto a titolo di esempio in precedenza) ma soltanto dopo aver ottenuto il consenso dell’utilizzatore U, previo esame dello stesso da parte dello stesso dei dati semantici e/o di informazione sul producer.

Si apprezzerà che la funzione della cache locale 504 può essere sostituita da un collegamento tale da portare il modulo estrattore 500 ad interfacciarsi ad un sistema esterno in grado di fornire un’associazione “trusted†fra l’indicatore ID e la chiave pubblica.

Le forme di attuazione qui considerate a titolo di esempio prevedono di accoppiare ai metadati di scaricamento 1000 tanto i metadati semantici 1002, quanto i metadati 1004 di identificazione del producer/sorgente. Varie forme di attuazione possono prevedere di accoppiare ai metadati di scaricamento 1000 o soltanto i metadati semantici 1002 o soltanto i metadati 1004 di identificazione del producer/sorgente, conservando in vantaggi qui descritti in relazione ai soli metadati accoppiati. Analogamente il ricorso alla firma elettronica non costituisce elemento essenziale.

Naturalmente, fermo restando il principio dell’invenzione, i particolari di realizzazione e le forme di attuazione potranno variare, anche in modo significativo, rispetto a quanto qui illustrato a puro titolo di esempio non limitativo, senza per questo uscire dall’ambito di protezione della presente invenzione, così come definito dalle rivendicazioni annesse.

Claims (11)

1. RIVENDICAZIONI 1. Procedimento per distribuire contenuti mediali su reti a condivisione di contenuti (P0, P1, T, C0, WS), comprendente: - associare a detti contenuti mediali (C) metadati di scaricamento (1000) cui accedere per avviare lo scaricamento di detti contenuti mediali da detta rete, e - associare a detti contenuti mediali informazione semantica (1002) sul contenuto di detti contenuti mediali, caratterizzato dal fatto che comprende: - accoppiare a detti metadati di scaricamento (1000), metadati semantici (1002) rappresentativi di detta informazione semantica e/o metadati di sorgente (1004) identificativi della sorgente dei contenuti mediali (C), e - consentire l’accesso a detti metadati di scaricamento (1000) ed ai metadati semantici (1002) e/o di sorgente (1004) accoppiati a detti metadati di scaricamento (1000), per cui detti metadati semantici (1002) e/o di sorgente (1004) sono accessibili senza procedere allo scaricamento di detti contenuti mediali.
2. 2. Procedimento secondo la rivendicazione 1, comprendente applicare a detti metadati di scaricamento (1000) ed ai metadati semantici (1002) e/o di sorgente (1004) accoppiati a detti metadati di scaricamento (1000) una firma digitale (DS) per la verifica di integrità dell’insieme dei metadati accoppiati.
3. 3. Procedimento secondo la rivendicazione 2, comprendente: - calcolare un hash (1008) di detti metadati di scaricamento (1000) e dei metadati semantici (1002) e/o di sorgente (1004) accoppiati a detti metadati di scaricamento (1000), - sottoporre il risultato di detto hash (1008) a cifratura (1010) al fine di generare detta firma digitale (DS).
4. 4. Procedimento secondo la rivendicazione 3, comprendente generare detta firma digitale (DS) mediante una funzione applicata all’hash (1008).
5. 5. Procedimento secondo la rivendicazione 3 o la rivendicazione 4, comprendente generare detta firma digitale (DS) con una chiave privata (KP).
6. 6. Dispositivo (100) per distribuire contenuti mediali su reti a condivisione di contenuti (P0, P1, T, C0, WS), associando a detti contenuti mediali (C) metadati di scaricamento (1000) cui accedere per avviare lo scaricamento di detti contenuti mediali da detta rete, ed associando a detti contenuti mediali informazione semantica (1002) sul contenuto di detti contenuti mediali (C), caratterizzato dal fatto che comprende: - almeno un modulo di accoppiamento (104, 106) per accoppiare a detti metadati di scaricamento (1000), metadati semantici (1002) rappresentativi di detta informazione semantica e/o metadati di sorgente (1004) identificativi della sorgente dei contenuti mediali.
7. 7. Dispositivo secondo la rivendicazione 6, comprendente almeno un modulo di firma digitale (112, 114) per applicare a detti metadati di scaricamento (1000) ed ai metadati semantici (1002) e/o di sorgente (1004) accoppiati a detti metadati di scaricamento (1000) una firma digitale (DS) per la verifica di integrità dell’insieme dei metadati accoppati.
8. 8. Dispositivo secondo la rivendicazione 7, comprendente almeno un modulo di firma digitale (112, 114) comprende: - mezzi di hash (112) per sottoporre ad hash (1008) detti metadati di scaricamento (1000) ed i metadati semantici (1002) e/o di sorgente (1004) accoppiati a detti metadati di scaricamento (1000), - mezzi di cifratura (114) per sottoporre il risultato di detto hash (1008) a cifratura (1010) al fine di generare detta firma digitale (DS).
9. 9. Dispositivo per ricevere contenuti mediali prodotti con il procedimento secondo una qualsiasi delle rivendicazioni 1 a 6 o con il dispositivo secondo una delle rivendicazioni 7 o 8, comprendente: - un modulo di verifica (510) per verificare l’integrità di detti metadati di scaricamento (1000) e dei metadati semantici (1002) e/o di sorgente (1004) accoppiati a detti metadati di scaricamento (1000), - un motore di scaricamento (514) di detti contenuti mediali collegato (512) a detto modulo di verifica (510) per permettere lo scaricamento di detti contenuti mediali a seguito dell’esito positivo di detta verifica di integrità.
10. 10. Dispositivo secondo la rivendicazione 9, in cui detto modulo di verifica (510) à ̈ collegato a: - un modulo di decifratura (506) di una firma digitale (DS) associata a detti metadati di scaricamento (1000) e dei metadati semantici (1002) e/o di sorgente (1004) accoppiati a detti metadati di scaricamento (1000); e - un modulo di hash (508) che realizza una funzione di hash su detti metadati di scaricamento (1000) e detti metadati semantici (1002) e/o di sorgente (1004) accoppiati a detti metadati di scaricamento (1000), ed in cui detto modulo di verifica (510) à ̈ configurato per verificare detta integrità confrontando detta firma digitale decifrata (2012) con il risultato di detto hash (2008) di detti metadati di scaricamento (1000) e dei metadati semantici (1002) e/o di sorgente (1004) accoppiati a detti metadati di scaricamento (1000).
11. 11. Prodotto informatico, caricabile nella memoria di almeno un elaboratore e comprendente porzioni di codice software per attuare il procedimento secondo una qualsiasi delle rivendicazioni 1 a 5 quando il prodotto à ̈ eseguito su un computer.