BR0006882B1

BR0006882B1 - Cartão de memória semicondutora, aparelho de execução, aparelho de gravação, método de execução, método de gravação e meio de gravação que pode ser lido por computador

Info

Publication number: BR0006882B1
Application number: BRPI0006882-9A
Authority: BR
Inventors: Teruto Hirota; Kenji Tagawa; Hideki Matsushima; Tomokazu Ishikawa; Shinji Inoue; Masayuki Kozura
Original assignee: Panasonic Corp
Priority date: 1999-05-28
Filing date: 2000-05-24
Publication date: 2014-03-18
Also published as: CN1187756C; US20050192686A1; EP1056092A1; EP1056092B1; JP4150278B2; DE60035455D1; DE60035455T2; CN1318196A; CA2338634C; BR0006882A; CA2338634A1; ID27746A; US6865431B1; US8156347B2; MY125354A; US20100064145A1; JP2001249695A; US7596698B2; JP2004030586A; JP3425119B2

Description

Relatório Descritivo da Patente de Invenção para "CARTÃO DE

MEMÓRIA SEMICONDUTORA, APARELHO DE EXECUÇÃO, APARELHO

DE GRAVAÇÃO, MÉTODO DE EXECUÇÃO, MÉTODO DE GRAVAÇÃO E MEIO DE GRAVAÇÃO QUE PODE SER LIDO POR COMPUTADOR".

Campo Técnico A presente invenção refere-se a um cartão de memória semi- condutora que armazena dados de áudio e dados de controle e com um aparelho de execução, aparelho de gravação, método de execução, método de gravação e com um meio de memória que pode ser lido por computador relacionando-se com tal cartão de memória semicondutora. Em particular, a presente invenção relaciona-se com o armazenamento aperfeiçoado da in- formação de gerenciamento e de dados de áudio distribuídos como conteú- do por um serviço de distribuição de conteúdo, tal como um serviço eletrôni- co de distribuição de música.

Fundamento da Técnica Os anos recentes têm testemunhado a introdução gradual da infra-estrutura de hardware necessária para a distribuição eletrônica de mú- sica. Isto dá origem ao potencial por uma grande alteração na indústria da música, onde os produtos têm sido convencionalmente distribuídos como software empacotado utilizando meios tal como os discos compactos (CDs) e fitas cassete. O conteúdo da música eletrônica (isto é, canções e álbuns) pode ser distribuído para os consumidores por se ter a transferência do conteúdo para o computador pessoal do consumidor a partir de um compu- tador servidor operado por uma gravadora. Para escutar a música digital transferida em um executor portátil, o usuário necessita armazenar os dados da música em um meio de gravação portátil. Atualmente, o meio mais ade- quado para armazenar os dados da música eletronicamente distribuídos são os cartões de memória semicondutora.

Como exemplo, os cartões flash ATA e os cartões COMPACT FLASH já são disponíveis. Tais cartões de memória semicondutora incluem um dispositivo semicondutora chamado de memória flash (EEPROM - Memória Programável Somente para Leitura que pode ser Eletricamente Apagada). A memória flash é capaz de leituras e gravações de dados em velocidades muito superiores do que o MD (MiniDisc) ou o CD-R (Disco Compacto que pode ser Gravado). Isto significa que a música digital pode ser transferida em um curto tempo, a despeito de suas grandes quantidades de dados).

Como uma desvantagem principal, os cartões de memória semi- condutora têm o risco de permitir aos usuários fazer cópias ilegais de músi- ca com direito autorais que foram transferidas de um serviço eletrônico de distribuição de música. Desde que os cartões de memória semicondutora permitem aos dados serem gravados em velocidades mais elevadas do que a do CD-R ou do MD, a cópia é pensada como sendo o problema mais sério para tais cartões de memória. De modo a superar os prejuízos potenciais com relação à transgressão do direito autoral, a música digital tem que ser criptografada utilizando um método de criptografia seguro antes de ser ar- mazenada em um cartão de memória semicondutora.

Um método de armazenamento que leva em consideração a ne- cessidade de impedir a cópia não-autorizada é o método de armazenamento de título utilizado no padrão de DVD-Áudio. Como um exemplo deste méto- do, um "título", que corresponde a um álbum de música convencional, inclui uma pluralidade de "conteúdos", que correspondem às trilhas no álbum. Os conteúdos que compõem um título são criptografados utilizando uma chave de criptografia, chamada de "chave de título", escolhida pelo produtor do disco antes de ser gravado em um disco de DVD-Áudio. Esta chave de título é criptografada utilizando uma chave de criptografia (normalmente chamada de "chave do disco") que é única para cada disco de DVD-Áudio e é arma- zenada em uma região de cabeçalho do setor de um disco de DVD-Áudio.

Esta chave de disco é ela própria criptografada utilizando uma chave de criptografia (normalmente chamada de "chave mestre") escolhida pelos fa- bricantes dos aparelhos de decodificação de conteúdo e é gravada na regi- ão condutora interna do disco DVD-Áudio. A região de cabeçalho do setor e a região condutora interna não podem ser acessadas por usuários normais, tornando extremamente difícil para os usuários obter de forma ilegal a chave de título gravada em um disco DVD-Áudio.

Em comparação com o meio de armazenamento magnético ou ótico, os cartões de memória semicondutora possuem capacidade de arma- zenamento limitada, de modo que normalmente é necessário compactar a música digitai com uma alta taxa de compactação quando armazenando a mesma em um cartão de memória semicondutora. Um método de codifica- ção para realizar uma taxa de compactação suficientemente alta para a mú- sica digital é o MPEG2-AAC (Motion Pictures Expert Group 2 - Codificação de Áudio Avançada). Uma característica da compactação MPEG2-AAC é que ela faz uso das limitações da audição humana e desse modo altera o comprimento do bit dos dados designados para cada quadro de áudio, um quadro de áudio sendo a menor unidade de execução e representando ao redor de 20 ms de áudio. Os dados com comprimentos de bit maiores são designados para quadros de áudio que possuem várias freqüências dentro da faixa da audição humana, ao mesmo tempo que os comprimentos de bit menores são designados para os quadros de áudio com menos sons ou fre- qüências fora da faixa da audição humana.

