IT201800005409A1 - Sistema, apparecchiatura e metodo per gestire in modo efficiente la memoria di dispositivi elettronici - Google Patents

Description

Descrizione del trovato avente per titolo:

"SISTEMA, APPARECCHIATURA E METODO PER GESTIRE IN MODO EFFICIENTE LA MEMORIA DI DISPOSITIVI ELETTRONICI"

CAMPO DI APPLICAZIONE

Le forme di realizzazione della presente divulgazione in generale riguardano un sistema, un’apparecchiatura e un metodo per gestire in modo efficiente la memoria di dispositivi elettronici. Più in particolare, le forme di realizzazione della presente divulgazione permettono a un dispositivo elettronico di ridurre la ridondanza dei dati.

STATO DELLA TECNICA

Con i progressi nel campo digitale della tecnologia, la richiesta di immagazzinamento di dati è aumentata rapidamente.

Tradizionalmente, i possessori di computer, computer portatili, telefono, ecc. erano soliti immagazzinare i dati in supporti di memorizzazione locali o su supporti portatili quali hard disk, compact disk, dispositivi di memorizzazione USB, ecc.

Ad ogni modo, tali dispositivi non sono ideali nel proteggere i dati in quanto sono soggetti a malfunzionamento (“crash”) e a furto. Inoltre, le loro capacità di immagazzinare i dati sono limitate.

Pertanto, i server remoti si sono affermati come soluzione ideale per immagazzinare dati importanti in piena sicurezza.

Tuttavia, l’uso di server remoti è diventato così popolare che si è rivelato molto difficile per le società continuare a espandere i propri server per far fronte alla domanda.

Inoltre, la manutenzione dei server remoti è costosa.

E’ ben noto che se si può ottimizzare la ridondanza di dati allora si può risparmiare molto spazio di immagazzinamento e il costo per mantenere dati non-ridondanti risulterà molto economico a confronto. Pertanto, esiste la necessità di un sistema e di un metodo in grado di ridurre la ridondanza di dati in dispositivi di memorizzazione come server di dati remoti.

Per ovviare agli inconvenienti della tecnica nota e per ottenere questi e ulteriori scopi e vantaggi, la Richiedente ha studiato, sperimentato e realizzato la presente divulgazione.

ESPOSIZIONE DEL TROVATO

Le forme di realizzazione secondo la presente divulgazione divulgano un metodo per gestire una memoria locale di un dispositivo elettronico che immagazzina una pluralità di file di dati genitore, in cui i file di dati genitore sono costituiti da una pluralità di set di dati figlio.

Il metodo permette al dispositivo elettronico di modificare un set di dati figlio di un file di dati genitore, immagazzinare il set di dati figlio modificato separatamente nella memoria locale come versione del set di dati figlio e permettere l accesso al file di dati genitore con e senza il set di dati figlio modificato.

Il metodo inoltre permette al dispositivo elettronico di determinare se almeno un parametro del set di dati figlio modificato ha attraversato un limite di soglia, dividere il set di dati figlio modificato in due o più nuovi set di dati sulla base del limite di soglia, immagazzinare i set di dati figlio nuovi separatamente come versione del set di dati figlio modificato e permettere l’accesso al file di dati genitore con il set di dati figlio modificato e con i set di dati figlio nuovi.

Il metodo inoltre permette al dispositivo elettronico di determinare se almeno un parametro del set di dati figlio modificato è al di sotto di un limite di soglia, unire il set di dati figlio modificato con il suo set di dati figlio sequenziale a formare un set di dati figlio nuovo, immagazzinare il set di dati figlio nuovo separatamente come versione del set di dati figlio modificato e permettere l’accesso al file di dati genitore con il set di dati figlio modificato e con il set di dati figlio nuovo.

Il metodo inoltre può prevedere di recuperare informazioni arbitrarie relative a un file di dati genitore e/o a un file di dati figlio e/o un sottofile di dati figlio allo scopo di calcolare e fornire la proprietà dei diritti per ciascun autore che ha lavorato sullo specifico file di dati, detta proprietà dei diritti essendo espressa in percentuali.

Similmente, il metodo inoltre permette al dispositivo elettronico di modificare l’uno o più sotto-set di dati figlio, immagazzinare i sotto-set di dati figlio modificati separatamente nella memoria locale come versione dell’uno o più sotto-set di dati figlio e permettere l’accesso al file di dati genitore con e senza i sotto-set di dati figlio modificati.

Le forme di realizzazione secondo la presente divulgazione divulgano un’apparecchiatura collegata a una rete che comprende uno o più processori, un modulo di interfaccia di rete per collegare l’apparecchiatura con la rete e una memoria comprendente una base di dati e un set di istruzioni.

La base di dati comprende una pluralità di file di dati genitore, in cui i file di dati genitore sono costituiti da una pluralità di set di dati figlio. Il set di istruzioni comprende istruzioni che quando vengono eseguite dall’uno o più processori fanno sì che l’apparecchiatura modifichi un set di dati figlio di un file di dati genitore, immagazzini il set di dati figlio modificato separatamente nella memoria locale come versione del set di dati figlio e permetta l’accesso al file di dati genitore con e senza il set di dati figlio modificato.

Il set di istruzioni inoltre comprende istruzioni per modificare l’uno o più sotto-set di dati figlio, immagazzini i sotto-set di dati figlio modificati separatamente nella memoria locale come versione dell’uno o più sotto-set di dati figlio e permettere l’accesso al file di dati genitore con e senza i sotto-set di dati figlio modificati. Può anche essere previsto l’accesso al set di dati figlio con e senza i sotto-set di dati figlio modificati.

Il set di istruzioni inoltre comprende istruzioni per determinare se almeno un parametro del set di dati figlio modificato ha attraversato un limite di soglia. Se ciò viene determinato, allora dividere il set di dati figlio modificato in due o più nuovi set di dati sulla base del limite di soglia. Quindi, immagazzinare i set di dati figlio nuovi separatamente come versione del set di dati figlio modificato e permettere l’accesso al file di dati genitore con il set di dati figlio modificato e con i set di dati figlio nuovi.

Il set di istruzioni inoltre comprende istruzioni per determinare se almeno un parametro del set di dati figlio modificato è al di sotto di un limite di soglia. Se ciò viene determinato, allora unire il set di dati figlio modificato con il suo set di dati figlio sequenziale a formare un set di dati figlio nuovo.

Successivamente, immagazzinare il set di dati figlio nuovo come versione del set di dati figlio modificato e permettere l’accesso al file di dati genitore con il set di dati figlio modificato e con il set di dati figlio nuovo.

In aggiunta alle predette forme di realizzazione, la presente invenzione presenta i seguenti vantaggi.

La presente invenzione riduce la ridondanza di dati e risparmia le esigenze di spazio di immagazzinamento, il che comporta costi ridotti nell’ acquisto e nella manutenzione di costosi dispositivi di memorizzazione .

La presente invenzione inoltre risparmia tempo nell’elaborazione di dati che devono venire immagazzinati su un dispositivo di memorizzazione.

La presente invenzione inoltre risparmia larghezza di banda che è richiesta per trasferire i dati via rete. Ciò inoltre riduce il tempo che è richiesto nel trasferimento di dati via rete.

La presente invenzione aumenta la sicurezza dei dati e protegge dagli eventi di perdite di dati o furti di dati.

La presente invenzione supporta l’accesso multi-utente a un file di dati senza entrare in conflitto nelle operazioni di lettura o scrittura. Questo permette agli utenti di collaborare allo stesso progetto senza contrastarsi tra loro.

Questi e altri aspetti, caratteristiche e vantaggi della presente divulgazione verranno meglio compresi facendo riferimento alla seguente descrizione, disegni e annesse rivendicazioni. I disegni, che sono integrati e formano parte della presente descrizione, mostrano alcune forme di realizzazione della presente divulgazione, e, assieme alla descrizione, hanno lo scopo di descrivere i principi della divulgazione.

ILLUSTRAZIONE DEI DISEGNI

Le suddette e ulteriori caratteristiche e vantaggi ancora della presente divulgazione appariranno evidenti considerando la seguente descrizione dettagliata di forme di realizzazione della stessa, in special modo se prese in combinazione con i disegni a corredo, e in cui:

la FIG. 1 illustra un ambiente esemplificativo in cui sono implementate varie forme di realizzazione della presente divulgazione. La FIG. 2 illustra un diagramma a blocchi che raffigura una struttura gerarchica in cui molteplici versioni di molteplici file sono immagazzinate in una memoria per l’accesso attraverso una rete, secondo una forma di realizzazione della presente divulgazione.

La FIG. 3 illustra un diagramma di flusso di un metodo per editare un particolare file da una base di dati di una pluralità di file immagazzinati nel server di dati, secondo una forma di realizzazione della presente divulgazione.

La FIG. 4 illustra un diagramma di flusso di un metodo per modificare un particolare chunk (blocco) di una particolare fork (biforcazione) di un file audio, secondo una forma di realizzazione della presente divulgazione.

La FIG. 5 illustra un diagramma di flusso di un metodo per immagazzinare la versione originale di una fork con o senza chunk modificato, secondo una forma di realizzazione della presente divulgazione.

La FIG. 6 illustra un diagramma di flusso di un metodo per modificare due o più chunk sequenziali da un file audio, secondo una forma di realizzazione della presente divulgazione.

La FIG. 7 illustra un diagramma di flusso di un metodo per suddividere la versione modificata da un utente di un chunk in due o più chunk, secondo una forma di realizzazione della presente divulgazione. La FIG. 8 illustra un diagramma di flusso di un metodo per suddividere automaticamente la versione modificata di un chunk in due o più chunk, secondo una forma di realizzazione della presente divulgazione.

La FIG. 9 illustra un diagramma di flusso di un metodo per modificare un set di dati figlio di un file di dati genitore, secondo una forma di realizzazione della presente divulgazione.

La FIG. 10 illustra un diagramma di flusso di un metodo per dividere un set di dati figlio modificato in due o più set di dati nuovi sulla base di un limite di soglia, secondo una forma di realizzazione della presente divulgazione.

La FIG. 11 illustra un diagramma di flusso di un metodo per unire un set di dati figlio modificato con il suo set di dati figlio sequenziale a formare un set di dati figlio nuovo, secondo una forma di realizzazione della presente divulgazione.

La FIG. 12 illustra un diagramma a blocchi di un’apparecchiatura di comunicazione, secondo una forma di realizzazione della presente divulgazione.

La FIG. 13 illustra un diagramma a blocchi che raffigura diverse operazioni che possono venire eseguite su sotto-set di dati figlio modificati, secondo una forma di realizzazione della presente divulgazione.

DESCRIZIONE DI FORME DI REALIZZAZIONE

La descrizione farà ora riferimento nel dettaglio alle varie forme di realizzazione della presente divulgazione, delle quali uno o più esempi sono illustrati nei disegni allegati. Ciascun esempio è fornito a titolo di illustrazione dell’invenzione e non è inteso come una limitazione della stessa. Ad esempio, le caratteristiche mostrate o descritte in quanto facenti parte di una forma di realizzazione potranno essere adottate su, o in associazione con, altre forme di realizzazione per produrre un’ulteriore forma di realizzazione. Resta inteso che la presente divulgazione includerà tutte tali modifiche e varianti.

La FIG. 1 illustra un ambiente esemplificativo 100 dove sono implementate varie forme di realizzazione della presente divulgazione. L’ambiente 100 include un server di dati 102 collegato a una pluralità di dispositivi elettronici 104a-n attraverso una rete 108, in cui il numero n è un numero arbitrario che rappresenta lo stesso o un diverso numero di dispositivi. Qui di seguito, i dispositivi 104a-n possono venire collettivamente designati come “dispositivi utente 104”.

Inoltre, i dispositivi utente 104 possono riferirsi a dispositivi elettronici che possono venire utilizzati da utenti per accedere al e comunicare col server di dati 102. Esempi dei dispositivi utente 104 possono includere, ma non si limitano a, dispositivi di comunicazione quali telefoni cellulari, tablet, computer portatili, computer da tavolo, ecc. che sono in grado di collegarsi alla rete 108.

La rete 108 può includere, ma non si limita a, una rete di comunicazione come internet, intranet, rete telefonica pubblica commutata (PSTN - Public Switched Telephone Network), rete locale (LAN - Locai Area Network), rete geografica (WAN - Wide Locai Area Network), rete per area metropolitana (MAN - Metropolitan Area Network) e via dicendo. La rete 108 può venire usata per collegare i dispositivi utente 104 al server di dati 102 con l’aiuto dell’applicazione di servizio o del sito web.

In una forma di realizzazione della presente divulgazione, i dispositivi utente 104 sono installati con un’applicazione di servizio (facoltativa e non mostrata). L’applicazione di servizio può essere implementata come un’applicazione software (o combinazione di software e hardware). Inoltre, l’applicazione di servizio installata nei dispositivi utente 104 è configurata per collegare i dispositivi utente 104 a molteplici servizi offerti dal server di dati 102.

In un’altra forma di realizzazione della presente divulgazione, i dispositivi utente 104 possono venire usati per accedere al server di dati 102 attraverso una piattaforma web (ad esempio: un sito web). Il sito web può includere qualsiasi piattaforma online che fornisce accesso al server di dati 102. Inoltre, il sito web può essere configurato per permettere ai dispositivi utente 104 di accedere a vari servizi offerti dal server di dati 102. Esempi del server di dati 102 possono includere, ma non si limitano a, un server cloud, server web, server locale, ecc.