Desde que a quantidade de dados designada para cada quadro de áudio na MPEG2-AAC dependente do número de freqüências audíveis no quadro (ou em outras palavras, porque a MPEG2-AAC utiliza a codifica- ção de taxa de bits variável (VBR), conteúdos de áudio de alta qualidade podem ser obtidos mesmo em altas taxas de compactação. Tais conteúdos de áudio são adequados para distribuição em uma rede pública e para ar- mazenamento em cartões de memória semicondutora que possuem uma capacidade de armazenamento limitada.

Primeiro Problema Quando os conteúdos estão armazenados de acordo com os métodos convencionais, a decodificação da chave de título utilizada para criptografar os conteúdos da música irá permitir ao usuário decriptografar todos os conteúdos da música gravada em um meio de gravação. Isto dá origem ao primeiro problema da exposição de uma chave de título única, tornando fácil para os usuários decriptografar todas as trilhas armazenadas em um cartão de memória semicondutora.

Ao mesmo tempo que as chaves de título raramente serão ex- postas, tal exposição irá resultar em uma perda incomensurável para o dono do direito autoral. Com os grandes avanços na força de processamento dos computadores domésticos em anos recentes, está se tornando muito difícil dizer que uma chave de título utilizada para criptografar a música digital será totalmente segura em relação à decodificação. Isto dá origem a de- mandas por uma distribuição de dados que irá minimizar o prejuízo para os possuidores do direito autoral quando uma chave de título é exposta.

Segundo Problema A medida que a proteção dos direitos autorais é necessária para a música digital; que é para ser distribuída pela distribuição eletrônica de música, tal música normalmente é distribuída em uma forma criptografada. A criptografia também é requerida para a música digital armazenada em um cartão de memória semicondutora. Entretanto, isto dá origem a um segundo problema no qual um usuário que pagou o preço apropriado para comprar a música digital não estará apto a livremente editar a música quando ela esti- ver armazenada de uma maneira criptografada em um cartão de memória semicondutora. Se os conteúdos da música forem armazenados de uma forma criptografada, será muito difícil para o usuário alterar a ordem das trilhas ou parcialmente deletar trilhas. Considerando que o usuário pagou o preço apropriado, não é desejável restringir a sua habilidade em editar os conteúdos de música deste modo.

Os gravadores de MiniDisc (MD), que podem ser utilizados para gravar música do mesmo modo que o cartão de memória semicondutora, permitem uma variedade de funções de edição de trilha através da provisão de uma TOC (Tabela de Conteúdos). Tais funções incluem a redisposição da ordem de execução das trilhas, a divisão das trilhas e a combinação das trilhas em uma única trilha. Se os gravadores de cartão de memória semi- condutora forem impossibilitados das mesmas funções que as dos gravado- res MD convencionais, é acreditado que os consumidores irão considerar os executores de cartão de memória semicondutora como inferior aos gravado- res de MD, por meio disso prejudicando o potencial comercial dos produtos do cartão de memória semicondutora.

Terceiro Problema Para proporcionar as funções de execução especiais para a música digital que foi sujeita à codificação VBR, como sob o MPEG2-AAC, os aparelhos de execução necessitam ser equipados com memórias de grande capacidade. Isto aumenta o custo de fabricação de tais aparelhos, e propõem um terceiro problema para a técnica de fundamento.

As funções de execução especiais proporcionadas pelos exe- cutores de MD ou CD incluem a habilidade de começar a execução a partir de qualquer trilha em um disco (especificando a posição da execução), uma função de pesquisa de música que executa rajadas intermitentes de música para permitir aos usuários saltar através das trilhas para frente ou para trás em alta velocidade e uma função de pesquisa de tempo por meio da qual os usuários podem ter o início da execução a partir de uma posição informada como uma medida de tempo a partir do início do disco. Para capturar o mer- cado atualmente mantido pelos executores de MD ou CD, é essencial para os aparelhos de execução de cartões de memória semicondutora proporcio- nar as mesmas funções de execução especiais que os executores de MD.

Quando os conteúdos de música são sujeitos à codificação de taxa de bits constante (CBR), a execução a partir de uma posição especificada utilizan- do um código de tempo (tal como um ponto um ou dois minutos a partir do início de uma trilha) pode ser executada simplesmente por se referir a um endereço que está deslocado por um múltiplo interior do tamanho dos dados do tempo de execução unitário. Entretanto, quando os conteúdos de música são codificados utilizando um método VBR tal como o MPEG2-AAC, as po- sições correspondendo a um ou dois minutos à frente da posição corrente raramente será o deslocamento por um múltiplo inteiro do tamanho dos da- dos do tempo de execução unitário. Como resultado, um executor irá neces- sitar se referir a uma tabela de pesquisa de tempo produzida antecipada- mente para apresentar que endereços correspondem aos pontos um minuto ou dois minutos adicionalmente à frente.

Ao mesmo tempo que uma tabela de pesquisa de tempo para uma trilha curta não irá necessitar incluir um grande número de posições de execução, isto não pode ser dito para as tabelas de pesquisa de tempo para trilhas longas, de modo que as tabelas de pesquisa de tempo de trilhas lon- gas são muito grandes. Para proporcionar os recursos de execução especi- ais, um aparelho de execução tem acesso à tabela de pesquisa de tempo tendo primeiro carregado a mesma em sua memória. Desde que trilhas lon- gas possuem tabelas de pesquisa de tempo longas, isto significa que um aparelho de execução tem que ser proporcionado com uma grande memória par armazenar a tabela de pesquisa de tempo. Isto também aumenta os custos de fabricação dos aparelhos de execução.

Revelação da Invenção É um primeiro objetivo da presente invenção proporcionar um cartão de memória semicondutora que proteja os direitos autorais dos con- teúdos de música armazenados no mesmo ao mesmo tempo que permitindo aos usuários editar os conteúdos de música. É um segundo objetivo da presente invenção proporcionar um aparelho de execução que possa executar as funções de execução especi- ais tal como a pesquisa para frente e para trás para dos conteúdos de musi- ca gravados em uma cartão de memória semicondutora sem utilizar uma memória de grande capacidade. O primeiro objetivo da presente invenção pode ser realizado por um cartão de memórias semicondutora que armazena pelo menos uma trilha de áudio, incluindo: uma área protegida que pode ser acessada por um dis- positivo conectado com o cartão de memória semicondutora se o dispositivo for visto como sendo autêntico, a área protegida armazenando uma seqüên- cia de chaves de criptografia composta de uma pluralidade de chaves de criptografia dispostas em uma ordem predeterminada; e uma área desprote- gida que pode ser acessada por qualquer dispositivo conectado com o car- tão de memória semicondutora, a área desprotegida armazenando pelo me- nos uma trilha de áudio e a informação de gerenciamento, a pelo menos uma trilha de áudio incluindo uma pluralidade de objetos de áudio cripto- grafados e a informação de gerenciamento apresentando que chave de criptografia, fora da pluralidade de chaves de criptografia, corresponde a cada objeto de áudio armazenado na área desprotegida.

Com a construção declarada, uma pluralidade de objetos de áu- dio podem ser criptografados utilizando uma pluralidade de chaves de crip- tografia, de modo que caso a chave de criptografia utilizada para criptogra- far um objeto de áudio particular seja decodificada e exposta, tal decodifica- ção somente irá permitir que o objeto de áudio particular seja decriptografa- do e desse modo não terá efeito sobre outros objetos de áudio. Isto significa que o presente cartão de memória semicondutora minimiza o prejuízo cau- sado pela exposição de uma das chaves de criptografia.

Aqui, cada trilha de áudio pode adicionalmente incluir (1) a in- formação de atributo e (2) a informação de ligação para cada objeto de áu- dio incluído na trilha de áudio, a informação de atributo apresentando um tipo (a), fora de tipo (b), tipo (c) e tipo (d), para cada objeto de áudio, o tipo (a) sendo uma trilha de áudio inteira, o tipo (b) sendo uma primeira parte de uma trilha de áudio, o tipo (c) sendo uma parte média de uma trilha de áudio e o tipo (d) sendo uma parte final de uma trilha de áudio e a informação de ligação para cada objeto de áudio é o tipo (b) ou o tipo (c) apresentando que objeto de áudio segue ao objeto de áudio. O uso da construção declarada alcança os efeitos descritos abaixo. A informação de atributo apresenta como os objetos de áudio cripto- grafados compõem as trilhas de áudio, de modo que quando dois objetos de áudio são gerenciados como duas trilhas separadas de áudio, tais trilhas podem ser combinadas para formar uma única trilha por simplesmente alte- rar a informação de atributo para apresentar que objetos de áudio corres- pondem ao início e ao fim de uma trilha. Desde que as trilhas de áudio po- dem ser combinadas por se alterar a informação de atributo, as trilhas po- dem ser combinadas em alta velocidade sem necessitar remover a cripto- grafia das trilhas de áudio.

Aqui, a pluralidade de objetos de áudio pode incluir: pelo menos um objeto de áudio que somente contém dados válidos que necessitam ser executados; e pelo menos um objeto de áudio que contém (1) dados válidos e (2) dados inválidos pelo menos um dos quais localizado antes e depois dos dados válidos, os dados inválidos não necessitando ser executados, cada trilha de áudio adicionalmente incluindo a informação de bloco para cada objeto de áudio na trilha de áudio, a informação de bloco incluindo: um deslocamento medido a partir da posição de armazenamento do objeto de áudio correspondente dada na informação de gerenciamento; e a informa- ção de comprimento apresentando um comprimento dos dados válidos que começa a partir de uma posição indicada pelo deslocamento, a informação de atributo para um objeto de áudio apresentando se os dados válidos indi- cados pelo deslocamento e pela informação de comprimento (a) correspon- dem à uma trilha de áudio inteira, (b) correspondem a uma primeira parte de uma trilha de áudio, (c) correspondem a uma parte média de uma trilha de áudio, ou (d) correspondem a uma parte final de uma trilha de áudio.

Quando os dados inválidos estão presentes no início de um quadro de áudio, o comprimento destes dados inválidos e o comprimento dos dados válidos no quadro de áudio pode ser estabelecido na informação de bloco. Como resultado, quando o usuário grava uma difusão de rádio onde o disc jockey fala sobre a introdução de uma canção, um desloca- mento de dados adequado pode ser estabelecido na informação de bloco para possuir o som executado sem a parte da introdução que inclui a voz do disc jockey. Tais operações de edição podem ser executadas por simples- mente indicar que dados não devem ser executados na informação de bloco e são executadas com os objetos de áudio em seu estado criptografado. Isto significa que as trilhas podem ser editadas em alta velocidade. O segundo objetivo da presente invenção pode ser alcançado por um aparelho de gravação para um cartão de memória semicondutora, incluindo: uma primeira unidade de geração para sucessivamente gerar quadros de áudio a partir de um sinal de entrada recebido de fora do apa- relho de gravação, um quadro de áudio sendo a menor quantidade de dados que pode ser decodificada de forma independente; uma unidade de grava- ção para criar um arquivo no cartão de memória semicondutora e gravar os quadros de áudio sucessivamente gerados dentro do arquivo; uma segunda unidade de geração para gerar, toda vez que a unidade de gravação tenha gravado um número predeterminado de quadros de áudio dentro de um ar- quivo, um pedaço da informação de entrada apresentando o comprimento dos dados de um elemento de áudio que é composto dos quadros de áudio gravados dentro do arquivo, onde toda vez que a segunda unidade de gra- vação tenha gerado um número predeterminado de pedaços da informação de entrada, a unidade de gravação cria um novo arquivo e grava os quadros de áudio sucessivamente gerados depois disso dentro do novo arquivo.

Quando um fluxo de áudio é para um álbum de músicas que in- clui uma trilha longa, a trilha longa é dividida em uma pluralidade de arqui- vos para garantir que o número de pedaços de informação de entrada para um único arquivo não exceda um número predeterminado. A limitação do número de pedaços da informação de entrada em um arquivo suprime o ta- manho da informação de gerenciamento de um arquivo. Esta informação de gerenciamento é utilizada por um aparelho de execução como descrito abai- xo. Quando um aparelho de execução lê um arquivo e começa a executar o objeto de áudio incluído no arquivo, o aparelho de execução também lê a informação de gerenciamento para o arquivo a armazena a mesma em uma memória interna. Esta informação de gerenciamento necessita ser mantida na memória enquanto a execução do objeto de áudio continua. Quando a execução deste objeto de áudio termina, o objeto de áudio seguinte é lido.

Quando a execução começa para este objeto de áudio seguinte, a informa- ção de gerenciamento correspondente é lida e gravada por cima dentro da memória interna do aparelho de execução para tomar o lugar da informação de gerenciamento que estava até agora armazenada.

Portanto, o aparelho de execução executa de forma repetida um processo que carrega somente a informação de gerenciamento para o ob- jeto de áudio correntemente sendo executado em sua memória interna. Isto permite aparelhos de execução com capacidade de memória limitada para executar as funções de execução especiais tal como a pesquisa para frente e para trás. A designação da pluralidade de objetos de áudio para as trilhas de áudio e a ordem a ser utilizada quando executando as trilhas de áudio é determinada pela informação de gerenciamento, de modo que as trilhas po- dem ser livremente editadas por simplesmente se atualizar a informação de gerenciamento.

Breve Descrição dos Desenhos Estes e outros objetivos, vantagens e aspectos da invenção irão se tornar aparentes a partir da descrição seguinte dos mesmos feita em conjunto com os desenhos acompanhantes que ilustram uma concretização específica da invenção. Nos desenhos: A Figura 1 apresenta a aparência de um cartão de memória fiash 31 quando visto de cima; A Figura 2 apresenta a construção do cartão de memória fiash 31 quando visto de baixo; A Figura 3 apresenta a composição hierárquica do cartão de memória fiash 31 nas concretizações; A Figura 4A apresenta a região especial, a região de autentica- ção e a região do usuário proporcionadas na camada física do cartão de memória fiash 31; A Figura 4B apresenta a composição da região de autenticação e da região do usuário na camada de sistema de arquivos; A Figura 5 apresenta a composição detalhada da camada de sistema de arquivos;

A Figura 6 é uma representação de quando o arquivo AOB "AOBOOI.SAI" é dividido em cinco partes que são armazenadas nos clus- ters 003, 004, 005, 00A e 00C; A Figura 7 apresenta um exemplo das configurações das entra- das do diretório e da tabela de alocação de arquivos quando o arquivo AOB "AOB001 .SA111 é gravado em uma pluralidade de clusters;

As Figuras 8A e 8B apresentam que diretórios são proporciona- dos na região do usuário e na região de autenticação na camada de sistema de arquivos quando os dois tipos de dados acima são gravados na camada de aplicação, bem como que tipo de arquivos são gravados em quais diretó- rios; A Figura 9 apresenta a correspondência entre o arquivo "AOBSA1 .KEY" e os arquivos AOB nos diretórios SD-Áudio; A Figura 10 apresenta a composição hierárquica dos dados em um arquivo AOB; A Figura 11A apresenta os parâmetros estipulados pelo padrão ISO/IEC 13818-7 em forma tabular; A Figura 11B apresenta os parâmetros de devem ser utilizados quando codificando um arquivo no formato MPEG-Layer 3 em forma tabular; A Figura 11C apresenta os parâmetros que devem ser utilizados quando codificando-se um arquivo no formato Windows Media Audio (WMA) em forma tabular; A Figura 12 apresenta a construção detalhada de um AOB_FRAME; A Figura 13 apresenta como o comprimento do byte dos dados de áudio em cada um dos três AOB_FRAME é estabelecido; A Figura 14 apresenta a correspondência entre a freqüência de amostragem e o número de AOB_FRAMEs incluídos em um AOB_ELEMENT; A Figura 15 apresenta exemplos de períodos de execução dos AOB_ELEMENT e os períodos de execução dos AOB_FRAME; A Figura 16 apresenta o que é reproduzido quando os AOB e os AOB_BLOCK gravados em um arquivo AOB são consecutivamente execu- tados; A Figura 17 apresenta a composição hierárquica do Gerente de Lista de Execução e do Gerente de Trilha utilizados nas concretizações, em detalhes; A Figura 18 apresenta os tamanhos do Gerente de Lista de Execução e do Gerente de Trilha; A Figura 19 apresenta a correspondência entre as TKIs apre- sentadas na Figura 17 e os AOB e os arquivos AOB apresentado na Figura 16; A Figura 20 apresenta a composição detalhada dos dados da TKTMSRT apresentado na Figura 17; A Figura 21 apresenta um exemplo do TKTMSRT; A Figura 22 apresenta a composição detalhada da TKGI;

As Figuras 23A e 23B apresentam a composição detalhada do BIT e a Figura 23C apresenta o campo Time_Length; A Figura 24 apresenta o cluster 007 até 00E dentro dos quais o AOB composto do AOB_ELEMENT N- 1 até o AOB_ELEMENT N9 4 está armazenado; A Figura 25 apresenta como o próximo AOB_FRAME NQ x+1 a ser executado é estabelecido quando a pesquisa para frente é executada começando a partir do AOB_FRAME N9 x em um AOB_ELEMENT N9 y arbi- trário em um AOB;

As Figuras 26A e 26B apresentam como um AOB, um AOB_ELEMENT e um AOB_FRAME que correspondem a um código de tempo de execução arbitrário são especificados;

As Figuras 27A e 27B apresentam a deleção de uma trilha; A Figura 28A apresenta o Gerente de Trilha após a deleção de uma trilha ter sido executada várias vezes; A Figura 28B apresenta como uma nova TKI e arquivo AOB são gravados quando TKI "não-utilizadas" estão presentes no Gerente de Trilha;

As Figuras 29A e 29B apresentam os TKIs sendo estabelecidos quando duas trilhas são combinadas para produzir uma nova trilha; A Figura 30 apresenta um AOB Tipo 1; A Figura 30B apresenta AOBs Tipo 2; A Figura 31A apresenta a combinação de uma pluralidade de trilhas em uma única trilha para uma combinação de um AOB Tipo 1+ Tipo 2+ Tipo 2+ Tipo 1; A Figura 31B apresenta a combinação de uma pluralidade de trilhas em uma única trilha para uma combinação de um AOB Tipo 1+ Tipo 2+ Tipo 2+ Tipo 2+ Tipo 1; A Figura 32 apresenta uma padrão onde um AOB Tipo 1 está presente no fim de uma trilha precedente e um AOB Tipo 1 está presente no começo de uma próxima trilha; A Figura 32B apresenta um padrão onde um AOB Tipo 1 está presente no fim de uma primeira trilha e um AOB Tipo 2 está presente no início de uma próxima trilha; A Figura 32C apresentada um padrão onde um AOB Tipo 1 e um AOB Tipo 2 estão presentes no fim de uma primeira trilha e um AOB

Tipo 1 está presente no início de uma próxima trilha; A Figura 32D apresenta um padrão onde um AOB Tipo 1 e um AOB Tipo 2 estão presentes no fim de uma primeira trilha e um AOB Tipo 2 e um AOB Tipo 1 estão presentes no início de uma próxima trilha; A Figura 32E apresenta um padrão onde dois AOB Tipo 2 estão presentes no fim de uma primeira trilha e um Tipo 1 está presente no início de uma próxima trilha;

As FIGS 33A e 33B apresentam a divisão de uma trilha para produzir duas trilhas;

As Figuras 34a e 34B apresentam o conteúdo das entradas do diretórios SD-Áudio no diretório SD-Áudio incluindo o arquivo AOB "AOB003.SA1" antes e depois da divisão da trilha; A Figura 35A apresenta a divisão de uma AOB a meio do cami- nho através do AOB_ELEMENT N9 2; A Figura 35B apresenta dois AOB, AOB N9 1 e AOB N9 2, obti- dos por se dividir um AOB a meio do caminho através do AOB_ELEMENT N9 2; A Figura 36 apresenta como o BIT é estabelecido quando um AOB é dividido como apresentado na Figura 35; A Figura 37 apresenta um exemplo específico das alterações no BIT antes e depois da divisão; A Figura 38 apresenta um exemplo específico das alterações no TKTMSRT antes e depois da divisão; A Figura 39A apresenta o formato de um DPL_TK_SRP; A Figura 39B apresenta o formato de um PL_TK_SRP; A Figura 40 apresenta a inter-relação entre a Informação Pre- estabelecida da Lista de Execução, as TKIs e os arquivos AOB; A Figura 41 apresenta configurações exemplo para a Lista Pre- estabelecida e de várias PLIs; A Figura 42 apresenta como os DPL_TK_SRPs correspondem com as TKI utilizando a mesma notação que a da Figura 40;

As Figuras 43A e 43B apresentam como a ordem das trilhas é redisposta;

As Figuras 44A e 44B apresentam como a Lista de Execução Preestabelecida, o Gerente de Trilha e os arquivos AOB irão ser atualizados quando DPL_TK Ns2e TKI N9 2 são deletados da Lista de Execução Pre- estabelecida apresentada na Figura 40;

As FIGS 45A e 45B apresentam como uma nova TKI e DPL_TK_SRP são gravados quando uma TKI e DPL_TK "Não-Utilizado" estão presentes;

As Figuras 46A e 46B apresentam como as trilhas são combina- das;

As FIGS 47A e 47B apresentam como uma trilha é dividida; A Figura 48 apresenta a aparência de um aparelho de execução portátil para o cartão de memória flash 31 das presentes concretizações;

A Figura 49 apresenta um exemplo da exibição no painel LCD quando uma lista de execução é selecionada;

As Figuras 50A até 50E apresentam exemplos da exibição no painel LCD quando uma trilha é selecionada;

As Figuras 51A até 51C apresentam operações exemplo da sintonização abrupta. A Figura 52 apresenta a construção interna do aparelho de re- produção; A Figura 53 apresenta como os dados são transferidos para dentro e para fora do buffer duplo 15;

As Figuras 54A e 54B apresentam como as áreas no buffer du- plo 15 são ciclicamente alocadas utilizando os ponteiros em anel; A Figura 55 é um fluxograma apresentando o procedimento de leitura do arquivo AOB; A Figura 56 é um fluxograma apresentando o procedimento de saída do arquivo AOB; A Figura 57 é um fluxograma apresentando o procedimento de saída do arquivo AOB; A Figura 58 é um fluxograma apresentando o procedimento de saída do arquivo AOB;

As Figuras 59A até 59D apresentam como o código de tempo de execução exibido no quadro de código de tempo de execução no painel LCD 5 é atualizado de acordo com a atualização da variável Play_time; A Figura 60 é um fluxograma apresentando o processamento da CPU 10 quando a função de pesquisa para frente é utilizada;

As Figuras 61A até 61D apresentam como o código de tempo de execução é incrementado quando a função de pesquisa para frente é utili- zada;

As FIGS 62A e 62B apresentam exemplos específicos de como a função de pesquisa de tempo é utilizada; A Figura 63 é um fluxograma apresentando o processamento no programa de controle de edição; A Figura 64 é um fluxograma apresentando o processamento no programa de controle de edição; A Figura 65 é um fluxograma apresentando o processamento no programa de controle de edição; A Figura 66 apresenta um exemplo de um aparelho de gravação para gravar dados em um cartão de memória flash 31; A Figura 67 apresenta a configuração de hardware do aparelho de gravação; A Figura 68 é um fluxograma apresentando o processamento durante a gravação; A Figura 69 apresenta a construção do hardware do cartão de memória flash 31; A Figura 70 apresenta a seqüência de comunicação utilizada quando um aparelho de execução conectado com o cartão de memória flash 31 lê a chave de criptografia FileKey e executa os AOBs; e A Figura 71 apresenta os detalhes da seqüência de comunica- ção utilizada quando a autenticação mútua é executada na Figura 70.

Melhor Modo de Realizar a Invenção O dito a seguir descreve um cartão de memória semicondutora (cartão de memória flash) que é uma concretização da presente invenção, com referência às figuras anexas.

Os parágrafos seguintes estão dispostos em uma hierarquia uti- lizando números de referência com a notação dada abaixo. [x1 -x2_x3-x4] O comprimento de um número de referência apresenta o nível do tópico na hierarquia. Como um exemplo específico, o número x1 é o nú- mero do desenho que está sendo referido na explicação. Os desenhos liga- dos com esta especificação foram numerados na ordem na qual eles são referidos na especificação, de modo que a ordem do desenhos grosseira- mente combina com a ordem da explicação. A explicação de certos dese- nhos foi dividida em seções, com o número de referência x2 dando o núme- ro de uma seção na explicação de um desenho indicado pelo número de referência x1. O número de referência x3 apresenta o número de um dese- nho adicional que é proporcionado para apresentar os detalhes das seções indicadas pelo número de seção x2. Finalmente, o número de referência x4 apresenta o número de uma seção na explicação deste desenho adicional.

PRIMEIRA CONCRETIZAÇÃO {1-1_2} Aparência Externa do Cartão de Memória Flash 31 A presente explicação começa com a aparência do cartão de memória flash 31. A Figura 1 apresenta a aparência do cartão de memória flash 31 quando visto de cima, enquanto a Figura 2 apresenta a construção do cartão de memória flash 31 quando visto de baixo. Como apresentado nas Figuras 1 e 2, o cartão de memória flash 31 é ao redor do mesmo tama- nho de um selo de postagem e desse modo é grande o suficiente para ser mantido na mão. Suas dimensões aproximadas são 32,0 mm de compri- mento, 24,0 mm de largura e 2,0 mm de espessura. O cartão de memória flash 31 pode ser visto como possuindo nove conectores em sua beira superior para conectar o cartão com um dis- positivo compatível e uma chave de proteção 32 em um lado para permitir ao usuário estabelecer se a gravação por cima do conteúdo armazenado do cartão de memória flash 31 é permitida ou proibida. {3-1} Construção Física do Cartão de Memória Flash 31 A Figura 3 apresenta a estrutura hierárquica do cartão de me- mória semicondutora (daqui para frente referido como "cartão de memória flash 31") da presente concretização. Como apresentado na Figura 3, o cartão de memória flash 31 é construído com uma camada física, uma cada de sistema de arquivos e uma camada de aplicação do mesmo modo que um DVD (Disco de Vídeo Digital), no entanto as construções lógica e física destas camadas são muito diferente daquelas em um DVD. {3-2} Camada Física do Cartão de Memória Flash 31 O dito a seguir descreve a camada física do cartão de memória flash 31. A memória flash é composta de uma pluralidade de setores, cada um dos quais armazena 512 bytes de dados digitais. Como um exemplo, um cartão de memória flash de 64 MB 31 irá possuir uma capacidade de arma- zenamento de 67.108.864 (=64*1, 024*1, 024) bytes, de modo que este cartão irá incluir 131.372 (=67108864/512) setores válidos. Uma vez que o número de setores de substituição, que são proporcionados para uso no caso de erros, é subtraído, o número restante de setores válidos dentro dos quais vários tipos de dados podem ser gravados é cerca de 128.000. {3-2+4A-1} Três Regiões na Camada Física As três regiões apresentadas na Figura 4A são proporcionadas na área de armazenamento composta destes setores válidos. Estas regiões são a "região especial", a "região de autenticação" e a "região do usuário" e são descritas em detalhes abaixo. A região do usuário é caracterizada pelo fato de que um dispositivo junto ao qual o cartão de memória flash está co- nectado pode livremente ler ou gravar vários tipos de dados a partir ou den- tro desta região. As áreas dentro da região do usuário são gerenciadas por um sistema de arquivos. A região especial armazena um ID do meio que é um valor uni- camente designado para cada cartão de memória flash 31. Ao contrário da região do usuário, esta região é somente para leitura, de modo que o ID do meio armazenado na região especial não pode ser alterado. A região de autenticação é uma região que pode ser gravada, como a região do usuário. Esta região difere da região do usuário pelo fato de que um dispositivo conectado com o cartão de memória flash 31 pode acessar (isto é, ler ou gravar dados) na região de autenticação somente se o cartão de memória flash 31 e o dispositivo tiverem primeiro confirmado que cada um é um dispositivo autêntico. Em outras palavras, os dados so- mente podem ser lidos ou gravados na região de autenticação se a autenti- cação mútua tiver sido executada com sucesso pelo cartão de memória flash 31 e pelo dispositivo conectado com o cartão de memória flash 31. {3-2_4A-2} Usos das Três Regiões nas Camada Física Quando o dispositivo conectado com o cartão de memória flash 31 grava dados no cartão de memória flash 31, a região utilizada para ar- mazenar estes dados irá depender de se a proteção de direito autoral é ne- cessária para os dados sendo gravados. Quando os dados que requerem proteção de direito autoral são gravados no cartão de memória flash 31, os dados são criptografados utilizando uma chave de criptografia predetermi- nada (chamada de ''FileKey") antes de serem gravados dentro da área do usuário. Esta FileKey pode ser livremente estabelecida pelo possuidor do direito autoral e ao mesmo tempo que o uso desta FileKey proporciona al- gum nível de proteção de direito autoral, a FileKey utilizada para criptogra- far os dados gravados é ela própria criptografada para tornar a proteção de direito autoral mais segura. Qualquer valor obtido por sujeitar o ID do meio armazenado na região especial dentro de um cálculo predeterminado pode ser utilizado para criptografar a FileKey. A FileKey criptografada produzida deste modo é armazenada na região de autenticação.

Desde que os dados que requerem proteção de direito autoral estão sujeitos a um processo de criptografia de duas etapas onde os dados são criptografados utilizando uma FileKey que é ela própria criptografada baseado no ID do meio, a transgressão do direito autoral, tal como a produ- ção de cópias não-autorizadas destes dados, será extremamente difícil. {3-2_4B-1} Vista Geral do Sistema de Arquivos Como pode ser entendido, a construção da camada física do cartão de memória flash 31 fortalece a proteção de direitos autorais dos da- dos gravados no cartão de memória flash 31. O dito a seguir descreve a camada de sistema de arquivos presente nesta camada física. Enquanto que a camada de sistema de arquivos do DVD utiliza um sistema de arqui- vos do tipo UDF (Formato Universal de Disco), a camada de sistema de ar- quivos do cartão de memória flash 31 utiliza um sistema de arquivos tipo FAT (Tabela de Alocação de Arquivo), como descrito na ISO/IEC 9293. A Figura 4 apresenta a construção da região de autenticação e da região do usuário na camada de sistema de arquivos. Como apresentado na Figura 4B, a região de autenticação e a região do usuário no sistema de arquivos, cada uma inclui "setores de partida de partição", uma "tabela de alocação de arquivo (FAT)", um "diretório raiz" e uma "região de dados", significando que a região de autenticação e a região do usuário possuem a mesma construção. A Figura 5 apresenta as várias partes destes sistemas de arquivos em mais detalhes. O dito a seguir descreve a construção da região do usuário com referência às FIGs. 4A, 4B e 5. {3-2_4B-2} Setores de Partida de Partição Os setores de partida de partição são setores que armazenam os dados que serão referidos por um computador pessoal padrão que está conectado com o cartão de memória flash 31 quando o cartão de memória flash 31 é estabelecido como o disco de partida para o sistema operacional (OS) do computador pessoal. {3-2_4B-3_5} Região de Dados A região de dados pode ser acessada por um dispositivo co- nectado com o cartão de memória flash 31 em unidades não menores do que um "cluster". Enquanto cada setor no cartão de memória flash 31 tem o tamanho de 512 bytes, o tamanho do cluster é 16 KB, de modo que a cama- da de sistema de arquivos lê e grava dados em unidades de 32 setores. A razão pela qual o tamanho do cluster é estabelecido em 16 KB é que quando os dados são gravados no cartão de memória flash 31, parte dos dados armazenados no cartão de memória flash 31 primeiro tem que ser apagada antes que a gravação possa ser executada. A menor quantidade de dados que pode ser apagada no cartão de memória flash 31 é 16 KB, de modo que estabelecendo o menor tamanho que pode ser apagado como o tamanho do cluster significa que as grava- ções de dados podem ser de forma favorável executadas. A seta ff2 dese- nhada utilizando uma linha partida na Figura 5 apresenta a pluralidade de clusters 002, 003, 004, 005, ... incluídos na região de dados. Os números 002, 003, 004, 005, 006, 007, 008, ... utilizados na Figura 5 são os números em hexadecimal de três dígitos do cluster que são exclusivamente designa- dos para identificar cada cluster. Desde que a menor unidade pela qual o acesso pode ser executado é um cluster, as posições de armazenamento dentro da região de dados são indicadas utilizando os números dos clusters. {3-2_4b-4_5} Sistema de Alocação de Arquivos O sistema de alocação de arquivos possui uma construção do sistema de arquivos de acordo com o padrão ISO/IEC 9293 e desse modo é construído de uma pluralidade de valores FAT. Cada valor FAT corresponde a um cluster e apresenta que cluster deve ser lido após o cluster correspon- dendo ao valor FAT. A seta ff1 apresentada pela linha partida na Figura 5 apresenta a pluralidade de valores FAT 002, 003, 004, 005, ... que estão incluídos na tabela de alocação de arquivos. Os números 002, 003, 004, 005, ... designados para cada valor FAT apresentam que clusters corres- pondem a cada valor FAT e portanto são números de clusters dos clusters correspondendo aos valores FAT. {3-2_4B-5_5-1} Entradas do Diretórios Raiz As "entradas do diretório raiz" são informações apresentando que tipos de arquivos estão presentes no diretório raiz. Como exemplos es- pecíficos, o "nome de arquivo" de um arquivo existente, sua "extensão do nome do arquivo", a "hora/data de revisão" e o "número do primeiro cluster no arquivo" apresentando onde o início do arquivo está armazenado podem ser gravado como a entrada do diretório raiz de um arquivo. {3-2_4B-5_5-2} Entradas do Diretório para os Subdiretórios A informação relacionando-se com os arquivos no diretório raiz é gravada como entradas do diretórios raiz, no entanto, a informação relaci- onando-se com os subdiretórios não é gravada como as entradas do diretó- rio raiz. As entradas do diretório para os subdiretórios são ao invés disso produzidas na região de dados. Na Figura 5, a entrada do diretório SD- Áudio dada na região de dados é um exemplo de uma entrada de diretório para um subdiretório. Como uma entrada do diretório raiz, uma entrada do diretório SD-Áudio inclui o "nome do arquivo" de um arquivo presente neste subdiretório, "sua extensão do nome do arquivo", a "hora/data de revisão" e o "número do primeiro cluster no arquivo" apresentando onde o início do arquivo está armazenado.

{3-2_4B-5_6-1} Formato de Armazenamento para os Arquivos AOB O dito a seguir descreve o método de armazenamento de arqui- vo por apresentar como um arquivo nomeado "AOB001.SA1" é armazenado no diretório SD-Áudio, com referência à Figura 6. Desde que a menor uni- dade pela qual a região de dados pode ser acessada é um cluster, o arquivo "AOB001.SA1" necessita ser armazenado na região de dados em partes que não sejam menores do que um cluster. O arquivo "AOB001.SA1" por- tanto é armazenado tendo primeiro sido dividido em clusters. Na Figura 6, o arquivo "AOB001.SA1" é dividido em cinco partes para acompanhar o tama- nho do cluster e as partes resultantes são armazenadas em clusters nume- rados 003, 004, 005, 00A e 00C.

{3-2_4B-5_7-1} Formato de Armazenamento para os Arquivos AOB

Quando o arquivo "AOB001.SA1" é dividido em partes e arma- zenado, uma entrada do diretório e a tabela de alocação de arquivos neces- sitam ser estabelecidos como apresentado na Figura 7. A Figura 7 apre- senta um exemplo de como a entrada do diretório e a tabela de alocação de arquivos necessitam ser estabelecidos quando o arquivo AOB001.SA1" é armazenado tendo sido dividido em parte e armazenado. Na Figura 7, o iní- cio do arquivo "AOB001.SA1" é armazenado no cluster 003, de modo que o número de cluster 003 é gravado dentro do "número do primeiro cluster no arquivo" na entrada do diretório SD-Áudio para indicar o cluster armazenan- do a primeira parte do arquivo. Como apresentado na Figura 7, as partes seguintes do arquivo "AOB001.SA1" são armazenadas nos clusters 004 e 005. Como resultado, enquanto o valor FAT 003 (004) corresponde ao cluster 003 que armazena a primeira parte do arquivo "AOB001.SA1", este valor indicar o cluster 004 como o cluster armazenando a próxima parte do arquivo 'AOB001.SA1". Do mesmo modo, enquanto os valores FAT (004(005) e 005(00A) respectivamente correspondem aos clusters 004 e 005 que armazenam as próximas partes do arquivo "AOB001 .SA1", estes valores respectivamente indicam o cluster 005 e o cluster 00A como os clusters armazenando as próximas partes do arquivo "AOB001.SA1". Por ler os cluster com os números de cluster gravados dentro destes valores FAT em ordem como apresentando pelas setas fk1, fk2, fk3, fk4, fk5, ... na Figura 7, todas as partes produzidas por se dividir o arquivo "AOB001.SA1" podem ser lidas. Como explicado acima, a região de dados do cartão de memória flash 31 é acessada em unidades de clusters, cada um dos quais está asso- ciado com um valor FAT. Observe que o valor FAT que corresponde ao cluster armazenando a parte final de um arquivo AOB (o cluster 00C no exemplo apresentado na Figura 7) é estabelecido para o número de cluster FFF para apresentar que o cluster correspondente armazena a parte final de um arquivo.

Isto completa a explicação do sistema de arquivos no cartão de memória flash 31 da presente invenção. O dito a seguir descreve a camada de aplicação que existe neste sistema de arquivos. {3-3} Vista Geral da Camada de Aplicação no Cartão de Memória Flash 31 Uma vista geral da camada de aplicação no cartão de memória flash 31 é apresentada na Figura 3. Como apresentado pela seta PN2 de- senhada com uma linha partida na Figura 3, a camada de aplicação no car- tão de memória flash 31 é composta dos dados de apresentação e dos da- dos de navegação que são utilizados para controlar a execução dos dados de apresentação. Como apresentado pela seta PN2, os dados de apresen- tação incluem conjuntos de objetos de áudio (conjuntos AOB) que são pro- duzidos por se codificar os dados de áudio que representam, por exemplo, música. Os dados de navegação incluem um "Gerente de Lista de Execu- ção" (PLMG) e um "Gerente de Trilha" (TKMG). {3-3_8A, B-1} Composição do Diretório As Figuras 8A e 8B apresentam que tipo de diretórios são apre- sentados na região do usuário e na região de autenticação na camada de sistema de arquivos quando estes dois tipos de dados estão armazenados na camada de aplicação, bem como apresentando que arquivos estão dis- postos dentro destes diretórios.

Os nomes de arquivo "SD_ÁUDIO.PLM" e "SD_ÁUDIO.TKM" na Figura 8A indicam os arquivos nos quais o Gerente de Lista de Execução (PLMG) e o Gerente de Trilha (TKMG) compondo a informação de navega- ção estão armazenados. Enquanto isto, os nomes de arquivo "AOBOOI.SAI", "AOB002.SA1", "AOB003.SA1", "AOB004.SA1", ... indicam os arquivos (arquivos "AOB") armazenando os objetos de áudio que são os dados de apresentação. As letras "SA" na extensão do nome do arquivo do nome de arquivo "AOBxx.SAI" são uma abreviação para "Áudio Seguro" e apresentam que o conteúdo armazenado deste arquivo requer proteção de direito autoral. Observe que enquanto somente oito arquivos AOB são apre- sentados no exemplo na Figura 8A, um máximo de 999 arquivos AOB po- dem ser armazenados em um diretório SD-Áudio.

Quando a proteção de direitos autorais é requerida para os da- dos de apresentação, um subdiretório chamado de um "diretório SD-Áudio" é proporcionado na região de autenticação e um arquivo de armazenamento da chave de criptografia "AOBSA1.KEY" é produzido neste diretório SD- Áudio. A Figura 8B apresenta o arquivo de armazenamento da chave de criptografia ''AOBSA1 .KEY" que é armazenado sob a legenda "SD-Áudio" (isto é, dentro do diretório SD-Áudio"). Este arquivo de armazenamento da chave de criptografia "AOBSA.KEY" armazena uma seqüência de chaves de criptografia que é produzida por se dispor uma pluralidade de chaves de criptografia dentro de uma ordem predeterminada. O diretório SD-Áudio apresentado nas FIGs 8A e 8B é armaze- nado em um computador servidor gerenciado por uma gravadora que utiliza a distribuição eletrônica de musica. Quando um consumidor encomenda um conteúdo de música, o diretório SD-Áudio correspondente é compactado, criptografado e transmitido para o consumidor via uma rede pública. O com- putador do consumidor recebe este diretório SD-Áudio, decriptografa o mesmo, descompacta o mesmo e desse modo obtém o diretório SD-Áudio original. Observe que a expressão "rede pública" aqui refere-se a qualquer tipo de rede que possa ser utilizada pelo público, tal como uma rede de co- municação com fios, por exemplo uma rede ISDN, ou uma rede de comuni- cações sem fios, como por exemplo, um sistema de telefone móvel. Também é possível para um computador do consumidor transferir um arquivo AOB a partir de um computador servidor operado por uma gravadora e então pro- duzir o diretório SD-Áudio, tal como apresentado nas FIGs. 8A e 8B, no cartão de memória flash 31. {3-3_9-1} Correspondência entre o arquivo "AOBSA1.KEY" e os arqui- vos AOB A Figura 9 apresenta a correspondência entre o arquivo 'AOBSA1.KEY" no diretório SD-Áudio e os arquivos AOB. As FileKey utiliza- das quando criptografando-se os arquivos na região do usuário apresentada na Figura 9 são armazenados no arquivo de armazenamento de chave de criptografia correspondente na região de autenticação.

Os arquivos AOB criptografados e o arquivo de armazenamento da chave de criptografia correspondem de acordo com as regras predeter- minadas (1), (2) e (3) descritas abaixo. (1) O arquivo de armazenamento da chave de criptografia está disposto dentro de um diretório com o mesmo nome de diretório que o dire- tório no qual o arquivo criptografado é armazenado. Na Figura 9, os arqui- vos AOB estão dispostos dentro do diretório SD-Áudio na região do usuário e o arquivo de armazenamento da chave de criptografia está disposto den- tro de um diretório chamado diretório SD-Áudio na região de autenticação, de acordo com esta regra. (2) Ao arquivo de armazenamento da chave de criptografia é dado um nome de arquivo produzido por se combinar as primeiras três le- tras do nome do arquivo dos arquivos AOB na região de dados com a ex- tensão ".key" predeterminada. Quando o nome do arquivo de um arquivo AOB é "AOB001 .SA1", ao arquivo de armazenamento da chave de cripto- grafia é dado o nome de arquivo "AOBSA1 .KEY" produzido por se adicionar os primeiros três primeiros caracteres "AOB", "SA1" e a extensão ".key", como apresentado pelas setas nk1 e nk2 na Figura 9. (3) Ao nome de arquivo de um arquivo AOB é dado um número de série apresentando a posição da FileKey correspondendo a este objeto de áudio na seqüência de chaves de criptografia dadas no arquivo de arma- zenamento de chave de criptografia.

As "Entradas de Chave de Arquivo N9 1, N9 2, N9 3, ..., N9 8" apresentam as primeiras posições das regiões nas quais as respectivas Fi- leKey no arquivo de armazenamento de chave de criptografia estão arma- zenadas. Enquanto isto, os nomes de arquivo dos arquivos AOB são desi- gnados com os números de série "001", "002", "003", "004".Estes núme- ros de série apresentam as posições das FileKeys correspondentes na se- qüência de chave de criptografia, de modo que a FileKey que foi utilizada para criptografar cada arquivo AOB será apresentada na "Entrada FileKey" com o mesmo número de série. Na Figura 9, as setas Ak1, Ak2, Ak3, ... apresentam a correspondência entre os arquivos AOB e as FileKey. Em ou- tras palavras, o arquivo "AOB001.SA1" corresponde à FileKey cuja posição de armazenamento é indicada pela "Entrada de FileKey N9 1", o arquivo "AOB002.SA1" corresponde à FileKey cuja posição de armazenamento é indicada pela "Entrada de FileKey N9 2" e o arquivo "AOB003.SA1" corres- ponde à FileKey cuja posição de armazenamento é indicada pela "Entrada de FileKey NQ 3". Como pode ser entendido a partir da regra (3), FileKeys diferentes são utilizadas para criptografar arquivos AOB diferentes, com estas FileKey sendo armazenadas nas "Entradas de FileKey" com os núme- ros de série "001", "002", "003", "004", etc., dados nos nomes de arquivo dos arquivos AOB correspondentes.

Desde que cada arquivo AOB é criptografado utilizando uma FileKey diferente, a exposição da chave de criptografia utilizada para um arquivo AOB não irá permitir aos usuários decriptografar outros arquivos AOB. Isto significa que quando os arquivos AOB são armazenados em uma forma criptografada em um cartão de memória flash 31, o prejuízo causado pela exposição de uma FileKey pode ser minimizado.

{3-3_10-1} Composição Interna de um Arquivo AOB O dito a seguir descreve a composição interna de um arquivo AOB. A Figura 10 apresenta a estrutura de dados hierárquica de um arquivo AOB. O primeiro nível na Figura 10 apresenta o arquivo AOB, enquanto o segundo nível apresenta o próprio objeto de áudio (AOB). O terceiro nível apresenta os AOB_BLOCK, o quarto nível apresenta um AOB_ELEMENT e o quinto nível um AOB_FRAME. O AOB_FRAME no quinto nível na Figura 10 é a menor unidade compondo o AOB e é composto de dados de áudio em formato ADTS (Fluxo de Transporte de Dados de Áudio) e de um cabeçalho ADTS. Os dados de áudio no formato ADTS são criptografados de acordo com um formato MPEG2-AAC (Perfil de Baixa Complexidade) e são dados em fluxo que po- dem ser executados em uma taxa de transferência de 16 Kbps até 144 Kbps. Observe que a taxa de transferência para PCM (Modulação por Códi- go de Pulso) que é grafada em um disco compacto convencional é 1,5 Mbps, de modo que os dados no formato ADTS geralmente utilizam uma taxa de transferência inferior do que o PCM. A construção dos dados de uma seqüência de AOB_FRAME é a mesma que a seqüência de quadros de áudio incluída em um fluxo de transporte de dados distribuído por um servi- ço de distribuição eletrônica de música. Isto significa que o fluxo de trans- porte de dados de áudio a ser armazenado como a seqüência AOB_FRAME é codificado de acordo com o padrão MPEG2-AAC, criptografado e transmi- tido em uma rede pública para o consumidor. Os arquivos AOB são produzi- dos por se dividir o fluxo de transporte de dados de áudio transmitido em uma seqüência de AOB_FRAME e por se armazenar estes AOB_FRAME.

{3-3_10-1_11} MPEG2-AAC O MPEG2-AAC é descrito em detalhes na ISO/IEC 13818- 17:1997 "Information Technology - Generic Coding of Moving Pictures and Associated Áudio Information - Part 7 Advanced Áudio Coding (AAC).

Deve ser observado que os objetos de áudio somente podem ser compactados de acordo com o MPEG2-AAC utilizando os parâmetros na tabela de parâmetros apresentada na Figura 11A que é definida na ISO/IEC 13818-7. Esta tabela de parâmetros é composta da coluna "Parâmetro", de uma coluna "Valor" e de uma coluna "Comentário". A legenda "perfil" na coluna Parâmetro apresenta o único perfil LC que pode ser utilizado, como estipulado pela ISO/IEC 13838-7. A legen- da "sampling_frequency N9 index" na coluna Parâmetro apresenta que as freqüências de amostragem de "48 kHz, 44,1 kHz, 32 kHz, 24 kHz, 22,05 kHz e 16 kHz" podem ser utilizadas. A legenda "number_of_data_block_in_frame" na coluna Parâ- metro apresenta que a relação de um cabeçalho com outro raw_data_block é utilizada.

Observe que enquanto esta explicação descreve o caso onde os AOB_FRAMEs são codificados de acordo com o formato MPEG2-AAC, os AOB_FRAMEs podem ao invés disso serem codificados de acordo com ou- tro formato, tal como o formato MPEG-Layer3 (MP3) ou o Windows Media Audio (WMA). Quando fazendo desse modo, os parâmetros apresentados nas tabelas de parâmetros da Figura, 11B ou da Figura 11C devem ser utili- zados.

{3-3_10-2_12} Composição de um AOB_FRAME

Enquanto cada AOB_FRAME inclui dados de áudio que são co- dificados de acordo com as restrições descritas acima, o comprimento dos dados dos dados de áudio em cada AOB_FRAME é restrito a um tempo de execução de somente 20 ms. Entretanto, desde que o MPEG2-AAC é um método de codificação de taxa de bits variável (VBR), o comprimento dos dados dos dados de áudio em cada AOB_FRAME irá variar. O dito a seguir descreve a composição de um AOB_FRAME, com referência à Figura 12. O primeiro nível na Figura 12 apresenta a composição total, en- quanto o segundo nível apresenta como cada parte de um AOB_FRAME é criptografada. Como pode ser visto a partir do desenho, o cabeçalho ADTS corresponde a uma parte não criptografada. Os dados de áudio incluem tanto uma parte criptografada como uma parte não criptografada. A parte criptografada dos dados de áudio é composta de uma pluralidade de peda- ços de oito bytes de dados criptografados, cada um dos quais é produzido por se criptografar um pedaço de oito bytes de dados de áudio utilizando uma FileKey de 56 bits. Quando a criptografia é executada em pedaços de 64 bits de dados de áudio, a parte não criptografada dos dados de áudio é simplesmente uma parte final dos dados que não pode ser criptografada devido a mesma ser menor do que 64 bits. O terceiro nível na Figura 12 apresenta o conteúdo do cabeça- lho ADTS que está na parte não criptografada do AOB_FRAME. O cabeça- lho ADTS tem o comprimento de sete bits e inclui uma palavra síncrona de 12 bits (estabelecida em FFF), o comprimento dos dados dos dados de áu- dio neste AOB_FRAME e a freqüência de amostragem utilizada quando os dados de áudio foram codificados. {3-3_10-3_12} Estabelecendo o Comprimento do Byte de um AOB_FRAME A Figura 13 apresenta como o comprimento do byte dos dados de áudio em cada um de três AOB_FRAMEs é estabelecido. Na Figura 13, o comprimento dos dados dos dados de áudio N91 incluídos no AOB_FRAME N91 é x1, o comprimento dos dados dos dados de áudio N9 1 incluídos no AOB_FRAME N9 2 é x2 e o comprimento dos dados dos dados de áudio N9 1 incluídos no AOB_FRAME N9 3 é x3. Quando os comprimentos dos dados x1, x2 e x3 são todos diferentes, o comprimento dos dados x1 será gravado no cabeçalho ADTS do AOB_FRAME N9 1, o comprimento dos dados x2 será gravado no cabeçalho ADTS do AOB_FRAME N9 2 e o comprimento dos dados x3 será gravado no cabeçalho ADTS do AOB_FRAME N9 3.

Apesar dos dados de áudio serem criptografados, o cabeçalho ADTS não é, de modo que o dispositivo de execução pode saber o compri- mento dos dados dos dados de áudio em um AOB_FRAME por ler o com- primento dos dados dado no cabeçalho ADTS do AOB_FRAME.

Isto completa a explicação de um AOB_FRAME.

{3-3_10-4} AOB_ELEMENT O dito a seguir descreve o AOB_ELEMENT apresentado no quarto nível na Figura 10.

Um "AOB_ELEMENT" é um grupo de AOB_FRAMEs consecuti- vos. O número de AOB_FRAMEs em um AOB_ELEMENT depende do valor estabelecido como sampling_frequency_index apresentado na Figura 11A e do método de codificação utilizado. O número de AOB_FRAMEs em um AOB_ELEMENT é estabelecido de modo que o tempo total de execução dos AOB_FRAME incluídos será ao redor de dois segundos, com este número dependendo da freqüência de amostragem e do método de codificação utili- zados.

{3-3_10-5_14} Número de AOB_FRAME em um AOB_ELEMENT A Figura 14 apresenta a correspondência entre a freqüência de amostragem e o número de AOB_FRAMEs incluídos em um AOB_ELEMENT. O número N dado na Figura 14 representa o período de execução de um AOB_ELEMENT em segundos. Quando o MPEG-AAC é utilizado como o método de codificação, o valor de N é "2".b Quando a freqüência de amostragem é 48 kHz, o número de AOB_FRAMEs incluídos em um AOB_ELEMENT é dado como 94 (=47*2), enquanto quando a freqüência de amostragem é 44,1 kHz, o número de AOB_FRAMEs incluídos em um AOB_ELEMENT é dado como 86 (43*2).

Quando a freqüência de amostragem é 32 kHz, o número de AOB_FRAMEs é dado como 64 (=32*2), quando a freqüência de amostragem é 24 kHz, o número de AOB_FRAMEs é dado como 48 (=24*2), quando a freqüência de amostragem é 22,05 kHz, o número de AOB_FRAMEs é dado como 44 (=22*2) e quando a freqüência de amostragem é 16 kHz, o número de AOB_FRAMEs incluídos em um AOB_ELEMENT é dado como 32 (=16*2).

Entretanto, quando uma operação de edição, tal como a divisão de um AOB, foi executada, o número de AOB_FRAMEs incluídos em um AOB_ELEMENT no início ou no fim de um AOB pode ser menor do que um número calculado deste modo.

Enquanto nenhum cabeçalho ou outra informação especial é proporcionada para cada AOB_ELEMENT, o comprimento dos dados de cada AOB_ELEMENT ao invés disso é apresentado por uma tabela de pes- quisa de tempo. {3-3_10-6_15} Um exemplo dos Períodos de Execução dos AOB_ELEMENTs e dos AOB_FRAMEs A Figura 15 apresenta um exemplo dos períodos de execução dos AOB_ELEMENTs e dos AOB_FRAMEs. O primeiro nível na Figura 15 apresenta uma pluralidade de AOB_BLOCKs, enquanto o segundo nível apresenta uma pluralidade de AOB_ELEMENTs. O terceiro nível apresenta uma pluralidade de AOB_FRAMEs.

Como apresentado na Figura 15, um AOB_ELEMENT possui um período de execução de cerca de 2,0 segundos, enquanto um AOB_FRAME possui um período de execução de 20 milissegundos. A "TMSRT_entry" dada para cada AOB_ELEMENT apresenta que o comprimento dos dados de cada AOB_ELEMENT é dado na tabela de pesquisa de tempo. Por se referir às TMSRT_entry, um aparelho de execução pode executar uma pes- quisa para frente ou para trás onde, por exemplo, rajadas intermitentes de música são executadas por repetidamente executar 240 milissegundos de dados de áudio e então saltar dois segundos de dados de áudio na direção desejada.

(3-3_10-7) AOB_BLOCK

Isto completa a explicação de um AOB_ELEMENT. O dito a se- guir descreve o conceito dos AOB_BLOCK apresentados no terceiro nível da construção dos dados de um arquivo AOB dada na Figura 10.

Cada "AOB_BLOCK" é composto de AOB_ELEMENTs válidos.

Somente existe um AOB_BLOCK em cada AOB_FILE. Enquanto um AOB_ELEMENT possui um período de execução ao redor de dois segun- dos, um AOB_BLOCK possui um período de execução máximo de 8,4 mi- nutos. A limitação de 8,4 minutos é imposta para restringir o tamanho da tabela de pesquisa de tempo para 504 bytes ou menos. {3-3_10-8} Restrição da Tabela de Pesquisa de Tempo O dito a seguir descreve em detalhes porque o tamanho da ta- bela de pesquisa de tempo é restrito por se limitar o período de execução.

Quando um aparelho de execução executa uma pesquisa para frente ou para trás, o aparelho de execução salta a leitura de dois segundos dos dados de áudio antes de executar 240 milissegundos. Quando saltando os dois segundos de dados, o aparelho de execução poderia na teoria refe- rir-se aos comprimentos dos dados apresentados nos cabeçalhos ADTS dos AOB_FRAMEs, no entanto isto significaria que o aparelho de execução teria que consecutivamente detectar 100 (2 segundos/20 milissegundos) AOB_FRAMEs apenas para saltar dois segundo de dados de áudio. Isto acarretaria em carga de processamento excessiva para o aparelho de exe- cução.

Para reduzir a carga de processamento de um aparelho de exe- cução, os endereços de leitura dos dados nos intervalos de dois segundos podem ser gravados dentro de uma tabela de pesquisa de tempo que é en- tão referida pelo aparelho de execução quando executando uma pesquisa para frente ou para trás. Por gravar a informação que permite que os ende- reços de leitura que são dois ou quatro segundos à frente ou atrás sejam encontrados rapidamente dentro da tabela de pesquisa de tempo (tal infor- mação sendo os tamanho dos dados dos AOB_ELEMENTs), um aparelho de execução somente irá necessitar se referir a esta informação quando executando a pesquisa para frente ou para trás. O tamanho dos dados dos dados de áudio com um período de execução de dois segundos irá depen- der da taxa de bits utilizada quando se executando os dados de áudio.

Como declarado anteriormente, uma taxa de bits na faixa de 16 Kbps até 144 Kbps é utilizada, de modo que a quantidade de dados executados em dois segundos estará na faixa de 4 KB (=16 Kbps x 2/8) até 36 KB (=144 Kbps x 2/8). Desde que a quantidade de dados executada em dois segun- dos estará em uma faixa de 4 KB até 36 KB, o comprimento dos dados de cada entrada na tabela de pesquisa de tempo para gravar o comprimento dos dados dos dados de áudio necessita ter o comprimento de dois bytes (=16 bits). Isto é porque o valor de 16 bits é capaz de expressar um número na faixa de 0 até 64 KB.

Por outro lado, se o tamanho total dos dados da tabela de pes- quisa de tempo necessitar ser restrito para 505 bytes (isto sendo o tamanho dos dados da TKTMSRT descrito posteriormente), por exemplo, o número máximo de entradas na tabela de pesquisa de tempo pode ser calculado como 504/2 = 252.

Desde que uma entrada é proporcionada a cada dois segundos, o tempo de execução correspondendo a este máximo de 252 entradas é 504 segundos (2s * 252), ou em outras palavras, 8 minutos e 24 segundos (=8,4 minutos). Isto significa que o estabelecimento do período de execução má- ximo para um AOB_BLOCK em 8,4 minutos limita o tamanho dos dados de cada tabela de pesquisa de tempo para 504 bytes. {3-3_10-9} Com Respeito aos AOBs Isto conclui a descrição dos AOB_BLOCK. O dito a seguir des- creve os AOBs.

Os AOBs apresentados no segundo nível da Figura 10 são regi- ões que possuem áreas inválidas em cada extremidade. Somente um AOB está presente em cada arquivo AOB.

As áreas inválidas são regiões que são lidas e gravadas junto com os AOB_BLOCK e são armazenadas nos mesmos clusters que os AOB_BLOCK. A posição inicial e final dos AOB_BLOCK dentro de um AOB são apresentadas por BITs incluídos nos dados de navegação. Estes BITs são descritos em detalhes posteriormente nesta especificação.

Isto completa a explicação de que dados são armazenados em um arquivo AOB. O dito a seguir descreve que tipo de conteúdo é executa- do quando os outros AOBs e AOB_BLOCKs apresentados no arquivo AOB na Figura 9 são lidos sucessivamente. {3-3_10-10_16} A Figura 16 apresenta o conteúdo de execução quando os AOBs e os AOB_BLOCKs neste arquivo AOB são lidos sucessivamente. O primeiro nível na Figura 16 apresenta os oito arquivos AOB na região do usuário, enquanto o segundo nível apresenta os oito AOBs gravados nestes arquivos AOB. O terceiro nível apresenta os oito AOB_BLOCKs incluídos nestes AOBs. O quinto nível apresenta os títulos de cinco conteúdos compos- tos por estes arquivos AOB. Neste exemplo, os "conteúdos" são as cinco canções SongA, SongB, SongC, SongD e SongE, enquanto o "título" é um álbum de música composto destas cinco canções. As linhas partidas AS1, AS1, AS3, ..., AS7 e AS8 apresentam a correspondência entre os AOB_BLOCKs e as partes dentro das quais o álbum está dividido, de modo que o quatro nível na Figura 16 apresenta as unidades utilizadas para divi- dir o álbum de músicas apresentado no quinto nível.

Por se referir às linhas tracejadas, pode ser visto que o AOB_BLOCK incluído no AOB N9 1 é uma canção (SongA) com um período de execução de 6,1 minutos. O AOB_BLOCK incluído no AOB N9 2 é uma canção (SongB) com um período de execução de 3,3 minutos. O AOB_BLOCK incluído no AOB N9 3 é uma canção (SongC) com um período de execução de 5,5 minutos. Deste modo, "AOB001.SA1" até "AOB003.SA1", cada um corresponde a uma canção diferente. O sexto nível da Figura 16 é uma seqüência de trilha composta das trilhas Trilha A até a Trilha E. Estas trilhas, Trilha A até a Trilha E, correspondem à cinco can- ções SongA, SongB, SongC, SongD e SongE e cada uma é tratada como uma unidade de execução separada.

Por outro lado, AOB N9 4 possui um período de execução de 8,4 minutos e é a primeira parte (ou "cabeça") da canção SongD que possui um período de execução de 30,6 minutos. Os AOB_BI_OCKs incluídos no AOB N9 5 e AOB N9 6 são partes médias da canção SongD e também possuem períodos de execução de 8,4 minutos. O AOB_BLOCK incluído no AOB N- 7 é a parte final da canção SongD e possui um período de execução de 5,4 minutos. Deste modo, uma canção que possui um período de execução total de 30,6 minutos é dividida em partes (8,4 + 8,4 + 8,4 + 5,4 minutos) que são cada uma incluída em um AOB diferente. Como pode ser visto a partir da Figura 16, cada canção incluída em um arquivo AOB está sujeita a um perí- odo de execução máximo de 8,4 minutos.

Esta explicação claramente apresenta que a limitação dos perí- odos de execução dos AOBs como descrito acima restringe o tamanho dos dados da tabela de pesquisa de tempo correspondendo a cada AOB. O dito a seguir descreve os dados de navegação incluídos em cada tabela de pes- quisa de tempo. {3-3_8A,B-2} Os dados de navegação são compostos de dois arquivos "SD_Áudio.PLM" e "SD_Áudio.TKM" mencionados anteriormente. O arquivo "SD_Áudio.PLM" inclui o Gerente de Lista de Execução, enquanto o arquivo "SD_Áudio.TKM" inclui o Gerente de Trilha.

Como mencionado como parte da explicação dos dados de apresentação, uma pluralidade de arquivos AOB armazenam AOBs codifi- cados, no entanto, outras informações, como o período de execução dos AOBs, os nomes das canções representadas pelos AOBs, ou os créditos para o compositor(es), são fornecidas. Ao mesmo tempo que uma pluralida- de de AOBs são gravados em uma pluralidade de arquivos AOB, nenhuma indicação sobre a ordem de execução dos AOBs é proporcionada. Para in- formar a um aparelho de execução de tal informação, o Gerente de Trilha e o Gerente de Lista de Execução são proporcionados. O Gerente de Trilha apresenta a correspondência entre os AOBs gravados nos arquivos AOB e as trilhas e inclui uma pluralidade de pedaços de informação de gerenciamento da trilha, os quais cada um forne- ce uma variedade de informações, tal como o período de execução dos AOBs e os nomes das canções e dos compositores dos vários AOBs.

Nesta especificação, o termo "trilha" refere-se a uma unidade de execução significativa para os usuários, de modo que quando uma música registrada é armazenada em um cartão de memória flash 31, cada canção é uma trilha separada. Inversamente, quando um "livro de áudio", isto é, lite- ratura registada armazenada como áudio gravado) é gravado em um cartão de memória flash 31, cada capítulo ou parágrafo pode ser estabelecido como uma trilha separada. O Gerente de Trilha é proporcionado para ge- renciar uma pluralidade de AOBs gravados em uma pluralidade de arquivos AOB como um grupo de trilhas.

Uma Lista de Execução estabelece a ordem de execução de uma pluralidade de trilhas. Uma pluralidade de Listas de Execução podem estar incluídas no Gerente de Lista de Execução. O dito a seguir descreve o Gerente de Trilha com referência aos desenhos. {17-1_18} Composição Detalhada do Gerente de Lista de Execução e do Gerente de Trilha A Figura 17 apresenta a composição detalhada do Gerente de Lista de execução e do Gerente de Trilha nesta concretização como uma hierarquia. A Figura 18 apresenta os tamanhos do Gerente de Lista de Exe- cução e do Gerente de Trilha. O lado direito da Figura 17 apresenta os itens no lado esquerdo em mais detalhes, com as linhas tracejadas indicando que itens estão sendo apresentados em mais detalhes.

Como apresentado na Figura 17, o Gerente de Trilha é com- posto da informação de Trilha (TKI) N9 1, N9 2, N9 3, N9 4... N9 n, como apresentado pela linha tracejada h1. Estas TKIs são informações para ge- renciar os AOBs gravados nos arquivos AOB como trilhas e cada uma cor- responde a um arquivo AOB diferente. A partir da Figura 17, pode ser visto que cada TKI é composta da Informação Geral da Trilha (TKGI), da Informa- ção de Texto da Trilha (TKTXTI_DA) na qual a informação de texto exclusi- va para uma trilha pode ser gravada e uma Tabela de Pesquisa de Tempo da Trilha (TKTMSRT) que serve como uma tabela de pesquisa de tempo. A partir da Figura 18, pode ser visto que cada TKI possui um tamanho fixo de 1.024 bytes, o que significa que o tamanho total da TKGI e da TKTXTI_DA é fixo em 512 bytes devido ao tamanho daTKTMSRT sendo fixo em 512 bytes. No Gerente de Trilha, um total de 999 TKIs podem ser estabelecidas.

Como apresentado pela linha tracejada h3, a TKTMSRT é com- posta de um Cabeçalho da TMSRT das TMSRT_entrys N9 1, N9 2, N9 3, ..., N9 n. {17-2_19} Correspondência da TKI com os arquivos AOB e com os AO Bs A Figura 19 apresenta como os TKIs apresentados na Figura 17 correspondem com os arquivos AOB e com os AOBs apresentados na Figu- ra 16. As caixas no primeiro nível na Figura 19 apresentam uma seqüência de trilhas composta das trilhas Trilha A até Trilha E, o quadro maior no se- gundo nível apresenta o Gerente de Trilha, enquanto os terceiro e quarto níveis apresentam os oito arquivos OAB dados na Figura 16. Os oito arqui- vos AOB são gravados nos oito AOBs apresentados na Figura 16 e com- põem um álbum de músicas incluindo as trilhas Trilha A, Trilha B, Trilha C, Trilha D e Trilha E. O segundo nível apresenta as oito TKIs. Os números "1", "2", "3", "4" designados para cada TKI são os números de série utiliza- dos para identificar cada TKI, com cada TKI correspondendo ao arquivo AOB ao qual foi dado o mesmo número de série 001, 002, 003, 004, 005, ...

Com isto em mente, pode ser visto a partir da Figura 19 que a TKI N9 1 corresponde ao arquivo "AOB001 .SA1", que a TKI N9 2 correspon- de ao arquivo "AOB002.SA1", a TKI N9 3 corresponde ao arquivo "AOB003.SA1" e a TKI N9 e corresponde ao arquivo "AOB004.SA1". A cor- respondência entre as TKIs e os AOB_FRAMEs é apresentada pelas setas TA1, TA2, TA3, TA4, ... na Figura 19.

Deste modo, cada TKI corresponde a um AOB diferente gravado em um arquivo AOB e fornece informações detalhadas que e aplicam so- mente ao AOB correspondente.

{17-3_20} Composição dos Dados de uma TKTMSRT O dito a seguir descreve a informação que se aplica aos AOBs únicos gravados nos arquivos AOBs, começando com a TKTMSRT A Figu- ra 20 apresenta a composição dos dados da TKTMSRT em detalhes. O lado direito da Figura 20 apresenta a composição detalhada dos dados do cabeçalho da tabela de pesquisa de tempo (Cabeçalho da TMSRT). Na Figura 20, o cabeçalho da TMSRT possui um tamanho dos da- dos de oito bytes e é composto de três campos. Os primeiros dois bytes são um ID da TMSRT, os próximos dois bytes são reservados e os quatro bytes finais são um Número Total de TMSRT_entrys.

Um ID único para identificar a TMSRT é gravado no "ID da TMSRT". O número total de TMSRT_entrys no TMSRT presente é gravado no "Número Total de TMSRT_entrys".

{17-3_21 -1} Exemplo Específico da TKTMSRT O dito a seguir descreve uma TKTMSRT em detalhes. A Figura 21 apresenta um exemplo de uma TKTMSRT. O lado esquerdo da Figura 21 apresenta um AOB, enquanto o lado direito apresenta a TKTMSRT corres- pondente. O AOB no lado esquerdo da Figura 21 é composto de uma plura- lidade de AOB_ELEMENTs numerados N- 1, N9 2, N9 3, ..., N9 n que ocu- pam as regiões numeradas AR1, AR2, AR3,..., ARn na direita.

Os números tal como "0", "32000", "64000", "97000", "1203400" e "1240000" apresentam os endereços relativos das áreas AR1. AR2. AR3, ARn-1 ocupadas pelos AOB_ELEMENTs com respeito ao início do AOB_BLOCK. Como exemplos, o AOB_ELEMENT N9 2 está gravado em uma posição que está a uma distancia "32000" do início do AOB_BLOCK, enquanto o AOB_ELEMENT N9 3 está gravado em uma posição que está a uma distância "64200" do início do AOB_BLOCK e o AOB_ELEMENT N9 n-1 está gravado em uma posição que está a uma distância "1203400" do início do AOB_BLOCK.

Deve ser observado que a distância entre cada região ocupada e o início do AOB_BLOCK não é um múltiplo de um certo valor, significando que as regiões ocupadas por AOB_ELEMENTs não são do mesmo tama- nho. A razão pela qual as regiões ocupadas possuem tamanhos diferentes é que quantidades variadas de dados são utilizadas para codificar cada AOB_FRAME.

Desde que o tamanho da região ocupada por cada AOB_ELEMENT difere, é necessário informar a um aparelho de execução antecipadamente da posição de cada AOB_ELEMENT em um AOB quando executando um salto para o início de um AOB_ELEMENT. Para este propó- sito, uma pluralidade de TMSRT_entry são fornecidas na TKTMSRT. As setas RT1, RT2, RT3, ..., RTn-1, RTn apresentam a correspondência entre as regiões AR1, AR2, AR3, ..., ARn-1, ARn ocupadas por cada AOB_ELEMENT e a TMSRT_entry NP 1, TMSRT_entry N9 2, TMSRT_entry N- 3.,,,, TMSRT_entry N- n-1, TMSRT_entry N9 n. Em outras palavras, o tamanho da região AR1 ocupada pelo AOB_ELEMENT N9 1 é gravado na TMSRT N9 1, enquanto os tamanhos das regiões AR2 e AR3 ocupadas pe- los AOB_ELEMENT N9 2 e AOB_ELEMENT N9 3 são gravados nas TMSRT_entry N9 2 e N9 3.

Desde que a área ocupada AR1 ocupa a região do início do AOB até o início do AOB_ELEMENT N9 2 "32000", o tamanho "32000" (=32000-0) é gravado na TMSRT_entry N9 1. A área ocupada AR2 ocupa a região do início do AOB_ELEMENT N9 2 "32000" até o início do AOB_ELEMENT N9 3 "64200", de modo que o tamanho "32200" (=64200- 32000) é gravado na TMSRT_entry N9 2. A área ocupada AR3 ocupa a re- gião do início do AOB_ELEMENT N9 3 "64200" até o início do AOB_ELEMENT N9 4 "97000", de modo que o tamanho "32800" (=97000- 64200) é gravado na TMSRT_entry N9 3. Do mesmo modo, a área ocupada ARn-1 ocupa a região do início do AOB_ELEMENT N9 n-1 "1203400" até o início do AOB_ELEMENT N9 n "1240000", o tamanho "36600" (=1240000- 1203400) é gravado na TMSRT_entry N9 n-1. {17-3_21-2} Como a TKTMSRT é lida Deste modo, os tamanhos dos dados dos AOB_ELEMENTs são gravados em uma tabela de pesquisa de tempo. Entretanto, desde que o comprimento dos dados de cada AOB_BLOCK está restrito a um máximo de 8,4 minutos, o número total de AOB_ELEMENTs incluídos em um único AOB está limitado a um número predeterminado ("252" como apresentado na Figura 20) ou menos. Desde que o número de AOB_ELEMENTs está restrito, o número de TMSRT_entry correspondendo aos AOB_ELEMENTs também está restrito, o que restringe o tamanho da TKTMSRT incluindo estas TMSRT_entry a um tamanho predeterminado. Desde que o tamanho da TKTMSRT é restrito, um aparelho de execução pode ler e utilizar as TKIs do seguinte modo. O aparelho de execução lê um certo AOB e ao começar a exe- cução do AOB, lê a TKI correspondente e armazena a mesma em uma me- mória. Esta TKI correspondente é mantida na memória enquanto a execu- ção deste AOB continua. Uma vez que a execução do AOB termina, o AOB seguinte é lido e quando a execução deste AOB começa, o aparelho de execução grava por cima a TKI correspondendo a este AOB seguinte dentro da memória no lugar da TKI anterior. Esta próxima TKI é mantida na memó- ria enquanto a execução deste AOB seguinte continua.

Por ler e armazenar as TKIs deste modo, a capacidade neces- sária de memória no aparelho de execução pode ser minimizada ao mesmo tempo que ainda permitindo às funções de execução especial tal como a pesquisa para frente e para trás, de serem realizadas. Ao mesmo tempo que a presente concretização descreve o caso onde o comprimento dos dados a partir do primeiro endereço de um AOB_ELEMENT até o primeiro endereço do próximo AOB_ELEMENT é gravado na TMSRT_entry, ao invés disso os endereços relativos a partir do início do AOB_BLOCK até os primeiros en- dereços do AOB_ELEMENTs podem ser lá.

{17-3_21-3} Especificando um Cluster Incluindo um AOB_ELEMENT O dito a seguir descreve como um AOB_ELEMENT pode ser lido utilizando a TKTMSRT. A TKTMSRT inclui o tamanho de cada AOB_ELEMENT, de modo que quando o AOB_ELEMENT NQ y, que é o ye AOB_ELEMENT a partir do início de um AOB, é para ser lido, o cluster u que satisfaz a Equação 1 dada abaixo é calculado e os dados posicionados com o deslocamento v a partir do início do cluster u é lido.

Equação 1 Cluster u = (Total das TMSRT_entries do AOB_ELEMENT NQ 1 até o AOB_ELEMENT N9 y-1 + DATA_Offset)/tamanho do Cluster Deslocamento v = (Total das TMSRT_entry do AOB_ELEMENT N9 1 até o AOB_ELEMENT N9 y-1 + DATA_offset) módulo do tamanho do Cluster onde c=a módulo b indica que c é o resto produzido quando a é dividido por b. O DATA_offset é gravado no BIT e é descrito posteriormente nesta especificação.

{17-4} TKTXI_DA

Isto completa a explicação da tabela de pesquisa de tempo (TKTMSRT). O dito a seguir descreve a Área de Dados Informação de Texto da Trilha (TKTXI_DA) gravada na parte superior da TKTMSRT. A Área de Dados Informação de Texto da Trilha (TKTXTI_DA) utilizada para armazenar informação de texto apresentando o nome do ar- tista, o nome do álbum, misturador, produtor e outras informações. Esta área é proporcionada mesmo quando tal informação de texto não existe.

{17-5} TKGI O dito a seguir descreve as TKIs gravadas na parte superior da TKTXI_DA. Na Figura 17, vários conjuntos de informações são apresenta- dos tal como o identificador "TKIJD" da TKI, o número da TKI "TKIN", o ta- manho da TKI "TKI_SZ", um ponteiro de ligação com a próxima TKI "TKI_LNK_PTR", os atributos do bloco UTKLBLK_ATR", um período de exe- cução "TKI_PB_TM", os atributos de áudio "TKI_AOB_ATR", uma "ISRC" e a informação do bloco "BIT". Observe que somente algumas destas infor- mações foram apresentadas na Figura 17 para simplificar a representação.

{17-5_22-1} TKGI O dito a seguir descreve a composição de uma TKGI em deta- lhes, com referência à Figura 22. A diferença entre a Figura 17 e a Figura 22 é que a composição dos dados da TKGI que foi apresentada na Figura 17 está disposta no lado esquerdo deste desenhos e que as composições do bit de "TKI_BLK_ATR", "TKI_AOB_ATR" e "ISRC" são claramente apre- sentadas.

{17-5_22-2} TKIJD

Um ID único para uma TKI é gravado no "TKIJD" Na presente concretização, um código "A4" de dois bytes é utilizado.

{17-5_22-3} TKIN O número da TKI na faixa de 1 até 999 é gravado no "TKIN".

Observe que o TKIN de cada TKI é único. Na presente concretização, a po- sição de cada TKI no Gerente de Trilha é utilizada como a TKIN. Isto signifi- ca que "1" é gravado como o número da TKI da TKI N9 1, "2" é gravado como o número da TKI de TKI N9 2 e "3" é gravado como o número da TKI de TKI N9 3.

{17-5_22-4} TKI_SZ O tamanho dos dados da TKI em unidades de byte é gravado no "TKI_SZ". Na Figura 22, 1.024 bytes são dados como o tamanho dos dados da TKI de modo que cada TKI na presente concretização tem o compri- mento de 1.024 bytes.

{17-5_22-5} TKI_LNK_PTR O TKIN da TKI com a qual a TKI presente está ligada é gravado no "TKI_LNK_PTR". O dito a seguir descreve tais ligações entre as TKIs.

Quando uma trilha é composta de uma pluralidade de AOBs que são gravados em uma pluralidade de arquivos AOB, estes arquivos AOB serão gerenciados como uma única trilha por ligar a pluralidade de TKIs que correspondem a estes arquivos AOB. Para ligar uma pluralidade de TKIs, é necessário apresentar a TKI do arquivo AOB que segue após o arquivo AOB da presente TKI. Por conseqüência, o TKIN da TKI que segue a TKI presente é gravado em TKI_LNK_PTR.

{17-5_22-6_19> TKI_LNK_PTR O dito a seguir descreve as configurações feitas para o TKI_LNK_PTR nas oito TKIs apresentadas na Figura 19. A informação da trilha numerada N9 1 até N9 3 e N9 8, cada uma corresponde a trilhas sepa- radas, de modo que nenhuma informação é estabelecida no seu TKI_LNK_PTR. A informação da trilha TKI N9 4, TKI N9 5, TKI N9 6, TKI N9 7 corresponde aos quatro arquivos AOB que compõem a Trilha D, de modo que a próxima informação de trilha é indicada no TKI_LNK_PTR destas TKIs. Como apresentado pelas setas TL4, TL5 e TL6 na Figura 19, a "TKI NQ 5" é estabelecida no TKI_LNK_PTR da TKI N9 4, a "TKI N9 6" é estabele- cida no TKI_LNK_PTR da TKI N9 5 e a "TKI N9 7" é estabelecida no TKI_LNK_PTR da TKI N9 6.

Como resultado, um aparelho de execução pode referir-se aos TKI_LNK_PTRs dados nas TKIs correspondendo a este quatro arquivos AOB e desse modo encontrar que as quatro TKIs TKI N9 4 até TKI N9 7 e os quatros arquivos AOB "AOB004.SA1" até "AOB007.SA1" compõem uma única trilha, a Trilha D.

N{17-5_22-7} TKI_BLK_ATR

Os atributos da TKI presente são gravados no "TKI_BLK_ATR".

Na Figura 22, a informação apresentada dentro das linhas tracejadas se estendendo a partir do TKI_BLK_ATR apresenta a composição do bit do TKI_BLK_ATR. Na Figura 22, ao TKI_BLK_ATR é apresentado como tendo o comprimento de 16 bits, com os bits de b3 até b15 sendo reservados para uso futuro. O três bits do bit b2 até bO são utilizados para apresentar os atributos da TKI.

Quando uma TKI corresponde a uma trilha completa, o valor "00b" é gravado no TKI_BLK_ATR" (este estabelecimento é daqui para frente referido como "Trilha"). Quando várias TKIs correspondem à mesma trilha, o valor "001b" é gravado no TKI_BLK_ATR da primeira TKI (este es- tabelecimento é daqui para frente referido como "Cabeçalho da Trilha"), o valor "010b" é gravado no TKI_BLK_ATR das TKIs que correspondem aos AOBs no meio da trilha (este estabelecimento é daqui para frente referido como "Ponto Médio da Trilha") e o valor "011b" é gravado no TKI_BI_K_ATR da TKI que corresponde ao AOB no final da trilha (este estabelecimento é daqui para frente referido como "End_if_Track"). Quando uma TKI não está utilizada mas uma região da TKI existe, ou seja, quando existe uma TKI de- letada, o valor "100b" é gravado no TKI_BLK_ATR (este estabelecimento é daqui para frente referido como "Não-Utilizado"). Quando uma TKI está não- utilizada e nenhuma região da TKI existe, o valor "101b" é gravado no TKI_BLK_ATR.

{17-5_22-8_19} Exemplo de Estabelecimento do TKI_BLK_ATR

O dito a seguir descreve os estabelecimentos do TKI_BLK_ATR para cada TKI no exemplo apresentado na Figura 19.

Por se referir ao TKI_BLK_ATR de cada TKI, pode ser visto que quatro pares TKI N2 1 ("AOB001.SA1"), TKI N2 2 ("AOB002.SA1"), TKI N2 3 ("AOB003.SAT') e TKI N2 8 ("AOB008.SA1"), cada um correspondendo a trilhas separadas, desde que o TKI_BLK_ATR de cada TKI N2 1, TKI N2 2, TKI N2 3 e TKI N9 8 é estabelecido como "Trilha11. O TKI_BLK_ATR da TKI N2 4 é estabelecida como "Cabeçalho da Trilha", o TKI_BLK_ATR da TKI N2 7 é estabelecido como "Fim da Trilha" e o TKI_BLK_ATR da TKI N2 5 e da TKI N2 6 são estabeleci- dos como "Ponto Médio da Trilha11. Isto significa que o arquivo AOB ("AOBOG4.SA1 ”) correspondendo a TKi NMéo início de uma trilha, os ar- quivos AOB ("AOB005.SA1") e ("AOB006.SA1") correspondendo a TKI N2 5 e a TKI N2 6 são pontos médios da trilha e o arquivo AOB ("AOB007.SA1") correspondendo a TKI N9 7 é o final de uma trilha.

Por classificar as combinações da TKI e do arquivo AOB corres- pondente de acordo com os estabelecimentos do TKI_BLK_ATR na TKI, pode ser visto que a combinação da TKI N2 1 com o "AOB001.SA1" com- põem uma primeira trilha (Trilha A). Da mesma forma, a combinação da TKI N2 2 com o "AOB002.SAT1 compõem uma segunda trilha (Trilha B) e a com- binação da TKI N2 3 com o "AOB003.SA1" compõem uma terceira trilha (Trilha C). A combinação da TKI N2 4 com o "AOB004.SA1" compõem a pri- meira parte da quarta trilha (Trilha D), as combinações da TKI N2 5 com o "AOB005.SA1" e da TKI N9 6 com o "AOB006.SA1" compõem as partes centrais da Trilha D e a combinação da TKI N2 7 com o "AOB007.SA111 com- põem a parte final da Trilha D. Finalmente, a combinação da TKI N2 8 com o "AOB008.SA1" compõem uma quinta trilha (Trilha E).

{17-5_22-9} TKI_PB_TM

O período de execução da trilha (canção) composta do AOB gravado no arquivo AOB correspondendo a uma TKI é gravado no TKI_PB_TM" na TKI.

Quando uma trilha é composta de uma pluralidade de TKIs, todo o período de execução da trilha é gravado no TKI_PB_TM da primeira TKI correspondendo à trilha, enquanto o período de execução do AOB corres- pondente é gravado na segunda e nas TKIs seguintes para a trilha.

{17-5_22-10} TKI_AOB_ATR

As condições de codificação utilizadas quando produzindo-se um AOB, que é para dizer a informação tal como (1) a freqüência de amos- tragem na qual o AOB gravado no arquivo AOB correspondente foi amos- trado, (2) a taxa de transferência de bits e (3) o número de canais, são gra- vadas no "TKI_AOB_ATR" em uma TKI. A composição do bit do TKI_AOB_ATR é apresentada dentro das linhas tracejadas que se esten- dem a partir do "TKI_AOB_ATR" na Figura 22.

Na Figura 22, o TKi_AOB_ATR é composto de 32 bits, com o modo de codificação sendo gravado no campo de quatro bits a partir do bit b16 até o bit b19. Quando o AOB é codificado de acordo com o MPEG2- AAC (com o cabeçalho ADTS), o valor "OOOOb" é gravado dentro deste cam- po, enquanto quando o AOB é codificado de acordo com o MPEGJayer 3 (MP3), o valor "0001b" é gravado. Quando o AOB é codificado de acordo com o Windows Media Audio (WMA), o valor "0010b" é gravado neste cam- po. A taxa de bits utilizada quando codificando-se o AOB é gravada no campo de oito bits entre o bit b15 e o bit b8. Quando o AOB é codificado de acordo com o MPEG2-AAC (com o cabeçalho ADTS), um valor entre "16" e "72" é gravado dentro deste campo, enquanto quando o AOB é codificado de acordo com o MPEG1-layer 3 (MP3), um valor entre "16" e "96" é grava- do. Quando o AOB é codificado de acordo com o MPEG1-layer 3 (MP3), um valor entre "16" e "80" é gravado dentro deste campo, enquanto quando o AOB é codificado de acordo com o Windows Media Audio (WMA), um valor entre "8" e "16" é gravado. A freqüência de amostragem utilizada quando codificando-se o AOB é gravada no campo de quatro bits entre o bit b7 e o bit b4. Quando a freqüência de amostragem é 48 kHz, o valor "OOOOb" é gravado neste cam- po. Quando a freqüência de amostragem é 44,1 kHz, o valor é "0010b", quando a freqüência de amostragem é 32 kHz, o valor "0010b", quando a freqüência de amostragem é 34 kHz, o valor "0011b", quando a freqüência de amostragem é 22,05 kHz, o valor "0100b" e quando a freqüência de amostragem é 16 kHz, o valor "0101b". O número de canais é gravado no campo de três bits a partir do bit b3 até o bit b1. Quando um canal (isto é, monoaural) é utilizado, o valor "000b" é gravado neste campo, enquanto quando dois canais (isto é, esté- reo) é utilizado, o valor "001b" é gravado neste campo. O campo de doze bits a partir do bit b31 até o bit b20 é reserva- do para uso futuro, como é o bit bO.

{17-5_22-11} ISRC um iSRC (Código de Gravação Padrão internacionai) é gravado no TKGI. Na Figura 22, as linhas tracejadas se estendendo a partir da caixa "ISRC" apresenta o conteúdo do ISRC. Como apresentado no desenho, o ISRC é composto de dez bytes, com o código de Gravação-ltem ( N9 12) sendo gravado dentro do campo de quatro bits entre o bit b4 e o bit b7. Um código de Gravação/código de Gravação-ltem ) N9 11) é gravado no campo de quatro bits entre o bit b8 e o bit b11. O Código de Gravação (ISRC N9 10, N9 9, N9 8) é gravado no campo de doze bits entre o bit b12 e o bit b23. Um código de Ano-de- Gravação (ISRC N9 6, N9 7) é gravado no campo de oito bits b24 até b31. O Código de Primeiro Proprietário (ISRC N9 3, N9 4, N9 5) é gra- vado no campo de seis bits entre o bit b32 e o bit b37, o campo de seis bits entre o bit b40 e o bit b45 e o campo de seis bits entre o bit b48 e o bit b53. O Código do País (ISRC N9 1, N9 2, N9 2) é gravado no campo de seis bits entre o bit b56 e o bit b61 e o campo de seis bits entre o bit b64 e o bits b69.