In una forma di realizzazione esemplificativa della presente divulgazione, il server di dati 102 è configurato con un sistema di versioning (non mostrato). Il sistema di versioning può essere costituito da hardware, software o da una combinazione degli stessi. Inoltre, il sistema di versioning (qui di seguito indicato saltuariamente come ‘il sistema’) è configurato per far collaborare file di musica e dati correlati sulla base di una piattaforma cloud. Il sistema di versioning è inoltre configurato per creare e gestire molteplici versioni dei file di musica e dati correlati assicurando le minori esigenze di memoria possibili nell’immagazzinare tutte le versioni dei file di musica e dei dati correlati nel server di dati 102.

Una persona esperta del ramo comprenderà che l’esempio dei file di musica viene usato solo per comodità di descrizione della presente divulgazione. Ad ogni modo, l’estensione della presente divulgazione non si limita ai soli file di musica. La presente divulgazione è in grado di gestire qualsiasi formato di file e qualsiasi tipo di file su una piattaforma di memorizzazione locale o cloud.

Inoltre, il sistema di versioning del server di dati 102 assicura che i file siano immagazzinati efficientemente nel server di dati 102 e possano venire recuperati per editing o modifiche. Qualsiasi modifica o cambiamento nei file o nei loro attributi sono salvati nel server di dati 102 come nuova versione del file. Le versioni nuova e originale sono anche rese disponibili per l’accesso immediato a utenti locali o remoti. La nuova versione può comprendere dati modificati quali, ma non limitati a, data, numero di versione, nome dell’editor e molti altri metadati che possono venire definiti in maniera flessibile. Il sistema pertanto immagazzina la storia di tutte le diverse versioni di un file per permettere l’accesso a qualsiasi versione specifica del file.

Maggiori dettagli corrispondenti alla funzionalità del server di dati 102 e al suo sistema di versioning vengono ulteriormente definiti in correlazione con le FIGG. 2-13 della presente divulgazione.

La FIG. 2 illustra un diagramma a blocchi 200 che illustra una struttura gerarchica in cui molteplici versioni di molteplici file di musica sono immagazzinate in una memoria di un server di dati (ad esempio: server di dati 102) per l’accesso attraverso una rete (ad esempio: rete 108). Come rappresentato dal diagramma a blocchi 200, molteplici versioni dei molteplici file di musica (204a-n) sono immagazzinate in molteplici cartelle (202a-n) nel server di dati.

Le molteplici cartelle (202a-n) possono immagazzinare molteplici versioni dei molteplici file (204a-n) immagazzinati nel server di dati. I molteplici file (204a-n) immagazzinati nelle molteplici cartelle (202a-n) possono includere, ma non si limitano a, file audio, file grafici, file video, file di testo o una combinazione degli stessi. Ad ogni modo, come parte di una forma di realizzazione della presente divulgazione, la FIG. 2 viene illustrata con uno scenario esemplificativo in cui la cartella 2 (202b) comprende molteplici file di musica (file audio) 204a-n.

I molteplici file di musica 204a-n possono essere costituiti da molteplici fork (biforcazioni) (fork 206a-n del file di musica 204b). Le molteplici fork 206a-n possono inoltre essere costituite da molteplici chunk (blocchi) 208a-n, in cui ‘n’ rappresenta qualsiasi numero arbitrario che rappresenta lo stesso o un diverso numero di cartelle, file, fork o chunk. Il numero di chunk e fork disponibile in un file di musica non è correlato o proporzionale gli uni rispetto agli altri e può essere diverso nel conteggio.

Ogni file di musica è costituito da un set di “fork” indipendenti che immagazzinano un componente individuale del file di musica. Per esempio, una traccia musicale o metadati relativi a un file. Ogni fork è composta da una lista di uno o più “chunk” (blocchi) di dati che sono ottenuti suddividendo la fork seguendo specifici criteri (ad esempio, per chunk di uguale dimensione). Questa struttura gerarchica fornisce flessibilità ed efficienza per le operazioni di versioning su file, fork e chunk.

Le fork contenute in un file musicale possono essere rappresentate in diversi formati digitali quali, ma non limitati a, dati grezzi, notazione musicale standard, midi (interfaccia digitale per strumenti musicali), ecc. Per esempio, i file di musica possono venire ‘biforcati’ da diversi utenti al fine di avere percorsi di editing diversi che possono venire ulteriormente uniti. Il server di dati è configurato specificamente per creare, immagazzinare e gestire diverse versioni di file divise per ‘chunk’ gestendo efficientemente lo spazio di memoria.

Inoltre, un set di attributi può venire associato a ciascun file, fork e chunk.

Ciascun attributo può essere costituito da una chiave e da una tupla di valori arbitrari.

Gli attributi arricchiscono singoli elementi di progetto con informazioni arbitrarie quali autore, data dell'ultima modifica, data di creazione, formato di file, compressione, collocazione, strumento musicale, ecc.

Un’altra informazione arbitraria può riferire quale autore ha lavorato su un file di dati genitore e/o su un file di dati figlio e/o su un sotto-file di dati figlio. Per esempio, l’informazione arbitraria può riferire quale autore o quali autori ha/hanno lavorato su uno specifico file di musica. Queste informazioni possono venire usate da un meccanismo automatico per calcolare e fornire la proprietà dei diritti, espressa per esempio in una percentuale, per ciascun autore che ha lavorato sullo specifico file di dati. Il meccanismo automatico è in grado di calcolare anche la quantità di denaro per ciascun autore che ha lavorato sullo specifico file.

Secondo una variante, le informazioni arbitrarie possono anche venire usate come tali da un utente, per esempio per calcolare manualmente la quantità di denaro per ciascun autore che ha lavorato sullo specifico file.

L’apparecchiatura può comprendere anche il meccanismo automatico. Un ulteriore meccanismo di indicizzazione viene applicato ad attributi e contenuti di un chunk per eseguire una classificazione accurata di quegli attributi, di modo tale che le task di ricerca e recupero possono venire eseguite in maniera più efficiente.

In una forma di realizzazione esemplificativa della presente divulgazione, il server di dati è configurato per fornire una capacità di gestire versioni diverse di un’unica fork o intero file (e cioè: tutte le fork). Per esempio, dopo aver eseguito un certo editing a una fork individuale di un file di musica, un utente può decidere di salvare la nuova versione della fork editata separatamente con un nome particolare. I chunk non modificati rimangono gli stessi per la nuova versione e i chunk editati vengono inoltre suddivisi o riuniti secondo specifici criteri di suddivisione e unione (split and join) dei chunk impostati per un progetto musicale. L’utente può anche scegliere di salvare l’intero file musicale come versione raggruppando le attuali versioni di tutte le fork nel file. Va inteso che due qualsiasi versioni di file sono diverse se contengono almeno una fork i cui contenuti/ i cui chunk/ i cui attributi sono diversi.

Inoltre, a prescindere dal formato di dati contenuto in una fork, i chunk di dati sono i componenti atomici che la compongono. Dopo aver caricato una nuova fork al server di dati, il server di dati automaticamente suddivide i dati della fork in una lista collegata di chunk.

Il numero dei chunk dipende dalla dimensione dell’array di byte che rappresenta la fork e ciascun chunk è al massimo di una dimensione di N byte, dove N è un parametro che può venire configurato dall’utente.

Un altro criterio di suddivisione è basato sull’estrazione di pezzi specifici della struttura della traccia dopo l’analisi dei formati dei dati di file. Ogni volta che un chunk viene editato, il server di dati lo contrassegna come modificato. Una volta che l’utente decide di salvare la fork come nuova versione, il server di dati trasforma i chunk editati e mantiene i chunk invariati aggiungendo un collegamento alla nuova versione senza essere duplicati. In questo modo il server di dati conserva efficientemente la storia di tutte le versioni risparmiando una quantità considerevole di spazio di memorizzazione, in special modo quando il numero di chunk modificati è piccolo.

Inoltre, il server di dati permette di recuperare qualsiasi versione specifica della fork attuale solo seguendo i collegamenti tra chunk etichettati con tale versione. Questo riduce le esigenze di memoria nell’ immagazzinamento di molteplici versioni in quanto solo i dati modificati sono immagazzinati separatamente e sono collegati ai dati originali senza mantenere una copia dei dati originali.

La FIG. 3 illustra un diagramma di flusso 300 di un metodo per editare un file particolare immagazzinato in una base di dati di un server di dati (come il server di dati 102), secondo una forma di realizzazione della presente divulgazione. Al file può avere accesso, ed esso può venire editato da, un utente locale o un utente remoto attraverso una rete (come la rete 108). Il file può comprendere qualsiasi tipo di dati, ma non è limitato ad, audio, video, grafica, testo o una combinazione degli stessi. L’editing/ la modifica di un file comprende, ma non si limita a, modificare i dati immagazzinati nel file, aggiungere dati nel file, cancellare dati dal file, sostituire il file o parte del file, cancellare il file o parte del file, modificare metadati del file, modificare proprietà del file, modificare attributi del file, ecc. Complessivamente, qualsiasi cambiamento nel file originale corrisponde all’editing o alla modifica del file.

Facendo ora riferimento alla fase 302 del diagramma di flusso 300, dal server di dati viene ricevuta una richiesta da un utente (locale o remoto) di editare un file particolare (preso da una pluralità di file) che è immagazzinato in una base di dati del server di dati. Per esempio, se un utente (musicista) ha immagazzinato le sue creazioni musicali (come file) nella base di dati del server di dati, l’utente può voler editare un particolare file musicale per creare una nuova versione dello stesso.

Alla fase 304, viene ricevuta un’altra richiesta dall’utente di selezionare una particolare fork del file selezionato a scopo di editing. Per esempio, nel caso in cui l’utente ha una pluralità di file audio immagazzinati nella base di dati del server di dati 102. L’utente può voler editare una specifica fork (componente) del particolare file audio. Alla fase 306, vengono ricevute istruzioni di editing dall’utente per editare la particolare fork. L’utente può usare le capacità di elaborazione del server di dati per editare la fork che è immagazzinata nella base di dati del server di dati.

Alla fase 308, le istruzioni di editing ricevute dall’utente vengono elaborate dal server di dati per modificare la particolare fork secondo le istruzioni di editing. Per esempio, se l’utente desidera editare la fork selezionata (melodia) aggiungendo una tonalità alla melodia. Le istruzioni di editing per editare la fork selezionata (melodia) vengono elaborate per modificare la fork selezionata in tal senso.

Alla fase 310, la fork modificata viene immagazzinata separatamente come nuova versione della fork. Per esempio, la melodia modificata (fork) con tonalità aggiunta viene immagazzinata come nuova versione della melodia (fork). Ad ogni modo, si deve notare che la nuova versione della fork comprende solo dati che sono modificati. I dati non modificati vengono ripresi dalla fork originale collegando i dati originali con i dati modificati. In questo modo viene risparmiato molto spazio di memoria, evitando la ridondanza nell’ immagazzinaggio di dati.

Alla fase 312, il server di dati fornisce accesso alle versioni sia originale sia modificata della fork a utenti locali o remoti. La versione modificata della fork viene immagazzinata come nuova versione aggiungendo un collegamento alla versione originale della fork. Pertanto, l’utente può avere accesso sia alla versione originale sia a quella modificata della fork seguendo i collegamenti tra le versioni originale e modificata della fork. Il processo di collegamento permette di abbinare dati modificati con i dati che non sono stati modificati. In questo modo un utente può avere accesso alla fork originale con e senza i dati modificati.

Per esempio, la fork modificata con tonalità aggiunta viene immagazzinata come la versione modificata della fork aggiungendo un collegamento alla fork originale del particolare file audio, e cioè la melodia originale senza tonalità aggiunta. Pertanto, l’utente può avere accesso alle versioni sia originale sia modificata della fork seguendo i collegamenti tra le versioni modificate della fork.

Similmente, alla fase 314, il server di dati può permettere l’accesso al file originale (con molteplici fork) con fork originale nonché con fork modificata. Si deve notare che mentre si accede al file con fork modificata, il server di dati avrà accesso solo ai dati modificati nella fork e si collegherà alle porzioni rimanenti della fork dalla copia originale della fork. Maggiori dettagli sul collegamento di dati modificati con dati non modificati vengono divulgati ulteriormente in combinazione con la FIG. 13 della presente divulgazione.

La FIG. 4 illustra un diagramma di flusso 400 di un metodo per modificare un particolare chunk di una particolare fork di un file audio, secondo una forma di realizzazione della presente divulgazione. Alla fase 402, vengono ricevute istruzioni di editing da un utente da parte di un server di dati di modificare un particolare chunk di una particolare fork di un file audio. Il server di dati esegue l’istruzione dell’utente di modificare il chunk alla fase 404 usando le sue capacità di elaborazione. Successivamente, alla fase 406, il server di dati può immagazzinare il chunk modificato separatamente come versione modificata del chunk e può permettere l’accesso alle versioni sia originale sia modificata della fork a un utente locale o remoto. Similmente, alla fase 410, l’accesso al file viene fornito all’utente con o senza la versione modificata della fork, sulla base delle esigenze dell’utente.

La FIG. 5 illustra un diagramma di flusso 500 di un metodo per immagazzinare la versione originale di una fork con o senza chunk modificato, secondo una forma di realizzazione della presente divulgazione. Alla fase 502, vengono ricevute istruzioni di editing da parte di un server di dati da un utente di modificare un chunk di una particolare fork di un file audio che è immagazzinato in una base di dati del server di dati.

Alla fase 504, le istruzioni dell’utente di modificare il chunk vengono eseguite dal server di dati. Per esempio, l’utente può richiedere di editare il particolare chunk (ad esempio: una parte specifica di una melodia di chitarra). La parte specifica/completa del chunk quindi viene modificata dal server di dati come da istruzioni dell’utente. Il server di dati può essere configurato per gestire richieste di editing dagli utenti con l’aiuto di correlati algoritmi, programmi o software pre- installati nel server di dati.