Um flag de Validade de um bit é gravado em um campo de um bit composto do bit b79. Uma descrição detalhada do ISRC pode ser encontrada na ISO3901:1986 "Documentationjnternational Standard Recording Code (ISRC)".

{17-5_22-12_23Α-1} BIT A "Tabela de Informação do Bloco (BIT)" é uma tabela para ge- renciar um AOB_BLOCK e possui a composição detalhada apresentada nas Figuras 23A e 23B.

Como apresentado na Figura 23A, um BIT é composto de um campo DATA_OFFSET que ocupa uma região do 60a byte até o 63a byte, um campo SZ_DATA que ocupa uma região do 645 byte até o 67s byte, um campo TMSRTE_Ns que ocupa uma região do 68s byte até o 71θ byte, um campo FNs_1 st_TMSRTE que ocupa uma região do 72a byte até o 73e byte, um campo FNs_Last_TMSRTE que ocupa uma região do 74a byte até ο 75θ byte, um campo FNs_Middle_TMSRTE que ocupa uma região do 76s byte até o 77a byte e um campo TIME_LENGH que ocupa uma região do 78a byte aié o 79a byte.

Cada um destes campos é descrito em detalhes abaixo. {17-5_22-12_23A-2> DATA_Offset O endereço relativo do início de um AOB_BLOCK a partir do limite entre clusters é gravado no "DATA_OFFSET" como um valor dado em unidades de byte. Isto expressa o tamanho de uma área inválida entre um AOB e o AOB_BLOCK. Como um exemplo, quando um usuário grava uma difusão de rádio em um cartão de memória flash 31 como AOBs e deseja deletar uma parte de introdução de uma trilha sobre a qual um DJ falou, o DATA_OFFSET no BIT pode ser estabelecido para possuir a trilha executa- da sem a parte incluindo a voz do DJ.

{17-5_22-12_23A-3} SZ_DATA O comprimento dos dados de um AOB_BLOCK expresso em unidades de bytes é gravado no "SZ_DATA". Por subtrair um valor produzi- do por se adicionar o SZ_DATA com o DATA_Offset do tamanho do arquivo (um número inteiro múltiplo do tamanho do cluster), o tamanho da área in- válida que segue o AOB_BL_OCK pode ser encontrado. {17-5_22-12_23A-4} TMSRTE_Ns O número total de TMSRT_entry incluídos em um AOB_BLOCK é gravado no "TMSRTE_Ns". {17-5_22-12_23A-5} "FNs_1st_TMSRTE", "FNs_Last_TMSRTE", "FNs_Middle_TMSRTE" O número de AOB_FRAMEs incluídos no AOB_ELEMENT posi- cionado no início de um AOB_BLOCK presente é gravado no MFNs_1st_TMSRTE". O número de AOB_FRAMEs incluídos no AOB_ELEMENT posi- cionado no final do AOB_BLOCK presente é gravado no "FNs_Last_TMSRTE".

O número de AOB_FRAMEs incluídos em cada AOB_ELEMENT separado daqueles no início e no fim do AOB_BLOCK presente, ou seja, os AOB_ELEMENTs no meio do AOB_BLOCK, é gravado no "FNs_Middle_TMSRTE". O período de execução de um AOB_ELEiviENT é gravado no formato apresentado na Figura 23C no campo "TIME_LENGHT" até uma precisão na ordem de milissegundos. Como apresentado na Figura 23C, o campo "TIME_LENGTH'' tem o comprimento de 16 bits. Quando o método de codificação utilizado no MPEG-AAC ou no MPEG-Layer 3, o período de execução de um AOB_ELEMENT é dois segundos, de modo que o valor "2000" é gravado no campo "TIME_LENGTH". {17-5_22-13_23B} A Figura 23B apresenta o número de AOB_FRAMEs indicado pelo "FNs_Middle_TMSRTE". Do mesmo modo que a Figura 14, a Figura 23B apresenta a relação entre a sampling_frequency e o número de AOB_FRAMEs incluídos em um AOB_ELEMENT no meio de um AOB_BLOCK. A relação entre a frequência de amostragem e o número de quadros incluídos no AOB_ELEMENT apresentada na Figura 23B é a mes- ma que esta apresentada na Figura 14, ou seja, o número de quadros em um AOB_ELEMENT depende da freqüência de amostragem utilizada. O número de quadros gravado em "FNs_1st_TMSRTE" e em "FNs_Last_TMSRTE" será fundamentalmente o mesmo que o número gra- vado no "FNs_Middle_TMSRTE", no entanto, quando uma área está pre- sente nos AOB_ELEMENTs no início e/ou no final de um AOB_BLOCK, os valores dados em "FNs_1st_TMSRTE" e/ou em "FNs_Last_TMSRTE" irão diferir do valor no "FNs_Middle_TMSRTE". {17-5_22-14_24} Exemplo de um AOB_ELEMENT Armazenado A Figura 24 apresenta os clusters 007 até 00E que armazenam o AOB composto dos AOB_ELEMENT N9 1 até o AOB_ELEMENT N9 4. O dito a seguir descreve os estabelecimentos no BIT quando um AOB é arma- zenado como apresentado na Figura 24. O AOB_ELEMENT N9 1 até o AOB_ELEMENT N9 4 que são armazenados no cluster 007 até o cluster 00E são indicados na Figura 24 pelos indicadores triangulares, com as TMSRTE_entry sendo estabelecidas na TKI para cada um dos AOB_ELEMENT N9 1 até AOB_ELEMENT N9 4.

Neste exemplo, a primeira parte do AOB_ELEMENT N° 1 no início do AOB é armazenada no cluster 007, enquanto a última parte do AOB_ELEMENT N9 4 no final do AOB é armazenada no cluster 00E. Os AOB_ELEMENTs N9 1 até N9 4 ocupam a região entre o mdO no cluster 007 até 0 md4 no cluster 00E. Como apresentado pela seta sd1 na Figura 24, o SZ_DATA no BIT indica que os AOB_ELEMENTs N91 até N9 4 ocupam uma região a partir do início do cluster 007 até o final do cluster 00E e desse modo não indica que existem as áreas inválidas udO e ud1 nos clusters 007 e 00E que não são ocupadas por um AOB_ELEMENT.

Por outro lado, o AOB também inclui as partes udO e ud1 que estão presentes nos clusters 007 e 00E mas não são ocupadas pelo AOB_ELEMENT N9 1 ou pelo AOB_ELEMENT N9 4. O DATA_Offset forne- cido no BIT dá o comprimento da região não ocupada udO, ou seja, um valor de posição para o início do AOB_ELEMENT N9 1 em relação ao início do cluster 007.

Na Figura 24, o AOB_ELEMENT N9 1 ocupa uma região a partir de mdO no cluster 007 até md1 no cluster 008.

Este AOB_ELEMENT N9 1 não ocupa todo o cluster 008, com a parte restante do cluster sendo ocupada pelo AOB_ELEMENT N9 2. O AOB_ELEMENT N9 4 ocupa uma região a partir do md2 a meio do caminho através do cluster 00C até md4 a meio do caminho através do cluster 00E.

Deste modo, os AOB_ELEMENTs podem ser armazenados através dos li- mites do cluster ou em outras palavras, os AOB_ELEMENTs podem ser gra- vados sem respeito aos limites entre os cluster. O "FNs_1st_TMSRTE" no BIT apresenta o número de quadros no AOB_ELEMENT N91 que está loca- lizado nos cluster 007 e 008, enquanto o "FNs_Last_TMSRTE" no BIT apre- senta o número de quadros no AOB_ELEMENT N- 4 que está localizado nos clusters 00C até 00E.

Deste modo, os AOB_ELEMENTs podem ser livremente posici- onados sem respeito aos limites entre os clusters. O BIT proporciona a in- formação apresentando o deslocamento a partir de um limite do cluster até um AOB_ELEMENT e o número de quadros em cada AOB_ELEMENT. {17-5 22-14 25} Uso do Número de Quadres dade em cada AOB_ELEMENT (parte 1) O dito a seguir descreve como o número de quadros em cada AOB_ELEMENT dado no BIT é utilizado. Este número de quadros dado no BIT é utilizado quando a pesquisa para frente ou para trás é executada.

Como mencionado anteriormente, tais operações executam 240 milissegun- dos de dados após o primeiro saltar dados com um período de execução de dois segundos. A Figura 25 apresenta como o AOB_FRAME N- x+1, que deve ser executado a seguir, é estabelecido quando executando-se a pesquisa para frente começando a partir de um AOB_FRAME N9 x em um AOB_ELEMENT N9 y em um AOB. A Figura 25 apresenta o caso quando um usuário seleciona a pesquisa para frente durante a execução de um AOB_FRAME N9 x incluído no AOB_ELEMENT N9 y. Na Figura 25, "t" representa o período de execu- ção intermitente (aqui, 240 milissegundos), "f(t)" apresenta o número de quadros que corresponde a este período de execução intermitente, "skip_time" apresenta o comprimento do período que deve ser saltado entre períodos de execução intermitentes (aqui, dois segundos), "f(skip_time)" apresenta o número de quadros que correspondem a este tempo de salto. A execução intermitente é realizada por se repetir os três procedimentos (1), (2) e (3) descritos abaixo. (1) O aparelho de execução refere-se à TMSRT_entry na TKTMSRT e salta para o início do símbolo do indicador (AOB_ELEMENT). (2) O aparelho de execução executa a execução por 240 milis- segundos. (3) O aparelho de execução salta para o início do próximo sím- bolo do indicador (AOB_ELEMENT). O AOB_FRAME N9 x+1 que existe 2s+240ms a partir do AOB_FRAME N9 x incluído no AOB_ELEMENT N9 y irá definitivamente estar presente no AOB_ELEMENT N9 y+1. Quando especificando o AOB_FRAME N9 x+1 que está a 2s+240ms do AOB_FRAME N9 x, o primeiro endereço do próximo AOB_ELEíviENT N5 y+1 pode ser imediatamente calculado por se ler uma TMSRT_entry a partir da TKTMSRT, no entanto, um aparelho de execução não pode saber o número de AOB_FRAMEs a partir do endereço inicial do AOB_ELEMENT N9 x+1 até o AOB_FRAME N9 x+1 a partir so- mente da TMSRT_entry.

Para calcular este número de AOB_FRAMEs, é necessário sub- trair o número total de quadros incluídos no AOB_ELEMENT N9 y do total de (1) do número N9 x apresentando a posição do AOB_FRAME N9 x em rela- ção ao início do AOB_ELEMENT N9 y, (2) d(t) e (3) f(skip_time). Para sim- plificar o cálculo da posição relativa do quadro de AOB_FRAME N9 x+1, o "FNs_1 st_TMSRTE", o "FNs_Middle_TMSRTE" e o "FNs_Last_TMSRTE" para cada AOB_ELEMENT são gravados no BIT, como mencionado acima. {17-5_22-15_26A} Uso do Número de Quadros dado em cada AOB_ELEMENT (parte 2) O número de quadros gravados no BIT também é utilizado quando o aparelho de execução executa uma função de pesquisa de tempo onde a execução começa em um ponto indicado utilizando-se um código de tempo. Na Figura 26A, é apresentado como um aparelho de execução pode especificar o AOB_ELEMENT e o AOB_FRAME correspondendo ao tempo de início da execução indicado pelo usuário. Quando a execução é para começar a partir de um tempo indicado pelo usuário o tempo indicado (em segundos) é estabelecido no campo Jmp_Entry e a execução deve começar a partir de um AOB_ELEMENT Ns y e em uma posição do AOB_FRAME x que satisfaça a Equação 2 dada abaixo.

Equação 2 Jmp_Entry(seg)=(FNs_1st_TMSRTE + FNs_Middle_TMSRTE*y+x)*20 mseg Desde que "FNs_1 st_TMSRTE" e "FNs_Middle_TMSRTE" são proporcionados no BIT, estes podem ser substituídos na Equação 2 para calcular o AOB_ELEMENT N9 y e o AOB_FRAME NQ x. Tendo feito isto, um aparelho de execução pode referir-se à TKTMSRT do AOB, calcular o pri- meiro endereço do AOB_ELEMENT N9 y+2 (que é o (y+2)e AOB_ELEMENT neste AOB) e começar a pesquisa peio áOõ_FRâmE N9 x a partir deste primeiro endereço. Ao encontrar o xe AOB_FRAME, o aparelho de execução começa a executar a partir deste quadro. Deste modo, o aparelho de execu- ção pode começar a execução dos dados a partir do tempo indicado pela Jmp_Entry (em segundos).

Deste modo, um aparelho de execução não tem que pesquisar pelas partes do cabeçalho ADTS dos AOB_FRAMEs e somente necessita executar a pesquisa nos AOB_ELEMENTs que foram dados nas TMSRT_entry na TKTMSRT. Isto significa que o aparelho de execução pode encontrar uma posição de execução correspondendo a um tempo de execução indicado em alta velocidade.

Do mesmo modo, quando a Jmp_Entry é estabelecida e a fun- ção de pesquisa por tempo é utilizada em uma trilha que é composta de uma pluralidade de AOBs, o aparelho de execução somente necessita cal- cular um AOB_ELEMENT N2yeo AOB_FRAME N9 x que satisfaçam a Equação 3 abaixo.

Equação 3 Jmp_Entry (em segundos) = período de execução de AOB N9 1 até o AOB N9 n + (FNs_1 st_TMSRTE( N9 n+1) + FNs_Middle_TMSRTE ( N9 n+1)*y+x)*20 mseg O período de execução total dos AOBs a partir do AOB N9 1 até o AOB N9 n é como se segue.

Período de execução Total de AOB N9 1 até AOB N9 n = ["FNs_1st_TMSRTE"( N9 1 )+"FNs_Middle_TMSRTE"( N9 1)* (Número de TMSRTE_entry ( N9 1) -2) + "FNs_Last_TMSRTE"( N9 1) + "FNs_1 st_TMSRTE"( N9 2) + ("FNs_Middle_TMSRTE"( N9 2) * Número de TMSRTE_entry ( N9 2) -2) + " FNs_Last_TMSRTE" ( N9 2) + "FNs_1 st_TMSRTE"( N9 3) + ("FNs_Middle_TMSRTE"( N9 3) * Número de TMSRTE_entry ( N9 3) - 2) + "FNs_Last_TMSRTE" ( N9 3) ... + "TMSRTE"( N9 n) + ("FNs_Middle_TMSRTE"( N9 n) * Número de TMSRTE_entry ( N9 n) - 2) + ,,FNs_Last_TMSRTE"( N9 n)] * 20 mseg Tendo caicuiaao um AOB N9 n, um A06_ELEMENT N-yeo AOB_FRAME N9 x que satisfazem a Equação 3, o aparelho de execução refere-se a TKTMSRT correspondendo ao AOB N9 n+1, pesquisa pelo xe AOB_FRAME a partir do endereço no qual o (y+2)o AOB_ELEMENT (isto é, o AOB_ELEMENT N9 y+2) está posicionado e começa a execução a partir deste xs AOB_FRAME.

{17-5_22-16_27A,B} Deleção de um arquivo AOB e de uma TKI

Isto completa a explicação de todas as informações incluídas na TKI. O dito a seguir descreve como a TKI é atualizada nos quatro casos se- guintes. No primeiro caso (Caso 1), uma trilha é deletada. No segundo caso (Caso 2) uma trilha é deletada e uma nova trilha é gravada. No terceiro caso (Caso 3) duas fora de uma pluralidade de trilhas são selecionadas e combi- nadas em uma única trilha. Finalmente, no quarto caso (Caso 4), uma trilha é dividida para produzir duas trilhas. O dito a seguir descreve o caso 1 onde uma trilha é deletada.

As FIGS 27A e 27B apresentam a deleção parcial de uma trilha. O exemplo nas Figuras 27A e 27B correspondem ao Gerente de Trilha apresentado na Figura 19 e assume que o usuário indicou a deleção parcial da Trilha B. O AOB correspondendo à Trilha B é gravado no ''AOB002.SA1", que está associado com a TKI N9 2. Isto significa que a deleção do "AOB002.SA1" é acompanhada pelo estabelecimento de "Não-Utilizado" dentro do TKI_BLK_ATR da TKI N9 2. Este estado onde "AOB002.SA111 foi deletado e "Não-Utilizado" foi estabelecido dentro do TKI_BLK_ATR da TKI N9 2 é apresentado na Figura 27B. Desde que "AOB002.SA1" foi deletado, a região que foi anteriormente ocupada por "AOB002.SA1" é liberada para tornar-se uma região não-utilizada. Como mencionado acima, a outra alte- ração é que "Não-Utilizado" é estabelecido para o TKI_BLK_ATR de TKI N9 2. {17-5_22-17_28A,B} Designação das TKIs quando um novo AOB é gra- vado O dito a seguir descreve o Caso 2 onde uma nova trilha é gra- vada após a deleção de uma trilha. A Fiyura 2ôA apresenta o Gerente de Tríiha após a deieçâo das trilhas ter sido executada várias vezes. Como apresentado na Figura 28A, se as trilhas correspondendo a TKI N9 2, TKI N9 4, TKI NQ 7 e TKI N9 8 tive- rem sido deletadas, então "Não-Utilizado" é estabelecido no TKI_BLK_ATR desta TKI. Ao mesmo tempo que os arquivos AOB são deletados do mesmo modo que os arquivos de dados convencionais, o Gerente de Trilha é atua- lizado por simplesmente se estabelecer "Não-Utilizado" no TKI_BLK_ATR da TKI correspondente. Isto significa que as TKIs cujo TKI_BLK_ATRs são estabelecidos para "Não-Utilizado" podem aparecer em lugares diferentes no Gerente de Trilha.

A Figura 28B apresenta como uma nova TKI e um arquivo AOB são gravados quando uma TKI cujo TKI_BLK_ATR é "Não-Utilizado" está presente no Gerente de Trilha. Como na Figura 28A, a TKI N9 2, TKI N9 4, TKI N9 5, TKI N9 7 e a TKI N9 8 na Figura 28B são estabelecidas como "Não-Utilizado".

Na Figura 28B, a nova trilha a ser gravada é composta de qua- tro AOBs. As TKIs não-utilizadas para gravar estes AOBs são determinadas de acordo com os DPL_TK_SRPs ou podem ser livremente escolhidas. No exemplo presente, as TKIs não-utilizadas numeradas TKI N9 2, TKI N9 4, TKI N9 4 e TKI N9 8 são utilizadas para gravar as TKIs para a nova trilha.

Desde que quatro AOBs compõem uma trilha, "Cabeçalho da Trilha" é estabelecido no TKI_Bl_K_ATR da TKI N9 2, "Meio da Trilha" é es- tabelecido no TKI_BLK_ATR da TKI N- 4 e da TKI N9 7 e "Fim da Trilha" é estabelecido no TKI_BLK_ATR da TKI N9 8. O TKI_LNK_PTR em cada uma das quatro TKIs, TKI N9 2, TKI N9 4, TKI N9 7 e TKI N9 8, utilizado para com- por a nova Trilha D é estabelecido de modo a apresentar a TKI formando a próxima parte da Trilha D, de modo que como apresentado pelas setas TL2, TL4 e TL7, TKI N9 4 é estabelecido no TKI_LNK_PTR da TKI N9 2, TKI N9 7 é estabelecida no TKI_LNK_PTR da TKI N9 4 e TKI N9 8 é estabelecida no TKI_LNK_PTR da TKI N9 7.

Após isto, os arquivos "AOB002.SA1", "AOB004.SA1", "AOB007.SA1" e "AOB008.SA1" possuindo os mesmo números que a TKI N9 2, TKi Ns 4, TKi N9 7, TKi N9 8 sáo produzidos e os quatro AOBs com- pondo a Trilha D são armazenados nestes quatro arquivos.

Por de forma apropriada estabelecer os TKI_LNK_PTRs e os TKI_BLK_ATRs, esta quarta trilha Trilha D pode ser gerenciada utilizando- se a TKI N9 2, TKI N9 4, TKI N9 7 e a TKI N9 8.

Como descrito acima, quando uma nova trilha é gravada no cartão de memória flash 31, as TKIs no Gerente de Trilha que são estabele- cidas para "Não-Utilizadas" são designadas como as TKIs a serem utiliza- das para as trilhas que são para serem de maneira nova gravadas. {17-5_22-18_29A,B} Estabelecimento da TKI quando Combinando duas Trilhas O dito a seguir descreve a atualização da TKI quando combina- do-se trilhas (Caso 3).

As FIGS 29A e 29B apresentam como as TKIs são estabeleci- das quando duas trilhas são combinadas para produzir uma nova trilha. O exemplo na Figura 29A utiliza o mesmo Gerente de Trilha que o da Figura 19 e apresenta o caso quando o usuário executa uma operação de edição para combinar a Trilha C com a Trilha E em uma única trilha.

Neste caso, os AOBs que correspondem à Trilha C e à Trilha E são gravados nos arquivos AOB "AOB003.SA1" e "AOB008.SA1" que cor- respondem à TKI N9 3 e ã TKI N9 8, de modo que os TKI_BLK_ATRs da TKI N9 3 e da TKI N9 8 são regravados. A Figura 29B apresenta a TKI_BLK_ATR destas TKIs após a regravação. Na Figura 29A, os TKI_BLK_ATRs das TKI N9 3 e TKI N9 8 são gravados como "Trilha", mas na Figura 29B, o TKI_BLK_ATR da TKI N9 3 é regravada como "Cabeçalho da Trilha" e o TKI_BLK_ATR da TKI N9 8 é regravado como "Fim da Trilha".

Por regravar os TKI_BLK_ATRs deste modo, os arquivos AOB "AOB003.SA1" e "AOB008.SA1" que correspondem à TKI N9 3 e a TKI N9 8 terminam sendo tratados como partes de uma única trilha, a nova Trilha C.

Esta operação é realizada pelo TKI_LNK_PTR da TKI N9 3 sendo regravado para indicar TKI N9 8.

Deve ser particularmente observado aqui que enquanto os TKi_BLK_ATRs na TKi são regravados, nenhum processamento é executa- do para fisicamente combinar os arquivos AOB "AOB003.SA1" com o "AOB008.SA1". Isto é porque cada um dos arquivos AOB são criptografados utilizando FileKeys diferentes, de modo que quando combinando-se os ar- quivos AOB, seria necessária executar dois processos para cada arquivo AOB para primeiro decriptografar o arquivo AOB criptografado e então crip- tografar de novo o resultado, resultando em uma carga de processamento excessiva. Além disso, um arquivo AOB combinado deste modo seria cripto- grafado utilizando uma única FileKey, o que tornaria a trilha combinada me- nos segura do que as trilhas utilizadas para produzir a mesma. A TKI é originalmente projetada de modo a suprimir o tamanho da TKTMSRT, de modo que a combinação física dos arquivos AOB por uma operação de edição também teria o risco de que a TKI torne-se muito gran- de.

Pelas razões dadas acima, as operações de edição que combi- nam trilhas deixam os arquivos AOB em seu estado criptografado e são rea- lizadas por simplesmente alterar os atributos dados pelos TKI_BLK_ATRs. {17-5_22-18_29A,B-1_30, 31} Condições Que Devem ser Satisfeitas Quando Combinando-se as Trilhas A combinação das trilhas é executada por se alterar os atributos TKI_BLK_ATR como descrito acima, mas os AOBs que estão incluídos nas trilhas combinadas devem satisfazer as condições dadas abaixo.

Uma primeira condição é que o AOB que é para compor uma última parte de uma nova trilha necessita possuir os mesmo atributos de áudio (modo de codificação do áudio, taxa de bits, freqüência de amostra- gem, número de canais, etc.) que o AOB que é para compor a primeira parte da nova trilha. Se um AOB possui atributos de áudio diferentes do AOB pre- cedente ou que sucede, o aparelho de execução terá que reinicializar a operação do decodificador, o que torna difícil a execução sem costuras (isto é, ininterrupta) dos AOBs. A segunda condição é que na trilha produzida pela combinação, três ou mais AOBs sejam compostos de somente AOB_ELEMENTs cujo número de AOB_FRAMEs esteja abaixo do número requerido para um "FNs_Middle_TMSRTE" não poder ser ligado.

Os AOBs são classificados em dois tipos dependendo de se pelo menos um AOB_ELEMENT inclui o mesmo número de AOB_FRAMEs que o número de quadros estipulado para um "FNs_Middle_TMSRTE". O AOB Tipo 1 inclui pelo menos um AOB_ELEMENT tendo este número de AOB_FRAMEs, enquanto o AOB Tipo 2 não inclui um AOB_ELEMENT pos- suindo este número de AOB_FRAMEs.

Em outras palavras, os AOB_ELEMENTs em um AOB Tipo 2 possui menos AOB_FRAMEs do que "FNs_Middle_TMSRTE" e a segunda condição estipula que três AOBs Tipo 2 não podem ser ligados juntos. A razão para a segunda condição é como se segue. Quando o aparelho de execução lê os AOBs sucessivamente, de preferência é para um número de AOB_FRAMEs suficiente para acumular no buffer do apare- lho de execução, no entanto, isto não pode ser realizado quando existem AOBs Tipo 2 consecutivos. Em tal caso, um fluxo insuficiente é provável de ocorrer no buffer do aparelho de execução, de modo que a execução ininter- rupta pelo aparelho de execução não pode ser mais garantida. Portanto, de modo a evitar tais fluxos insuficientes, a segunda condição estipulando que três ou mais AOBs Tipo 2 não podem ser ligados continuamente é utilizada.

A Figura 30 apresenta um AOB Tipo 1, enquanto a Figura 30B apresenta dois exemplos de AOBs Tipo 2. Na Figura 30B, ambos AOBs são compostos de menos do que dois AOB_ELEMENTs, com nenhum dos AOB_ELEMENTs incluindo um número de AOB_FRAMEs que seja estabe- lecido para um ,lFNs_Middle_TMSRTE". Desde que a ausência de um AOB_ELEMENT com o número de AOB_FRAMEs estabelecido para um "FNs_Middle_TMSRTE" é a condição pela qual um AOB é classificado como um AOB do Tipo 2, isto significa que todos os AOBs apresentados neste desenho são classificados como AOBs do Tipo 2.

Na Figura 31 A, uma combinação de AOBs do Tipo 1 + Tipo 2 + Tipo 2 + Tipo 1 em uma única trilha é apresentada. Como esta combinação não envolve a ligação de três AOBs do Tipo 2, estes AOBs podem ser liga- dos para formar uma única trilha. A Figura 31 apresenta a ligação dos AOBs do Tipo 1 + Tipo 2 + Tipo 2 + Tipo 2 + Tipo 1 em uma única trilha. Esta combinação resultaria em existirem três AOBs do Tipo 2 consecutivos e desse modo é proibida. {17-5_22-18_29A,B-1_32} Combinação das Trilhas Com Respeito às Combinações dos AOBs do Tipo 1 e do Tipo 2 Na combinação dos AOBs em uma única trilha apresentada na Figura 31 A, se o último AOB na primeira trilha for um AOB do Tipo 1, a combinação pode ser executada independente de se a primeira parte desta trilha é um AOB do Tipo 1 ou um AOB do Tipo 2. A Figura 32A apresenta o caso onde o último AOB na primeira trilha é um AOB do Tipo 1 e o primeiro AOB na próxima trilha também é um AOB do Tipo 1. A Figura 32B apresenta o caso onde o último AOB na primeira trilha é um AOB do Tipo 1 e o primei- ro AOB na próxima trilha é um AOB do Tipo 2. Como a segunda condição está satisfeita em ambos os casos, as trilhas ilustradas podem ser combina- das em uma única trilha.

Quando o último AOB na primeira trilha é um AOB do Tipo 2 e o AOB precedente na primeira trilha é um AOB do Tipo 1, esta primeira trilha pode ser combinada com uma trilha seguinte que começa com um AOB do Tipo 1 independente de se o primeiro AOB na primeira trilha é um AOB do Tipo 1 ou um AOB do Tipo 2. A Figura 32C apresenta o caso onde a primeira trilha termina com um AOB do Tipo 1 e um AOB do Tipo 2 nesta ordem e a segunda trilha começa com um AOB Tipo 1. A Figura 32S apresenta o caso onde a primei- ra trilha termina com um AOB do Tipo 1 e um AOB do Tipo 2 nesta ordem e a segunda trilha começa com um AOB do Tipo 2 e um AOB do Tipo 1 nesta ordem. Como a segunda condição está satisfeita em ambos os casos, as trilhas ilustradas podem ser combinadas em uma única trilha.

Quando a primeira trilha termina com um AOB do Tipo 2 e o AOB imediatamente precedente também é um AOB do Tipo 2, esta primeira trilha pode ser combinada com a trilha seguinte que começa com um AOB do Tipo 1. A Figura 32E apresenta o caso onde a primeira trilha termina com dois AOBs do Tipo 2 e a segunda trilha começa com um AOB do Tipo 1.

Como a segunda condição está satisfeita neste caso, as trilhas ilustradas podem ser combinadas em uma única trilha. Deste modo, quando duas tri- lhas são para ser combinadas, é executada uma investigação para ver se as duas trilhas satisfazem as primeira e segunda condições e as duas trilhas somente são combinadas se elas forem julgadas como satisfazendo estas condições. O dito a seguir descreve a atualização da TKI para o caso 4, onde uma trilha é dividida. {17-5_22-19_33A,B> Estabelecimentos para a TKI quando uma Trilha é Dividida As Figuras 33A e 33B apresentam exemplos de quando uma única trilha é para ser dividida para produzir duas novas trilhas. Para estes exemplos, o conteúdo do Gerente de Trilha é o mesmo que na Figura 27, com o usuário sendo assumido como tendo executado uma operação de edição que divide a Trilha C em duas novas trilhas, Trilha C e Trilha F.

Quando a Trilha C é para ser dividida em uma nova trilha Trilha C e Trilha F, o arquivo AOB "AOB002.SA1" é gerado correspondendo à Trilha F. A

Figura 33A apresenta que a TKI N9 2 é estabelecida como "Não-Utilizada", com esta TKI N9 2 sendo designada como o arquivo AOB mais recente ge- rado "AOB002.SA1". {17-5_22-19_33A, B-1_34A, B} Atualização das Entradas do Diretório e dos Valores FAT

Quando o arquivo AOB "AOB003.SA1" é dividido para produzir o "AOB002.SA1", as entradas do diretório e os valores FAT têm que ser atualizados. Esta atualização é explicada abaixo. A Figura 34A apresenta como a Entrada do Diretório SD-Áudio no Diretório SD-Áudio ao qual o ar- quivo AOB "AOB003.SA1" pertence é gravada antes do arquivo ser dividido. O arquivo "AOB003.SA1" é dividido em uma pluralidade de partes que são armazenadas nos clusters 007, 008, 009, 00A.00D, 00E.

Neste caso, o primeiro número do cluster para o arquivo AOB "AOB003.SA1" dado na entrada do diretório é gravado como "007". Os valo- res (008), (000), (00A), .... (GOD), (G0E) também sãu gravados nos vaiores FAT 007, 008, 009, 00A, ..., 00D correspondendo aos clusters 007, 008, 009, 00A, ..., 00D.

Quando o arquivo AOB "AOB003.SA1" é dividido de modo que sua última parte torna-se o novo arquivo AOB "AOB002.SA1", um "nome de arquivo", uma "extensão do nome do arquivo" e um "número dos primeiros clusters no arquivo" para o novo arquivo AOB "AOB002.SA1" são adiciona- dos para a entrada do diretório SD-Áudio. A Figura 34B apresenta como a Entrada do Diretório SD-Áudio no Diretório SD-Áudio para a qual o arquivo AOB "AOB003.SA1" pertence é gravada após o arquivo AOB "AOB003.SA1" ter sido dividido.

Na Figura 34B, o cluster 00F armazena uma cópia do cluster 00B que inclui o limite indicado pelo usuário quando dividindo o arquivo. As partes do arquivo AOB "AOB002.SAr que seguem a parte incluída no cluster 00B são armazenadas nos clusters 00C, 00D, 00E como antes. Des- de que a primeira parte do arquivo AOB "AOB002.SAT1 é armazenada no cluster 00F e as partes restantes são armazenadas nos clusters 00C, 00D, 00E, "00F" é gravado dentro do "número do primeiro cluster no arquivo" para o novo arquivo AOB "AOB002.SA1", enquanto (00C), (00D), (00E) são gravados dentro dos valores FAT 00F, 00C, 00D, 00E correspondendo aos clusters OOF, OOC, OOD e OOE. {17-5_22-19_33A,B-2_35A,B} Estabelecimento dos Campos de Informa- ção na TKI

O dito a seguir descreve como os campos de informação na TKI são estabelecidos para o arquivo AOB "AOB002.SA1" uma vez que este arquivo tenha sido obtido por se atualizar as entradas do diretório e os valo- res FAT. Quando gerando uma TKI para uma trilha dividida, existem dois tipos de campos de informação na TKI. Estes são (1) a informação que pode ser copiada a partir da TKI original e (2) a informação obtida por se atualizar a informação na TKI original. A TKTXTI_DA e o ISRC são do primeiro tipo, enquanto o BIT, a TKTMSRT e outros campos de informação são do último tipo. Desde que ambos os tipos de informação existem, a presente concreti- zação yem uma TKi para uma iriiha dividida por copiar a TKi originai para produzir um gabarito para a nova TKI e então dividindo/atualizando a TKTMSRT e o BIT neste gabarito e atualizando os campos de informação restantes. A Figura 35A apresenta o caso onde um AOB_FRAME em um AOB é dividido. O primeiro nível na Figura 35A apresenta os quatro AOB_ELEMENTs, AOB_ELEMENT N9 1, AOB_ELEMENT N9 2, AOB_ELEMENT N9 3 e o AOB_ELEMENT N9 4. Os comprimentos dos da- dos destes AOB_ELEMENTs são estabelecidos na TKTMSRT como as quatro TMSRT_entry N9 1, N9 2, N9 3 e N9 4. Se o limite bd1 para a divisão for estabelecido no AOB_ELEMENT N9 2 na Figura 35A, o AOB_ELEMENT N9 2 é dividido em uma primeira região (1) composta dos quadros localiza- dos antes do limite bd1 e de uma segunda região (2) composta dos quadros localizados depois do limite bd1. A Figura 35B apresenta os dois AOBs AOB N9 1 e AOB N9 2 obtidos por se dividir o AOB a meio do caminho do AOB_ELEMENT N9 2.

{17-5_22-19_33A,B-3_36} Estabelecimento do BIT A Figura 36 apresenta como o BIT é estabelecida quando um AOB é dividido como apresentado na Figura 35. O AOB apresentado na Fi- gura 35 é dividido no limite bd1. O AOB N9 1 produzido por esta divisão in- clui os dois AOB_ELEMENTs AOB_ELEMENT N2 1 e AOB_ELEMENT N2 2, enquanto o outro AOB N2 2 produzido por esta divisão inclui os três AOB_ELEMENTs, AOB_ELEMENT N2 1, AOB_ELEMENT N2 2 e AOB_ELEMENT N2 3.

Na Figura 36, também foram dados para estes AOB_ELEMENTs indicadores triangulares para apresentar os estabelecimentos das TMSRT_entrys incluídas nas TKIs correspondendo a estes AOBs. A expli- cação primeiro irá focar o AOB N2 1 que é obtido por esta divisão. O

AOB_ELEMENT N2 1 e o AOB_ELEMENT N2 2 que estão incluídos no AOB N2 1 ocupam o cluster 007 até o cluster 00A, de modo que o AOB N2 1 é manipulado como sendo o composição do cluster 007 com o cluster 00A. o AOB_ELEMENT N2 2 no AOB N2 1 possui um comprimento dos dados que termina não no íim uo cíusíer 00A, mas no iimite bai que está presente dentro do cluster 00A, de modo que o SZ_DATA para o AOB N2 1 é dado como a quantidade de dados da região mdO até o limite bd1 no cluster 00A. O "FNs_1st_TMSRTE" para o AOB N2 1 é o mesmo que antes da divisão, enquanto o "FNs_Last_TMSRTE" para o AOB N2 1 difere do valor utilizado antes da divisão pelo fato de que ele agora indica o número de quadros a partir do início do AOB_ELEMENT N2 2 antes da divisão até o limite bd1. O dito a seguir descreve o AOB N2 2 que é obtido por esta divi- são. O AOB_ELEMENT N2 1, AOB_ELEMENT N2 2 e AOB_ELEMENT N2 3 que estão incluídos no AOB N2 2 ocupam o cluster 00B até o cluster 007. O cluster 00F inclui uma cópia do conteúdo do cluster 00A. A razão pela qual o cluster 00F armazena uma cópia do cluster 00A é que o cluster 00A está ocupado pelo AOB_ELEMENT N2 2 no AOB N2 1, de modo que é necessá- rio designar um cluster diferente para o AOB_ELEMENT N21 no AOB N2 2. O AOB_ELEMENT N2 1 no AOB N2 2 possui um comprimento dos dados que começa não no começo do cluster 00F, mas no limite bd1 que está presente dentro do cluster 00F, de modo que o SZ_DATA para o AOB N2 2 é dado como a quantidade de dados do início do cluster 00B até o ponto médio através do cluster 00E mais o comprimento dos dados da parte do cluster 00F ocupada pelo AOB_ELEMENT N2 1. A parte do AOB_ELEMENT N9 2 no AOB N9 1 que está incluída na cópia do cluster 00A armazenado no cluster 00F necessita ser excluída do AOB N9 2, de modo que o campo DATA_Offset no BIT do AOB N9 2 é estabelecido no tamanho da parte do AOBJELEMENT N9 2 no AOB N9 1 incluída no cluster 00F.

Como pode ser visto a partir da Figura 36, a divisão do AOB resulta em somente o AOB_ELEMENT que inclui o limite para a divisão sendo dividido em dois e em outros AOB_ELEMENTs posicionados antes e depois do AOB_ELEMENT dividido permanecendo inalterado. Como resul- tado, o "FNs_Last_TMSRTE" do AOB N9 2 é estabelecido com o mesmo valor para o "AOB_ELEMENT N9 4" antes da divisão e o "FNs_1 st_TMSRTE" do AOB N9 2 é estabelecido no AOB_ELEMENT N9 1 do AOB Ns 2, ou seja, o número de quadros incluídos na parte que segue ao limite uma vez que o AOB_ELEMENT N9 2 tenha sido dividido.

{ 17-5_22-19_33A,B-4_37} Estabelecimento do BIT A Figura 37 apresenta um exemplo mais específico das altera- ções nas BITs como resultado da divisão de uma trilha. O lado esquerdo da Figura 37 apresenta um exemplo dos estabelecimentos do BIT antes da di- visão. Neste BIT, o DATA_Offset é estabelecido para "X", o SZ_DATA é estabelecido para "52428" e o TMSRTE_Ns é estabelecido para "η". O FNs_1st_TMSRTE é estabelecido para "80 quadros", o FNs_Middle_TMSRTE é estabelecido para "94 quadros" e o FNs_Last_TMSRTE é estabelecido para "50 quadros". O lado direito da Figura 37 apresenta os estabelecimentos de duas BITs produzidas pela divisão de uma trilha. Quando o AOB correspon- dendo à BIT no lado esquerdo da Figura 37 é dividido como apresentado na Figura 35A, o DATA_Offset no BIT da primeira trilha produzido pela divisão é estabelecido para "X" como a trilha antes da divisão, o SZ_DATA é atuali- zado para o comprimento dos dados "Q" a partir do início até o ponto de divisão Q e o TMSRTE_Ns é estabelecido para "k" que apresenta o número de TMSRT_entrys a partir da primeira TMSRT_entry até a kâ TMSRT_entry. O FNs_1st_TMSRTE e o FNs_Middle_TMSRTE são respectivamente esta- belecidos para "80" e "94" quadros do mesmo modo que o BIT antes da di- visão, mas desde que o AOB_ELEMENT final no AOB da primeira trilha produzida pela divisão inclui "p" AOB_FRAMEs, o FNs_Last_TMSRTE é estabelecido para "p quadros".

No BIT da segunda trilha produzida pela divisão, o "DATA_Offset" é estabelecido para "R", o "SZ_DATA" é estabelecido para (SZ N9 DATA original "52428" - comprimento dos dados até o ponto de divi- são Q) e o TMSRTE_Ns é estabelecido para "n-k+1" produzido por se adici- onar um (para a kâ TMSRT_entry que é mais recentemente adicionada como um resultado da divisão) para o número de TMSRT_entrys a partir da kã TMSRT_entry até a nâ TMSRT_entry. O FNs_Middle_TMSRTE e p FNs_Last_TMSRTE são estabele- cidos para os mesmus vaiores que o BíT antes da divisão, ou seja, ::94 qua- dros" e "50 quadros", respectivamente. O primeiro AOB_ELEMENT no AOB desta segunda trilha inclui "94-p" AOB_FRAMEs, de modo que "94-p" é estabelecido no FNs_1 st_TMSRTE do BIT correspondendo a esta trilha.

{17-5_22-19_33A,B-5_38} Estabelecimento do BIT A Figura 38 apresenta a TKTMSRT após a divisão. O dito a se- guir explica primeiro os estabelecimentos da TMSRT. A TMSRT da primeira trilha inclui as TMSRT_entrys da primeira TMSRT_entry do AOB antes da divisão até a kâ TMSRT_entry, ou seja, as TMSRT_entrys N9 1 até NQ k.

Deve ser observado aqui que o AOB_ELEMENT N9 k que inclui o limite para a divisão somente inclui a região (1), de modo que a kã TMSRT_entry somente inclui um tamanho dos dados correspondendo a esta região (1). A TMSRT da segunda trilha inclui as TMSRT_entrys a partir da ks TMSRT_entry do AOB antes da divisão até a nâ TMSRT_entry, ou seja, as TMSRT_entrys N9 k até N9 n. Deve ser observado aqui que o AOB_ELEMENT N9 k que inclui o limite para a divisão somente inclui a regi- ão (2), de modo que a kâ TMSRT_entry somente inclui um tamanho dos da- dos correspondendo a esta região (2). A cópia da TKI é acompanhada pela divisão e pela atualização da TKTMSRT e do BIT e uma vez que a informação restante tenha sido atu- alizada, as TKIs para as novas trilhas produzidas pela divisão estarão com- pletas. Do mesmo modo que quando combinando-se as trilhas, os arquivos AOB não são decriptografados, de modo que as duas trilhas podem ser pro- duzidas por se dividir um arquivo AOB em seu estado criptografado. Desde que a divisão de um arquivo AOB não envolve a decriptação e a nova crip- tografia, a carga de processamento da divisão de uma trilha pode ser supri- mida. Isto significa que as trilhas podem ser editadas mesmo por um apare- lho de execução com capacidade de processamento limitada.

Isto completa a explicação da TKI. O dito a seguir descreve as Listas de Execução. {17-6} Gerente de Lista de Execução Como apreseniaao peias iinha tracejadas n5 na Figura 17, o Gerente de Lista de Execução apresentado é composto da Informação de Execução do Gerente de Lista (PLMGI) para gerenciar as Listas de Execu- ção armazenadas no cartão de memória flash 31, a Informação Preestabe- lecida da Lista de Execução (DPLI) para gerenciar todas as trilhas armaze- nadas no cartão de memória flash 31 e a Informação da Lista de Execução (PLI) N9 1, N9 2, N9 3, N9 4, ..., N9 m. Cada PLI é a informação para uma Lista de Execução definida pelo usuário. Como apresentado pelas linhas tracejadas h6, a DPLI é composta da Informação Geral Preestabelecida da Lista de Execução (DPLGI) e dos Ponteiros Preestabelecidos de Pesquisa da Trilha da Lista de Execução (DPL_TK_SRP) N9 1, N9 2, N9 3, N9 4, ..., N9 m. Como apresentado pelas linhas tracejadas h7, cada PLI é composta da Informação Geral da Lista de Execução (PLGI) e dos Ponteiros de Pesquisa de Trilha da Lista de Execução (PL_TK_SRP) N9 1, N9 2, N9 3, N9 4...N9 m. A DPLI referida aqui difere de cada PLI do seguinte modo. En- quanto a DPLI tem que indicar todas as trilhas armazenadas no cartão de memória flash 52, uma PLI não tem que possuir esta restrição e pode indi- car qualquer número de trilhas. Isto abre várias possibilidades para o usuá- rio. Como exemplos representativos, o usuário pode gerar a Informação da Lista de Execução indicando somente suas trilhas favoritas e armazenar esta Informação da Trilha de Execução no cartão de memória flash 31, ou pode ter uma aparelho de execução automaticamente gerando a Informação da Lista de Execução que somente indica as trilhas de um certo gênero, fora de uma pluralidade de trilhas armazenadas no cartão de memória flash 31 e armazenar a informação da Lista de Execução resultante no cartão de me- mória flash 31. {17-7_18} Número de Listas de Execução e Seus Tamanhos dos Dados Como apresentado na Figura 18, um máximo de 99 Listas de Execução pode ser armazenado em um cartão de memória flash 31. O ta- manho dos dados combinado da Informação do Gerente de Lista de Execu- ção (PLMGI) e a Informação da Lista de Execução Preestabelecida (DPLI) também é fixa em 2.560 bytes. Cada rLi possui um comprimento fixo de 512 bytes. A "DPL_TK_SRP" incluída na Informação de Lista de Execução Pre- estabelecida inclui um "DPL_TK_ATR" e um "DPL_TKIN". Por outro lado, o campo "PL_TK_SRP" incluído em uma PLI inclui somente um "PL_TK_SRP". O formato dos campos DPL_TK_ATR, DPL_TKIN e PL_TKIN é apresentado na Figura 39.

{17-8_39-1} Formato do DPL_TK_SRP A Figura 39A apresenta o formato do DPL_TK_SRP. Na Figura 39A, o DPL_TKIN é gravado nos 0Θ até o 9S bits no DPL_TK_SRP, enquanto o DPL_TK_ATR é gravado no 13s até 0 15s bit. O 10e até o 12s bits no DPL_TK_SRP são reservados para uso futuro. O número da TKI é gravada no DPL_TKIN que ocupa o 0e até o 9S bits no DPL_TK_SRP. Isto permite a uma TKI ser especificada.

{17-9_39B> Formato do PL_TK_SRP A Figura 39B apresenta o formato do PL_TK_SRP. Este é um campo de dez bits no qual o PL_TKIN, ou seja, um número da TKI, é grava- do.

{17-8_39A-2} Composição do DPL_TK_ATR

As linhas tracejadas h51 e h52 que se estendem do DPL_TK_ATR na Figura 39A apresentam um estabelecimento exemplo do DPL_TK_ATR. Como pode ser visto a partir deste desenho, o DPL_TK_ATR é estabelecido para um DPL_TK_SRP do mesmo modo que o TKI_BLK_ATR é estabelecido para uma TKI, ou seja, o DPL_TK_ATR é es- tabelecido como um entre "Trilha", "Cabeçalho da Trilha", "Ponto Médio da Trilha" e "Fim da Trilha".

Em mais detalhes, quando a TKI indicada pelo TKIN é utilizada e um objeto de Áudio (AOB) correspondendo a uma trilha completa é grava- do no arquivo AOB correspondendo à TKI indicada (isto é, quando o TKI_BLK_ATR da TKI é "Trilha"), o valor "00b" é estabelecido no "DPL_TK_ATR".

Quando a TKI indicada pelo TKIN é utilizada e um Objeto de Áudio (AOB) correspondendo a somente o início de uma trilha é gravado no arquive AOB correspondendo à TKI indicada (isto é, quando o TKI_BLK_ATR da TKI é "Cabeçalho da Trilha"), o valor "001b" é estabeleci- do no "DPL_TK_ATR". Quando a TKI indicada pelo TKIN é utilizada e um Objeto de Áudio (AOB) correspondendo a uma trilha da parte do meio é gra- vado no arquivo AOB correspondendo à TKI indicada (isto é, quando o TKI_BLK_ATR da TKI é "Ponto Médio da Trilha"), o valor "010b" é estabele- cido no "DPL_TK_ATR". Quando a TKI indicada pelo TKIN é utilizada e um Objeto de Áudio (AOB) correspondendo a uma parte final de uma trilha é gravado no arquivo AOB correspondendo à TKI indicada (isto é, quando o TKI_BLK_ATR da TKI é "Fim da Trilha", o valor "011b" é estabelecido no "DPL_TK_ATR".

Inversamente, quando a TKI indicada pelo TKIN não é utilizada e a região da TKI é simplesmente estabelecida, o que corresponde a quan- do uma TKI foi deletada (isto é, quando o TKI_BLK_ATR da TKI é "Não- Utilizado"), o valor "100b" é estabelecido no DPL_TK_ATR.

Quando a TKI indicada pelo TKIN é não-utilizada e nenhuma região de TKI foi estabelecida, ou seja, quando uma TKI está em um estado inicial, o valor "101b" é estabelecido no "DPL_TK_ATR".

Desde que o número de uma TKI é gravado no DPL_TKIN, é claro qual da pluralidade de TKIs corresponde a cada DPL_TK_SRP. A po- sição do DPL_TK_SRP na Informação Preestabelecida da Lista de Execu- ção apresenta quando o AOB correspondendo à TKI que por sua vez cor- responde ao DPL_TK_SRP irá ser executada, isto é, a posição ordinal do AOB na Lista de Execução Preestabelecida. Como resultado, a ordem dos itens DPL_TK_SRP na Lista de Execução Preestabelecida denota a ordem na qual uma pluralidade de trilhas será executada, ou em outras palavras, determina a ordem de execução das trilhas. {17-9_40-1} Inter-relacionamento Entre a Informação da Lista de Execu- ção Preestabelecida, a TKI e os arquivos AOB A Figura 40 apresenta a inter-relação entre a Informação da Lista de Execução Preestabelecida, a TKI e os arquivos AOB. O segundo, terceiro e quarto níveis neste desenho são os mesmos que o primeiro, se- gundo e terceiro níveis na Figura 19 e desse modo apresentam um Gerente de Trilha incluindo oito TKIs e oito arquivos AOB. A Figura 40 difere da Fi- gura 19 pelo fato de que uma caixa apresentando a Informação da Lista de Execução Preestabelecida é dada no primeiro nível. As oito pequenas divi- sões nesta caixa apresentam os oitos DPL_TK_SRP incluídos na Informa- ção de Lista de Execução Preestabelecida. A parte superior de cada divisão apresenta o DPL_TK_ATR, enquanto a parte inferior apresenta o DPL_TKIN.

Como apresentado pelas setas DT1, DT2, DT3, DT4, ..., na Fi- gura 40, o DPL_TK_SRP ηθ 1 e a TKI ns 1 estão relacionados, como estão os DPL_TK_SRP ns2ea TKI η®-2, o DPL_TK_SRP n9 3 e a TKI n9 3 e o DPL_TK_SRP n54eaTKI n°4.

Olhando os campos DPL_TK_ATR no DPL_TK_SRP, pode ser visto que "Trilha" foi estabelecido para cada um dos DPL_TK_SRP ns 1, DPL_TK_SRP ne 2, DPL_TK_SRP n9 3e DPL_TK_SRP ne 8. Em outras pa- lavras, as quatro combinações DPL_TK_SRP ns 1 -» TKI n5 1 ("AOB001.SA1"), DPL_TK_SRP ηθ 2 -> TKI n9 2 ("AOB002.SA1"), DPL_TK_SRP n9 2 -» TKI ne 2 ("AOB002.SA1"), DPL_TK_SRP n9 3 TKI n9 3 ("AOB003.SA1"), DPL_TK_SRP ns 8 -» TKI n9 8 ("AOB008.SA1"), cor- responde à quatro trilhas separadas.

Enquanto isto, nenhum dos DPL_TK_SRP ns4, DPL_TK_SRP

ns 5, DPL_TK_SRP ns 6 e DPL_TK_SRP ns 7 possui uma DPL_TK_ATR estabelecido como "Trilha". Ao invés disso, o DPL_TK_SRP ns 4 do DPL_TK_ATR é estabelecido como "Cabeçalho da Trilha", o DPL_TK_ATR do DPL_TK_SRP ηθ 7 é estabelecido como "Fim da Trilha" e os DPL_TK_ATRs do DPL_TK_SRP n° 5 e DPL_TK_SRP ns 6 são estabeleci- dos como "Ponto Médio da Trilha".

Isto significa que a TKI ne 4 ("AOB004.SA1"), que está relacio- nada com o DPL_TK_SRP ns 4, é o início da trilha, a TKI ne 5 ("AOB005.SA1") e a TKI n5 6 ("AOB006.SA1"), que estão respectivamente relacionadas com DPL_TK_SRP ns 5 e com o DPL_TK_SRP ns 6, são as partes médias de uma trilha e a TKI ns 7 ("AOB007.SA1"), que está relacio- nada com o DPL_TK_SRP ns 7, é o fim de uma trilha.

As entradas DPL_TK_SRP na Lista de Execução Preestabeleci- da apresentam em que ordem os AOBs correspondendo a cada TKI são para ser executados. Os DPL_TKINs das DPL_TK_SRP ne 1, nô 2, ns 3, ne 4, ..., ne 8 na Lista de Execução Preestabelecida da Figura 40 indicam as TKI ne 1, ne 2, ns 3, ne 4, ..., ne 8. Como apresentado pelas setas (1), (2), (3), (4), ..., (8), o arquivo AOB "AOB001.SA1" correspondendo à TKI ne 1 será exe- cutado primeiro, "AOB002.SA1" correspondendo à TKI ne 2 será executado em segundo, "AOB003.SA1" correspondendo à TKI ne 3 será executado em terceiro e o "AOB004.SA1" correspondendo à TKI ns 4 será executado em quarto. {17-10_41> Estabelecimentos Exemplos para a Lista de Execução Pre- estabelecida e para a Informação da Lista de Execução A Figura 41 apresenta estabelecimentos exemplo para a Lista de Execução Preestabelecida e para a Informação da Lista de Execução utilizando a mesma notação que na Figura 40. Na Figura 41, a caixa no pri- meiro nível apresenta a Lista de Execução Preestabelecida, enquanto as três caixas no segundo nível apresentam as PLIs.

As pequenas divisões na caixa apresentando as Listas de Exe- cução Preestabelecidas apresentam oito valores do DPL_TK_SRP incluídos na Lista de Execução Preeslabelecida, enquanto as pequenas divisões nas caixas ilustrando cada PLI apresentam três ou quatro valores de PL_TK_SRP. O estabelecimento do TKIN de cada DPL_TK_SRP incluído na Informação da Lista de Execução Preestabelecida é o mesmo que na Figura 40. Entretanto, os estabelecimentos da TKIN do PL_TK_SRP incluído em cada PLI são completamente diferentes daqueles na DPL_TK_SRP.

{17-10_42} Correspondência entre o DPL_TK_SRP e a TKI

A Figura 42 apresenta a correspondência entre a DPL_TK_SRP e a TKI utilizando a mesma notação que na Figura 40. Na Figura 42, a Lista de Execução ηθ 1 é composta dos PL_TK_SRP n3 1, ns 2, n3 3. Destes, o ne 3 é gravado como o PL_TKIN do PL_TK_SRP ne 1, enquanto on51 é gra- vado como o PL_TKIN do PL_TK_SRP ns 2 e o ne 2 como o PLJTKIN do PL TK SRP n3 3. Isto significa que quando as trilhas são execuiadas de acordo com a Lista de Execução n3 1, uma pluralidade de AOBs serão exe- cutados como apresentado pelas setas (11), (12), (13) na ordem AOB ns 3, AOB ns 1, AOB ne 2. A Lista de Execuçio* ns 2 é composta dos PL_TK_SRP nõ 1, ns 2, ηθ 3. Destes, o ns 8 é grava-do como o PL_TKIN do PL_TK_SRP ns 1, en- quanto o n3 3 é gravado como o PLJTKIN do PL_TK_SRP ns 2 e o n9 1 como o PLJTKIN do PL_TK_SRIP n3 3. Isto significa que quando as trilhas são executadas de acordo com a Lista de Execução n3 2, uma pluralidade de AOBs serão executados, ccmo apresentado pelas setas (21), (22), (23) na ordem AOB na8, AOB ηθ 3, AOB n3 1, ou seja, em uma ordem totalmente diferente da Lista de Execução n9 1. A Lista de Execução ηδ 3 é composta dos PL_TK_SRP n3 1, n3 2, n3 3, n3 4. O PLJTKIN destes PL_TK_SRP n3 1 até n3 4 são respectiva- mente estabelecidos como n3 8, n3 4, n3 3 e n3 1. Isto significa que quando as trilhas são executadas de acordo com a Lista de Execução n3 3, uma plu- ralidade de AOBs serão executados como se segue. Primeiro, o AOB n3 8 que compõem a Trilha E é executado como apresentado pela seta (31). A

seguir, o AOB n3 4, AOB n3 5, AOB n3 6 e AOB n3 7 que compõem a Trilha D são executados como apresentado pela seta (32). Após isto, o AOB n3 3 e o AOB ns 1 que respectivamente compõem a Trilha Cea Trilha A são execu- tados como apresentado pelas setas (33) e (34).

Aqui é de observação especial que quando uma trilha é com- posta de uma pluralidade de TKIs, somente o número da TKI do início da trilha é gravado dentro da entrada PL_TK_SRP. Em mais detalhes, en- quanto o valor do DPL_TK_SRP dado na Informação da Lista de Execução Preestabelecida especifica as quatro TKIs (TKI ne 4, TKI ns 5, TKI ne 6, TKI ns 7) que compõem a Trilha D, o PL_TK_SRP dado em um estabelecimento da Informação da Lista de Execução não necessita indicar todas as quatro TKIs. Por esta razão, o PL_TK_SRP ηθ 2 na Lista de Execução ns 3 somente indica a TKI ηθ 4 fora da TKI ne 4 até a TKI ne 7.

Por outro lado, uma DPLI incluindo uma pluralidade de DK_TK_SRP possui um tamanho dos dados que não é maior do que um setor e é sempre carregada dentro da RAM de um aparelho de execução.

Quando as trilhas são executadas de acordo com uma Lista de Execução, o aparelho de execução refere-se aos DK_TK_SRPs que estão carregados dentro de sua RAM e desse modo pode pesquisar por TKIs em alta veloci- dade. Para executar as TKIs (AOBs) utilizando um PL_TK_SRP que so- mente indica o número da TKI da primeira TKI, um aparelho de execução pesquisa o DPL_TK_SRP carregado em sua RAM baseado na TKI indicada pelo PL_TK_SRP e julga se a trilha corrente é composta de uma pluralidade de TKIs. Se sim, o aparelho de execução executa o procedimento apropria- do para executar todas as TKIs (AOBs ) correspondentes.

Como descrito acima, a Lista de Execução Preestabelecida e a pluralidade de PLIs são gravados no Gerente de Lista de Execução. Se or- dens de execução diferentes forem gravadas nos DPL_TKIN e nos PL_TKINs dos PL_TK_SRPs e dos PL_TK_SRPs compondo tais listas de execução, torna-se possível executar os AOBs em ordens diferentes. Por oferecer uma variedade de ordens de execução para o usuário desse modo, pode ser dado ao usuário a impressão de existirem uma série de álbuns de músicas armazenados no cartão de memória flash 31.

De nota especial é que o tamanho dos dados do DPL_TK_SRP correspondendo a um arquivo AOB é pequeno (não mais do que dois bytes), enquanto o tamanho dos dados da TKI correspondendo a um arquivo AOB é maior (até 1.024 bytes). Quando reordenando a TKI no Gerente de Trilha, um grande número de acesso necessitam ser feitos junto ao cartão de me- mória flash 31, mas quando os DPL_TK_SRPs são reordenados na Infor- mação da Lista de Execução Preestabelecida ou em uma PLI, isto pode ser executado com menos acesso junto ao cartão de memória flash 31.

Em vista disto, quando os dados de navegação são editados, a ordem dos DPL_TK_SRPs na Lista de Execução Preestabelecida é ativa- mente alterada de acordo com a operação de edição, enquanto a ordem da TKI no Gerente de Trilha é deixada inalterada independente da operação de edição.

{17-9_40-2_43A,B} Reordenamento do DPL_TK_SRP O dito a seguir descreve uma operação de edição que altera a ordem da execução das trilhas por reordenar os DPL_TK_SRPs na Informa- ção da Lista de Execução Preestabelecida. As Figuras, 43A e 43B apre- sentam um exemplo do reordenamento das trilhas. Os estabelecimentos dos DPL_TK_SRPs e das TKIs na Figura 43A são os mesmos que na Figura 40.

Na Figura 40A, o DPL_TKIN no DPL_TK_SRP ns 3 é estabele- cido como TKI ns 3, enquanto o DPL_TKIN no DPL_TK_SRP n9 8 é estabe- lecido como TKI ns 8. O dito a seguir descreve o caso quando estes DPL_TK_SRPs com as linhas externas finas na Figura 40A são intercambi- ados.

Os números (1), (2), (3), (4), (5), (6), (7), (8) na Figura 43B apresentam a ordem de execução das trilhas após esta operação de edição.

Deve ser observado aqui que enquanto a ordem de execução apresentada na Figura 43A é Trilha A, Trilha B, Trilha C, Trilha D, Trilha E, na Figura, 43B os DPL_TKIN do DPL_TK_SRP n9 3 e do DPL_TK_SRP n9 8 estão in- tercambiados na Informação da Lista de Execução Preestabelecida, de modo que as trilhas serão executadas na ordem Trilha, A, Trilha B, Trilha E, Trilha D, Trilha C. Deste modo, a ordem de execução pode ser facilmente alterada por se alterar a ordem dos DPL_TK_SRPs na Informação da Lista de Execução Preestabelecida.

Ao mesmo tempo que a explicação acima lida com uma opera- ção de edição que altera a ordem das trilhas, o dito a seguir descreve as quatro operações seguintes que foram explicadas com respeito às altera- ções nas TKIs. Estas operações são um primeiro caso (caso 1) onde uma trilha é deletada, um segundo caso (caso 2) onde uma nova trilha é grava- da, um terceiro caso (caso 3) onde duas trilhas livremente selecionadas são combinadas para produzir uma nova trilha e um quarto caso (caso 4) onde uma trilha é dividida para produzir duas novas trilhas. {17-9_40-3_44A,B} Deleção de uma Trilha O dito a seguir descreve o caso 1 onde uma trilha é deletada.

As Figuras 44A e 44B apresentam como a Lista de Execução prGôStdbôiêCidâ, Ο ΟθΓΘΓιΐθ u8 Trilhei 6 05 ãfCjüiVGS AOBs SciG cuUci!iZciCÍGS quando, fora da Lista de Execução Preestabelecida apresentada na Figura 40, o DPL_TK_SRP ns 2 e a TKI ns 2 são deletados. Nestes desenhos, a mesma parte de um AOB é deletada na Figura 27 que foi utilizada para des- crever a deleção de uma TKI. Como resultado, o segundo, terceiro e quarto níveis na Figura 44A e 44B são os mesmo que na Figura 27. A diferença com a Figura 27 é que a Informação da Lista de Execução Preestabelecida incluindo uma pluralidade de DPL_TK_SRPs é dada no primeiro nível, do mesmo modo que na Figura 40. O presente exemplo lida com o caso onde o usuário deleta a Trilha B composta do DPL_TK_SRP ns 2 TKI ns 2 ("AOB002.SA1") que é apresentado com a linha externa fina na Figura 44A. Neste caso, o DPL_TK_SRP ne 2 é deletado da Informação da Lista de Execução Preesta- belecida e o DPL_TK_SRP ns 3 até o DPL_TK_SRP ne 8 são cada um movi- dos para cima um lugar na ordem de execução de modo a preencher o lugar na ordem liberada pela deleção do DPL_TK_SRP ne 2.

Quando os DPL_TK_SRPs são movidos para cima deste modo, o DPL_TK_SRP ne 8 final é estabelecido como "Não-Utilizado". Por outro lado, a TKI correspondendo à parte deletada é estabelecida como "Não- Utilizado" como apresentado nas Figuras 27A e 27B sem as outras TKIs sendo movidas para preencher a brecha criada pela deleção. A deleção da TKI também é acompanhada pela deleção do arquivo AOB ‘'AOB002.SA1 Deste modo, os DPL_TK_SRPs são movidos para cima na or- dem de execução mas as TKIs não são movidas, de modo que na Figura 44B somente as DPL_TKINs nos DPL_TK_SRPs são atualizados. Para este exemplo, o DPL_TKIN no DPL_TK_SRP ne 2 é estabelecido de modo a indi- car a TKI ns 3, como apresentado pela seta DT11, o DPL_TKIN no DPL_TK_SRP ne 3 é estabelecido de modo a indicar a TKI ns 4, como apre- sentado pela seta DT12, o DPL_TKIN no DPL_TK_SRP n9 4 é estabelecido de modo a indicar a TKI ns 5 e o DPL_TKIN no DPL_TK_SRP n9 5 é esta- belecido de modo a indicar a TKI n9 6. O DPL_TKIN no DPL_TK_SRP n9 8 que foi estabelecido como "Não-Utilizado" é estabelecido de modo a indicar a TKI n9 2, como apresentado pela seta DT13.

Quando uma trilha é deletada, os DPL_TK_SRPs utilizados para as trilhas seguintes na ordem de execução são movidos para cima, en- quanto a TKI correspondendo à trilha deletada é estabelecida para "Não- Utilizada" enquanto permanecendo na sua posição atual. Deste modo, uma operação de edição não é acompanhada pelo movimento das TKIs, o que suprime a carga de processamento quando editando as trilhas. {17-9_40-4_45A,B} Designação das TKIs quando Gravando as Trilhas O dito a seguir descreve o caso 2 quando uma nova trilha é gra- vada seguindo-se a deleção parcial de uma trilha. As Figuras 45A e 45B

apresentam como uma operação que grava uma nova TKI e o DPL_TK_SRP é executada quando uma TKI "Não-Utilizada" e o DPL_TK_SRP estão pre- sentes.

Estes desenhos são largamente os mesmo que as FIGs 28A e 28B que foram utilizadas para explicar a designação de uma nova TKI esta- belecida como "Não-Utilizada". O segundo, terceiro e quarto níveis nas FIGs. 45A e 45B são os mesmo que os primeiros três níveis nas Figuras 28A e 28B. A diferença entre estes desenhos é que os primeiros níveis nas Figuras 45A e 45B apresentam a Informação da Lista de Execução Preesta- belecida composta de uma pluralidade de DPL_TK_SRPs. Na Figura 45A, o DPL_TK_SRP η9 4 até o DPL_TK_SRP n9 8 são estabelecidos como "Não- Utilizado". Por outro lado, na Figura 28 as TKI n9 2, TKI ns 4, TKI n9 5, TKI ne 7, TKI ns 8 são estabelecidas como "Não-Utilizado".

Ao mesmo tempo que as TKIs estabelecidas para "Não- Utilizado" estão presentes aqui e existem no Gerente de Trilha, as DPL_TK_SRPs estão posicionadas próximas umas as outras na Informação da Lista de Execução Preestabelecida. Isto resulta das DPL_TK_SRPs utili- zadas sendo movidas para cima na Informação da Lista de Execução Pre- estabelecida como descrito acima, enquanto nenhum tal movimento para cima é executado para as TKIs. A explicação seguinte descreve o caso onde a Trilha D com- posta de quatro AOBs é gravada. As TKIs par estes quatro AOBs são res- pectivamente gravadas dentro das seguintes TKIs "Não-Utilizada" no Ge- rente de Trilha: TKI ns 2, TKI n9 4, TKI ns 7 e TKI n9 8.

Os DPL_TK_SRPs para estes quatro AOBs são gravados no DPL_TK_SRP ns 4 até o DPL_TK_SRP ns 7 na Informação da Lista de Exe- cução Preestabelecida. Desde que quatro AOBs compõem uma única trilha, o DPL_TK_ATR do DPL_TK_SRP ns 4 é estabelecido como "Cabeçalho da Trilha", os DPL_TK_ATRs dos DPL_TK_SRP ne 5 e do DPL_TK_SRP ne 6 são estabelecidos como "Meio da Trilha" e o DPL_TK_ATR do DPL_TK_SRP ns 7 é estabelecido como "Fim da Trilha". O DPL_TKIN do DPL_TK_SRP ne 4 é estabelecido como TKI n9 2, o DPL_TKIN do DPL_TK_SRP n9 5 é estabelecido como TKI ns 4, o DPL_TKIN do DPL_TK_SRP ns 6 como TKI n9 7 e o DPL_TKIN do DPL_TK_SRP ns 7 como TKI ne 8.

Por estabelecer os DPL_TKINs e os DPL_TK_ATRs deste modo, as TKI n9 2, TKI n9 4, TKI n9 7 e TKI n9 8 são gerenciadas como a quarta trilha Trilha D.

No processamento acima, uma gravação é executada para as TKIs "Não-Utilizada", no entanto, isto não possui efeito sobre as outras TKIs, TKI n9 1, TKI n9 2, TKI n9 3 e TKI n9 4, como foi também o caso nas FIGs 28A e 28B. {17-9_40-5_46A,B} Caso 3: Combinando Trilhas O dito a seguir descreve a atualização da Informação da Lista de Execução Preestabelecida quando as trilhas são combinadas (isto é, no caso 3). As Figuras 46A e 46B apresentam um exemplo da combinação das trilhas.

Estes desenhos são largamente os mesmos que as Figuras 29A e 29B que foram utilizadas para explicar a combinação das TKIs. O segun- do, terceiro e quarto níveis nas FIGS, 46A e 46B são os mesmo que os pri- meiros dois níveis nas Figuras 29A e 29B. A diferença entre estas figuras é que os primeiros níveis nas Figuras 46A e 46B apresentam a Informação da Lista de Execução Preestabelecida, na qual o DPL_TK_SRP ne 8 é estabe- lecido como "Não-Utilizado" e está relacionado com a TKI ns 2 que também está estabelecido como "Não-Utilizado". Quando uma operação de adição combinando as trilhas é executada para os arquivos AOBs e para as TKIs como apresentado nas Figuras 29A e 29B, os conteúdos dos DPL_TK_SRP n9 3 até DPL_TK_SRP ns 6 são cada um movidos para baixo por um e o conteúdo do DPL_TK_SRP ns 7 que é apresentado com a linha externa fina é copiado para dentro do DPL_TK_SRP ηθ 3 como apresentado nas Figuras 46A e 46B. As TKIs também são atualizadas, como apresentado nas Figu- ras 29A e 29 B. {17-9_40-6_47A,B} Caso 4: Divisão de uma Trilha O dito a seguir descreve a atualização da Informação da Lista de Execução Preestabelecida quando uma trilha é dividida (caso 4).

As Figuras 47A e 47B apresentam um exemplo da divisão de uma trilha. Estes desenhos são largamente os mesmo que as Figuras 33A e 33B que foram utilizadas para explicar a divisão das TKIs. Os segundo e terceiro níveis nas Figuras 47A e 47B são os mesmos que os primeiros dois níveis nas Figuras 33A e 33B. A diferença entre estas figuras é que o pri- meiro nível nas Figuras 47A e 47B apresenta a Informação da Lista de Exe- cução Preestabelecida, na qual o DPL_TK_SRP ns 8 é estabelecido como "Não-Utilizado" e está relacionado com a TKI ns 2 que também está estabe- lecida para "Não-Utilizado".

Se, como nas FIGS 33A e 33B, o usuário indicar a divisão da TKI n9 3 (AOB003.SA1") apresentada com a linha externa fina por dois, as posições do DPL_TK_SRP n9 3 até DPL_TK_SRP n9 7 são cada uma movi- das para baixo por um na ordem e um DPL_TK_SRP estabelecido como "Não-Utilizado" é movido dentro da Informação da Lista de Execução Pre- estabelecida para a primeira posição do DPL_TK_SRP n9 3.

Este novo DPL_TK_SRP n9 3 está associado com a TKI, TKI n9 2, recentemente produzida pela divisão. O arquivo AOB "AOB002.SA1" as- sociado com a TKI n9 2 armazena o que foi originalmente a última parte do arquivo AOB "AOB003.SA1". O DPL_TK_SRP n9 2 está presente antes do DPL_TK_SRP n9 3 que está associado com a TKI n9 2 e está associado com a TKI n-2e com o "AOB002.SA1".

Ou seja, o "AOB002.SA1" e o "AOB003.SA1" respectivamente armazenam a última e a primeira parte do "AOB003.SA1" original, com o DPL_TK_SRP n9 2 e o DPL_TK_SRP n9 3 correspondendo a estes arquivos indicando que estes AOBs são para ser executados na ordem "AOB003.SA1" e "AOB002.SA1". Como resultado, a última e a primeira partes do "AOB003.SA1" original serão executadas na ordem primeira parte, última parte, de acordo com a ordem de execução dada no DPL_TK_SRP. {17-9_40-8} Aplicação do Processamento de Edição Por combinar os quatro processos de edição acima, um usuário pode executar uma grande variedade de operações de edição. Quando, por exemplo, uma trilha gravada possui uma introdução sobre a qual um disc jockey falou, o usuário pode primeiro dividir a trilha para separar a parte in- cluindo a voz do disc jockey. O usuário pode então deletar esta trilha para deixar a parte da trilha que não inclui o disc jockey.

Isto completa a explicação dos dados de navegação. O dito a seguir descreve uma aparelho de execução com uma composição adequada para executar os dados de navegação e os dados de apresentação descri- tos acima. {48-1} Aparência Externa do Aparelho de Execução A Figura 48 apresenta um aparelho de execução portátil para o cartão de memória flash 31 da presente invenção. O aparelho de execução apresentado na Figura 48 possui uma fenda de inserção para a inserção do cartão de memória flash 31um painel chave para receber as indicações do usuário para as operações tal como a execução, a pesquisa para frente, a pesquisa para trás, ir para frente rápido, voltar, parar, etc. e um painel LCD (Vídeo de Cristal Líquido). Em termos de aparência, este aparelho de exe- cução parece com outros tipos de executores de música portáteis. O painel chave inclui: Uma tecla de "Lista de Execução" que recebe a seleção de uma Lista de Execução ou de uma trilha; uma tecla " I«" que recebe uma operação de salto que move a posição de execução para um início da trilha corrente; um tecla "»|11 que recebe uma operação de salto que move a posição de execução para um início da próxima trilha; uma tecla "«" e uma tecla "»" que respectivamente recebem uma operação de pesquisa para trás e uma operação de pesquisa para frente que permitem ao usuário ter um movimento da execução rapidamente através da trilha corrente; uma tecla "Exibe" que recebe uma operação para ter imagens paradas no cartão de memória flash 31 exibidas; uma tecla "Rec" que recebe uma operação de gravação; uma tecla "Áudio" para receber as seleções do usuário da fre- qüência de amostragem ou de se estéreo ou mono é para ser utilizado; uma tecla "mark" que recebe indicações do usuário que marcam as posições nas trilhas; e uma tecla "Edit" que recebe indicações do usuário para a edição de trilhas ou para a entrada de títulos da trilha. {48-2} Aperfeiçoamentos Feitos Neste Aparelho Executor Portátil para o Cartão de Memória Flash 31 As diferenças entre este aparelho de execução portátil do cartão de memória flash 31 e um executor de música portátil convencional situa-se nos seguintes quatro aperfeiçoamentos (1) até (4). (1) Uma lista de listas de execução e de trilhas é apresentada no painel LCD para permitir ao usuário indicar a Informação de Lista de Execução Preestabelecida, uma PL1 ou trilhas separadas. (2) As teclas no painel de teclas são designadas para as listas de execução e/ou trilhas exibidas no painel LCD para permitir ao usuário selecionar uma trilha ou lista de execução que é para ser executada ou editada. (3) Um código de tempo apresentando uma posição em uma trilha é exibido no painel LCD 5 quando uma trilha é executada. (4) Um mostrador de mudança de direção é proporcionado para permitir ao usuário estabelecer um código de tempo para uso como o tempo de início de execução quando utilizando a função de pesquisa de tempo ou como um limite de divisão quando dividindo uma trilha. {48-2_49_50} Aperfeiçoamento (2) O dito a seguir descreve o aperfeiçoamento (2) em detalhes. A

Figura 49 apresenta um exemplo de uma tela de vídeo apresentada no pai- nel LCD quando o usuário seleciona uma lista de execução, enquanto as FIGs. 50A até 50E apresentam exemplos do conteúdo exibido quando o usuário seleciona uma trilha.

Na Figura 49, as cadeias de caracteres ASCII "LISTA DE EXE- CUÇÃO PREESTABELECIDA", "LISTA DE EXECUÇÃO NQ 1, "LISTA DE

EXECUÇÃO Nq 2", "LISTA DE EXECUÇÃO UQ 3" e "LISTA DE EXECUÇÃO

Ne 4" representam a lista de execução preestabelecida e as quatro listas de execução armazenadas no cartão de memória flash 31.

Enquanto isto, as cadeias de caracteres ASCII "Trilha ns 1", "Trilha ns 2", "Trilha ns 3", "Trilha ns 4", "Trilha ne 5" representam as cinco trilhas que estão indicadas na ordem de execução das pela lista de execu- ção preestabelecida armazenada no cartão de memória flash 31. Nas Figu- ras 49 e 50A, a Lista de Execução e a trilha realçadas apresentam a trilha ou Lista de Execução que está atualmente indicada para execução ou edi- ção.

Se o usuário pressionar a tecla "»" quando a Trilha ns 1" esti- ver indicada para execução dentro de uma ordem de execução dada pela Lista de Execução preestabelecida no painel LCD, a Trilha ns 2 será indica- da para execução dentro da lista de trilhas, como apresentado na Figura 50B. Se o usuário pressionar a tecla "»" novamente, a Trilha ne 3 será indi- cada para execução dentro da lista de trilhas, como apresentado na Figura 50C.

Se o usuário pressionar a tecla "«" quando a Trilha ns 3 está indicada para execução dentro da ordem de execução dada pela Lista de Execução preestabelecida no painel LCD, a Trilha ne 2 será indica para execução dentro da lista de trilhas, como apresentado na Figura 50D. Como apresentado na Figura 50E, se o usuário pressionar a tecla "Play" quando qualquer das trilhas estiver indicada, a execução da trilha indicada irá co- meçar, enquanto se o usuário pressionar a tecla "Edit", a trilha indicada irá ser selecionada para edição. {48-3_51} Aperfeiçoamento (4) O dito a seguir descreve o aperfeiçoamento (4) em detalhes. As Figuras 51A até 51C apresentam uma operação exemplo do mostrador de mudança de direção. Quando o usuário gira o mostrador de mudança de direção até uma certa quantidade, o código de tempo de execução no painel LCD será aumentado ou diminuído de acordo com esta certa quantidade. O exemplo na Figura 51A apresenta o caso onde o código do tempo de exe- cução que é inicialmente exibido no painel LCD é "00:00:20".

Quando o usuário gira o mostrador de mudança de direção no sento contrário ao dos ponteiros do relógio, como apresentado na Figura 51B, o código de tempo de execução é reduzido para "0:00:10" ao acompa- nhar a quantidade pela qual o mostrador de mudança de direção foi girado.

Inversamente, quando o usuário gira o mostrador de mudança de direção no sentido dos ponteiros do relógio como apresentado na Figura 51C, o código de tempo de execução é aumentado para "0:00:30" ao acompanhar a quan- tidade pela qual o mostrador de mudança de direção foi girado.

Por permitir ao usuário alterar o código de tempo de execução deste modo, o aparelho de execução permite ao usuário indicar qualquer código de tempo de execução em uma trilha por simplesmente girar o mos- trador de mudança de direção. Se o usuário então pressionar a tecla "Play", os AOBs serão executados começando a partir de uma posição encontrada de acordo com a Equação 2 ou com a Equação 3.

Por utilizar o mostrador de mudança de direção durante uma operação de divisão de trilha, o usuário pode fazer os ajustes finos junto ao código de tempo de execução utilizado como o limite da divisão. {52-1} Construção Interna do Aparelho de Execução O dito a seguir descreve a construção interna do aparelho de execução. Esta construção interna é apresentada na Figura 52.

Como apresentado na Figura 52, o aparelho de execução inclui um conector do cartão 1 para conectar o aparelho de execução com o car- tão de memória flash 31, uma interface com o usuário 2 que está conectada com o painel de teclas e com o mostrador de mudança de direção, uma RAM 3, uma ROM 4, um painel LCD 5 possuindo um quadro de listas para exibição de uma lista de trilhas ou de listas de execução e um quadro do código de tempo de execução para exibir um código de tempo de execução, um acionar do LCD 6 para acionar o primeiro painel LCD 5, um desamonto- ador 7 para decriptografar os AOB_FRAMEs utilizando uma FileKey dife- rente para cada arquivo AOB, um decodificador AAC 8 para refere-se aos ADTS de um AOB_FRAME desamontoado pelo desamontoador 7 e decodi- ficação do AOB_FRAME para obter os dados PCM, um conversor D/A 9 para converter D>A os dados PCM e emitir os sinais analógicos resultantes para o alto-falante ou para a tomada do headphone e uma CPU 10 para executar o controle geral sobre o aparelho de execução.

Como pode ser entendido a partir desta construção de hardwa- re, o presente aparelho de execução não possui elementos de hardware especial para processar o Gerente de Trilha e a Informação da Lista de Execução Preestabelecida. Para processar o Gerente de Trilha e a Informa- ção da Lista de Execução Preestabelecida, uma área de posse da DPLI 11, uma área de armazenamento da PLI 12, uma área de armazenamento da TKI 13, uma área de armazenamento da FileKey 14 e um buffer duplo 15 são proporcionados na RAM 3, enquanto um programa de controle de exe- cução e um programa de controle de edição são armazenados na ROM 4. {52-2} Área de Posse da DPL111 A área de posse da DPLI 11 é uma área para continuamente manter a Informação da Lista de Execução Preestabelecida que foi lida do cartão de memória flash 31 conectado com o conector do cartão 1.

{52_12} Área de Armazenamento da PLI A área de armazenamento da PLI 12 é uma área que é reserva- da para armazenar a Informação da Lista de Execução que foi selecionada para execução pelo usuário. {52-3} Área de Armazenamento da TK113 A área de armazenamento da TKl 13 é uma área que é reserva- da para somente armazenar a TKl correspondendo ao arquivo AOB que está atualmente indicado para execução, fora da pluralidade de TKIs incluí- das no Gerente de Trilha. Por esta razão, a capacidade da área de armaze- namento da TKl 13 é igual ao tamanho dos dados de uma TKl. {52-4} Área de Armazenamento da FileKey 14 A aérea de armazenamento da FileKey 14 é uma área que está reservada para somente armazenar a FileKey correspondendo ao arquivo AOB que está atualmente indicado para execução, fora da pluralidade de FileKeys incluídas no ''AOBSA1 .KEY" na região de autenticação. {52-5} Buffer Duplo 15 O buffer duplo 15 é um buffer de entrada/saída que é utilizado quando um processo de entrada, que sucessivamente informa dados do cluster (dados que estão armazenados em um cluster) lidos a partir do car- tão de memória flash 31 e um processo de saída, que lê os AOB_FRAMEs a partir dos dados do cluster e sucessivamente emite os AOB_FRAMEs para o desamontoador 7, são executados em paralelo. O buffer duplo 15 sucessivamente libera as regiões que esta- vam ocupadas pelos dados do cluster que foram emitidos como AOB_FRAMEs e desse modo protege regiões para armazenar os próximos clusters a serem lidos. Ou seja, as regiões no buffer duplo 15 são ciclica- mente seguras para armazenar os dados do cluster utilizando ponteiros em anel. {52-5_53_54A,B} Entrada e Saída pelo Buffer Duplo 15 A Figura 53 apresenta como a entrada e a saída são executadas para o buffer duplo 15. As Figuras 54A e 54B apresentam como as regiões no buffer duplo 15 são ciclicamente seguras para armazenar os dados do cluster utilizando ponteiros em anel.

As setas apontando para baixo e para a esquerda são ponteiros para os endereços de gravação para os dados do cluster, ou seja, o pontei- ro de gravação. As setas apontando para cima e para a esquerda são pon- teiros para endereços de leitura para os dados do cluster, ou seja, ponteiro de leitura. Estes ponteiros são utilizados como ponteiros em anel. {54-6_53} Quando um cartão de memória flash 31 está conectado com o conector de cartão 1, os dados do cluster na região do usuário do cartão de memória flash 31 são lidos e armazenados no buffer duplo 15 como apre- sentado pelas setas w1 e w2.

Os dados do cluster lidos são sucessivamente armazenados dentro das posições no buffer duplo 15 apresentadas pelos ponteiros de gravação wp1 ewp2. {52-7_54A} Dos AOB_FRAMEs incluídos nos dados do cluster armazenados deste modo, os AOB_FRAMEs presentes nas posições (1)(2)(3)(4)(5)(6)(7) (8)(9) que são sucessivamente indicados pelo ponteiro de leitura são emiti- dos um por vez para o desamontoador 7 como apresentado pelas setas r1, r2, r3, r4, r5.

No presente caso, os dados do cluster 002 e 003 são armaze- nados no buffer duplo 15 e as posições de leitura (1)(2)(3)(4) são sucessi- vamente indicadas pelo ponteiro de leitura, como apresentado na Figura 53.

Quando o ponteiro de leitura alcança a posição de leitura (%), todos os AOB_FRAMEs incluídos no cluster 002 terão sido lidos, de modo que o cluster 004 é lido e como apresentado pela seta w6 na Figura 54A, é grava- do por cima dentro da região que foi anteriormente ocupada pelo cluster 002. {58-8_54B} O ponteiro de leitura então avança até as posições de leitura (6) e (7) e eventualmente alcança a posição de leitura (9), ponto em que todos os AOB_FRAMEs incluído no cluster 003 terão sido lidos, de modo que o cluster 005 é lido e como apresentado pela seta w7 na Figura 54B, é grava- do por cima na região que foi anteriormente ocupada pelo cluster 003. A saída de um AOB_FRAME e a gravação por cima dos dados do cluster são repetidamente executadas como descrito acima, de modo que os AOB_FRAMEs incluídos em um arquivo AOB são todos sucessivamente emitidos para o desamontoador 7 e para o decodificador AAC 8.

{52-9_55-58} Programa de Controle de Execução Armazenado na ROM 4 O dito a seguir descreve o programa de controle de execução armazenado na ROM 4. A Figura 55 é um fluxograma apresentando o processamento no procedimento de leitura do arquivo AOB. As Figuras 56, 57 e 58 são fluxo- gramas apresentando o processamento no procedimento de saída do AOB_FRAME. {52-9_55-1} Estes fluxogramas utilizam as variáveis w, z, y e x. A variável w indica um da pluralidade de DPL_TL_SRPs. A variável z indica um arquivo AOB gravado na região do usuário, a TKI correspondente a este arquivo AOB e o AOB incluído neste arquivo AOB. A variável y indica um AOB_ELEMENT incluído no AOB n9z indicado pela variável z. A variável x indica um AOB_FRAME incluído no AOB_ELEMENT N9 y indicado pela va- riável y. O dito a seguir primeiro explica o processamento no procedimento de leitura do arquivo AOB, com referência à Figura 55. {52-9_55-2} Na etapa S1, a CPU 10 lê o Gerente de Trilha e exibe uma lista incluindo a Informação da Lista de Execução Preestabelecida e as PLIs.

Na etapa S2, a CPU 10 aguardar por uma indicação para exe- cutar os AOBs de acordo com a Informação da Lista de Execução Preesta- belecida ou com uma das PLIs.

Quando a Informação da Lista de Execução Preestabelecida é indicada, o processamento move-se da etapa S2 para a etapa S3 onde a variável w é inicialmente inicializada (ns w<-1) e então para a etapa S4 onde a TKI ne z indicada pelo DPL_TKIN correspondendo ao DPL_TK_SRP ne w na Informação da Lista de Execução Preestabelecida é especificado e so- mente esta TKI ns z é lida do cartão de memória flash 31 e armazenada na área de armazenamento da TKI 13.

Na etapa S5, um arquivo AOB ne z com o mesmo número da TKI nõ z é especificado. Deste modo, o arquivo AOB que é para ser executado é finalmente especificado. O arquivo AOB especificado está em um estado criptografado e necessita ser decriptografado, de modo que as etapas S6 e S7 são execu- tadas. Na etapa S6, o aparelho de execução acessa a região de autentica- ção e lê a FileKey ne z que está armazenada em uma FileKey_Entry ne z no arquivo de armazenamento de chave de criptografia, a FileKey_Entry ne z possuindo o mesmo número que o arquivo AOB especificado. Na Etapa S7, a CPU 10 estabelece a FileKey ns z no desamontoador 7. Esta operação resulta na FileKey sendo estabelecida no desamontoador 7, de modo que por sucessivamente informar os AOB_FRAMEs incluídos no arquivo AOB dentro do desamontoador 7, os AOB_FRAMEs podem ser sucessivamente executados. {52-9_55-3>

Após isto, o aparelho de execução sucessivamente lê os clus- ters que armazenam o arquivo AOB. Na etapa S8, o "primeiro número do cluster no arquivo" é especificado para o AOB_FILE ns z na entrada do di- retório. Na etapa S9, a CPU 10 lê os dados armazenados neste cluster a partir do cartão de memória flash 31. Na etapa S10, a CPU 10 julga se o número do cluster no valor FAT é "FFF". Se não, na etapa S11, a CPU lê os dados armazenados no cluster indicado pelo valor FAT, antes de retornar para a etapa S10.

Quando o aparelho de execução lê os dados armazenados em qualquer dos clusters e refere-se ao valor FAT correspondendo a este cluster, o processamento nas etapas S10 e S11 será repetido enquanto o valor FAT não estiver estabelecido em "FFF". Isto resulta no aparelho de execução sucessivamente lendo os clusters indicados pelos valores FAT.

Quando o número do cluster dado por um valor FAT é ''FFF", isto significa que todos os clusters compondo o arquivo AOB ne z foram lidos, de modo que o processamento avança da etapa S10 para a etapa S12. {52-9_55-4} Na etapa S12, a CPU 10 julga se a variável ns w combina com o número total de DPL_TK_SRPs. Se não, o processamento avança para a etapa S13, onde a variável nõwé incrementada (ns w <- w + 1) antes do processamento retornar para a etapa S4. Na etapa S4, o aparelho de exe- cução especifica a TKI ns z que está indicada pelo DPL_TKIN ns w do DPL_TK_SRP ns w na Informação da Lista de Execução Preestabelecida e grava somente a TKI ne z dentro da área de armazenamento da TKI 13. A TKI que foi utilizada até este ponto ainda estará armazenada na área de armazenamento da TKI 13, no entanto esta TKI corrente será gravada por cima pela TKI nez que é mais recentemente lida pela CPU 10.

Esta gravação por cima resulta em somente a última TKI sendo armazenada na área de armazenamento da TKI 13. Uma vez que a TKI te- nha sido gravada por cima, o processamento nas etapas S5 até S12 é repe- tido para o arquivo AOB ns z. Uma vez que este processamento tenha lido todas as TKIs e os arquivos AOB correspondentes a todos os DPL_TK_SRPs incluídos na Informação da Lista de Execução Preestabele- cida, a variável n9 z irá combinar com o número total de DPL_TK_SRP de modo que o julgamento "Sim" é dado na etapa S12 e o processamento neste fluxograma termina.

{52-9_56_57_58} Processamento de Saída para um AOB_FRAME

Em paralelo com o procedimento de leitura do arquivo AOB, a CPU 10 executa o procedimento de saída do AOB_FRAME de acordo com os fluxogramas nas Figuras 56, 57 e 58. Nestes fluxogramas, a variável "play_time'' apresenta por quanto tempo a execução foi executada para uma trilha corrente, ou seja, o código do tempo de execução. O tempo exibido no quadro de código de tempo de execução no painel LCD 5 é atualizado de acordo com as alterações junto a este código de tempo de execução. En- quanto isto, a variável "play_data" representa o comprimento dos dados que foram executados para a trilha corrente. {52-9_56-1} Na etapa S21, a CPU 10 monitora se os dados do cluster para o arquivo AOB n9 z foram acumulados no buffer duplo 15. Esta etapa S21 será repetidamente executada até que os dados do cluster tenham acumulado, ponto em que o processamento avança para a etapa S22 onde as variáveis x e y são inicializadas (n9 x <- 1, n9 y <- 1). Após isto, na etapa S23, a CPÜ 10 pesquisa o cluster para o arquivo AOB n9 z e detecta o AOB_FRAME n9 x no AOB_ELEMENT n9 y que está posicionado não antes do que o Data_Offset dado no BIT n9 z incluído na TKI n9 z. Neste exemplo, é assu- mido que os sete bytes começando a partir do SZ_DATA são ocupados pelo cabeçalho ADTS. Por referir-se ao cabeçalho ADTS, o comprimento dos dados indicados pelo cabeçalho ADTS pode ser reconhecido como dados de áudio. Os dados de áudio e o cabeçalho ADTS são lidos juntos e são emitidos para o desamontoador 7. O desamontoador 7 decriptografa os AOB_FRAMEs, que são então decodificados pelo decodificador AAC 8 e reproduzidos como áudio. {52-9_56-2>

Após esta detecção, na etapa S24, o AOB_FRAME n9 x é emiti- do para o desamontoador 7 e na etapa S25, a variável play_time é incre- mentada pelo período de execução do AOB_FRAME n9 x e a variável play_data é incrementada pela quantidade de dados correspondendo ao AOB_FRAME ns x. Desde que o tempo de execução do AOB_FRAME é 20 mseg no presente caso, 20 mseg é adicionado para a variável "play_time".

Uma vez que o primeiro AOB_FRAME tenha sido emitido para o desamontoador 7, na etapa S26 o aparelho de execução refere-se ao cabe- çalho ADTS do AOB_FRAME ne x e especifica onde o próximo AOB_FRAME está. Na Etapa S27, o aparelho de execução incrementa a variável ns x (ηθ x <- ns x +1_ e estabelece o AOB_FRAME ηθ x como o pró- ximo AOB_FRAME. Na etapa S28, o AOB_FRAME ne x é informado para dentro do desamontoador 7. Após isto, na etapa S29, a variável play_time é incrementada pelo período de execução do AOB_FRAME ngxea variável play_data é incrementada pela quantidade de dados correspondendo ao AOB_FRAME n9 x. Após incrementar o AOB_FRAME n9 x, na etapa S30 a CPU 10 julga se a variável ns x alcançou o valor dado no FNs_1st_TMSRTE.

Se a variável ns x não tiver alcançado o valor no FNs_1st_TMSRTE, na etapa S31 o aparelho de execução verifica se o usu- ário pressionou qualquer tecla com exceção da tecla "Play" e então retorna para a etapa S26. O aparelho de execução depois disso repete o proces- samento nas etapas S26 até S31 até que a variável ns x alcance o valor no FNs_1st_TMSRTE ou até que o usuário pressione qualquer tecla com exce- ção da tecla "Play".

Quando o usuário pressionar uma tecla com exceção da tecla "Play", o processamento neste fluxograma termina e o processamento ade- quado para a tecla pressionada é executado. Quando a tecla pressionada é a tecla "Stop", o procedimento de execução para, enquanto quando a tecla pressionada é a tecla Pause", a execução é parada. {52-9_57-1} Por outro lado, quando a variável n9 x alcança o valor no FNs_1st_TMSRTE, o julgamento "Sim" é feito na etapa S30 e o processa- mento continua para a etapa S32 na Figura 57. Desde que todos os AOB_FRAMEs incluídos no presente AOB_ELEMENT terão sido informados dentro do desamontoador 7 no processamento entre a etapa S26 e S30, na etapa S32 a variável n9 y é incrementada para estabelecer o próximo AOB_ELEMENT como os dados a serem processados e a variável n9 x é inicializada (n9 y <- n9 y + 1, nõ x 1).

Após isto, na etapa S33, o aparelho de execução refere-se a TKTMSRT e calcula o primeiro endereço do AOB_ELEMENT ns y. O aparelho de execução então executa o procedimento com- posto das etapas S34 até S42. Este procedimento lê os AOB_FRAMEs in- cluídos em um AOB_ELEMENT um após o outro e desse modo pode ser dito parecer com o procedimento composto das etapas S24 até S31. A dife- rença do procedimento composto das etapas S24 até S31 é a condição pela qual o procedimento composto das etapas S24 até S31 termina é se a vari- ável ne x alcançou o valor apresentado pelo "FNs_1st_TMSRTE", enquanto a condição pela qual o procedimento composto das etapas S34 até S42 termina é se o variável n9 x alcançou o valor apresentado pelo "FNs_1st_TMSRTE".

Quando a variável n9 x alcança o valor apresentado pelo "FNs_1st_TMSRTE", o procedimento de repetição composto das etapas S34 até S42 termina, o julgamento "Sim" é dado na etapa S41 e o proces- samento avança para a etapa S43. Na etapa S43, a CPU 10 incrementa a variável ns y e inicializa a variável ns x (n9 y <-n9 y+1, ns x <- 1). Após isto, na etapa S44, a variável y julga se a variável ne y alcançou um valor que é igual a um menos do que o Número Total de TMSRT_entrys no cabeçalho TMSRT na TKI ns z.

Quando a variável ne y é menor do que (Número Total de TMSRT_entrys - 1), o AOB_ELEMENT n9 y não é o AOB_ELEMENT final, de modo que o processamento retorna da etapa S44 para a etapa S32 e o procedimento de repetição da etapa S32 até a etapa S42 é executado.

Quando a variável n9 y alcança (Número Total de TMSRT_entrys - 1), o pro- cedimento de leitura pode ser assumido como tendo continuado até o pe- núltimo AOB_ELEMENT, de modo que o julgamento "Sim" é dado na etapa S44 e o processamento avança para a etapa S45 na Figura 58. {52-9_57-2} O procedimento composto das etapas S45 até S54 parecem com o procedimento composto das etapas S33 até S42 pelo fato de que cada um dos AOB_FRAMEs no AOB_ELEMENT final são lidos. A diferença com o procedimento composto das etapas S33 até S42 é que enquanto o procedimento de repetição composto das etapas S33 até a etapa S42 termina quando é julgado na etapa S41 que a variável ηθ x alcançou o valor no "FNs_Middle_TMSRTE", o procedimento de repetição composto das etapas S45 até S54 termina quando é julgado na etapa S53 que a variável ne x alcançou o valor no "FNs_Last_TMSRTE" e a variável play_data apresentando o tamanho dos dados que até aqui tinham sido li- dos alcançou o valor dado por "SZ_DATA". O procedimento composto das etapas S49 até S54 é repetido até que as condições na etapas S53 sejam satisfeitas, ponto em que o jul- gamento "Sim11 é dado na etapa S53 e o processamento avança para a eta- pa S55. Na etapa S55, a CPU 10 incrementa a variável ne z (ns z ns z+1) antes do processamento retornar para a etapa S21 onde a CPU 10 aguarda pelo próximo arquivo AOB para acumular no buffer duplo 15. Uma vez que isto acontece, o processamento avança para a etapa S22 e o procedimento composto das etapas S22 até a etapa S54 é repetido. Isto significa que a TKI indicada pelo DPL_TKIN do próximo DPL_TK_SRP é especificada e o arquivo AOB correspondendo a esta TKI, ou seja, o arquivo AOB com o mesmo número que o da TKI, é especificado.

Após isto, o aparelho de execução acessa a região de autenti- cação e especifica a FileKey, fora das FileKeys no arquivo de armazena- mento de chave de criptografia, que possui o mesmo número que a TKI, antes de ler esta FileKey e estabelecer a mesma no desamontoador 7.

Como resultado, os AOB_FRAMEs incluídos no arquivo AOB possuindo o mesmo número que a TKI são sucessivamente lidos e executados. {52-9_57-3_59} Atualização do Código de Tempo de Execução As Figuras 59A e 59D apresentam como o código de tempo de execução exibido no quadro de exibição do código de tempo de execução do painel LCD 5 é aumentado de acordo com a atualização da variável play_time. Na Figura 59A, o código de tempo de execução é "00:00:00.000", no entanto, quando a execução do AOB_FRAME N91 termina, o período de execução de 20 mseg do AOB_FRAME nõ 1 é adicionado para o código de tempo de execução para atualizar o mesmo para "00:00:00.020", como apresentado na Figura 59B. Quando a execução do AOB_FRAME n® 2 ter- mina, o período de execução de 20 mseg do AOB_FRAME n® 2 é adiciona- do para o código de tempo de execução para atualizar o mesmo para "00:00:00:.040", como apresentado na Figura 59C. Do mesmo modo, quan- do a execução do AOB_FRAME NQ 6 termina, o período de execução de 20 mseg do AOB_FRAME n® 6 é adicionado ao código de tempo de execução para atualizar o mesmo para "00:00:00.120", como apresentado na Figura 59D.

Isto completa a descrição do procedimento de saída do AOB_FRAME.

Na etapa S31 do fluxograma na Figura 56, se o usuário pressio- nar uma tecla com exceção da tecla "Play", o processamento neste fluxo- grama é terminado. O processamento que acompanha a pressão da tecla "Stop" ou Pause" já foi descrito, no entanto, quando o usuário pressiona uma das teclas proporcionadas para ter o aparelho de execução executando uma execução especial, o processamento neste fluxograma, ou nos fluxo- gramas apresentados nas Figuras 56, 57 e 58 é terminado e o processa- mento adequado para a tecla pressionada é executado.

O dito a seguir descreve o procedimento executado pela CPU 10 (1) quando executando a função de pesquisa para frente em resposta ao usuário pressionar a tecla "»" e (2) quando executando a função de pes- quisa de tempo em reposta ao usuário operar o mostrador de mudança de direção após pressionar a tecla "Pause" ou "Stop". {52-1060} Função de Pesquisa para Frente A Figura 60 é um fluxograma apresentando o procedimento exe- cutado pela CPU 10 quando executando a função de pesquisa para frente.

Quando o usuário pressiona a tecla "»", o julgamento "Sim" é dado na eta- pa S31, etapa S42 ou na etapa S54 nos fluxogramas nas Figuras 56, 57, e 58 e a CPU 10 executa o processamento no fluxograma da Figura 60.

Na etapa S61, os AOB_FRAMEs n® x até n® (x+f(t)-1) são infor- mados para o desamontoador 7. Aqui, "t" representa o período de execução intermitente, f(t) representa o número de quadros correspondendo ao perío- do de execução intermitente e d(t) representa o quantidade de dados cor- respondendo ao período de execução intermitente. Na etapa S62, a variável play_time apresentando o tempo de execução decorrido e a variável play_data apresentando a quantidade de dados executada são respectiva- mente atualizados utilizando o período de execução intermitente "t", o nú- mero de quadros f(t) correspondendo ao período de execução intermitente e a quantidade de dados d(t) correspondendo ao período de execução inter- mitente (x <- x+f(t), play_time <- play_time+t, play_data play_data+d(t)).

Observe que o período de execução intermitente geralmente será 240 mseg (equivalente ao período de execução de doze AOB_FRAMEs). {52-10_60-1_61A,B} As Figuras 61A e 61B apresentam o incremento do código de tempo de execução durante uma operação de pesquisa para frente. A Figu- ra 61A apresenta o valor inicial do código de tempo de execução, com o ponto de execução sendo o AOB_FRAME ne 1 no AOB_ELEMENT ns 51. O código de tempo de execução neste caso é "00:00:01.000''.

Quando o primeiro até o décimo segundo AOB_FRAMEs foram informados para o desamontoador 7 como o período de execução intermitente, o perío- do de execução de doze AOB_FRAMEs (isto é, 240 mseg.) é adicionado para o código de tempo de execução de modo que o código de tempo de execução torna-se "00:00"01.240", como apresentado na Figura 61B. {52-10_60-2} Após esta atualização, na etapa S63, a CPU 10 compara a vari- ável ne x incrementada com o número total de quadros no AOB_ELEMENT nsye julga se a variável ns x incrementada está dentro do número total de quadros no AOB_ELEMENT s y.

Como mencionado anteriormente, o número de quadros em um AOB_ELEMENT posicionado no início de um AOB é "FNs_1st_TMSRTE", o número de quadros em um AOB_ELEMENT posicionados em uma parte central de um AOB é "FNs_Middle_TMSRTE" e o número de quadros em um AOB_ELEMENT posicionado no fim de um AOB é "FNs_Last_TMSRTE". A CPU 10 executa o julgamento acima por comprar um valor apropriado entre estes valores com a variável n9 x. Quando a variável x não está dentro do AOB_ELEMENT ns y presente, a CPU 10 então julga na eta- pa S64 se existe um AOB_ELEMENT que segue o AOB_ELEMENT ns y.

Quando o AOB_ELEMENT n9 y é o AOB_ELEMENT final em um AOB_BLOCK, não existirá AOB_ELEMENT que siga ao AOB_ELEMENT n9 y, de modo que o julgamento "Não" é dado" na etapa S64 e o processa- mento no fluxograma presente termina. Ao contrário, quando um AOB_ELEMENT que segue o AOB_ELEMENT n9 y existe, na etapa S65 a variável n9 x é reduzida pelo número de AOB_FRAMEs no AOB_ELEMENT n9 y e na etapa S66 a variável n9 y é atualizada (n9 y <- n9 y+1). Como re- sultado, a variável n9 x irá indicar agora a posição do quadro de um quadro no próximo AOB_ELEMENT n9 y indicado pela variável n9 y atualizada. In- versamente, quando a variável ns x indica um AOB_FRAME que está pre- sente no AOB_ELEMENT corrente (S63:Sim), o processamento nas etapas S64 até S66 é saltado e o processamento avança para a etapa S67. {52-10_60-3} Após isto, as variáveis n9 x, play_time e play_data são atualiza- das de acordo com o período de salto intermitente. O período "skip_time" que é equivalente ao período de salto intermitente é dois segundos, o nú- mero de quadros que são equivalentes a este skip_time é dado como f(skip_time) e a quantidade de dados que é equivalente a este skip_time é dada como d(skip_time). Na etapa S67, estes valores são utilizados para atualizar as variáveis n9 x, play_time e play_data (n9 x <- n9 x+f(skip_time), play_time play_time+skip_time e play_data <- play_data+d(skip_time)). {52-10_60-4_61 C} Como apresentado na Figura 61C, o período de salto intermi- tente é adicionado para a variável n9 x apresentando uma posição do qua- dro dentro do AOB_ELEMENT n9 51. Quando a variável n9 x atualizada ex- cede ao número de quadros no AOB_ELEMENT n9 51, a variável n9 y é atu- alizada para indicar o próximo AOB_ELEMENT e o número de quadros no AOB_ELEMENT n9 51 é subtraído da variável n9 x. Como resultado, a variá- vel n9 x irá agora indicar uma posição do quadro dentro do AOB_ELEMENT ηθ 52 indicada pela variável ns y atualizada. 0 valor 2,000 (- 2 segundos) é então adicionado para o valor presente "00:00:01.240" do código de tempo de execução de modo que ele se torna "00:00:03.240". A variável nsxé atu- alizada por se calcular (3240 mseg. - 2000 mseg)/20 mseg.) para fornecer o valor "62"e desse modo indicar o AOB_FRAME vf 62 no AOB_ELEMENT ns 52. {52-10_60-5_61 (d)} Uma vez que o AOB_FRAME ns 62 no AOB_ELEMENT ne 52 tenha sido informado para o desamontoador 7, o código de tempo de exe- cução é atualizado como apresentado na Figura 61D por se adicionar "0,240" para o valor atual de "00:00:03.240" para fornecer "00:00:03.480".

Na etapa S67, as variáveis são atualizadas de acordo com o tempo de salto intermitente e então o processamento nas etapas S68 até S71 são executadas. Este processamento nas etapas S68 até S71 é o mesmo que o processamento nas etapas S63 até S66 e desse modo atuali- za a variável nfi x por um número de quadros que é equivalente ao tempo de salto intermitente 'skip.Jime", antes de verificar se a variável ns x ainda indi- ca um AOB_FRAME dentro do AOB_ELEMENT ηθ y atual. Se não, a variá- vel ne y é atualizada de modo que o próximo AOB_ELEMENT é estabelecido como o AOB_ELEMENT ne y e a variável nsxé convertida de modo a indi- car uma posição do quadro neste próximo AOB_ELEMENT.

Uma vez que as variáveis ns x e ne y tenham estado de acordo com o tempo de execução intermitente e com o tempo de salto intermitente, na etapa S72, a CPU 10 refere-se à TKTMSRT e calcula o endereço inicial para o AOB_ELEMENT ne y. Então, na etapa S73, a CPU 10 começa a pes- quisa por um cabeçalho ADTS começando a partir do endereço inicial do AOB_ELEMENT ns y até detectar o AOB_FRAME nõ x. Na etapa S74, a CPU 10 julga se o usuário pressionou qualquer tecla com exceção da tecla de pesquisa para frente. Se não, os AOB_FRAMEs a partir do AOB_FRAME ns x até o AOB_FRAME ns x+f(t) -1 são informados para o desamontoador 7 e o processamento nas etapas S62 até S73 é repetido. O procedimento acima incrementa as variáveis ne x e ns y que indicam o AOB_FRAME n8 x e o AOB_ELEMENT n8 y e desse modo avança a posição de execução. Após isto, se o usuário pressionar a tecla "Play", o julgamento " Não" é dado na Figura 74 e o processamento no presente flu- xograma termina. {52-11} Execução da Função de Pesquisa de Tempo O dito a seguir descreve o processamento executado quando a função de pesquisa de tempo é utilizada. Primeiro, as trilhas na Informação da Lista de Execução Preestabelecida são exibidas e o usuário indica uma trilha desejada. Quando esta trilha foi indicada e o usuário operou o mostra- dor de mudança de direção, o código de tempo de execução é atualizado.

Se o usuário então pressiona a tecla "Play", o código de tempo de execução neste ponto é utilizado para estabelecer um valor na variável "Jmp_Entry" em segundos.

Um julgamento é então feito em relação a se a trilha indicada é composta de uma pluralidade de AOBs ou de um único AOB. Quando a tri- lha é composta de um único AOB, as variáveis n8 y e n8 x são calculadas de modo a satisfazer a Equação 2. Após isto, uma pesquisa em relação ao AOB_FRAME n8 x é iniciada a partir do endereço na (y+2)â posição na TKTMSRT correspondendo a este AOB. Uma vez que este AOB_FRAME n8 x tenha sido encontrado, a execução começa a partir do AOB_FRAME n8 x. {52-12} Quando a trilha é composta de uma pluralidade de AOBs, as variáveis η8 n (indicando um AOB), n8 y, e n8 x são calculadas de modo a satisfazer a Equação 3. Após isto, é iniciada uma pesquisa em relação ao AOB_FRAME n8 x a partir do endereço na (y+2)â posição na TKTMSRT cor- respondendo ao AOB n8 n. Uma vez que este AOB_FRAME n8 x tenha sido encontrado, a execução começa a partir do AOB_FRAME n8 x. O dito a seguir descreve o caso quando a execução é começada a partir de uma posição arbitrária com um AOB onde o "FNs_1st_TMSRTE" no BIT é "80 quadros", o "FNs_Middle_TMSRTE" no BIT é "94 quadros" e o "FNs_Last_TMSRTE" no BIT é "50 quadros". {52-13_62A,B} Como um exemplo específico de quando a função de pesquisa de tempo é utilizada, o dito a seguir descreve como o AOB_ELEMENT e a posição do quadro a partir da qual a execução deve começar são especifi- cados quando um código de tempo de execução é indicado utilizando o mostrador de mudança de direção.

Como apresentado na Figura 62A, o usuário segura o aparelho de execução na sua mão e gira o mostrador de mudança de direção com seu polegar direito para indicar o código de tempo de execução "00:04:40.000 (=240 segs.). Quando o BIT na TKI para este AOB é como apresentado na Figura 62B, a Equação 2 é utilizada como se segue: 280 segs. = (FNs_1 st_TMSRTE + (FNs_Middle_TMSRTE*y)+x)*20 msegs. = (80+(94*148)+8)*20 msegs. de modo que a Equação 2 é satisfeita para os valores y=148 e x=8.

Desde que y=148, o endereço da entrada do AOB_ELEMENT ne 150 (=148+2) é obtido a partir da TKTMSRT. A execução a partir do código de tempo indicado 00:04:40.000 (=280,00 segs.) pode então se executada por se iniciar a execução no oitavo AOB_FRAME a partir deste endereço de entrada. {52-14_63_64_65} Isto completa a explicação do processamento da CPU 10 em resposta ao usuário pressionar a tecla "Play". O dito a seguir descreve o programa de controle de edição armazenado na ROM 4. Este programa de controle de edição é executado quando o usuário pressiona a tecla "Edit" e contém os procedimentos apresentados nas Figuras 63, 64 e 65. O dito a seguir descreve o processamento neste programa com os fluxogramas apresentados nestes desenhos. {52-14_63-1) Programa de Controle de Edição Quando o usuário pressiona a tecla "Edit", uma tela interativa é exibida na etapa S101 na Figura 63 para perguntar ao usuário qual das três operações de edição fundamentais "deleção", "divisão" e "combinação" é para ser executada. Na etapa S102, a CPU 10 julga que operação foi feita pelo usuário em resposta à tela interativa. No exemplo presente, é assumido que as teclas "l«" e "»Γ no painel de teclas também são utilizadas como indicando as operações de cursor "Para cima" e "Para baixo", (isto é, estas teclas são utilizadas como as teclas cursoras "para cima" e "para baixo").

Quando o usuário indica uma operação de "deleção", o processamento con- tinua para o procedimento de repetição composto das etapas S103 e S104.

Na etapa S103, a CPU 10 julga se o usuário pressionou a tecla "l«" ou "»l Na etapa S104, a CPU 10 julga se o usuário pressiona a te- cla "Edit". Quando o usuário pressionou a tecla "l«" ou "»l", o processa- mento avança da etapa S103 para S105, onde a trilha indicada é estabele- cida como a trilha a ser editada. Por outro lado, quando o usuário pressio- nou a tecla "Edit", a trilha indicada é estabelecida como a trilha a ser dele- tada. O processamento apresentado na Figura 44 é executado, de modo que o TKi_BLK_ATR de cada TKI para a trilha indicada é estabelecido como "Não-Utilizado" para deletar a trilha indicada. {52-14_63-2} Processo de Combinação Quando o usuário seleciona o processo de combinação, o pro- cessamento continua da etapa S102 para o procedimento de repetição composto das etapas S107 até S109. No procedimento de repetição com- posto das etapas S107 até S109, o aparelho de execução recebe as entra- das do usuário via as teclas "l«", "»l", e "Edit". Quando o usuário pressio- na a tecla "l«" ou "»Γ, o processamento avança da etapa S107 para a etapa S110 onde a trilha indicada é realçada no vídeo. Quando o usuário pressiona a tecla "Edit", o julgamento "Sim" é dado na etapa S108 e o pro- cessamento avança para a etapa S111. Na etapa S111, a trilha atualmente indicada é estabelecida como a primeira trilha a ser utilizada neste processo de edição e o processamento retorna para o procedimento de repetição composto das etapas S107 até S109.

Quando uma segunda trilha foi selecionada para edição, o jul- gamento "Sim" é dado na etapa S109 e o processamento avança para a etapa S112. Na etapa S112, a CPU 110 refere-se à BIT nas TKIs da primei- ra e da últimas trilhas e julga que tipo de AOBs (Tipo 1 ou Tipo 2) estão pre- sentes nos respectivos início e fim de cada uma destas trilhas e das trilha sem ambos os lados destas trilhas, se presente.

Após identificar o tipo de cada AOB relevante, na etapa S113 a CPU 10 julga se a disposição dos AOBs combina com um certo padrão.

Quando a disposição dos AOBs combina com um dos quatro padrões apre- sentados na Figura 32A até 32D, onde é claro que três AOBs Tipo 2 não estarão presentes consecutivamente após a combinação, a primeira e a úl- tima trilha são combinadas em uma única trilha na etapa S115.

Em outras palavras, a operação apresentada na Figura 46 é executada para a TKI e para o DPL_TK_SRP correspondendo a estes AOBs. Por gravar novamente os TKI_BLK_ATRs nas TKIs, a pluralidade de trilhas selecionadas para edição são combinadas em uma única trilha.

Quando a disposição dos AOBs não combina com qualquer um dos padrões nas Figuras 32A até 32D, significando que existirão três ou mais AOBs Tipo 2 após a combinação, a CPU 10 julga se a trilha combinada pode causar um fluxo inferior no buffer e desse modo termina o processo de combinação. {52-14_64-1} Processo de Divisão de Trilha Quando o usuário indica que uma trilha é para ser dividida, o processamento avança da etapa S102 para o procedimento de repetição composto das etapas S116 até S117. No procedimento de repetição com- posto das etapas S116 até S117, o aparelho de execução recebe as entra- das do usuário via as teclas "l«", "»l" e "Edit".

Quando o usuário pressiona a tecla "l«" ou »l", o processa- mento avança da etapa S116 para a etapa S118, onde a trilha indicada é estabelecida como a trilha a ser editada. Quando o usuário pressiona a te- cla "Edit", o julgamento "Sim" é dado na etapa S117 e o processamento avança para a etapa S119.

Na etapa S119, a trilha indica é determinada como a trilha a ser editada e o processamento avança para a etapa S120 onde a execução desta trilha é começada. Na etapa S121, o aparelho de execução recebe uma entrada do usuário via a tecla "Mark".

Quando o usuário pressiona a tecla "Mark", a execução da trilha é paralisada e o processamento avança para o procedimento de repetição composto das etapas S122 e S123. Na Etapa S122, o aparelho de execução recebe as operações do usuário feitas via o mostrador de mudança de dire- ção. Quando o usuário gira o mostrador de mudança de direção, o código de tempo de execução é atualizado na etapa S124 de acordo com a rotação do mostrador de mudança de direção.

Após isto, o procedimento de repetição composto das etapas S122 e S123 é repetido. Se o usuário pressionar a tecla "Edit", o processa- mento continua da etapa S123 para a etapa S125, onde o código de tempo de execução exibido quando o usuário pressionou a tecla "Edit" é estabele- cido como o limite da divisão. Observe que uma função "Desfaz" pode ser proporcionada para este estabelecimento do limite da divisão para permitir ao usuário invalidar o limite da divisão selecionado.

Após isto, o processamento explicado com referência ã Figura 47 é executado na etapa S126 para atualizar a DPLI e a TKI de modo a di- vidir a trilha selecionada. {52-14_65-1} Processo Estabelecendo uma Lista de Execução Quando o usuário escolhe estabelecer uma Lista de Execução, o processamento troca para o procedimento apresentado pelo fluxograma na Figura 65. Neste fluxograma, a variável k dada neste fluxograma é utili- zada para indicar a posição de uma trilha na ordem de execução dada pela Lista de Execução que está sendo editada. O fluxograma na Figura 65 co- meça com esta variável k sendo inicializada para "1" na etapa S131, antes do processamento avançar para o procedimento de execução composto das etapas S132 até S134.

No procedimento de repetição composto das etapas S132 até S134, o aparelho de execução recebe as operações do usuário feitas via as teclas "l«", "»l", "Edit" e "Stop". Quando o usuário pressiona a tecla "l«" ou "»l", o processamento avança da etapa S132 para a etapa S135, onde uma nova trilha é indicada de acordo com a pressão da tecla Ί«" ou "»l".

Se o usuário pressionar a tecla "Edit", o julgamento "Sim" é dado na etapa S133 e o processamento avança para a etapa S136.

Na Etapa S136, a trilha indicada quando o usuário pressiona a tecla "Edit" é selecionada como a ks trilha na ordem de execução. Após isto, na etapa S137 a variável k é incrementada e o processamento retorna para o procedimento de repetição composto das etapas S132 até S134. Este procedimento é repetido de modo que a segunda, terceira e quarta trilhas são sucessivamente selecionadas. Se o usuário pressionar a tecla "Stop" tendo especificado várias trilhas que são para serem executada na ordem especificada como uma nova Lista de Execução, o processamento avança da etapa S134 para a etapa S138, onde uma PLI composta dos PL_TK_SRPs que especificam as TKIs correspondentes a estas trilhas é gerada. {66-1} Aparelho de Gravação O dito a seguir descreve um exemplo de um aparelho de grava- ção para o cartão de memória flash 31. A Figura 66 apresenta um exemplo de um aparelho de gravação. Este aparelho de gravação pode ser conecta- do com a Internet e é um computador pessoal padrão que pode executar a recepção quando um diretório SD-Áudio criptografado é enviado via as li- nhas de comunicação para o aparelho de gravação por um serviço eletrôni- cos de distribuição de música, ou quando um fluxo de transporte de dados de áudio é enviado via as linhas de comunicação para o aparelho de grava- ção por um serviço eletrônico de distribuição de música. {67-1} Composição do Hardware do Aparelho de Gravação A Figura 67 apresenta a composição do Hardware do presente aparelho de gravação.

Como apresentado na Figura 67, o aparelho de gravação inclui um conector de cartão 21 para conectar o aparelho de gravação com o car- tão de memória flash 31, uma RAM 22, um aparelho de disco não-removível 23 para armazenar um programa de controle de gravação que executa o controle geral sobre o aparelho de gravação, um conversor A/D 24 que con- verte A/D o áudio informado via um microfone para produzir dados PCM, um codificador AAC 25 para codificar os dados PCM em unidades de um tempo fixo e designar os cabeçalhos ADTS para produzir os AOB_FRAMEs, uma unidade de amontoamento 26 para criptografar os AOB_FRAMEs utilizando uma FileKey diferente para cada AOB_BL.OCK, um aparelho de modem 27 para receber um fluxo de transporte de dados de áudio quando um diretório SD-Áudio criptografado é enviado via as linhas de comunicação para o apa- relho de gravação por um serviço eletrônico de distribuição de música, ou quando um fluxo de transporte de dados de áudio é enviado via linhas de comunicação para o aparelho de gravação por um serviço eletrônico de dis- tribuição de música, uma CPU 28 para executar o controle geral sobre o aparelho de gravação, um teclado 29 para receber entradas feitas pelo usu- ário e um vídeo 30. {67-2} Circuitos de Entrada RT1 até RT4 Quando um diretório SD-Áudio criptografado, que é para ser gravado na região de dados e na região de autenticação é enviado via li- nhas de comunicação para o aparelho de gravação por um serviço eletrôni- co de distribuição de música, o aparelho de gravação pode gravar o diretó- rio SD-Áudio criptografado na região de dados e na região de autenticação do cartão de memória flash 31 assim que o diretório SD-Áudio criptografado tenha sido recebido de forma apropriada.

Entretanto, (1) quando um fluxo de transporte de dados de áudio que não está na forma do diretório SD-Áudio é enviado para o aparelho de gravação por um serviço eletrônico de distribuição de música, (2) quando os dados são informados para o aparelho de gravação no formato PCM, ou (3) quando áudio analógico é gravado pelo aparelho de gravação, o aparelho de gravação utiliza as seguinte quatro rotas de entrada para gravar um fluxo de transporte de dados de áudio dentro do cartão de memória flash 31.

Como apresentado na Figura 67, as quatro rotas de entrada RT1, RT2, RT3 3 RT4 são utilizadas para informar um fluxo de transporte de dados de áudio quando um fluxo de transporte de dados de áudio é arma- zenado no cartão de memória flash 31. {67-3} Rota de Entrada RT1 A rota de entrada RT1 é utilizada quando um diretório SD-Áudio criptografado é enviado via as linhas de comunicação para o aparelho de gravação por um serviço eletrônico de distribuição de música, ou quando um fluxo de transporte de dados de áudio é enviado via as linhas de comu- nicação para o aparelho de gravação por um serviço eletrônico de distribui- ção de música. Neste caso, os AOB_FRAMEs incluídos no fluxo de trans- porte são criptografados de modo que uma FileKey diferente é utilizada para os AOB_FRAMEs em AOBs diferentes. Desde que não existe necessidade de criptografar ou codificar um fluxo de transporte criptografado, o diretório SD-Áudio ou o fluxo de transporte de dados de áudio pode ser armazenado diretamente na RAM 22 em seu estado criptografado. {67-4} Rota de Entrada RT2 A rota de entrada RT2 é utilizada quando o áudio é informado via um microfone. Neste caso, o áudio informado via o microfone é sujeito a uma conversão A/D pelo conversor A/D 24 para produzir Dados PCM. Os dados PCM são então codificados pelo codificador AAC 25 e tem os cabe- çalhos ADTS designados para produzir AOB_FRAMEs. Após isto, a unidade de amontoamento 26 criptografa os AOB_FRAMEs utilizando uma FileKey diferente para cada AOB_FRAMEs em AOB_FILEs diferentes para produzir os dados de áudio criptografados. Após isto, os dados de áudio criptografa- dos são armazenados na RAM 22. {67-5} Rota de Entrada RT3 A rota de entrada RT3 é utilizada quando os dados PCM lidos de um CD são informados dentro do aparelho de gravação. Desde que os dados são informados no formato PCM, os dados podem ser informados como se eles estivessem dentro do codificador AAC 25. Estes dados PCM são codificados pelo codificador AAC 25 e têm cabeçalhos ADTS designa- dos para produzir AOB_FRAMEs.

Após isto, a unidade de amontoamento 26 criptografa os AOB_FRAMEs utilizando uma FileKey diferente para os AOB_FRAMEs em AOBs diferentes para produzir dados de áudio criptografados. Após isto, os dados de áudio criptografados são armazenados na RAM 22. {67-6} Rota de Entrada RT4 A rota de entrada RT4 é utilizada quando um fluxo de transporte informado via uma das três rotas de entrada RT1, RT2 e RT3 é gravado no cartão de memória flash 31.

Este armazenamento dos dados de áudio é acompanhado pela geração das TKIs e da Informação da Lista de Execução Preestabelecida.

Do mesmo modo que o aparelho de execução, a funcionalidade principal do aparelho de gravação é armazenada na ROM. Ou seja, um programa de gravação que inclui o processamento característico do aparelho de grava- ção, ou seja, a gravação dos AOBs, o Gerente de Trilha e o Gerente de Lista de Execução, é armazenado no aparelho de disco não-removível 23. {67-7_68} Processamento do Aparelho de Gravação O dito a seguir descreve o processamento no procedimento de gravação que grava um fluxo de transporte no cartão de memória flash 31 via as rotas de entrada RT1, RT2, RT3 e RT4, com referência ao fluxograma na Figura 68 que apresenta este processamento.

As variáveis "Frame_Number" e ''Data_Size" utilizadas neste fluxograma são como se segue. A variável Frame_Number é utilizada para gerenciar o número total de AOB_FRAMEs que já foram gravados em um AOB_FILE. A variável Data_Size é utilizada para gerenciar o tamanho dos dados dos AOB_FRAMEs que já foram gravados no AOB_FILE. O processamento neste fluxograma começa na etapa S200 com a CPU 28 gerando a Lista de Execução Preestabelecida e o Gerente de Trilha. Na etapa S201, a CPU 28 inicializa a variável n® z (z 1). Na etapa S202, a CPU 28 gera o AOB_FILE ns z e armazena o mesmo na região de dados do cartão de memória flash 31. Neste ponto, o nome do arquivo, a extensão do nome do arquivo e o primeiro número de cluster para o AOB_FILE nõ z serão estabelecidos em uma entrada do diretório no Diretó- rio SD-Áudio na região de dados. Após isto, na etapa S203, a CPU 28 gera a TKI ns z e armazena a mesma no Gerente de Trilha. Na etapa S204, a CPU 28 gera o DPL_TK_SRP ne w e armazena o mesmo na Informação de Lista de Execução Preestabelecida. Após isto, na etapa S205, a CPU 28 inicializa a variável n® y (n® y 1) e na etapa S206, a CPU 28 inicializa o Frame_Number e o Data_Size (Frame_Number <- 0, Data_Size <- 0).

Na etapa S207, a CPU 28 julga se a entrada do fluxo de trans- porte de dados de áudio que deve ser gravada no AOB_FILE ns terminou Quando a entrada de um fluxo de transporte de dados de áudio que foi co- dificado pelo codificador AAC 25 e criptografado pela unidade de amontoa- mento 26 na RAM 22 continuar e for necessário continuar a gravação dos dados do cluster, a CPU 28 dá o julgamento "Não" na etapa S207 e o pro- cessamento avança para a etapa S209.

Na etapa 209, a CPU julga se a quantidade de dados de áudio AAC que acumulou na RAM 22 é pelo menos igual ao tamanho do cluster.

Se sim, a CPU 28 da o julgamento "Sim" e o processamento avança para a etapa S210, onde uma quantidade de dados de áudio AAC igual ao tama- nho do cluster é gravada no cartão de memória flash 31. O processamento então vai para a etapa S211.

Quando dados de áudio AAC suficiente não acumulou na RAM 22, a etapa S210 é saltada e o processamento avança para a etapa S211.

Na etapa S211, a CPU incrementa o Frame_Number (Frame_Number <- Frame_Number + 1) e aumenta o valor da variável Data_Size pelo tamanho dos dados do AOB_FRAME.

Após esta atualização, na etapa S212, a CPU 28 julga se o valor do Frame_Number alcançou o número de quadros que está estabelecido em "FNs_Middle_TMSRTE", o valor de "FNs_Middle_TMSRTE" é estabelecido de acordo com a freqüência de amostragem utilizada quando codificando o fluxo de transporte de dados de áudio. Quando o valor de Frame_Number alcançou o número de quadros estabelecido em "FNs_Middle_TMSRTE", a CPU 28 dá o julgamento "Sim" na etapa S212.

Se não, a CPU 28 dá o julgamento "Não" e o processamento retorna para a etapa S207. O processamento nas etapas S207 até S212 é portanto repeti- do até que o julgamento "Sim" seja dado na etapa S207 ou na etapa S212.

Quando a variável Frame_Number alcança o valor de "FNs_Middle_TMSRTE", a CPU 28 dá o julgamento "Sim" na etapa S212 e o processamento avança da etapa S212 para a etapa S213, onde Data_Size é armazenado na TKTMSRT da TKI ne z como a TMSRT_entry ηθ y para o AOB_ELEMENT ne y. Na etapa S214, a CPU 28 incrementa a variável ns y (n-°y^ney + 1) antes de verificar na etapa S215 se a variável n° y alcançou "252". O valor ''252" é utilizado desde que é o número máximo de AOB-ELEMENTs que podem ser armazenados em um único AOB. Se a va- riável ne y estiver abaixo de 252, o processamento avança para a etapa S216, onde a CPU 28 julga se um silêncio de um comprimento predetermi- nado está presente no áudio codificado, ou seja, se os dados de áudio al- cançaram uma brecha presente entre as trilhas. Quando nenhum tal silêncio contínuo está presente, o processamento composto das etapas S206 até S215 é repetido. Quando a variável n° y alcançou o valor 252, ou um silên- cio de um comprimento predeterminado está presente no áudio codificado, o julgamento "Sim" é dado em uma das etapas S215 e S216 e o processa- mento avança para a etapa S217 onde a variável n° z é incrementada (ne z <-nez + 1).

Após isto, o processamento nas etapas S202 até S216 é repeti- do para a variável ns z incrementada. Por repetir este processamento, a CPU 28 pode ter AOBs incluindo uma pluralidade de AOB_ELEMENTs gra- vado um após o outro dentro do cartão de memória flash 31.

Quando a transferência de um fluxo de transporte de dados de áudio pelo codificador AAC 25, pela unidade de amontoamento 26 e pelo aparelho de modem 27 está completa, isto significa que a entrada do fluxo de transporte de dados de áudio a ser gravado dentro do AOB_FILE ne z também estará completa, de modo que o julgamento "Sim" é dado na etapa S207 e o processamento avança para a etapa S208. Na etapa S208, a CPU 28 armazena o valor da variável Data_Size na TKTMSRT da TKI ns z como a TMSRT_entry ηθ y para o AOB_ELEMENT na y. Após armazenar os dados de áudio acumulados na RAM 22 no arquivo AOB correspondendo ao AOB ns z, o processamento neste fluxograma termina. O processamento acima resulta em um fluxo de transporte de dados de áudio sendo armazenado no cartão de memória flash 31. O pro- cedimento seguinte é então utilizado para armazenar a FileKey requerida para decriptografar este fluxo de transporte de dados de áudio criptografado na região de autenticação.

Quando o fluxo de transporte dos dados de áudio foi informado via a rota de entrada RT1, o arquivo(s) AOB, o arquivo armazenando a TKGM, o arquivo armazenando a PLMG e o arquivo de armazenamento da chave de criptografia armazenando uma FileKey diferente para cada AOB são enviados para o aparelho de gravação por um provedor do serviço ele- trônico de distribuição de música. A CPU 28 recebe estes arquivos e grafa o arquivo(s) AOB, o arquivo armazenando o TKGM e o arquivo armazenando o PLMG dentro da região do usuário do cartão de memória flash 31. Por outro lado, a CPU 28 grava somente o arquivo armazenando a chave de criptografia armazenando uma FileKey diferente para cada AOB dentro da região de autenticação.

Quando o áudio é informado via a rota de entrada RT2 ou RT3, a CPU 28 gera uma FileKey diferente cada vez que a codificação de um novo AOB começa e estabelece a chave gerada na unidade de amontoa- mento 26. Em adição a ser utilizada pela unidade de amontoamento 26 para criptografar o presente AOB, esta FileKey é armazenada seguindo a Entra- da de FileKey no arquivo de armazenamento da chave de criptografia pre- sente na região de autenticação.

Com a presente concretização descrita acima, os arquivos ar- mazenados os AOBs são criptografados utilizando-se chaves de criptografia diferentes, de modo que se a chave de criptografia utilizada para criptogra- far um arquivo for decodificada e exposta, a chave de criptografia exposta somente pode ser utilizada para decriptografar um arquivo armazenando um AOB, com tal exposição não possuindo efeito sobre outros AOBs que estão armazenados em outros arquivos. Isto minimiza o prejuízo causado quando uma chave de criptografia é exposta.

Observe que ao mesmo tempo que a descrição acima focaliza um sistema exemplo que é pensado como sendo a concretização mais efi- caz da presente invenção, a invenção não está limitada a este sistema. Vá- rias modificações são possíveis dentro do escopo da invenção, com exem- plos de tais modificações sendo dados como (a) até (e) abaixo. (a) A concretização acima descreve uma memória semiconduto- ra (cartão de memória flash) como o meio de gravação utilizado, no entanto, a presente invenção pode ser aplicada com outro meio, incluindo discos óti- cos, tal como o DVD-RAM, ou um disco rígido. (b) Na concretização acima, os dados de áudio foram descritos como estando no formato AAC, no entanto, a presente invenção também pode ser aplicada com dados de áudio em outro formato tal como MP3 (MPEG1 Áudio Layer 3), Dolby-AC3, ou DTS (Digital Theater System). (c) Ao mesmo tempo que o arquivo armazenando o TKMG e o arquivo armazenando o PLMG foram descritos como sendo recebidos a partir do provedor do serviço eletrônico de distribuição de música em uma forma completa, a informação principal utilizada para criar o TKGM e o PLMG pode ser transmitida junto com o arquivo de armazenamento da cha- ve de criptografia que armazena uma chave de criptografia diferente para cada AOB. O aparelho de gravação pode então processar esta informação para obter o TKMG e o PLMG que ele então grava no cartão de memória flash. (d) Para facilidade de explicação, o aparelho de gravação e o aparelho de execução foram descritos como sendo dispositivos separados, no entanto, um aparelho de execução portátil pode ser equipado com o fun- cionamento do aparelho de gravação e um aparelho de gravação na forma de um computador pessoal pode ser equipado com as funções do aparelho de execução. À parte do aparelho de execução portátil e do aparelho de gravação do computador pessoal, as funções do aparelho de execução e do aparelho de gravação também podem ser proporcionadas para um dispositi- vo de comunicação que seja capaz de transferir o conteúdo de uma rede.

Como um exemplo, um telefone móvel capaz de acesso à Inter- net pode ser proporcionado com as funções do aparelho de execução e do aparelho de gravação descritas na concretização acima. Este telefone mó- vel pode armazenar os conteúdos transferidos via uma rede sem fios no cartão de memória flash 31 do mesmo modo que na concretização acima.

Além disso, ao mesmo tempo que o aparelho de gravação descrito na con- cretização acima é proporcionado com um aparelho de modem 27 para co- nexão com a Internet, qualquer outro dispositivo capaz de conexão com a Internet, tal como um adaptador de terminal para uma linha ISDN, pode ao invés disso ser proporcionado. (e) Os procedimentos apresentados nos fluxogramas apresen- tados nas Figuras 55 até 58, Figura 60, Figura 63 até Figura 65 e Figura 68 podem ser realizados por programas executáveis que podem ser distribuí- dos e vendidos tendo sido gravados em um meio de gravação. Este meio de gravação pode ser um cartão IC, um disco ótico, um disco flexível, ou se- melhante, com o programa gravado no meio de gravação sendo utilizado tendo primeiro sido instalado dentro do hardware padrão do computador.

Por executar o processamento de acordo com tais programas instalados, o hardware padrão do computador pode executar o mesmo funcionamento que o aparelho de execução e aparelho de gravação descritos na concreti- zação acima. (f) Enquanto a concretização acima descreve o caso onde uma pluralidade de AOBs e uma pluralidade de FileKeys são armazenados no cartão de memória flash 31, somente um AOB e uma FileKey necessitam ser armazenados. Além disso, não é essencial para os AOBs serem cripto- grafados, de modo que os AOBs podem ser armazenados no cartão de me- mória flash 31 no formato ACC.

SEGUNDA CONCRETIZAÇÃO A primeira concretização somente menciona as regiões de ar- mazenamento diferentes no cartão de memória flash 31 e não descreve a construção de hardware interna utilizada. Esta segunda concretização, en- tretanto, descreve a construção do hardware do cartão de memória flash 31 em detalhes. {69-1} Configuração do Hardware do Cartão de Memória Flash 31 A Figura 69 apresenta a construção do hardware do cartão de memória flash 31. Como apresentado na Figura 69, o cartão de memória flash 31 inclui três chips IC, a saber, o IC de controle 302, a memória flash 303 e a ROM 304. A ROM 304 inclui a região especial descrita na primeira concre- tização e é utilizada para armazenar o ID do meio mencionado na primeira concretização, em adição a um ID do meio seguro 343 que é produzido por se criptografar o ID do meio seguro. O IC de controle 302 é um circuito de controle composto de elementos ativos (portas lógicas) e inclui uma unidade de autorização 321, uma unidade de decodificação de comando 322, uma unidade de armaze- namento de chave mestra 323, uma unidade de controle de acesso a região especial 324, uma unidade de controle de acesso a região de autenticação 325, uma unidade de controle de acesso a região que não é de autentica- ção 326 e um circuito de criptografia/decriptografia 327. A unidade de autorização 321 é um circuito que executa a au- tenticação mútua no formato de desafio-resposta com um dispositivo que tenta acessar o cartão de memória flash 31. Esta unidade de autorização 321 inclui um gerador de número randômico, um criptografador e seme- lhante e verifica se o dispositivo tentando acessar o cartão de memória flash 31 é autêntico por detectar se o dispositivo inclui o mesmo criptografador que a unidade de autorização 321.

Aqui, a autenticação mútua no formato de desafio-resposta si- gnifica que um primeiro dispositivo envia dados de desafio para outro dispo- sitivo para verificar a autenticidade do outro dispositivo. O outro dispositivo processa estes dados de desafio de um modo predeterminado de modo a provar sua autenticidade e envia os dados resultantes para o primeiro dis- positivo como dados da resposta. O primeiro dispositivo compra os dados do desafio com os dados da resposta para julgar se o outro dispositivo deve ser autênticado. Desde que isto é uma autenticação mútua, o processa- mento é então repetido com os dispositivos trocando os papéis. A unidade de decodificação de comando 322 é um controlador que inclui um circuito de decodificação, um circuito de controle e seme- lhantes que interpretam e executam um comando (uma instrução para o cartão de memória flash 31) que foi informado via o pino de COMANDO. A unidade de decodificação de comando 322 controla os componentes 321 até 327 no IC de controle 302 de acordo com o tipo de comando informado. O comando emitido para o cartão de memória flash 31 inclui comandos que lêem, gravam ou deletam dados na memória flash 303. Como exemplos de comandos relacionados com a leitura e a gravação de dados, os comandos "SecureRead address count" e "SecureWrite address count" acessam a região de autenticação, enquanto os comandos Read address count" e "Write address count" acessam a região que não é de autentica- ção. Nestes comandos, o "address" é o número do primeiro setor a ser acessado na área sujeita a leitura (ou gravação), enquanto o "count" é o número total de setores a serem lidos (ou gravados). Neste caso, um setor é a unidade utilizada para a leitura e gravação de dados no cartão de memó- ria flash 31, que é 512 bytes no presente exemplo. A unidade de armazenamento da chave mestra 323 armazena a chave mestra 323a em um estado criptografado antecipadamente. A chave mestra é a chave de criptografia utilizada para criptografar o ID do meio.

Quando o cartão de memória flash 31 está conectado com um dispositivo, a chave mestra 323a é passada para o dispositivo em sua forma criptografa- da. A chave mestra 323a é criptografada de um modo que somente permite a decriptografia por um dispositivo que receba a chave mestra utilizando a informação especial da chave (geralmente chamada de uma "chave do dis- positivo"). A unidade de controle de acesso a região especial 324 é um circuito que o ID do meio armazenado na ROM 304 que proporciona a regi- ão especial. O ID do meio lido pela unidade de controle de acesso a região especial 324 é passado para um dispositivo conectado com o cartão de memória flash 31 que então criptografa o ID do meio utilizando a chave mestre obtida pela decriptografia da chave mestra criptografada utilizando a chave do dispositivo. A unidade de controle de acesso a região de autenticação 325 e a unidade de controle de acesso a região que não é de autenticação 326 são circuitos que executam as leituras de dados e as gravações de dados para a região de autenticação e para a região que não é de autenticação, respectivamente, na memória flash 303. Esta unidade de controle de acesso a região de autenticação 325 e a unidade de controle de acesso à região que não é de autenticação 326 transferem os dados para e de um dispositi- vo externo (tal como o aparelho de gravação e o aparelho de execução des- critos na primeira concretização).

Observe que estas unidades de controle de acesso 325 e 326 cada uma inclui um buffer interno capaz de armazenar um bloco de dados e executar a entrada e a saída via os pinos marcados DADOS 1 ATÉ DADOS 4. Em termos lógicos, tais entrada e saída são executadas em unidades de setores, mas quando o conteúdo da memória flash 303 é gravado por cima, os dados são informados ou emitidos em unidades de bloco (cada bloco possuindo 32 setores (16 KB) em tamanho). Em mais detalhes, quando os dados em um setor são gravados por cima, o bloco apropriado é lido a partir da memória flash 303 e armazenado no buffer na unidade de controle de acesso apropriada, o bloco é deletado da memória flash, o setor apropriado na memória do buffer é regravado e o bloco na memória do buffer é então gravado novamente na memória flash 303. O circuito de criptografia/decriptografia 327 executa a criptogra- fia e a decriptografia utilizando a chave mestra 323a armazenada na unida- de de armazenamento da chave mestra 323 sob o controle da unidade de controle de acesso a região de autenticação 325 ou da unidade de controle de acesso a região que não é de autenticação 326. Quando os dados são para serem gravados na memória flash 303, o circuito de criptogra- fia/decriptografia 327 criptografa os dados e grava os mesmo na memória flash 303. Inversamente, quando os dados são para serem lidos a partir da memória flash 303, o circuito de criptografia/decriptografia 327 decriptografa os dados. Este circuito de criptografia/decriptografia 327 é proporcionado para impedir usuários de executar atos não-autorizados, tal como desman- telar o cartão de memória flash 31 e diretamente analisar o conteúdo da memória flash 303 para obter as senhas armazenadas na região de autenti- cação. {69-70} Seqüência de Comunicação quando Executando os AOBs A Figura 70 apresenta a seqüência de comunicação executada quando um aparelho de execução conectado com o cartão de memória flash lê a FileKey da chave de criptografia e executa um AOB. O aparelho de execução emite um comando para ler a chave mestra para o cartão de memória flash 31 (sc1). Uma vez que este comando é emitido, a unidade de decodificação de comando 322 obtém a chave mestra criptografada 323b que está armazenada na unidade de armazena- mento da chave mestra 323 e passa a mesma para o aparelho de execução (sc2). O aparelho de execução que recebe o ID do meio seguro utiliza a chave do dispositivo 211a que ele próprio armazena para decriptografar o ID do meio seguro (sc3). O algoritmo de decriptografia utilizado no processo de decriptografia corresponde ao algoritmo de criptografia que foi utilizado quando gerando-se a chave mestra criptografada 323b armazenada no cartão de memória flash 31, de modo que se a chave do dispositivo 211a utilizada pelo aparelho de execução for uma chave cujo uso é esperado (isto é, uma chave apropriada), o aparelho de execução estará apto a obter com sucesso a chave mestra por executar esta decriptografia.

Após receber a chave mestra, o aparelho de execução emite um comando especial para o cartão de memória flash 31 para ler o ID do meio (sc4). A unidade de controle de acesso a região especial 324 obtém o ID do meio a partir da ROM 304 do cartão de memória flash 31 e passa o mesmo para o aparelho de execução (sc5). O circuito de criptografia/decriptografia 327 então criptografa o ID do meio utilizando a chave mestra obtida através do processo de decriptografia acima (sc6). O algoritmo utilizado para esta criptografia é o mesmo que o algoritmo que foi utilizado para gerar o ID do meio seguro 343 armazenado no cartão de memória flash 31. Como resulta- do, um ID do meio seguro que é o mesmo que o ID do meio seguro 343 do cartão de memória flash 31 é obtido. O aparelho de execução que teve sucesso em obter o ID do meio seguro então executa a autenticação mútua com a unidade de autori- zação 321 do cartão de memória flash 31 (sc7). Este processo resulta em tanto o aparelho de execução como a unidade de autorização 321 tendo (a) a informação ((OK/NG) apresentando se o outro dispositivo foi autênticado com sucesso e (b) uma chave segura com tempo variante cujo conteúdo depende do resultado da autenticação.

Quando a autenticação mútua é bem sucedida, o aparelho de execução gera um comando para acessar a região de autenticação do car- tão de memória flash 31. Como um exemplo, quando os dados são para se- rem lidos a partir da região de autenticação, o aparelho de execução cripto- grafa os parâmetros (isto é, um "address" de endereço de 24 bits e um "count" de comprimento de dados de oito bits) do comando "SecureRead address count" utilizando a chave segura (sc8) e liga estes parâmetros com o rótuio deste comando (isto é, o código de 6 bits apresentando que este comando é um "SecureRead") para produzir um comando criptografado (sc9), que o aparelho de execução envia para o cartão de memória flash 31 (sc10).

Ao receber este comando criptografado, o cartão de memória flash 31 identifica o tipo do comando a partir do rótulo (sc11). No presente exemplo, o cartão de memória flash 31 identifica que o comando é um co- mando "SecureRead" para uma leitura da região de autenticação.

Quando um comando de leitura foi identificado, o circuito de criptografia/decriptografia 327 decriptografa os parâmetros incluídos no co- mando utilizando a chave segura (sc12) obtida durante a autenticação mú- tua (sc13). O algoritmo utilizado para decriptografar os parâmetros corres- pondem ao algoritmo de criptografia que foi utilizado pelo aparelho de exe- cução quando gerando o comando criptografado, de modo que quando a autenticação mútua é bem sucedida, ou seja, quando a chave segura no cartão de memória flash 31 combina com a chave segura no aparelho de execução, os parâmetros obtidos por esta decriptografia serão os parâme- tros utilizados pelo aparelho de execução.

Ao receber um comando incluindo os parâmetros válidos, a uni- dade de controle de acesso à região de autenticação 325 acessa os setores especificados pelos parâmetros válidos e lê a FileKey da chave de cripto- grafia armazenada nestes setores da região de autenticação. O circuito de criptografia/decriptografia 327 criptografa a FileKey da chave de criptografia armazenada no arquivo 'AOBSA1.KEY" na região de autenticação (sc15) utilizando a chave segura (sc14) obtida durante a autenticação mútua. Após isto, a unidade de controle de acesso à região de autenticação 325 envia a FileKey da chave de criptografia armazenada no arquivo "AOBSA1.KEY" na região de autenticação para o aparelho de execução (sc16). O aparelho de execução decriptografa (sc18) a FileKey da cha- ve de criptografia que ele recebeu utilizando a chave segura (sc17) obtida durante a autenticação mútua. O algoritmo de decriptografia utilizado aqui corresponde ao algoritmo que foi utilizado pelo cartão de memória flash 31 para criptografar a FileKey da chave de criptografia, de modo que a FileKey da chave de criptografia original pode ser obtida. Após isto, a FileKey da chave de criptografia obtida é decriptografada utilizando-se a chave mestra 323b e o ID do meio para se obter a FileKey da chave de criptografia (sc20).

Uma vez que a FileKey da chave de criptografia tenha sido obti- da e um AOB correspondendo a esta FileKey da chave de criptografia tenha sido lido a partir da região que não é de autenticação (sc21), o AOB é de- criptografado utilizando esta FileKey da chave de criptografia e a música é simultaneamente executada. {69_70_71} Seqüência de Comunicação Detalhada Durante a autentica- ção Mútua A Figura 71 apresenta a seqüência de comunicação utilizada durante a autenticação mútua apresentada na Figura 70 em detalhes. Neste exemplo, o cartão de memória flash 31 e o aparelho de execução executam a autenticação mútua no formato de desafio-resposta. A unidade de autorização 321 no cartão de memória flash 31 gera um número randômico para testar a autenticidade do aparelho de exe- cução (sc30) e envia este número randômico para o aparelho de execução como os dados de desafio (sc50). De modo a provar sua própria autentici- dade, o aparelho de execução criptografa os dados de desafio (sc31) e en- via o resultado para a unidade de autenticação 321 no cartão de memória flash 31 como os dados de resposta (sc32). A unidade de autorização 321 no cartão de memória flash 31 criptografa o número randômico que ela en- viou como os dados de desafio (sc33) e compara este número randômico criptografado com os dados de resposta (sc34).

Quando o número randômico criptografado e os dados de res- posta combinam, o aparelho de execução será autênticado (OK) e o cartão de memória flash 31 irá depois disso aceitar os comandos de acesso para a região de autenticação recebidos a partir do aparelho de execução. Por ou- tro lado, quando o número randômico criptografado e os dados de resposta não combinam, o aparelho de execução não será autênticado e o cartão de memória fiash 31 irá depois disso rejeitar quaisquer comandos de acesso para a região de autenticação recebidos a partir do aparelho de execução. O mesmo procedimento de autenticação é executado pelo apa- relho de execução para verificar se o cartão de memória flash 31 é autênti- co.

Em outras palavras, o aparelho de execução gera um número randômico (sc40) e envia este número randômico para a unidade de autori- zação 321 no cartão de memória flash 31 como dados de desafio (sc51). De modo a provar a autenticidade do cartão de memória flash 31, a unidade de autorização 321 criptografa os dados de desafio (sc41) e envia o resultado para o aparelho de execução como os dados de resposta (sc42). O aparelho de execução criptografa o número randômico que ele enviou como os dados de desafio (sc43) e compara este número randô- mico criptografado com os dados de resposta (sc44).

Quando o número randômico criptografado e os dados de res- posta combinam, o cartão de memória flash 31 será autênticado (OK) e o aparelho de execução depois disso tenta acessar a região de autenticação do cartão de memória flash 31. Por outro lado, quando o número randômico criptografado e os dados de resposta não combinam, o cartão de memória flash 31 não será autênticado (NG) e o aparelho de execução não irá tentar acessar a região de autenticação do cartão de memória flash 31.

Quando o cartão de memória flash 31 e o aparelho de execução são autênticos, o mesmo algoritmo de criptografia será utilizado por ambos os lados na autenticação mútua. Tanto o cartão de memória flash 31 como o aparelho de execução fazem um OT exclusivo dos dois números randômi- cos criptografados (isto é, o número randômico criptografado enviado para o outro lado como dados de desafio e o número randômico criptografado para verificar os dados de resposta recebidos) utilizados nos processos de au- tenticação mútua (sc45, sc46), estabelecem o resultado do XOR exclusivo como uma chave segura que é utilizada quando acessando a região de au- tenticação do cartão de memória flash 31. Deste modo, a mesma chave se- gura será estabelecida no cartão de memória flash 31 e no aparelho de execução somente quando a autenticação mútua tiver sido bem sucedida.

Desde que uma chave segura que é variante com o tempo (isto é, utilizada somente para esta sessão) pode ser compartilhada deste modo, a execução com sucesso do procedimento de autenticação mútua é estabelecido como a condição para o acesso à região de autenticação.

Como uma alternativa, cada lado pode produzir a chave segura por fazer um XOR lógico dos dados de desafio criptografados produzidos por este lado, dos dados de resposta recebidos do outro lado e do ID do meio seguro.

As concretizações acima possuem dados que se relacionam com a proteção dos direitos autorais armazenados na região de autentica- ção e de outros dados armazenados na região que não é de autenticação.

Isto permite a realização de um cartão de memória semicondutora capaz de simultaneamente armazenar tanto produções digitais cujos direitos autorais necessitam ser protegidos como produções digitais não sujeitas a tais restri- ções.

Apesar da presente invenção ter sido totalmente descrita a título de exemplo com referência aos desenhos acompanhantes, é para ser ob- servado que várias alterações e modificações serão aparentes para aqueles versados na técnica. Portanto, a não ser que tais alterações e modificações afastem-se do escopo da presente invenção, elas devem ser construídas como estando incluídas na mesma.

APLICABILIDADE INDUSTRIAL O cartão de memória semicondutora da presente invenção é especialmente adequado para uso no campo de aparelhos eletrônicos do consumidor como um meio de gravação para gravar música ou outro materi- al distribuído eletronicamente ou de outro modo. Os aparelhos de gravação e de execução da presente invenção permitem aos consumidores fazer uso total deste cartão de memória semicondutora.

Claims

1. Cartão de memória semicondutora (31) que armazena pelo menos uma trilha de áudio caracterizado pelo fato de que compreende: uma área protegida que pode ser acessada por um dispositivo conectado ao cartão de memória semicondutora (31) somente se o disposi- tivo for confirmado como autêntico, a área protegida armazenando uma se- quência de chave de criptografia (fk1,fk2,fk3,...) composta de uma pluralida- de de chaves de criptografia dispostas em uma ordem predeterminada; e uma área desprotegida que pode ser acessada por qualquer dispositivo conectado com o cartão de memória semicondutora (31), a área desprotegida armazenando pelo menos uma trilha de áudio (trilhas A-E) e a informação de gerenciamento (TKI#1,TKI#2,TKI#3, ...), pelo menos uma trilha de áudio (trilhas A-E) incluindo uma plura- lidade de objetos de áudio criptografados (AOB001.SA1,AOB002.SA1,...), e a informação de gerenciamento (TKI#1,TKI#2,TKI#3,...) apre- sentando que chave de criptografia, fora da pluralidade de chaves de cripto- grafia, corresponde a cada objeto de áudio (AOB001.SA1,AOB002.SA1,...) armazenado na área desprotegida.

2. Cartão de memória semicondutora, de acordo com a reivindi- cação 1, caracterizado pelo fato de que a informação de gerenciamento (TKI#1,TKI#2,TKI#3,...) apresenta, para cada objeto de áudio (A- OB001.SA1,AOB002.SA1,...), uma posição de armazenamento do objeto de áudio (AOB001 .SA1 ,AOB002.SA1,...) e um número apresentando uma po- sição na sequência de chave de criptografia da chave de criptografia que corresponde ao objeto de áudio (AOB001.SA1,AOB002.SA1,...).

3. Cartão de memória semicondutora, de acordo com a reivindi- cação 2, caracterizado pelo fato de que cada trilha de áudio (trilhas A-E) ainda inclui: (1) informação de atributo (TKI_BLK_ATR); e (2) informação de ligação (TKI_LNK_PTR) para cada objeto de áudio (AOB001.SA1,AOB002.SA1,...) inclu- ído na trilha de áudio, a informação de atributo (TKI BLK ATR) apresentan- do um tipo, fora do tipo (a), tipo (b), tipo (c), e tipo (d), para cada objeto de áudio (AOB001.SA1 .AOB002.SA1,...), o tipo (a) sendo uma trilha de áudio (trilhas A-E) completa, o tipo (b) sendo uma primeira parte de uma trilha de áudio (tri- lhas A-E), o tipo (c) sendo uma parte média de uma trilha de áudio (trilhas A-E), e o tipo (d) sendo uma parte final de uma trilha de áudio (trilhas A- E),e a informação de ligação (TKI LNK PTR) para cada objeto de áudio (AOB001.SA1,AOB002.SA1,...) que é do tipo (b) ou do tipo (c) apre- sentando que objeto de áudio (AOB001.SA1,AOB002.SA1,...) segue ao ob- jeto de áudio (AOB001 .SA1 .AOB002.SA1,...).

4. Cartão de memória semicondutora, de acordo com a reivindi- cação 3, caracterizado pelo fato de que a pluralidade de objetos de áudio (AOB001 .SA1 .AOB002.SA1,...) inclui: pelo menos um objeto de áudio (AOB001.SA1,AOB002.SA1,...) que somente contém dados válidos que necessitam ser executados; e pelo menos um objeto de áudio (AOB001.SA1,AOB002.SA1,...) que contém (1) dados válidos e (2) dados inválidos localizados pelo menos um antes e depois dos dados válidos, os dados inválidos não necessitando serem executados, cada trilha de áudio (trilhas A-E) adicionalmente incluindo a in- formação do bloco para cada objeto de áudio (A- OB001.SA1,AOB002.SA1,...) na trilha de áudio (trilhas A-E), a informação de bloco incluindo: um deslocamento medido a partir da posição de armazenamen- to do objeto de áudio (AOB001.SA1,AOB002.SA1,...) correspondente dado na informação de gerenciamento (TKI#1,TKI#2,TKI#3,...); e a informação de comprimento apresentando um comprimento dos dados válidos que começam a partir de uma posição indicada pelo des- locamento, a informação de atributo (TKI_BLK_ATR) para um objeto de áu- dio (AOB001.SA1,AOB002.SA1,...) apresentando se os dados válidos indi- cados pelo deslocamento e pela informação de comprimento (a) correspondem a uma trilha de áudio (trilhas A-E) completa, (b) correspondem a uma primeira parte de uma trilha de áudio (trilhas A-E), (c) correspondem a uma parte média de uma trilha de áudio (tri- lhas A-E), ou (d) correspondem a uma parte final de uma trilha de áudio (tri- lhas A-E).

5. Cartão de memória semicondutora, de acordo com a reivindi- cação 4, caracterizado pelo fato de que as trilhas de áudio (trilhas A-E) podem ser executadas de acordo com uma execução padrão ou com uma execução intermitente, a execução padrão sendo um modo onde os dados válidos nos objetos de áudio (AOB001.SA1,AOB002.SA1,...) compondo as trilhas de áudio (trilhas A-E) são executados sem qualquer dado válido ser omitido e a execução intermitente sendo um modo onde (1) a omissão de dados válidos equivalente a um primeiro período e (2) a execução de dados válidos equivalentes a um segundo período, são repetidas, cada trilha de áudio (trilhas A-E) adicionalmente incluindo uma pluralidade de pedaços de informação de posição de entrada (TMS- RT_entry#1,#2,#3,...) que apresentam as posições internas dos dados váli- dos dentro do objeto de áudio (AOB001.SA1,AOB002.SA1,...) em intervalos que são equivalentes ao primeiro período, e a informação de bloco para um objeto de áudio (A- OB001 .SA1 ,AOB002.SA1,...) apresentando: o deslocamento que indica uma diferença entre (1) a posição interna apresentada por um primeiro pedaço de informação de posição de entrada (TMSRT_entry#1,#2,#3,...) para o objeto de áudio (A- OB001.SA1,AOB002.SA1,...) e (2) a posição de armazenamento para o ob- jeto de áudio (AOB001.SA1,AOB002.SA1,...) dada na informação de geren- ciamento (TKI#1,TKI#2,TKI#3,...); e um comprimento dos dados válidos que começa em uma posi- ção indicada pelo deslocamento.

6. Aparelho de execução para ler e reproduzir trilhas de áudio (trilhas A-E) a partir de um cartão de memória semicondutora conforme defi- nido na reivindicação 1, caracterizado pelo fato de que compreende: dispositivo de leitura para ler um da pluralidade de objetos de áudio (AOB001.SA1,AOB002.SA1,...) incluído na pelo menos uma trilha de áudio (trilhas A-E) do cartão de memória semicondutora (31) e para ler uma chave de criptografia que corresponde ao objeto de áudio (A- OB001.SA1,AOB002.SA1,...) lido a partir da sequência de chave de cripto- grafia fk1,fk2,fk3,...) armazenada na área protegida do cartão de memória semicondutora (31); dispositivo de decriptografia (7) para decriptografar o objeto de áudio (AOB001.SA1,AOB002.SA1,...) lido utilizando a chave de criptografia lida; e dispositivo de execução (8) para executar o objeto de áudio (A- OB001 .SA1 ,AOB002.SA1,...) decriptografado, em que quando o dispositivo de decriptografia terminou de de- criptografar o objeto de áudio (AOB001.SA1,AOB002.SA1,...) lido, o disposi- tivo de leitura lê um objeto de áudio (AOB001.SA1,AOB002.SA1,...) diferen- te incluído em uma trilha de áudio (trilhas A-E), lê uma chave de criptografia correspondendo ao objeto de áudio (AOB001.SA1,AOB002.SA1,...) diferen- te a partir da sequência de chave de criptografia (fk1,fk2,fk3,...) e fornece a chave de criptografia mais recentemente lida para o dispositivo de decripto- grafia (7).

7. Aparelho de gravação para gravar um título composto de uma pluralidade de conteúdos em um cartão de memória semicondutora (31) ca- racterizado pelo fato de que compreende: dispositivo de criptografia (26) para designar pelo menos uma de uma pluralidade de chaves de criptografia para cada conteúdo incluído no título e criptografar cada conteúdo utilizando as chaves de criptografia de- signadas para os conteúdos para produzir uma pluralidade de objetos de áudio (AOB001 .SA1 .AOB002.SA1e dispositivo de gravação (21) para gravar no cartão de memória semicondutora (31) a pluralidade de chaves de criptografia como uma se- quência de chaves de criptografia (fk1,fk2,fk3,...) e gravar na área desprotegida do cartão de memória semicondu- tora (31) a pluralidade de objetos de áudio (AOB001.SA1,AOB002.SA1,...) como pelo menos uma trilha de áudio (trilhas A-E) ao longo da informação de gerenciamento correspondente a pelo menos uma trilha de áudio (trilhas A-E).

8. Aparelho de gravação, de acordo com a reivindicação 7, ca- racterizado pelo fato de que após gravar a pluralidade de chaves de crip- tografia e a pluralidade de objetos de áudio (AOB001.SA1,AOB002.SA1,...), a informação de gerenciamento (TKI#1,TKI#2,TKI#3,...) gravada pelo dispo- sitivo de gravação (21) apresenta, para cada objeto de áudio (A- OB001.SA1,AOB002.SA1,...), a correspondência entre a região no cartão de memória semicondutora (31) armazenando o objeto de áudio (A- OB001.SA1,AOB002.SA1,...) e uma posição de armazenamento da chave de criptografia correspondendo ao objeto de áudio (A- OB001 .SA1 ,AOB002.SA1,...).

9. Aparelho de gravação, de acordo com a reivindicação 8, ca- racterizado pelo fato de que para cada objeto de áudio (A- OB001.SA1,AOB002.SA1,...), o dispositivo de gravação (21) também grava a informação de atributo (TKIBLKATR) e a informação de ligação (TKI_LNK_PTR) no cartão de memória semicondutora (31), a informação de atributo (TKI_BLK_ATR) para cada objeto de áudio (AOB001 .SA1 ,AOB002.SA1,...) apresentando um tipo, fora do tipo (a), tipo (b), tipo (c) e tipo (d), o tipo (a) sendo uma trilha de áudio (trilhas A-E) completa o tipo (b) sendo uma primeira parte de uma trilha de áudio (tri- lhas A-E), o tipo (c) sendo uma parte média de uma trilha de áudio (trilhas A-E), e ο tipo (d) sendo uma parte final de uma trilha de áudio (trilhas A- E).e a informação de ligação (TKI LNK PTR) para cada objeto de áudio (AOB001.SA1,AOB002.SA1,...) que é do tipo (b) ou do tipo (c) apre- sentando que objeto de áudio (AOB001.SA1,AOB002.SA1,...) segue ao ob- jeto de áudio (AOB001.SA1.AOB002.SA1

10. Aparelho de gravação, de acordo com a reivindicação 7, ca- racterizado pelo fato de que cada um da pluralidade de objeto de áudio (AOB001.SA1,AOB002.SA1,...) são armazenados em um arquivo único na área desprotegida do cartão de memória semicondutora (31), compreen- dendo: um codificador (25) para sucessivamente gerar quadros de áu- dio a partir de uma entrada de sinal recebida de fora do aparelho de grava- ção, um quadro de áudio sendo uma menor quantidade de dados que pode ser independentemente codificada; um dispositivo de geração (28) para gerar um pedaço de infor- mações de entrada apresentando um comprimento de dados de um elemen- to de áudio que é composto de um número predeterminado de quadros de áudio; e toda hora que um predeterminado número de pedaços de infor- mação de entrada é gerado, a etapa de gravação cria um novo arquivo na área desprotegida do cartão de memória semicondutora (31) e escreve os quadros de áudio sucessivamente gerados desde então na etapa de codifi- cação dentro do novo arquivo.

11. Método de execução para ler e executar uma pluralidade de trilhas de áudio (trilhas A-E) a partir do cartão de memória semicondutora (31) conforme definido na reivindicação 1, caracterizado pelo fato de que compreende as etapas de: ler um da pluralidade de objetos de áudio (A- OB001.SA1,AOB002.SA1,...) incluído em pelo menos uma trilha de áudio (trilhas A-E) do cartão de memória semicondutora (31) e para ler uma chave de criptografia que corresponde ao objeto de áudio (A- OB001.SA1,AOB002.SA1,...) lido a partir da sequência de chaves de cripto- grafia (fk1,fk2,fk3,...) armazenada na área protegida do cartão de memória semicondutora (31); decriptografar o objeto de áudio (AOB001.SA1,AOB002.SA1,...) lido utilizando a chave de criptografia lida; e executar o objeto de áudio (AOB001.SA1,AOB002.SA1,...) de- criptografado, em que quando a etapa de decriptografar terminou de decripto- grafar o objeto de áudio (AOB001.SA1,AOB002.SA1,...) |jdo, a etapa de lei- tura lê um objeto de áudio (AOB001.SA1.AOB002.SA1,...) diferente incluído em uma trilha de áudio (trilhas A-E), lê uma chave de criptografia correspondendo ao objeto de áudio (AOB001.SA1.AOB002.SA1,...) diferente a partir da sequência de chaves de criptografia fk1,fk2,fk3,...), e fornece a chave de criptografia mais recentemente lida para a etapa de decriptografia.

12. Método de gravação para gravar um título composto de uma pluralidade de conteúdos em um cartão de memória semicondutora (31) pa- ra obter um cartão de memória semicondutora (31) conforme definido na reivindicação 1, caracterizado pelo fato de que compreende as etapas de: designar pelo menos uma de uma pluralidade de chaves de crip- tografia para cada conteúdo incluído no título e criptografar cada conteúdo utilizando as chaves de criptografia designadas para os conteúdos para pro- duzir uma pluralidade de objetos de áudio (AOB001.SA1,AOB002.SA1,...); e gravar na área protegida do cartão de memória semicondutora (31) a pluralidade de chaves de criptografia como uma sequência de chaves de criptografia (fk1,fk2,fk3,...) e gravar na área desprotegida do cartão de memória semicondu- tora (31) a pluralidade de objetos de áudio (AOB001.SA1,AOB002.SA1,...) como pelo menos uma trilha de áudio (trilhas A-E) ao longo da informação de gerenciamento (TKI#1,#2,#3,...) correspondente a pelo menos uma trilha de áudio (trilhas A-E).

13. Método de gravação, de acordo com a reivindicação 12, ca- racterizado pelo fato de que após gravar a pluralidade de chaves de crip- tografia e a pluralidade de objetos de áudio (AOB001.SA1,AOB002.SA1,...), a informação de gerenciamento (TKI#1,TKI#2,TKI#3,...) gravada na etapa de gravação apresenta, para cada objeto de áudio (A- OB001.SA1,AOB002.SA1,...), a correspondência entre a região no cartão de memória semicondutora (31) armazenando o objeto de áudio (A- OB001.SA1,AOB002.SA1,...) e uma posição de armazenamento da chave de criptografia correspondendo ao objeto de áudio (A- OB001 .SA1 .AOB002.SA1

14. Método de gravação, de acordo com a reivindicação 13, ca- racterizado pelo fato de que para cada objeto de áudio (A- OB001.SA1,AOB002.SA1,...), a etapa de gravação também grava a infor- mação de atributo (TKI_BLK_ATR) e a informação de ligação (TKILNKPTR) no cartão de memória semicondutora (31), a informação de atributo (TKI_BLK_ATR) para cada objeto de áudio (AOB001.SA1,AOB002.SA1,...) apresentando um tipo, fora do tipo (a), tipo (b), tipo (c) e tipo (d), o tipo (a) sendo uma trilha de áudio (trilhas A-E) completa o tipo (b) sendo uma primeira parte de uma trilha de áudio (tri- lhas A-E), o tipo (c) sendo uma parte média de uma trilha de áudio (trilhas A-E), e o tipo (d) sendo uma parte final de uma trilha de áudio (trilhas A- E),e a informação de ligação (TKILNKPTR) para cada objeto de áudio (AOB001 .SA1 ,AOB002.SA1,...) que é do tipo (b) ou do tipo (c) apre- sentando que objeto de áudio (AOB001.SA1,AOB002.SA1,...) segue ao ob- jeto de áudio (AOB001.SA1,AOB002.SA1,...).

15. Método de gravação, de acordo com a reivindicação 12, ca- racterizado pelo fato de que cada um da pluralidade de objeto de áudio (AOB001.SA1,AOB002.SA1,...) é gravado em um arquivo único na área desprotegida do cartão de memória semicondutora (31), compreendendo as etapas de: sucessivamente gerar quadros de áudio a partir de uma entrada de sinal recebida de fora do aparelho de gravação, um quadro de áudio sendo uma menor quantidade de dados que pode ser independentemente codificada; gerar um pedaço de informações de entrada apresentando um comprimento de dados de um elemento de áudio que é composto de um número predeterminado de quadros de áudio; e em que toda hora que um predeterminado número de pedaços de informação de entrada é gerado, a etapa de gravação cria um novo ar- quivo na área desprotegida do cartão de memória semicondutora (31) e es- creve os quadros de áudio sucessivamente gerados desde então na etapa de codificação dentro do novo arquivo.

16. Meio de gravação que pode ser lido por computador carac- terizado pelo fato de que compreende um código operável para fazer um computador executar o método de execução conforme definido na reivindi- cação 11.

17. Meio de gravação que pode ser lido por computador carac- terizado pelo fato de que compreende um código operável para fazer um computador executar o método de execução conforme definido em qualquer uma das reivindicações 12 a 15.