Alla fase 506, il server di dati immagazzina il chunk modificato come versione separata del chunk nella sua base di dati. La versione modificata del chunk è collegabile alla parte restante della sua fork per permettere a qualsiasi utente di accedere alla fork completa con o senza il chunk modificato, alla fase 508. Similmente, alla fase 510, il server di dati permette a qualsiasi utente di accedere al file di musica con o senza il chunk modificato. Immagazzinando copia solo dei dati modificati e poi collegando i dati modificati con il resto del file non modificato, il server di dati risponde alla necessità di gestire efficientemente lo spazio di memorizzazione tenendo sotto controllo la ridondanza di dati. Maggiori dettagli sul collegamento di dati modificati con dati non modificati vengono divulgati ulteriormente in combinazione con la FIG. 13 della presente divulgazione.

La FIG. 6 illustra un diagramma di flusso 600 di un metodo per unire due o più chunk sequenziali da un file audio, secondo una forma di realizzazione della presente divulgazione. Alla fase 602, un server di dati analizza la sua base di dati immagazzinando una pluralità di file audio per identificare un file, in cui parametri di certi chunk sono al di sotto di un limite di soglia. Successivamente, alla fase 604, il server di dati raggruppa (abbina o unisce) i chunk determinati con i loro chunk sequenziali.

Per esempio, i chunk del file potrebbero richiedere di essere di una particolare dimensione e i chunk con una dimensione minore potrebbero richiedere di venire raggruppati con i loro chunk sequenziali per soddisfare il limite di dimensione di soglia. Se dopo il raggruppamento la dimensione dei chunk viene superata al di sopra di un limite di soglia, allora il chunk raggruppato può richiedere la suddivisione per soddisfare i livelli di soglia della dimensione. Questo processo di suddivisione viene definito ulteriormente in combinazione con la FIG. 7 della presente divulgazione.

Alla fase 606, le versioni raggruppate dei chunk sequenziali sono immagazzinate separatamente come copia dei chunk originali. Va inteso che i chunk originali non sono modificati ma una copia degli stessi viene modificata e immagazzinata separatamente come versione dei chunk originali. Successivamente, alla fase 608, il server di dati permette l’accesso ai chunk originali nonché ai chunk modificati o raggruppati a un utente locale o remoto. L’utente può avere accesso ai chunk soli oppure può avere accesso ai chunk con il resto della sua fork o come file di musica completo.

La FIG. 7 illustra un diagramma di flusso 700 di un metodo per suddividere un chunk, secondo una forma di realizzazione della presente divulgazione. Alla fase 702, un server di dati riceve istruzioni da un utente di modificare un particolare chunk di una particolare fork di un file di musica. Il server di dati modifica il chunk secondo le istruzioni dell’utente alla fase 704. Inoltre, la copia modificata del chunk è immagazzinata separatamente nella base di dati del server di dati di modo da conservare anche la copia originale del chunk.

Successivamente, alla fase 706, il server di dati può rilevare che uno dei parametri della versione modificata (copia) del chunk ha superato un parametro di soglia. Il parametro di soglia può venire impostato da un utente. Per esempio, il parametro potrebbe essere la dimensione del chunk. Successivamente, il server di dati può suddividere il chunk in due o più chunk per soddisfare il parametro di soglia. Le copie suddivise dei chunk sono immagazzinate separatamente nella base di dati conservando anche la copia originale del chunk suddiviso, alla fase 708. Inoltre, il server di dati permette l’accesso per l’utente sia ai chunk originali sia a quelli suddivisi. In questo modo l’utente può seguire tutte le modifiche eseguite su qualsiasi chunk particolare dalla storia delle modifiche salvata dal server di dati.

La FIG. 8 illustra un diagramma di flusso 800 di un metodo per suddividere automaticamente un chunk di un file audio, secondo una forma di realizzazione della presente divulgazione. Alla fase 802, un server di dati analizza i file immagazzinati nella sua base di dati per determinare un file di musica, in cui uno o più chunk del file sono al di sopra di un livello di soglia. I chunk possono avere diversi parametri come dimensione, tempo, tipo, ecc. Questi parametri possono avere livelli di soglia predefiniti che possono venire impostati dagli utenti. Se uno qualsiasi dei livelli di soglia viene superato, il server di dati può venire configurato per innescare delle azioni.

Alla fase 804, il server di dati innesca un’azione di creare una copia di un chunk determinato per la suddivisione. Successivamente, il server di dati divide la copia del determinato chunk in due o più chunk separati secondo i livelli di soglia di parametri pre-defìniti. La copia divisa del chunk determinato viene immagazzinata separatamente nella base di dati del server di dati, alla fase 806. Successivamente, la copia originale e la copia divisa del chunk sono rese disponibili per l’accesso a un utente locale o remoto, alla fase 808.

Per esempio, se il server di dati ha determinato che la dimensione di un particolare chunk viene superata rispetto a un limite di soglia, allora il server di dati può dividere una copia di quel chunk in molteplici chunk più piccoli di uguali dimensioni, secondo il limite di soglia della dimensione. Inoltre, se dopo la suddivisione dei chunk, la dimensione di qualsiasi chunk suddiviso viene ridotta al di sotto di un livello di soglia, allora il server di dati può unire il chunk più piccolo con il suo chunk sequenziale per mantenere una dimensione di soglia, lo stesso processo viene descritto nel dettaglio in combinazione con la FIG. 7 della presente divulgazione.

La FIG. 9 illustra un diagramma di flusso 900 per modificare in remoto un file di dati immagazzinato su un server di dati, secondo una forma di realizzazione della presente divulgazione. Il server di dati può avere una base di dati che immagazzina una pluralità di file comprendenti vari tipi di dati quali testo, audio, video, grafica o una combinazione degli stessi. Il server di dati può inoltre essere configurato per permettere a un utente locale o a un utente remoto di accedere ai file immagazzinati nella base di dati e di eseguire azioni come, ma non limitate ad, aggiunta, cancellazione, modifica, ecc.

Ciascun file immagazzinato nella base di dati può inoltre essere costituito da varie parti che possono ulteriormente venire suddivise. Per un riferimento comodo, qualsiasi file immagazzinato nella base di dati del server di dati può venire designato qui di seguito come ‘file genitore’. Inoltre, il file genitore viene ritenuto essere in grado di dividersi in set di dati figlio. Va inteso che se tutti i set di dati figlio sono combinati in forma gerarchica, può venire ottenuto il file genitore. In modo simile, i set di dati figlio sono anche in grado di venire divisi in sotto-set di dati figlio. Per esempio, un file di musica può venire diviso in molteplici fork e ciascuna fork può venire suddivisa in molteplici chunk.

In un altro esempio, un file di testo con grafica può venire diviso in un set di dati di testo e in un set di dati grafici. Il file di testo può anche essere diviso in molteplici capitoli o in un set di pagine ecc. Similmente, un file video può venire diviso in dati video, dati audio, dati di testo separati (intestazioni). Una persona esperta del ramo comprenderà che sebbene la descrizione sia redatta con un esempio primario di file di musica costituiti da fork e chunk, lo stesso non deve venire ritenuto limitare l’estensione della divulgazione. Tutti i tipi di file di dati sono inclusi nella presente entro l’estensione della presente divulgazione.

Più specificamente, il metodo è relativo alla gestione di una memoria locale di un dispositivo elettronico (come il server di dati 102) che immagazzina una pluralità di file di dati genitore, in cui i file di dati genitore sono costituiti da una pluralità di set di dati figlio.

Il metodo permette al dispositivo elettronico di modificare un set di dati figlio di un file di dati genitore e quindi di immagazzinare il set di dati figlio modificato separatamente nella memoria locale come versione del set di dati figlio. Questo permette al dispositivo elettronico di consentire l’accesso al file di dati genitore con e senza il set di dati figlio modificato, a qualsiasi utente locale o remoto. Il metodo è descritto sotto nel dettaglio con un esempio di file di musica che sono i file di dati genitore, le fork che sono il set di dati figlio, e i chunk che sono i sottoset di dati figlio.

Facendo ora riferimento al diagramma di flusso 900, alla fase 902 il server di dati riceve una richiesta da un utente remoto (attraverso una rete) di modificare un file di dati genitore. Più specificamente, la richiesta dell’utente comprende uno specifico set di dati figlio del file genitore che deve venire modificato secondo l’istruzione dell’utente. Il server di dati successivamente elabora le istruzioni dell’utente e per modificare il particolare set di dati figlio del file genitore. Il processo di modificare in remoto qualsiasi file attraverso una rete è noto nella tecnica e pertanto non viene descritto nel dettaglio. Qualsiasi persona esperta nella tecnica deve avere la conoscenza di base della stessa.

Alla fase 904, il set di dati figlio modificato viene immagazzinato in una memoria locale del server di dati come versione del set di dati figlio. Nella presente, le modifiche sono fatte su una copia del set di dati figlio e non sul set di dati figlio stesso. Inoltre, il set di dati figlio originale viene mantenuto in memoria assieme alla copia modificata e viene designato nella presente come versione del set di dati figlio originale. La copia del set di dati figlio modificato è immagazzinata nella memoria locale come la versione del set di dati figlio aggiungendo un collegamento al set di dati figlio originale. Il collegamento permette al server di dati di accedere al file di dati genitore con o senza il set di dati figlio modificato.

Più specificamente, altri set di dati figlio del file di dati genitore possono venire collegati alla copia originale del set di dati modificato e possono anche venire collegati con la copia modificata stessa. Sulla base dell’esigenza, si può accedere al file di dati genitore con o senza set di dati figlio modificato, alla fase 906. Va inteso che il set di dati figlio del file di dati genitore è inoltre divisibile in uno o più sotto-set di dati figlio.

Il server di dati è anche in grado di modificare uno o più sotto-set di dati figlio del file di dati genitore su richiesta dell’utente. Dopo le modifiche richieste dall’utente, il server di dati può immagazzinare il sotto- set di dati figlio modificato separatamente nella memoria locale come versione dell’uno o più sotto-set di dati figlio, per permettere l’accesso al file di dati genitore con e senza il sotto-set di dati figlio modificato. Il server di dati può inoltre permettere l’accesso al set di dati figlio con e senza il sotto-set di dati figlio modificato.

La FIG. 10 illustra un diagramma di flusso 1000 per dividere un set di dati figlio modificato in due o più set di dati nuovi sulla base di un limite di soglia, secondo una forma di realizzazione della presente divulgazione. Il diagramma di flusso 1000 è una continuazione del diagramma di flusso 900 e tutte le terminologie sono ereditate nella presente dalla descrizione del diagramma di flusso 900. Facendo ora riferimento alla fase 1002 del diagramma di flusso 1000, viene determinato dal server di dati se almeno un parametro di un set di dati figlio modificato ha attraversato un limite di soglia per innescare un’azione. In una forma di realizzazione, l’utente può avere un’opzione di impostare il limite di soglia per i set di dati figlio sulla base di diversi parametri come dimensione del file, tipo di file ecc.

Alla fase 1004, se viene determinato che il set di dati figlio modificato ha attraversato una soglia, allora il server di dati divide il set di dati figlio modificato in due o più set di dati, sulla base del limite di soglia definito dall’utente. Alla fase 1006, i set di dati figlio nuovi (copia divisa dell’originale) sono immagazzinati separatamente come versione del set di dati figlio modificato. I set di dati figlio nuovi sono immagazzinati separatamente aggiungendo un collegamento al set di dati modificato per la determinazione di molteplici versioni del set di dati modificato.

Alla fase 1008, l’utente può essere in grado di accedere al file di dati genitore con il sotto-set di dati figlio modificato nonché con il set di dati figlio nuovo. I set di dati figlio nuovi sono immagazzinati con il set di dati figlio modificato aggiungendo il collegamento ai set di dati figlio nuovi. Pertanto, l’utente può accedere al file genitore con il set di dati figlio modificato e con i set di dati figlio nuovi seguendo i collegamenti tra il set di dati modificato e i set di dati figlio nuovi. In una forma di realizzazione alternativa, lo stesso processo può anche essere valido con sotto-set di dati figlio di un set di dati figlio. Per esempio, se almeno un parametro di un sotto-set di dati figlio ha attraversato un limite di soglia, il sotto-set di dati figlio può venire diviso in due o più sotto-set di dati figlio sulla base del limite di soglia.

La FIG. 11 illustra un diagramma di flusso 1100 di un metodo per unire un set di dati figlio modificato con il suo set sequenziale di dati figlio per formare un set di dati figlio nuovo, secondo una forma di realizzazione della presente divulgazione. Il diagramma di flusso 1100 è una continuazione del diagramma di flusso 900 e tutte le terminologie sono ereditate nella presente dalla descrizione del diagramma di flusso 900 e 1000.

Facendo ora riferimento alla fase 1 102 del diagramma di flusso 1100, viene determinato se almeno un parametro di un set di dati figlio modificato è al di sotto di un limite di soglia. Alla fase 1 104, se il set di dati figlio modificato viene determinato al di sotto del limite di soglia, allora il server di dati può automaticamente unire il set di dati figlio modificato con il(i) suo(i) set di dati figlio sequenziale(i) a formare un set di dati figlio nuovo che soddisfa il limite di soglia. Alla fase 1106, il set di dati figlio nuovo viene immagazzinato separatamente come versione del set di dati figlio modificato. Inoltre, il set di dati figlio nuovo è immagazzinato separatamente aggiungendo un collegamento al set di dati modificato.

Alla fase 1108, il server di dati può permettere all’utente di accedere al file di dati genitore con il set di dati figlio modificato nonché con il set di dati figlio nuovo. I set di dati figlio nuovi sono immagazzinati con il set di dati figlio modificato aggiungendo il collegamento al set di dati figlio nuovo. Pertanto, l’utente può accedere al file genitore con il set di dati figlio modificato e con il set di dati figlio nuovo seguendo i collegamenti tra il set di dati modificato e i set di dati figlio nuovi. In uno scenario alternativo, lo stesso processo può essere valido con sotto-set di dati figlio dei set di dati figlio.

La FIG. 12 illustra un diagramma a blocchi di un dispositivo elettronico 1200 (come il server di dati 102), secondo una forma di realizzazione della presente divulgazione. Il dispositivo elettronico può essere qualsiasi dispositivo elettronico come, ma non limitato a, computer portatile, computer da tavolo, telefono mobile, tablet, server, ecc. Come rappresentato dalla figura, il dispositivo elettronico 1200 comprende un processore 1202, un modulo di interfaccia di rete 1204 e una memoria 1206 per l’immagazzinamento dei dati. Il modulo di interfaccia di rete 1204 viene usato per collegare il dispositivo elettronico 1200 con una rete (come la rete 108). Il processore 1202 può comprendere uno o più di un processore. Il modulo di interfaccia di rete 1204 può essere un hardware, un software o una combinazione degli stessi.

La memoria 1206 inoltre comprende un set di istruzioni 1208 e una base di dati 1210. Il set di istruzioni 1208 immagazzinato nella memoria 1206 usa il processore 1202 per eseguire delle azioni, ad esempio ricevere, immagazzinare, elaborare e trasmettere dati immagazzinati nella memoria 1206. In una forma di realizzazione della presente divulgazione, la memoria 1206 può essere una memoria volatile nontransitoria o una memoria non-volatile. Per esempio, ma non limitatamente a, memoria ad accesso casuale (RAM - Random Acess Memory), memoria cache, disco rigido (HDD - Hard Disk Drive), unità a stato solido (SSD - Solid State Drive), compact disk (CD), memorie portatili e simili.

La base di dati 1210 comprende una pluralità di file di dati genitore che sono costituiti da una pluralità di set di dati figlio. Il set di istruzioni 1208 comprende istruzioni che quando eseguite dall’uno o più processori fanno sì che il dispositivo elettronico 1200 modifichi un set di dati figlio di un file di dati genitore, immagazzini il set di dati figlio modificato separatamente nella memoria locale come versione del set di dati figlio e permetta l’accesso al file di dati genitore con e senza il set di dati figlio modificato. Il set di dati figlio del file di dati genitore è inoltre divisibile in uno o più sotto-set di dati figlio.

Il set di istruzioni 1208 inoltre comprende istruzioni per modificare l’uno o più sotto-set di dati figlio, immagazzinare i sotto-set di dati figlio modificati separatamente nella memoria locale come versione dell’uno o più sotto-set di dati figlio e permettere l’accesso al file di dati genitore con e senza i sotto-set di dati figlio modificati. Può anche essere previsto l’accesso al set di dati figlio con e senza i sotto-set di dati figlio modificati.

Il set di istruzioni 1208 inoltre comprende istruzioni per determinare se almeno un parametro del set di dati figlio modificato ha attraversato un limite di soglia. Se ciò viene determinato, allora dividere il set di dati figlio modificato in due o più set di dati nuovi sulla base del limite di soglia. Successivamente, immagazzinare i set di dati figlio nuovi separatamente come versione del set di dati figlio modificato e permettere l’accesso al file di dati genitore con il set di dati figlio modificato e con i set di dati figlio nuovi.

Il set di istruzioni 1208 inoltre comprende istruzioni per determinare se almeno un parametro del set di dati figlio modificato è al di sotto di un limite di soglia. Se ciò viene determinato, allora unire il set di dati figlio modificato con il suo set di dati figlio sequenziale a formare un set di dati figlio nuovo. Successivamente, immagazzinare il set di dati figlio nuovo separatamente come versione del set di dati figlio modificato e permettere l’accesso al file di dati genitore con il set di dati figlio modificato e con il set di dati figlio nuovo.

Maggiori dettagli corrispondenti all’unione e alla divisione dei set di dati figlio sono spiegati più oltre in connessione con la FIG. 13 della presente divulgazione, in cui il file genitore viene indicato con un esempio di un file di musica, il set di dati figlio viene indicato come una fork e i sotto-set di dati figlio sono indicati come chunk.

Facendo ora riferimento alla FIG. 13, viene illustrata una struttura rappresentativa di immagazzinaggio di memoria per definire un modo in cui un server di dati può immagazzinare la storia delle versioni di file di musica. Viene illustrata un’unica fork 1302 di un file musicale (non mostrato). La singola fork 1302 è inoltre illustrata come formata da una pluralità di chunk 1304a-n. La pluralità di chunk originali 1304a-n vengono designati qui come parte della versione 1 della fork 1302. Qualsiasi modifica nei chunk può essere immagazzinata separatamente e si può accedere alla fork 1302 con i chunk modificati come versione 2 della fork 1302. Qualsiasi ulteriore modifica nella fork creerà la versione 3 e via dicendo.

Va inteso che, sebbene qualsiasi modifica in una fork sia considerata una nuova versione della fork, purtuttavia tutti i chunk della fork non sono immagazzinati nelle nuove versioni e solo il chunk modificato è immagazzinato separatamente. Il server di dati collega i dati modificati con dati non modificati e pertanto consente l’accesso a molteplici versioni della stessa fork senza dover creare ridondanza nell’ immagazzinamento di dati.

Inoltre, come illustrato, i chunk 1304b e 1304c vengono uniti a formare un singolo chunk 1304bc. Si può accedere facilmente alla fork 1302 con il chunk modificato 1304 facendo riferimento alla versione 2 della fork 1302. Similmente, il chunk 1304d viene suddiviso in due nuovi chunk 1304dl e 1304d2 e forma la versione 3 della fork 1302. Qualsiasi ulteriore modifica nei chunk può avere come risultato ulteriori versioni della fork 1302.

Nonostante la presente divulgazione sia stata descritta in termini di alcune forme di realizzazione preferenziali, varie caratteristiche di forme di realizzazione separate possono venire combinate a formare forme di realizzazione aggiuntive non descritte espressamente. Inoltre, altre forme di realizzazione evidenti per le persone con ordinarie competenze nella tecnica dopo aver letto questa divulgazione rientrano anch’esse nell’estensione di questa invenzione. Inoltre, non sono necessariamente richieste tutte le caratteristiche, gli aspetti e i vantaggi per mettere in pratica la presente divulgazione. Pertanto, mentre la descrizione dettagliata di cui sopra ha mostrato, descritto ed evidenziato nuove caratteristiche dell’invenzione così come applicate a varie forme di realizzazione, si comprenderà che varie omissioni, sostituzioni e cambiamenti nella forma e nei dettagli dell’ apparecchiatura o processo illustrati possono venire apportate dalle persone con ordinarie competenze nella tecnologia senza allontanarsi dallo spirito dell’invenzione.

Le invenzioni possono venire realizzate in altre forme specifiche non descritte esplicitamente nella presente. Le forme di realizzazione descritte sopra devono venire considerate sotto tutti gli aspetti solo a titolo illustrativo e in nessun modo limitativo. Pertanto, l’estensione dell’invenzione viene individuata dalle rivendicazioni che seguono, piuttosto che dalla descrizione che precede.

La presente divulgazione è espressa e caratterizzata nelle rivendicazioni indipendenti, mentre le rivendicazioni dipendenti descrivono altre caratteristiche dell’invenzione o varianti dell’idea inventiva principale.

Claims (17)

1. RIVENDICAZIONI 1. Metodo per gestire una memoria locale di un dispositivo elettronico che immagazzina una pluralità di file di dati genitore, in cui i file di dati genitore sono costituiti da una pluralità di set di dati figlio, caratterizzato dal fatto che il metodo permette al dispositivo elettronico di: - modificare (902) un set di dati figlio di un file di dati genitore; - immagazzinare (904) il set di dati figlio modificato separatamente nella memoria locale come versione del set di dati figlio; e - permettere (906) l’accesso al file di dati genitore con e senza il set di dati figlio modificato.
2. 2. Metodo secondo la rivendicazione 1, in cui il metodo inoltre permette al dispositivo elettronico di: - determinare (1002) se almeno un parametro del set di dati figlio modificato ha attraversato un limite di soglia; - dividere (1004) il set di dati figlio modificato in due o più nuovi set di dati sulla base del limite di soglia; - immagazzinare (1006) i set di dati figlio nuovi separatamente come versione del set di dati figlio modificato; e - permettere (1008) l’accesso al file di dati genitore con il set di dati figlio modificato e con i set di dati figlio nuovi.
3. 3. Metodo secondo la rivendicazione 1, in cui il metodo inoltre permette al dispositivo elettronico di: - determinare (1102) se almeno un parametro del set di dati figlio modificato è al di sotto di un limite di soglia; - unire (1104) il set di dati figlio modificato con il suo set di dati figlio sequenziale a formare un set di dati figlio nuovo; - immagazzinare (1106) il set di dati figlio nuovo separatamente come versione del set di dati figlio modificato; e - permettere (1108) l’accesso al file di dati genitore con il set di dati figlio modificato e con il set di dati figlio nuovo.
4. 4. Metodo secondo la rivendicazione 1, in cui il set di dati figlio del file di dati genitore è inoltre diviso in uno o più sotto-set di dati figlio.
5. 5. Metodo secondo la rivendicazione 4, in cui il metodo inoltre permette al dispositivo elettronico di: - modificare l’uno o più sotto-set di dati figlio; - immagazzinare i sotto-set di dati figlio modificati separatamente nella memoria locale come versione dell’uno o più sotto-set di dati figlio; e - permettere l’accesso al file di dati genitore con e senza i sotto-set di dati figlio modificati.
6. 6. Metodo secondo la rivendicazione 5, in cui il metodo inoltre permette l’accesso al set di dati figlio con e senza i sotto-set di dati figlio modificati.
7. 7. Metodo secondo la rivendicazione 5, in cui prevede di recuperare informazioni arbitrarie relative a un file di dati genitore e/o a un file di dati figlio e/o un sotto-file di dati figlio allo scopo di calcolare e fornire la proprietà dei diritti per ciascun autore che ha lavorato sullo specifico file di dati, detta proprietà dei diritti essendo espressa in percentuali.
8. 8. Metodo secondo la rivendicazione 5, in cui il file di dati genitore è un file audio.
9. 9. Metodo secondo la rivendicazione 5, in cui il set di dati figlio comprende almeno una fork audio.
10. 10. Metodo secondo la rivendicazione 5, in cui i sotto-set di dati figlio comprendono almeno un chunk audio.
11. 11. Apparecchiatura (1200) collegata a una rete, l’apparecchiatura comprendendo: - uno o più processori (1202); - un modulo di interfaccia di rete (1204) per collegare l’apparecchiatura alla rete; - una memoria (1206) comprendente: - una base di dati (1210) comprendente una pluralità di file di dati genitore, in cui i file di dati genitore sono costituiti da una pluralità di set di dati figlio; - un set di istruzioni (1208) comprendente istruzioni che quando vengono eseguite dall’uno o più processori fanno sì che l’apparecchiatura compia una pluralità di operazioni, caratterizzata dal fatto che l’apparecchiatura è inoltre configurata per: - modificare un set di dati figlio di un file di dati genitore; - immagazzinare il set di dati figlio modificato separatamente nella memoria locale come versione del set di dati figlio; e - permettere l’accesso al file di dati genitore con e senza il set di dati figlio modificato.
12. 12. Apparecchiatura secondo la rivendicazione 11, in cui l’apparecchiatura è inoltre configurata per: - determinare se almeno un parametro del set di dati figlio modificato ha attraversato un limite di soglia; e - dividere il set di dati figlio modificato in due o più nuovi set di dati sulla base del limite di soglia; - immagazzinare i set di dati figlio nuovi separatamente come versione del set di dati figlio modificato; e - permettere l’accesso al file di dati genitore con il set di dati figlio modificato e con i set di dati figlio nuovi.
13. 13. Apparecchiatura secondo la rivendicazione 11, in cui l’apparecchiatura è inoltre configurata per: - determinare se almeno un parametro del set di dati figlio modificato è al di sotto di un limite di soglia; e - unire il set di dati figlio modificato con il suo set di dati figlio sequenziale a formare un set di dati figlio nuovo; - immagazzinare il set di dati figlio nuovo separatamente come versione del set di dati figlio modificato; e - permettere l’accesso al file di dati genitore con il set di dati figlio modificato e con il set di dati figlio nuovo.
14. 14. Apparecchiatura secondo la rivendicazione 11, in cui il set di dati figlio del file di dati genitore è inoltre diviso in uno o più sotto-set di dati figlio.
15. 15. L’apparecchiatura secondo la rivendicazione 14 è inoltre configurata per: - modificare l’uno o più sotto-set di dati figlio; - immagazzinare i sotto-set di dati figlio modificati separatamente nella memoria locale come versione dell’uno o più sotto-set di dati figlio; e - permettere l’accesso al file di dati genitore con e senza i sotto-set di dati figlio modificati.
16. 16. L’apparecchiatura secondo la rivendicazione 14 inoltre permette l’accesso al set di dati figlio con e senza i sotto-set di dati figlio modificati.
17. 17. Apparecchiatura secondo la rivendicazione 15, in cui comprende un meccanismo automatico configurato per recuperare informazioni arbitrarie relative a un file di dati genitore e/o a un file di dati figlio e/o a un sotto-file di dati figlio al fine di calcolare e fornire la proprietà dei diritti per ciascun autore che ha lavorato sullo specifico file di dati, detta proprietà di diritti essendo espressa in percentuali.