BRPI0007945B1 - processo para conexão de código neutro de arquitetura transferido para um computador de recursos restritos - Google Patents

Abstract

"processos para transferir código para um computador de recursos restritos, para criar um arquivo cap e para conectar código transferido para um computador de recursos restritos, cartão inteligente, dispositivo de recursos restritos, processo para conectar código neutro de arquitetura transferido para um computador de recursos restritos, onda portadora levando instruções para conectar código neutro de arquitetura transferido para um computador de recursos restritos, e, sistema implementado em computador para conectar código neutro de arquitetura transferido para um computador de recursos restritos". um sistema conecta código neutro de arquitetura transferido para um computador de recursos restritos. o código pode ser separado em um ou mais pacotes, possuindo um ou mais itens referenciáveis. o sistema mapeia o um ou mais itens referenciáveis em uma ou mais indicações magnéticas correspondentes; ordena as indicações magnéticas para corresponder a um modo de tempo de execução, transfere os pacotes para o computador de recursos restritos; e conecta os pacotes em um código executável usando as indicações magnéticas ordenadas.

Description

“PROCESSO PARA CONEXÃO DE CÓDIGO NEUTRO DE ARQUITETURA TRANSFERIDO PARA UM COMPUTADOR DE RECURSOS RESTRITOS.” FUNDAMENTOS A presente invenção está relacionada, em termos genéricos, a programas de arquitetura neutra, orientados por objeto, para o emprego com dispositivos de recursos restritos, tais como cartões inteligentes e dispositivos similares, Uma máquina virtual c uma máquina de computação abstrata gerada por meio de uma aplicação de software ou por meio de uma sequência de instruções, a qual é executada por intermédio de um processador. A dita expressão “arquitetura neutra” diz respeito aos programas, tais como aqueles escritos na linguagem de programação JavaIM, os quais podem ser executados por intermédio de urna máquina virtual em uma variedade de plataformas de computador que apresentam uma pluralidade de arquiteturas de computador diferentes. Como consequência disso, por exemplo, uma máquina virtual que é executada em um sistema de computador pessoal com base em Windows[M irã utilizar o mesmo conjunto de instruções que uma máquina virtual que seja executada em um sistema de computador com base em UNIXIM. O resultado da codificação independente de plataforma de uma sequência de instruções de urna máquina virtual é um fluxo de um ou mais códigos de bytes, cada um dos quais é, por exemplo, um código numérico de duração de um byte.

Uso da linguagem de programação Java tem encontrado muitas aplicações incluindo, por exemplo, as associadas aos navegadores da Web. A linguagem de programação Java é orientada a objeto. Em um sistema orientado a objeto, uma “classe” descreve uma coleção de dados c processos que operam naqueles dados. Considerados juntos, os dados e processos descrevem o estado e comportamento de um objeto. A linguagem de programação Java é também verificável de tal forma que, antes de uma execução de uma aplicação escrita na linguagem de programação Java, pode ser feita uma determinação de se qualquer seqüência de instrução no programa tentará processar dados de um tipo impróprio para aquele código de byte ou se a execução das instruções de código de byte no programa causará retenção (“underflow”) ou transbordo (“overflow”) de uma pilha de “operando”.

Uma máquina virtual Java™ executa código de máquina virtual escrito na linguagem de programação Java e é projetada para uso com uma arquitetura de 32 bits. Entretanto, vários dispositivos de recursos restritos, tais como cartões inteligentes, possuem uma arquitetura de 8 bits ou 16 bits.

Cartões inteligentes, também conhecidos de cartões portadores de dados portáteis inteligentes, são geralmente feitos de plástico ou de metal e possuem um “chip” eletrônico que inclui um microprocessador embutido para executar programas e memória para armazenar ambos programas e dados. Tais dispositivos, que podem ser, aproximadamente, do tamanho de um cartão de crédito, possuem tipicamente capacidade de memória limitada. Por exemplo, alguns cartões inteligentes possuem menos de um quilobyte (1K) de memória de acesso randômico (RAM) bem como memória de somente leitura limitada (ROM) e/ou memória não volátil tal como aquela memória de somente leitura programável apagável eletricamente (EEPROM).

Geralmente, programas rodando um processador de um cartão inteligente determinam os serviços oferecidos pelo cartão. Na medida em que o tempo passa, os programas no cartão podem necessitar de ser atualizados, por exemplo, no sentido de adicionar uma nova função ou melhorar uma função existente. Para tal fim, o cartão deveria ser capaz de aceitar novos programas que podem substituir outros programas.

Tipicamente, uma máquina virtual executando um código de byte (por exemplo, uma máquina virtual Java plena) requer uma ponderável quantidade de memória no carregamento do código de byte e resolução de referências. Particularmente, na máquina virtual Java, referências simbólicas são usadas para se referir a elementos de programa, como classes, processos e campos. Uma referência para elementos de programa como estes é resolvida localizando o elemento usando seu nome simbólico. Tais operações requerem uma memória de acesso randômico (RAM) relativamente grande. Num ambiente tendo pouca memória RAM, isto pode não ser factível. Uma vez que os cartões inteligentes são sensíveis a custo, eles se apoiam em processadores baratos, de baixo desempenho e dispositivos de memória de baixa capacidade. Visto que o custo e razões de potência determinam que componentes de processador e memória de baixa potência e baixa capacidade sejam distribuídos em tais computadores de recursos restritos, a capacidade de operar a máquina virtual Java em tais dispositivos de recursos restritos é difícil e ainda desejável. SUMÁRIO

Num primeiro aspecto, um processo transfere código para um computador de recursos restritos. O código é separável em pelo menos um pacote que tem pelo menos um item referenciável. O processo inclui formar o pacote; formar um mapeamento do item referenciável para um correspondente token; e prover o pacote e o mapeamento.

Num segundo aspecto, um processo conecta código transferido para um computador de recursos restritos. O processo inclui receber o pacote; receber um mapeamento do item referenciável para um correspondente token; e conectar o pacote usando o mapeamento.

Vantagens da invenção podem incluir uma ou mais das abaixo. A invenção usa eficientemente recursos num dispositivo de recursos limitados, usando espaços de armazenagem menores através de identificadores de token únicos. Adicionalmente, a invenção pode conectar e resolver referências para itens exportados no dispositivo de recursos limitados. Através de arquivos de metadados, como arquivos de exportação, a invenção permite que elementos exportados sejam publicados. Tal publicação, contudo, pode ser feita de modo a não expor elementos e detalhes privados ou de proprietários dos applets e bibliotecas associadas. Logo, várias aplicações desenvolvidas separadamente podem ser transferidas a um dispositivo de recursos limitados; e compartilhar seus componentes entre si, sem comprometer a informação segura privada.

Além do mais, as vantagens de uma linguagem de arquitetura neutra, tal como o Java, podem ser verificadas em um dispositivo de recursos limitados, enquanto que preserva a sua semântica. Tokens podem também ser usados para elementos internos ou privados. Assim sendo, tokens podem ser designados para campos privados e de instância visível de pacote assim como a processos virtuais visíveis de pacote. A invenção impõe poucas restrições na designação de tokens, e as categorias de tokens podem ser ainda definidas ou otimizadas para aplicações particulares. Como tal, a invenção suporta código de arquitetura neutra portátil que é escrito só uma vez e que é executável em toda a parte, mesmo em dispositivos de recursos restritos, tais como cartões inteligentes, com capacidade de armazenagem limitada.

DESENHOS

Fig. 1 ilustra a conversão e carregamento de código de hardware independente de plataforma em um cartão inteligente.

Fig. 2 mostra um sistema de computador que se comunica com o cartão inteligente da Fig. 1.

Fig. 3 apresenta um diagrama que ilustra as dependências entre pacotes.

Figs.4A e 4B são diagramas que ilustram as duas operações de conversor.

Fig. 5 é um diagrama ilustrando dois pacotes e um registro de pacote para resolver referências estáticas.

Fig. 6 é um fluxograma ilustrando um processo de conexão em conjunto com os pacotes da Fig. 5.

Figs. 7A-7I são diagramas que ilustram as várias referências de classe, campo e processo.

Figs. 8A-8I são fluxogramas ilustrando processos para designar tokens e tabelas de suporte.

Figs. 9A-9C são fluxogramas ilustrando processos para resolver tokens para campos e processos de instância.

DESCRIÇÃO É descrito um processo para representar informação de conexão para programas orientados a objeto em uma forma compacta e segura. Usando-se tal processo, os programas podem ser transferidos, conectados e executados em um dispositivo de recursos restritos. Dispositivos de recursos restritos são geralmente considerados como sendo aqueles que são restritos em memória e/ ou potência de computação e velocidade. Embora a implementação particular discutida abaixo seja descrita com referência a um cartão inteligente, a invenção pode ser usada com outros dispositivos de recursos restritos incluindo, porém não limitado a, os telefones celulares, dispositivos de varredura de contorno, dispositivos programáveis de campo, auxiliares de dados pessoais (PDA) e radiolocalizadores (“pagers”) bem como outros dispositivos de pequeno porte ou miniatura. Em alguns casos, o dispositivo de recursos restritos pode ter tão pouco como 1K de RAM ou 16K de ROM. Similarmente, alguns dispositivos de recursos restritos são baseados numa arquitetura projetada para menos de 32 bits. Por exemplo, alguns dos dispositivos de recursos restritos que podem ser usados com a invenção são baseados numa arquitetura de 8 bits ou 16 bits, em vez de um arquivo de 32 bits.

Referindo-se à Fig. 1, o desenvolvimento de um applet para um dispositivo de recursos restritos, tal como um cartão inteligente 40, começa de uma maneira similar ao desenvolvimento de um programa Java. Em outras palavras, um desenvolvedor escreve uma ou mais classes Java e compila o código fonte com um compilador Java, para produzir um ou mais arquivos de classes 10. O applet pode ser executado, testado e depurado, por exemplo, em uma estação de trabalho usando-se ferramentas de simulação para emular o ambiente no cartão 40. Quando o applet está pronto para ser transferido para o cartão 40, os arquivos de classes 10 são convertidos para um arquivo applet convertido (CAP) 16, por um conversor 14. O conversor 14 pode ser uma aplicação Java sendo executada por um computador de mesa. O conversor 14 pode aceitar como sua entrada um ou mais arquivos de exportação 12 além de os arquivos de classe 10 a serem convertidos. Um arquivo de exportação 12 contém informação de nome ou conexão para o conteúdo de outros pacotes que são importados pelas classes sendo convertidas.

Em geral, o arquivo CAP 16 inclui todas as classes e interfaces definidas em um único pacote Java e é representado por um fluxo de bytes de 8 bits. Todas as quantidades de 16 bits e 32 bits são construídas pela leitura em dois ou quatro bytes de 8 bits consecutivos, respectivamente. Entre outras coisas, o arquivo CAP 16 inclui um componente de combinação de recursos constantes (ou “combinação de recursos constantes”) 18 que é empacotada de modo separado de um componente de processo 20. A combinação de recursos constantes 18 pode incluir vários tipos de constantes incluindo referências de processo e campo que são resolvidas quando o programa estiver conectado ou for transferido ao cartão inteligente 40, ou na ocasião de execução pelo cartão inteligente. Componente de processo 20 especifica as instruções de aplicação a serem transferidas ao cartão inteligente 40 e, subsequentemente, executadas pelo cartão inteligente.

Após conversão, o arquivo CAP 16 pode ser armazenado num meio legível por computador 17, tal como um disco rígido, um disco flexível, um meio de armazenagem óptica, um dispositivo “flash”, ou algum outro meio adequado. Ou o meio legível por computador pode estar na forma de uma onda portadora, por exemplo, uma transmissão de dados de rede ou um enlace de dados de radiofrequência (RF). O arquivo CAP 16 então pode ser copiado ou transferido para um terminal 22, tal como um computador de mesa com um dispositivo de aceitação de cartão periférico (CAD) 24. O CAD 24 permite a informação de ser escrita e recuperada a partir do cartão inteligente 40. CAD 24 inclui uma porta de cartão (não mostrada) dentro da qual o cartão inteligente 40 pode ser inserido, Uma vez inserido, contatos de um conector pressionam contra a área de conexão da superfície do cartão inteligente 40 para prover energia e permitir comunicações com o cartão inteligente, ainda que, em outras implementações, comunicações sem contato podem ser usadas.Terminal 22 inclui também uma ferramenta de instalação 26 que carrega o arquivo CAP 1.6 para transmissão ao cartão 40. O cartão inteligente 40 possui uma porta de entrada/saída (I/O) 42 que pode incluir um conjunto de contatos através dos quais programas, dados e outras comunicações são providos. Cartão 40 inclui também uma ferramenta de instalação 46 para receber o conteúdo do arquivo CAP 16 e preparar um applet para a execução no cartão 40. A ferramenta de instalação 46 pode ser implementada, por exemplo, como um programa Java e pode ser executada no cartão 40. O cartão 40 também possui memória, incluindo memória volátil tal como RAM 50. O cartão 40 tem também ROM 52, e memória não volátil, tal como a EEPROM 54. O applet preparado pelo controlador 44 pode ser armazenado na EEPROM 54.

Numa implementação particular, o applet é executado por uma máquina virtual 49 rodando num microprocessador 48. A máquina virtual 49, que pode ser referida como a máquina virtual de Cartão Java, não precisa de carregar ou manipular o arquivo CAP 16. Em vez disso, a máquina virtual de Cartão Java 49 executa o código applet armazenado previamente como parte do arquivo CAP 16, A divisão ou funcionalidade entre a máquina virtual de Cartão Java 49 e a ferramenta de instalação 46 permitem que ambas a máquina virtual e a ferramenta de instalação sejam mantidas rei ativa mente pequenas.

Em termos gerais, implementações e applets escritos para uma plataforma de recursos restritos, tal como o cartão inteligente 40, seguem as regras padrão para pacotes de plataforma Java. A máquina virtual de Cartão Java e a linguagem de programação Java são descritas por T. Lindholm et al., The Java Virtual Machine Specification (1997), e K. Amold et al., The Java Programming Language Second Edition, (1998) que são aqui incorporados por referência na sua totalidade. Classes de interface de programação de aplicação (API) para a plataforma do cartão inteligente podem ser escritas como arquivos fonte Java, que incluem designações de pacotes, onde um pacote inclui um número de unidades de compilação e possui um nome único. Mecanismos de pacotes são usados para identificar e controlar o acesso a classes, campos e processos. API do Cartão Java permite que aplicações escritas na plataforma habilitada pelo Cartão Java rodem em qualquer outra plataforma habilitada por Cartão Java. Adicionalmente, API do Cartão Java é compatível com padrões internacionais formais tais como ISO 7816, e padrões específicos da indústria tais como Europay/MasterCard/Visa (EMV).

Embora uma máquina virtual de Cartão Java 49 rodando num microprocessador 48 tenha sido descrita como implementação para executar os códigos de byte no cartão inteligente 40, em implementações alternativas, um circuito integrado específico da aplicação (ASIC) ou uma combinação entre hardware e firmware podem ser usadas ao invés disso.

Referindo-se à Fig. 1, o controlador 44 usa uma ferramenta de instalação 46 para receber o conteúdo do arquivo CAP 16 e preparar o applet para ser executado por um processador 48. Tal ferramenta de instalação 46 pode ser implementada, por exemplo, como um programa Java que tenha sido adequadamente convertido para execução no referido cartão inteligente 40. Na descrição abaixo, supõe-se que o controlador 44 compreenda um programa de máquina virtual 49 rodando num microprocessador 48. A máquina virtual 49 não precisa carregar ou manipular o arquivo CAP 16. Ao contrário, a máquina virtual 49 executa código applet no arquivo CAP 16. Divisão de funcionalidade entre a máquina virtual 49 e a ferramenta de instalação 46 permite a máquina virtual e a ferramenta de instalação de serem mantidas relativamente pequenas.

Em implementações alternativas, dito controlador 44 pode ser construído em hardware, por exemplo, como circuito integrado de aplicação específica (ASIC) ou pode ser implementado como uma combinação de hardware e firmware. A plataforma de cartão inteligente, que pode ser utilizada para outros dispositivos de recursos restritos,suporta objetos criados dinamicamente, incluindo instâncias de classe e de arranjos. Uma classe é implementada como uma extensão ou subclasse de uma única classe existente e os seus elementos são processos, bem como variáveis citadas como campos. Um processo declara um código executável que pode ser solicitado e que passa um número fixo de valores como argumentos. Tais classes também podem implementar interfaces Java. Uma interface é um tipo de referência, cujos elementos são constantes e processos abstratos. A máquina virtual 49 pode incluir um interpretador ou implementação nativa que provê acesso a um sistema de tempo de execução que inclui o API de cartão Java e funcionalidades de suporte.

Conforme mostrado na Fig. 2, um computador 22 é equipado com um dispositivo de aceitação de cartão 24, para receber o cartão 40 da Fig. 1. O computador 22 pode ser conectado a uma rede 45 que se comunica com diversos outros dispositivos de computação, tal como um servidor 47. É possível carregar dados e software em um cartão inteligente ao longo da rede 45, usando dispositivos equipados com cartão. Transferências desta natureza podem incluir applets ou outros programas a serem carregados em um cartão inteligente, bem como dinheiro digital e outras informações usadas de acordo com uma variedade de comércio eletrônico e outras aplicações. As instruções e dados para controlar elementos de processamento do dispositivo de aceitação de cartão e do cartão inteligente podem ser armazenadas em memória volátil, ou não volátil, ou poderão ser recebidas diretamente através de um enlace de comunicações, por exemplo, como uma onda portadora contendo as instruções e/ou dados. Adicionalmente, por exemplo, a rede 45 pode ser uma LAN ou uma WAN tal como Internet ou outra rede.

Fig. 3 exibe um diagrama ilustrando dependências hierárquicas típicas entre um grupo de pacotes de programa (incluindo ambos as Interfaces de Programa de Aplicação (API) e os applets de programa) carregados em um cartão inteligente 40. Aplicações podem ser carregadas no cartão inteligente 40 incrementalmente e conectados no cartão para execução, de tal modo que a funcionalidade do cartão inteligente 40 possa ser atualizada com capacidades adicionais, além de as funcionalidades programadas em fábrica. No diagrama, uma estrutura de linguagem Java 50 e uma estrutura de Cartão Java 52 existem num nível API de Cartão Java. Acima do nível API de Cartão Java está nível API sob medida com uma ou mais estruturas sob medida 54. A estrutura sob medida 54 pode ser fornecida por um ou mais provedores de valor adicionado através de vários kits de desenvolvimento de software (SDK) para estender uma estrutura existente ou um outro API. No nível mais alto está o nível de aplicação onde vários applets 56, 58 e 60 residem.

Conforme mostrado na Fig. 3, um pacote poderá depender de outros pacotes no mesmo nível API ou daqueles pacotes em níveis API mais baixos. Por exemplo, o applet 58 pode se referir a elementos de programa no applet 58 e a estrutura de Cartão Java 52 pode ter dependências da estrutura de linguagem Java 50. Ainda mais, a estrutura sob medida 54 no nível API sob medida e applets 58 e 60 podem ter referências que dependem da estrutura de Cartão Java 52. Por sua vez, os applets 56 e 58 podem ter referências que dependem da estrutura sob medida 54. O applet 56 e a estrutura sob medida 54 podem, também, depender da estrutura de linguagem Java 50. Embora o exemplo da Fig. 3 mostre dependências lineares, dependências não lineares tais como dependências circulares podem ser suportadas usando um conversor adequado 14 e ferramenta de instalação 46.

Conversão de um conjunto de arquivo de classe, por exemplo, de uma aplicação Java para um arquivo CAP 74 pode geralmente ocorrer num computador de mesa em preparação para instalação num cartão inteligente 40. O computador de mesa 22 geralmente não é de recursos tão restritos quanto os de um cartão inteligente típico 40. Adicionalmente, a operação de conversão pode ser conduzida em outras plataformas adequadas.

Fig. 4A mostra um sistema para converter um pacote, o qual pode definir um applet ou uma biblioteca em preparação para transferência para o cartão inteligente 40. O conversor 72 recebe entradas de dados de um ou mais arquivos de classe 70, que definem a funcionalidade de um applet. O conversor 72, por sua vez, gera um arquivo CAP 74 de Cartão Java adequado para transferência.

Conforme discutido em maior detalhe abaixo, arquivo CAP 74 contém um componente de exportação 82 para resolver referências a elementos em seu pacote, em que aqueles elementos possam ser referenciados por outros pacotes. O componente de exportação 82 contém entradas para itens estáticos, tais como classes, processos e campos. Referências a itens dinâmicos, como os campos de instância, processos virtuais e processos de interface são inexigíveis para serem apresentados no componente de exportação, entretanto, podem ser processadas de acordo com processos descritos abaixo.

Em dispositivos de recursos restritos, uso de cadeias Unicode para representar itens, consome memória e recursos de processador. No lugar de cadeias, o componente de exportação 82 mapeia tokens ou simples valores numéricos únicos para elementos específicos definidos em outros componentes no arquivo CAP 74. Valores de token usados para representar estes elementos naquele componente de exportação coincidem com aqueles publicados em um correspondente Arquivo de Exportação 80.

Em mais detalhe, o arquivo CAP 74 possui, entre outros, um componente de cabeçalho 76, recursos constantes 78, componente de processo 80 e componente de exportação 78. Tais recursos constantes 78, tipicamente, incluem uma ou mais referências de classe, campo e processo, de tal modo que, em geral, referências a elementos ou itens de programa são indiretamente feitas através dos recursos constantes do pacote 78. O referido componente de processo 80 contém todos os processos implementado pelo pacote applet aqui representado pelo arquivo CAP 74. Referências de processos resolvem para processos localizados no componente de processos.

Referências de classe e referências de campo estático resolvem para localizações em componentes de classe e componentes de campo estático, respectivamente. O componente de exportação 78 inclui uma ou mais entradas com um valor de token 84 e informação de conexão de elemento de programa correspondente 86 que descreve onde, no pacote definido no arquivo CAP 74, um elemento de programa particular dever ser encontrado. A informação de conexão é especifica para o conteúdo do arquivo CAP 74, não para a representação interna em um cartão particular. Este componente, portanto, não descreve informação privada ou segura específica de cartão. O conversor 72 pode também gerar um arquivo de Exportação 80 durante a conversão de arquivos de classe em um arquivo CAP 74. Um arquivo de Exportação é gerado para cada arquivo CAP. O arquivo de Exportação 80 possui tipicamente uma ou mais entradas com um nome simbólico 90 para um elemento de programa particular no arquivo CAP 74 e seu correspondente valor de token 92. O arquivo de Exportação 80 provê informação sobre cada elemento do pacote de arquivos de classe e informação de programa acessível extemamente no arquivo CAP 74 que pode ser referenciado (importado) por um segundo pacote em um segundo arquivo CAP (descrito adicionalmente abaixo). Por exemplo, o arquivo de Exportação 80 contém referências a todas as classes públicas e interfaces definidas em um pacote Java, e todos os campos e processos públicos e protegidos, definidos naquelas classes e interfaces. O arquivo de Exportação 80 contém também um mapeamento destes elementos de programa ou itens para tokens que podem então ser usados para mapear nomes para itens importados para fichas durante a conversão de pacotes. O arquivo de Exportação não expõe detalhes privados ou proprietários dos applets e bibliotecas associadas. Deste modo, várias aplicações desenvolvidas separadamente podem ser carregadas em um dispositivo de recursos limitados e compartilhar seus componentes com cada outro, sem comprometer informação segura privada. O arquivo de Exportação 80 não expõe elementos privados ou proprietários e detalhes dos applets e bibliotecas associadas, aplicações desenvolvidas separadamente podem ser carregadas no cartão 40 e compartilhar seus elementos exportados um com o outro, sem comprometer a informação segura privada.

Com referência às Figs. 3 e 4A, se um número de arquivo de classe 70 compreendendo javacard.framework API 52 sendo convertido, o arquivo de Exportação 80 gerado durante a conversão permitiría que outros programas applet, sendo convertidos separadamente, saibam quais tokens usar no sentido de referenciar extemamente itens do javacard.framework.API. Por exemplo, se unir applet referência à classe de estrutura PIN, o arquivo de Exportação 80 para o javacard.framework contém uma entrada para classe javacard,framework.PIN, juntamente com seu respectivo token. O conversor 72 colocaria seu token nos recursos constantes do arquivo CAP do novo applet, para representar uma referência não resolvida para aquela classe na estrutura. Conforme explicado adicionalmente abaixo, durante a execução applet, o token pode ser usado para localizar o item referenciado no componente de exportação 78 do pacote API de estrutura, para recuperar a informação de conexão de elemento. Por exemplo, informação de conexão de um processo pode prover informação para localizar o processo apropriado contido no componente de processo 80 daquele pacote.

Fig. 4B mostra o conversor 72 convertendo um segundo pacote de arquivo de classe 94, onde aqueles arquivos de classe 94 importam elementos dos arquivos de classe do primeiro pacote 70 (Fig. 4A). Por exemplo, o segundo pacote pode ser um conjunto de classes applet que se apoiam em certas classes contidas, por exemplo, em um pacote de biblioteca javacard.framework, que tenha sido previamente convertido (conforme descrito acima com respeito à Fig. 4A). O conversor 72 recebe entrada de dados de arquivos de classe 94 e de um ou mais arquivos de Exportação 80, a partir de pacotes previamente convertidos. O conversor 72 gera um arquivo CAP 100 adequado para transferência, por exemplo, ao cartão inteligente 40. O arquivo CAP B 100 para o segundo pacote inclui um componente de importação 104 com uma lista de todos os pacotes referenciados pelas classes applet. Cada referência de pacote externo compreende um mapeamento 106 entre um token de pacote interno e um Identificador de Aplicação (AID) único externo para aquele pacote. Cada token de pacote é usado em outros componentes dentro do arquivo CAP 100 para identificar um pacote externo referenciado particular de uma forma concisa, reduzindo deste modo o tamanho base da representação do applet. O arquivo CAP 100 possui também entre outros, um componente de cabeçalho 102, um componente de importação 104 e recursos constantes 108. Os recursos constantes 108 incluem uma ou mais referências de classes 110, que mapeiam cada referência de classe com tokens de pacote correspondentes, tokens de classe, mapeando deste modo a classe especificada para seu pacote externo correspondente e classe dentro daquele pacote. O uso destes tokens é descrito adicionalmente abaixo. Os recursos constantes 108 podem também incluir uma ou mais referências de processos 112 que, similarmente, mapeiam cada referência de processo com tokens de pacote correspondentes, tokens de classe e tokens de processo. Os recursos constantes 108 podem também incluir uma ou mais referências de campo 114, cada uma com seu token de pacote, token de classe e token de campo, respectivamente.

Geralmente, referências a elementos ou itens de programa são feitas indiretamente através dos recursos constantes 108 de cada pacote.

Referências a itens em outros pacotes são chamadas externas, e são representadas em termos de tokens. Referências a itens no mesmo arquivo CAP são chamadas internas, e podem ser representadas em termos de tokens, ou em um formato interno diferente (tal como apontadores para localizações dentro do arquivo CAP). Por exemplo, a referência externa 110 para uma classe é composta de um token de pacote e um token de classe. Em conjunto, aqueles itens especificam uma certa classe em um certo pacote externo. Uma referência interna a uma classe pode ser um apontador para a localização de estrutura de classe dentro do arquivo CAP. Altemativamente, o sistema de token externo pode ser usado intemamente. As referências externas 112-114 referem-se a elementos de classe estática ou um campo ou processo, com um token de pacote, token de classe, e token para o campo estático ou o processo estático. Uma referência interna a um elemento de classe estático pode ser um apontador para a localização do item no arquivo CAP, mas pode também usar o sistema de token. Referências a campos de instância, a processos virtuais e a processos de interface consistem de uma referência de classe e um token do tipo adequado. Referência de classe indica se a referência é externa ou interna.

Referências externas num arquivo CAP podem ser resolvidas em um cartão a partir da forma de token na representação interna usada pela máquina virtual de Cartão Java. Um token pode só ser resolvido no contexto do pacote que o define. No momento exato em que o arquivo de exportação mapeia a partir de nomes visíveis extemamente de pacote para tokens, há um conjunto de informação de conexão para cada pacote no cartão que mapeia de tokens para referências resolvidas. Desta maneira, o conversor 97 processa ambos arquivos de classe 92 e arquivo de Exportação 94, criando uma imagem adequada para transferir o applet em um dispositivo de recursos limitados e resolver referências (conectando) ao primeiro pacote.

Após o pré-processamento realizado nas Figs. 4A e 4B, o arquivo CAP da Fig. 4B pode ser transferido para o cartão inteligente 40 ou para um dispositivo de recursos restritos que contém o arquivo CAP da Fig. 4A. Figs. 5 e 6 ilustram em maior detalhe como a conexão baseada em token é feita para elementos estáticos no cartão inteligente 40 ou um pequeno dispositivo. Os elementos estáticos incluem elementos cujas representações exatas são identificáveis pelo conversor, durante o processo de conversão.

Na Fig. 5, uma imagem 200 de um pacote P2 foi carregada a partir de, por exemplo, Arquivo CAP B 100, no cartão 40 e pode ser conectado a um pacote anterior P 1 , antes ou durante a execução. Elementos de programa no pacote P2 200 podem incluir referências a processos e outros dados no pacote externo PI que já existe como uma imagem 174 no cartão 40 (do Arquivo CAP A 74). A imagem 174 inclui, entre outras coisas, um componente de cabeçalho 176, recursos constantes 178, componente de processo 180, e um componente de exportação 182 que contém uma lista de tokens para todos os itens estáticos exportados 185. Para auxiliar a resolução da referência para um pacote externo, um registro de pacote 120 é criado no cartão 40, para prover informação usada para localizar um ou mais pacotes externos, incluindo imagem 174 do pacote PI que contém processos particulares requeridos pela imagem 200 do pacote P2. A imagem 200 do pacote P2 inclui, entre outras coisas, um componente de cabeçalho 202, um componente de importação 204, recursos constantes 208, e um componente de processo 216, todos correspondendo aos respectivos componentes 102, 104, 108 e 116 no arquivo CAP B 100. A organização geral destes componentes é descrita acima com respeitos aos arquivos CAP. Tipicamente, o componente de processo 216 incluirá referência de programas tais como “new” (218), “invokestatic” (220) e “getstaticb” (222) juntamente com suas respectivas referências de classe ativadas, referências de processo e referências de campo.

Fig. 6 mostra um processo de conexão 140 para o pacote P2 200 da Fig. 5. Quando um processo de execução no componente de processo 216 ativa um processo particular, por exemplo, Processo T, no componente de processo 180 que está localizado em um pacote externo (pacote 1), a conexão é requerida (etapa 142). Usando o índice provido como um operando para a instrução, o processo 140 localiza e recupera nos recursos constantes 208 a referência de processo de coincidência 212 (etapa 144). Conforme descrito abaixo, a referência de processo consiste de um token de pacote, token de classe e token de processo, que são usados para localizar aquele processo particular em pacote externo. A seguir, o processo 140 examina o componente de importação 204 para encontrar o AID único do pacote externo Pl, com base no token de pacote recuperado (etapa 146). O registro de pacote 120 é então examinado para encontrar a localização do pacote Pl com base no AID (etapa 148). Uma vez que a imagem 174 para o pacote Pl é obtida a partir do registro de pacote 120, o componente de exportação 182 da imagem 174 é procurado para localizar a classe com o token de classe especificado (etapa 150). A informação de conexão de programa para o processo desejado, por exemplo, Processo T é então encontrada buscando a lista de processos associados à classe particular encontrada na etapa 150, para localizar um processo com o token de processo especificado (aqui, o token de processo y corresponde ao Processo T do pacote Pl 174) (vide etapa 152). Finalmente, a localização do processo especificado, por exemplo, Processo T, no componente de processo 180 é determinado com base na informação de conexão provida para o processo no componente de exportação 182 (etapa 154).

Usando o processo da Fig. 6, um pacote pode ser transferido a um cartão e preparado para a execução por uma máquina virtual. Tal processo é chamado de “instalação”. Vários processos de instalação podem ser usados, os quais diferem na ordem de processamento e operações de conexão (quando os dados são recebidos no cartão e quando são armazenados). Estes processos de instalação poderão ser otimizados com base naqueles recursos disponíveis no cartão. Em uma implementação, nenhuma conexão ocorre, e, assim, à medida que os dados são recebidos, são imediatamente armazenados. Durante interpretação ou execução do código, ocorre resolução de referências externas. Deste modo, esta implementação é usada num pequeno dispositivo maior (menos restrito), uma vez que toda a informação de conexão temporária é armazenada permanentemente neste cartão.

Conforme discutido acima, em vez de cadeias Unicode como são usadas nos arquivos de classe Java, os tokens são usados para identificar item em um arquivo CAP e para resolver referências no dispositivo de recursos limitados. Tokens para um API são designadas pelo desenvolvedor do API e publicados no(s) arquivo(s) de exportação de pacote para aquele API. Visto que os mapeamentos de nome para tokens são publicados, um desenvolvedor API poderá escolher qualquer ordem para os tokens dentro de restrições da invenção.

Juntas, as Figs.5 e 6 descrevem a resolução de referências para itens estáticos, isto é, classes, campos estáticos, e processos estáticos. As implementações destes itens são plenamente localizáveis durante compilação e conversão. Em contraste, durante compilação e conversão, referências para campos de instância, processos virtuais e processos de interface não se limitam estatisticamente a implementações particulares. Tais itens exigem informação adicional que somente é disponível com referência a uma instância no tempo de execução.Resolução de referência para estes tipos édescrita com referência às Figs. 9A-9C.

As designações de token para processos virtuais preservam as relações dentro de hierarquias de classe orientadas ao objeto. Os tokens para processos virtuais e processos de interface são usados como índices em tabelas de processo virtual e tabelas de processo de interface, respectivamente. Uma plataforma de cartão particular pode resolver token numa representação interna que é mais útil para aquela implementação de um dispositivo de recursos limitados VM.

Alguns tokens podem ser resolvidos pura índices. Por exemplo, um token de campo de instância pode ser resolvido para um índice numa instância de classe. Em tais casos, o valor de token pode ser distinto e não relacionado ao valor do índice resolvido.

Cada espécie de item num pacote possui o seu próprio escopo independente para tokens daquela espécie. Amostras de faixa de tokens e de regras de designação para cada espécie de referência estão listadas a seguir. Outras faixas e designações de tokens podem ser feitas.

Figs.7A-71 são diagramas ilustrando aquelas representações de referências. Fígs. 7A-7C descrevem referências para elementos importados, ao passo que Figs. 7D-71 descrevem referências para itens internos, alguns dos quais usam tokens.

Fig. 7A mostra uma referência de classe para uma classe externa 180. A referência de classe da Fig. 7A inclui um token de pacote e um token de classe. Fig. 7B mostra uma representação de uma referência de campo externa, À referência de campo externa 182 inclui um token de pacote, um token de classe c um token de campo. Fig. 7C mostra uma representação de uma referência de processo externa 184. A referência externa 184 inclui um token de pacote, um token de classe e um token de processo. Deve-se notar que, para processos virtuais, o bit alto do token de processo é ajustado para zero. O ajuste do bit alto indica que o processo é acessível fora da definição do pacote. O bit alto pode ser o bit mais significativo, como o 7o bit de um byte, 15° bit de uma palavra ou o 23° bit de uma unidade de três bytes. O bit alto de um token de pacote é ajustado para indicar um pacote importado. Isto é usado para distinguir entre as referências externa e interna. Como mostrado nas Figs. 7D-7I, referências para elementos internos têm seus bits altos ajustados para 0 (zero). Os formatos das Figs. 7D-7I são exemplos de uso estendido de token, em casos selecionados, a itens internos.

Fig. 7D mostra uma representação de uma referência de classe interna 186. A referência de classe interna 186 inclui um deslocamento para uma estrutura de informação de classe no componente de classe. A Fig. 7E mostra uma representação de uma referência de campo estático 188 para um campo interno. Como tal, a referência de campo estático 188 tem um campo que é ajustado para zero e um campo para incluir um deslocamento para um campo estático na imagem de campo estático. Fig. 7F é uma representação de uma referência de processo estático 190 para processos internos. A referência de processo estático 190 inclui um campo de preenchimento, que é ajustado para zero, para tomar a referência do mesmo tamanho de uma referência de processo importado. A referência de processo estático 190 inclui também um campo que provê informação relacionada a um deslocamento para um processo estático no componente de processo.

Fig. 7G exibe uma representação para uma referência de campo de instância 192 para um campo interno. Na Fig. 7G, a referência de campo de instância 192 inclui um deslocamento a uma estmtura de informação de classe no componente de classe, bem como um token de campo. Fig. 7H mostra uma referência de processo virtual 194 para um processo público ou protegido para um processo interno. Aquela referência de processo virtual 194 inclui um deslocamento para uma estrutura de informação de classe no componente de classe, um campo que é liberado para indicar um processo virtual acessível extemamente e para tomá-lo conforme ao formato na Fig. 7C. A referência de processo virtual 194 também inclui um token de processo.

Finalmente, aquela Fig. 71 mostra uma representação de uma referência de processo virtual 196 para um processo visível de pacote para processos internos. A mencionada referência de processo virtual 196 inclui um deslocamento para a estrutura de informação de classe e para o componente de classe, um campo que é ajustado para 1 (um), indicando que o escopo daquela referência é interno ao pacote. A referência 196 inclui também um token de processo.

Figs. 8A-8I são, por sua vez, fluxogramas ilustrando processos para designar tokens e para construir tabelas de processos virtuais e tabelas de processos de interface. Tais processos podem ser efetuados por meio de um conversor 72, conforme discutido acima. Referindo-se agora à Fig. 8A, é mostrado um processo 230 para designar tokens de pacote. Geralmente, as referências de pacotes de dentro de um arquivo CAP são designadas de tokens, que são usados somente no arquivo CAP.

Processo 230 obtém primeiro uma lista de pacotes importados (etapa 231). A lista pode estar em qualquer ordem. A seguir, o processo 230 verifica se o número de pacotes importados excede um limiar predeterminado tal como 127 (etapa 232). Neste caso, limite de 127 é usado para representar um token de pacote em 8 bits, com o bit alto reservado. Se aquele número de pacotes importados exceder limiar predeterminado, tal como 127, o processo falha (etapa 205).

Altemativamente, o processo 230 inicializa o valor de token corrente para zero (etapa 233). A seguir, o processo 230 inicializa o pacote corrente para o primeiro pacote na lista (etapa 234). O processo 230 verifica então se o pacote corrente é nulo (etapa 235). Caso negativo, o processo 230 designa o token corrente para o pacote corrente (etapa 236). A seguir, o processo 23 incrementa o valor de token corrente de um (etapa 237), e ajusta o pacote corrente para o próximo pacote na lista (etapa 238). A partir da etapa 235, no caso em que o pacote corrente é nulo, indicando que não há mais pacotes importados, o processo 230 grava o token em um componente de Importação (etapa 239) e sai. Referências a itens em pacotes importados usam valores de token gravados nos componentes de importação.

Retomando agora à Fig. 8B, é mostrado um processo 240 para designar tokens de classe e interface. O processo 240 obtém primeiro uma lista ordenada arbitrariamente de classes e interfaces públicas (etapa 241). A seguir, verifica-se se o número de classes e interfaces excede um valor predeterminado, tal como 256, que é o número máximo de classes que pode ser representado em 8 bits (etapa 242). Caso afirmativo, o processo 240 falha (etapa 205). Altemativamente, o processo 240 inicializa o valor de token corrente para zero (etapa 243). Inicializa também o item corrente para a primeira classe ou interface na lista obtida na etapa 241 (etapa 244). A seguir, o processo 240 determina se o item corrente é nulo, o que indica que não permanecem mais classes ou interfaces na lista (etapa 245). Caso negativo, o processo 240 designa um valor de token corrente para o item corrente, que pode ser um item de classe ou um item de interface (etapa 246). A seguir, o processo 240 incrementa o valor de token corrente de um (etapa 247) e ajusta o item corrente para a próxima classe ou interface na lista (etapa 248), antes de retomar na malha para a etapa 245. A partir da etapa 245, no caso em que um item corrente é nulo, indicando que não há mais classes ou interfaces na lista, o processo 240 grava um valor de token na tabela de componente de Exportação (etapa 249). Adicionalmente, o processo 240 publica os valores de token no arquivo de exportação (etapa 251) e sai.

As Figs. 8C-1 e 8C-2 processam os tokens de campo estático, com a Fig. 8C-2 sendo uma versão otimizada da Fig. 8C-1 por constantes de tempo de compilação internas. Campos estáticos visíveis extemamente em um pacote, são tokens públicos designados.

Campos visíveis de pacote e estáticos privados não são tokens designadas. Fig. 8C-2 descreve um processo 280 que é uma otimização do processo 250. Nesta otimização, os tokens não são designados para campos estáticos finais que são inicializados para constantes de tempo de compilação. Neste caso, os campos não são conectados no cartão.

Retomando agora à Fig. 8C-1, um processo 250 é mostrado para designar tokens de campo estático em uma classe ou interface pública. O processo 250 obtém primeiramente uma lista ordenada arbitrariamente de campos estáticos públicos e protegidos na classe ou interface pública (etapa 252). Então, o processo 250 ajusta o valor de token corrente para zero (etapa 254) e inicializa o campo corrente para o primeiro campo estático na lista (etapa 256). O processo 225 determina então se o campo corrente é nulo, indicando que não são deixados mais campos (etapa 258), Caso negativo, o processo 250 designa o valor de token corrente para o campo corrente (etapa 260) e incrementa o valor de token corrente de um (etapa 262). O processo 250 então ajusta o campo corrente para o próximo campo corrente na lista (etapa 264) antes de retomar na malha à etapa 258. A partir da etapa 258, no caso em que o campo corrente é nulo, indicando que não são deixados mais campos, o processo 250 determina se o token corrente é maior que um valor predeterminado tal como 255, que é o número máximo de tokens que pode ser representado em 8 bits (etapa 266). Caso afirmativo, o processo 250 falha (etapa 205). Altemativamente, o processo 250 grava os valores de token na tabela de componente de exportação se o componente de exportação deve ser gerado (etapa 268). Finalmente, o processo 250 publica os valores de token nos arquivos de exportação (etapa 270).

Referindo-se agora à Fig. 8C-2, é mostrado um processo 280 que otimiza a designação de tokens de campo estático em uma classe ou interface pública. A otimização reduz o consumo de memória eliminando as constantes de tempo de compilação e substituindo referências para as constantes internas no código de byte. O processo 280 obtém uma lista de campos estáticos públicos e protegidos em uma classe ou interface pública (etapa 282). O processo 280 então ajusta o valor de token corrente para zero (etapa 284) e inicializa o campo corrente para o primeiro campo estático na lista (etapa 286). O processo 280 então verifica se o campo corrente é nulo (não há mais campos) (etapa 288). Caso negativo, o processo 280 determina se o campo corrente é uma constante de tempo de compilação (etapa 290). Caso afirmativo, o processo 280 designa um valor tal como OxFF como um valor de token do campo corrente (etapa 296). Altemativamente, se o campo corrente não é uma constante de tempo de compilação, o processo 280 designa um valor de token corrente ao campo corrente (etapa 292) e incrementa o valor de token corrente de um (etapa 294). A partir das etapas 294 e 296, o processo 280 ajusta então o campo corrente para o próximo campo estático na lista (etapa 298), antes de retomar na malha à etapa 288, para continuar a processar os tokens. A partir da etapa 288, no caso de um campo corrente ser nulo (não há mais campos), o processo então verifica se o token corrente excede um limiar predeterminado tal como 255, que é um número máximo que pode ser representado usando 8 bits (etapa 300). Caso afirmativo, o processo 280 falha (etapa 205), Altemativamente, se exportando, o processo 280 grava os valores de token no componente de exportação (etapa 302). O processo então publica os valores de token no arquivo de Exportação, com as constantes de tempo compiladas (etapa 304) de modo que pacotes de referência podem inserir os respectivos valores antes de sair.

Retomando agora à Fig. 8D, é mostrado um processo 310 para designar tokens de processo estático em uma classe pública. O processo 310 obtém primeiro uma lista de processos estáticos públicos e protegidos e constmtores em uma classe pública (etapa 312). O processo 310 verifica então se o número de processos estáticos excede um valor predeterminado tal como 256 (etapa 314). Caso negativo, o processo ajusta o valor de token para zero (etapa 316) e inicializa o processo corrente para o primeiro processo estático na lista (etapa 318). A seguir, o processo 310 verifica se o processo corrente é nulo (não há mais processos) (etapa 320). Caso negativo, o processo 310 designa um valor de token corrente ao processo estático corrente (etapa 322) e incrementa o valor de token corrente de um (etapa 324). O processo 310 entoa ajusta o processo corrente para o próximo processo estático na lista (etapa 326), antes de retomar na malha à etapa 320. A partir da etapa 320, se o processo corrente é nulo (não há mais processos) o processo grava o valor de token no componente de exportação (etapa 328) e publica os valores de token no arquivo de exportação (etapa 330) antes de sair.

Figs. 8E-1 e 8E-2 relacionam-se a esquemas de designação de token de campos de instância. Figs. 8E-1 e 8E-2 relacionam-se a esquemas de designação de token de campo de instância. Fig. 8E-1 mostra um processo geral para designar tokens de campo, enquanto Fig. 8E-2 é um processo otimizado que estende designações de token a campos internos (ou visíveis de pacotes e privados), campos de gmpos de referências de tipo e permite que tokens sejam facilmente mapeadas para deslocamentos dentro de instâncias.

Retomando agora à Fig. 8E-1, é mostrado um processo 340 para designar tokens de campo de instância em uma classe pública. Primeiro, o processo 340 obtém uma lista de campos de instâncias públicos e protegidos em uma classe pública (etapa 342). Verifica então se o número de campos de instância excede um valor predeterminado tal como 256 (etapa 344) e, caso afirmativo, falha (etapa 205). Altemativamente, o processo 340 ajusta o valor de token corrente para zero (etapa 346) e inicializa um campo corrente para o primeiro campo na lista (etapa 348). A seguir, o processo 340 verifica se o campo corrente é nulo (etapa 350). Caso negativo, o processo 340 designa um valor de token corrente para o campo de instância corrente (etapa 352) e incrementa o valor de token corrente de um (etapa 354). A partir da etapa 354, o processo ajusta o campo corrente para o próximo campo de instância na lista (etapa 360) antes de retornar na malha à etapa 350. A partir da etapa 350, caso o campo corrente seja nulo, o processo 340 publica os valores de token no arquivo de exportação (etapa 362) e sai. Vários fatores podem ser levados em, coma na otimização da abordagem geral da Fig. 8E-1. Em geral, a ordenação dos tokens permanece flexível, tal que o arranjo de token pode ser adaptado para implementações específicas. Fig. 8E-2 descreve um esquema de designação restrito conforme mostrado no exemplo abaixo: Referindo-se agora ã Fig. 8K-2, ú mostrado um processo 370 para otimizar a designação acima de tokens de campo de instância. Como antes, o processo 370 obtém uma lista de todos os campos de instância em um classe (etapa 372). A seguir, o processo 370 verifica se os campos de instância numerados excedem, um, valor predeterminado tal como 256 (etapa 374). Caso afirmativo, o processo 370 falha (etapa 205) e caso negativo, o processo 370 classifica a lista em categorias, incluindo tipos primitivos públicos e protegidos primeiro, tipos de referência públicos e protegidos em segundo lugar, tipos de referenda de pacote e privado em terceiro lugar, e tipos primitivos de pacote e privado por último (etapa 376). O valor de token é ajustado para zero (etapa 378) e o campo corrente é inicializado para o primeiro campo de instância na lista (etapa 380). A seguir, o processo 370 verifica se o campo corrente é nulo (etapa 382). Caso negativo, o processo designa um valor de token corrente para o campo corrente (etapa 384) e incrementa o valor de token corrente de um (etapa 386). O processo 370 determina então se o campo corrente é um tipo inteiro (etapa 388). O tipo inteiro usa dois módulos para permitir que tokens sejam facilmente mapeadas para instâncias. Caso afirmativo, o valor de token corrente é incrementado de um (etapa 390). A partir da etapa 388 ou etapa 390, o processo 370 ajusta o campo corrente para o próximo campo de instância na lista (etapa 392), antes de retomar na malha à etapa 382. A partir da etapa 382, se o campo corrente é nulo, o processo 370 publica os valores de token dos campos de instância público e protegido no arquivo de exportação (etapa 394), antes de sair.

Figs. 8F-1 e 8F-2 designam tokens para processos virtuais. Fig. 8F-1 mostra um esquema geral para designação de ficha de processo virtual enquanto a Fig. 8F-2 estende a designação de ficha para processos virtuais visíveis de pacote.

Referindo-se agora às Figs. 8F-1 e 8F-2, processos para designar tokens de processo virtual são mostrados. Geralmente, processos virtuais definidos em um pacote são designados como tokens exportáveis ou internas. Tokens exportáveis são designadas a processos virtuais públicos e protegidos; neste caso, o bit alto do token é 0 (zero). Os tokens internos são designados a processos virtuais visíveis de pacotes; neste caso, o bit alto do token é um. Uma vez que o bit alto é reservado, estes tokens variam de 0 a 127, inclusive.

Os tokens exportáveis para os processos virtuais introduzidos, visíveis extemamente em uma classe, são numerados de maneira consecutiva, começando num maior que o token de processo virtual exportável numerado mais alto da super classe da classe. Se um processo suprime um processo implementado na super classe da classe, aquele processo usa o mesmo número de token que o processo correspondente na super classe, de modo que os processos suprimidos possam ser identificados como sendo relacionados ao processo que suprimiram.

Aqueles tokens de processo virtual interno são diferentemente designados daqueles tokens de processo virtual exportável. Se uma classe e a sua super classe são definidas no mesmo pacote, os tokens para os processos virtuais introduzidos visíveis de pacote naquela classe são numerados de forma consecutiva, começando em um maior que o token de processo virtual interno numerado mais alto da super classe da classe. E a classe e a sua super classe são definidas em um pacote diferente, os tokens para os processos virtuais introduzidos visíveis de pacotes naquela classe são numerados consecutivamente, começando de zero. Se um processo suprime um processo implementado na super classe da classe, aquele processo usa o mesmo número de token que o processo correspondente na super classe. Para informação fundamental, a definição da linguagem de programação Java especifica que suprimir um processo virtual visível de pacote só é possível se ambas a classe e a sua super classe são definidas no mesmo pacote. O bit alto do byte contendo um token de processo virtual é sempre ajustado para um, para indicar que é um token interno. A ordem dos tokens de processo virtual de pacote introduzida em uma classe não é especificada.

Na Fig. 8F-1, o processo 400 obtém primeiramente uma lista de processos virtuais públicos e protegidos em uma classe (etapa 402). O processo 400 então verifica se a classe possui uma super classe (etapa 402). O processo 400 então verifica se a classe possui uma super classe (etapa 404). Caso afirmativo, o processo 400 verifica adicionalmente se a super classe está no mesmo pacote (etapa 406). A partir da etapa 406, caso a super classe esteja no mesmo pacote, o processo encontra a super classe (etapa 408). E obtém os processos virtuais e tokens para a super classe (etapa 412). O conjunto do processo virtual inclui aqueles definidos para todas as super classe da super classe. A partir da etapa 406, no caso em que a super classe não está no mesmo pacote, o processo 400 encontra a super classe no arquivo de exportação, do pacote importado (etapa 410) e então prossegue para a etapa 412. Da etapa 412, o processo 400 inicializa um valor de token corrente para token de processo virtual de super classe máxima e incrementa seu valor de um (etapa 414), assegurando que não haverá colisão de token dentro da hierarquia. A partir da etapa 404 no caso em que a classe não possui uma super classe, o processo 400 inicializa para zero o valor de token corrente (etapa 416), A partir da etapa 414 ou etapa 416, o processo 400 inicializa o processo corrente para o primeiro processo virtual na lista (etapa 418). A seguir, o processo 400 determina se o processo corrente é nulo (etapa 420). Caso negativo, o processo então determina se o processo virtual corrente é definido pela super classe (etapa 422). Caso afirmativo, o processo é um processo suprimido e o mesmo valor de token é designado ao processo corrente como aquele designado ao processo suprimido na super classe (etapa 424), antes de retomar na malha à etapa 420. A partir da etapa 422, no caso em que o processo virtual corrente não é definido pela super classe este é um processo introduzido. Naquele caso, o processo 400 designa um valor de token corrente ao processo corrente (etapa 426) e incrementa o valor de token corrente de um (etapa 428). O processo 400 então ajusta o processo corrente para o próximo processo na lista (etapa 430) antes de retomar na malha à etapa 420. A partir da etapa 420, caso o processo corrente seja nulo, o processo 400 verifica se o valor de token corrente excede um valor predeterminado, tal como 127 (etapa 432). Caso afirmativo, processo 400 falha (etapa 205). Altemativamente, se o valor de token não é maior que 127, o processo 400 publica os valores de token, no arquivo de exportação, juntamente com os processos “herdados” e seus valores de token (etapa 434), antes de sair. O processo da Fig. 8F-1 pode também ser usado para designar tokens para processos virtuais públicos e protegidos em uma classe visível de pacotes, conforme mostrado na Fig. 8F-2.

Na Fig. 8F-2, é mostrado um processo 440 para estender designação de token a processos virtuais visíveis de pacotes em uma classe. O processo 440 obtém inicialmente uma lista de processos virtuais visíveis de pacotes na classe (etapa 442). A seguir, este verifica se a classe possui uma super classe (etapa 444). Caso afirmativo, o processo verifica então se a super classe está no mesmo pacote (etapa 446). Caso afirmativo, o processo 440 encontra então a super classe no mesmo pacote (etapa 448), obtém os processos virtuais visíveis de pacote e tokens da super classe (etapa 450) e inicializa o valor de token corrente para o token de processo virtual de super classe máxima mais um (etapa 452), para evitar colisões de token com a hierarquia que faz parte do pacote. Isto assegura que os valores de token designados previamente dentro das super classes não são reutilizados para processos introduzidos. Deve ser notado que a etapa 450 pode ser recursiva, até as super classes no mesmo pacote. A partir da etapa 444, caso a classe não possua uma super classe, ou a partir da etapa 446, caso a super classe não esteja no mesmo pacote, o processo 440 ajusta o valor de token corrente para zero (etapa 454). Particularmente, se a super classe não está no mesmo pacote, os processos virtuais visíveis de pacotes daquela super classe não estão acessíveis e então não incluídos na etapa 454. Estes processos potenciais são considerados ao resolver referências para processos virtuais, conforme descrito acima nas Figs. 9D-2 e 9D-3. A partir da etapa 452 ou etapa 454, o processo 440 inicializa o processo corrente para o primeiro processo virtual em uma lista (etapa 456). A seguir, o processo 440 verifica se o processo corrente é nulo (etapa 458). Caso negativo, o processo 440 verifica se o processo virtual corrente é definido por uma super classe (etapa 460). Neste caso, o processo é um processo suprimido. Caso afirmativo, o processo 440 designa então o mesmo valor de token ao processo corrente conforme designado ao processo suprimido na super classe (etapa 462) antes de retomar na malha à etapa 458. A partir da etapa 460, se o processo virtual corrente não é definido por sua super classe, este é um processo introduzido. Neste caso, o processo 440 designa um valor de token corrente ao processo corrente e ajusta o bit alto para um (etapa 464). O bit alto do token do processo virtual é usado para determinar se este é um token de processo virtual público e privado. A seguir, o processo 440 incrementa o valor de token corrente de um (etapa 466) e ajusta o processo corrente para o próximo processo na lista (etapa 468) antes de retomar na malha à etapa 458.

Na etapa 458, no caso em que o processo corrente é nulo, o processo 440 determina se o valor de token corrente excede um valor tal como 127 (que é o número máximo representável em 8 bits com o bit alto reservado) na etapa 470. Caso afirmativo, o processo 440 falha (etapa 205). Altemativamente, no caso em que o valor de token corrente está dentro da faixa, o processo 440 sai. Notar que os tokens para processos virtuais visíveis de pacote são usados intemamente e não são exportados.

Referências de processo virtual podem somente ser resolvidas durante a execução. A tabela de processo virtual permite que o cartão determine qual processo ativar, com base no token, bem como instâncias da classe de processo. O valor de token é usado como um índice para a tabela do processo virtual. Fig. 8G-1 mostra um processo 480 para constmir tabelas de processo virtual público em uma classe. Primeiro, uma lista de processos virtuais públicos e protegidos na classe, é obtida (etapa 482). A seguir, o processo 480 obtém processos virtuais e tokens de uma super classe (etapa 484). A etapa 484 é recursiva, incluindo todas as super classes da classe. O processo 480 cria então uma tabela, ordenando processos virtuais por valores de token (etapa 486) e elimina processos virtuais duplicados. As duplicatas são geradas para processos suprimidos. Neste caso, o processo definido na classe corrente é representado na tabela de processo, ao invés daquele definido em uma super classe. O processo 480 então estabelece uma contagem até uma classe de token de processo virtual máximo na etapa 488 e grava uma tabela e contagem no componente de classe (etapa 490) antes de sair.

Retomando agora à Fig. 8G-2, é mostrado um processo 500 que otimiza a constmção de tabelas de processo virtual público na classe. O processo 500 diminui o tamanho requerido para armazenar uma tabela de processo virtual, removendo elementos superpostos em uma tabela de processo virtual de super classe. O processo 500 obtém inicialmente uma lista de processos virtuais públicos e protegidos em uma classe (etapa 502). A seguir, os processos virtuais e tokens da super classe são obtidos (etapa 504). Etapa 504 é recursiva, incluindo todas as super classes da classe. A seguir, o processo 500 inicializa uma tabela, ordenando processos virtuais obtidos nas etapas 502 e 504 por valores de token (etapa 506). Este processo supõe que o processo tem pelo menos uma entrada. O processo 500 inicializa uma contagem para um token de processo virtual máxima mais um (etapa 508). O processo 500 também ajusta a contagem base para zero (etapa 510). A seguir, o processo 500 verifica se a contagem é positiva (etapa 512). Caso afirmativo, o processo verifica se a primeira entrada na tabela é definida pela classe corrente (etapa 514). Caso negativo, o processo remove o processo da tabela e desloca os processos restantes para cima na tabela (etapa 518). O processo 500 então decrementa a contagem de um (etapa 520) e incrementa a contagem de base de um (etapa 522), antes de retomar na malha à etapa 512. A partir da etapa 514, no caso em que a primeira entrada definida na classe corrente, ou no caso em que contagem é zero na etapa 512, o processo 500 prossegue para gravar a tabela, contagem e base na componente de classe (etapa 516), antes de sair.

Figs. 8H-1 e 8H-2 mostram um processo 524 para designar tokens de processo de interface em uma interface pública. Particularmente, Fig. 8H-2 mostra em mais detalha a etapa 526 da Fig. 8H-1. Referindo-se agora à Fig. 8H-1, o processo 524 designa tokens de processo de interface em uma interface pública. O processo 524 inicialmente obtém um conjunto de processos de interface na interface pública (etapa 525). A seguir, o processo 534 obtém uma lista de super interfaces da interface (etapa 526). Esta operação é definida em mais detalhe na Fig. 8H-2. O processo 524 então incorpora o conjunto de processos definidos pela interface e por suas super interfaces (etapa 527). A seguir, o processo 524 verifica se mais de 256 processos existem ou não (etapa 529). Caso afirmativo, o processo 524 falha (etapa 205).

Altemativamente, se existem menos de 256 processos, o processo 524 ajusta o valor de token corrente para zero (etapa 530) e inicializa o processo corrente para o primeiro processo no processo do conjunto de processos (etapa 532). A seguir, o processo 524 verifica se o processo corrente é nulo (etapa 533). Caso negativo, o processo 524 designa o valor de token corrente ao processo de interface corrente (etapa 534), incrementa o valor de token corrente de um (etapa 535), e ajusta o processo corrente para o próximo processo no conjunto (etapa 536) antes de retomar na malha à etapa 533. A partir da etapa 533, se processo corrente é nulo, o processo 524 publica a lista de super interface associada à interface e os valores de token de processo no arquivo de exportação (etapa 537) e sai.

Referindo-se agora à Fig. 8H-2, a etapa 526 da Fig. 8H-1 é mostrada em mais detalhe. Primeiro, o processo da Fig. 8H-2 seleciona uma interface (etapa 682). A seguir, obtém uma lista de interfaces “herdadas” pela interface (etapa 684) e ajusta a interface corrente para a primeira interface na lista (etapa 686). A seguir, o processo de 8H-2 inicializa o conjunto de resultados para um conjunto vazio (etapa 688). A partir da etapa 688, o processo da Fig. 8H-2 adiciona iterativamente interfaces a um conjunto resultado. Isto é feito verificando primeiro se a interface corrente é nula, indicando que não precisam ser processadas outras interfaces (etapa 690). Caso negativo, o processo obtém um conjunto de super interfaces da interface corrente (etapa 692). Etapa 692 ativa o processo 526, recursivamente.

Ao completar a etapa 692, o processo da Fig. 81-1-2 adiciona o conjunto de super interfaces a um conjunto resultado (etapa 694) e a interface corrente ao conjunto resultado (etapa 696). O processo então ajusta a interface corrente para a próxima interface (etapa 698) e retoma na malha à etapa 690 para continuar a processar todas as interfaces. A partir da etapa 690, no caso em que a interface corrente é nula, o processo da Fig. 8H-2 sai, retomando o conjunto resultado.

Uma tabela de interface contém uma entrada para cada interface diretamente implementada por uma classe, e para todas as super interfaces das interfaces implementadas diretamente. Cada entrada na tabela de interface contém uma identificação da interface e uma tabela de processo de interface. A tabela mapeia declarações de processo de interface para implementações na classe.

Figs. 81-1 e 81-2 mostram um processo 700 para constmir uma tabela de interface de uma classe. Particularmente, a Fig. 81-2 mostra em mais detalhe as etapas 708 da Fig. 81-1.

Referindo-se agora à Fig. 81-1, é mostrado um processo 700 para construir tabelas de interface. Primeiro, o processo 700 obtém uma lista de interfaces, incluindo super interfaces (ver processo 526) que são implementadas pela classe corrente (etapa 702). A seguir, o processo 700 ajusta a interface corrente para a primeira interface neste conjunto (etapa 704). O processo 700 verifica então se a interface corrente é nula, indicando que está terminado (etapa 706). Caso negativo, o processo 700 procede à construção de uma tabela de processo de interface para a interface corrente para a classe (etapa 708), conforme mostrado em mais detalhe na Fig. 81-2. A seguir, o processo 700 ajusta uma interface corrente para a próxima interface (etapa 710), antes de retomar na malha à etapa 706. A partir da etapa 706, no caso em que a interface corrente é nula, o processo 700 grava as interfaces com suas tabelas de processo de interface no componente de classe (etapa 712) antes de sair.

Referindo-se agora à Fig. 81-2, etapa 708 é mostrada em mais detalhe. Este processo obtém primeiro a tabela de processo virtual para a classe (etapa 722) e os processos de interface tokens para a interface, incluindo processos “herdados” (etapa 724). A seguir, o processo da Fig. 81-2 inicializa uma tabela de processo de interface, ordenando os processos por seu valor de token (etapa 726). A seguir, o processo ajusta o processo corrente para o primeiro processo da tabela de processo de interface (etapa 728). A partir da etapa 728, o processo verifica se o processo corrente é nulo, indicando que terminou (etapa 730). Caso negativo, o processo da Fig. 81-2 encontra uma implementação do processo de interface na tabela de processo virtual (etapa 732). A seguir, o processo grava um valor de token do processo virtual na tabela de processo de interface, na localização do processo corrente (etapa 736), antes de retomar na malha à etapa 730. A partir da etapa 730, no caso em que o processo corrente é nulo, o processo da Fig. 81-2 sai. A ligação dinâmica de elementos durante a execução, é discutida a seguir nas Figs. 9A-9C que descrevem a resolução de referências para elementos dinâmicos. Durante a compilação, conversão e designação de token, referências a campos de instância, processos virtuais e processos de interfaces não podem ser resolvidas para uma implementação particular, mas somente para uma descrição abstrata do item.

No caso de campos de instância, tokens são designadas dentro do escopo da classe de definição. Uma instância da classe contém todos os campos definidos, não só pela classe como também por todas as suas super classes. Os tokens não indicam a localização do campo dentro da instância, uma vez que não podem refletir uma distribuição particular da instância e não podem responder pela localização de campos privados e visíveis de pacote definidos pela super classe.

No caso de processos virtuais, durante compilação e conversão, o nome e tipo de assinatura são conhecidos, bem como uma classe dentro de uma hierarquia que implementa tal processo. Entretanto, a implementação exata não pode ser conhecida até a execução, quando é possível determinar a classe particular na instância na qual o processo é ativado. Por exemplo, ambas classe A e sua super classe B implementam uma definição de processo M. Não pode ser sabido, até a execução, se uma ativação do processo M em uma instância de tempo de compilação tipo B resultará na execução da implementação da classe A ou da classe B.

Para prover um meio para expedição adequada de uma ativação de um processo virtual durante execução, a designação de token de processo virtual é estendida dentro da hierarquia de classe. Isto é, um processo de uma subclasse que suprime um processo introduzido previamente em uma cadeia hereditária de super classe precisa ter o mesmo valor de token que o processo que suprime. Também, processos introduzidos (aqueles processos que não suprimem processos definidos em uma super classe) precisam ter valores de token que sejam únicos dentro da cadeia hereditária. Tabelas de processos virtuais são definidas para cada classe, para prover um meio para mapear um token de processo virtual para uma implementação particular.

Processos de interfaces são similares a processos virtuais no aspecto em que a implementação particular não pode ser conhecida até o momento de execução, porém diferem pelo fato de os processos de interface poderem ser herdados de interfaces múltiplas. A hereditariedade múltipla de interface causa um problema com o modo pelo qual os tokens de processo virtual são designados. Um processo em uma classe que suprime um processo introduzido em mais de uma interface pode não ter necessariamente o mesmo valor de token que os processos que suprimem, pois as definições múltiplas podem todas possuir valores diferentes. Portanto, cada conjunto de processos para uma interface particular tem valores de token designados sem observar os valores de token dos processos de qualquer outra interface.

Como as interfaces não compartilham valores de token, é necessária a informação adicional para expedir uma ativação de processo de interface para uma implementação de processo particular. Como os tokens de processos de interface são únicos dentro do escopo de uma interface, ambos tokens de processo de interface e identidade da interface são necessários para determinar o processo implementado pela classe de uma instância no tempo de execução. Uma tabela de interface é definida para cada classe que mapeia uma identidade de interface para uma tabela de processo de interface. A tabela de processo de interface mapeia os tokens de processos de interface para aquela interface, para implementações de processo naquela classe.

Figs. 9A-9C são fluxogramas ilustrando processos para resolver tokens durante a execução. Referindo-se agora à Fig. 9A, é mostrado um processo 580 para resolver referências de campo de instância. Primeiramente, o processo 580 obtém uma instância contendo o campo a partir de uma pilha de tempo de execução (etapa 582). Então, o processo 580 determina um token associado ao campo e mapeia o token para um índice (etapa 584). O referido mapeamento do token para o índice pode requerer examinar informação de tipo de campo de instância. Ainda mais, a operação pode requerer ajustar o valor de token pelo tamanho da instância da super classe. Finalmente, o processo 580 encontra a representação do campo na instância, usando o índice (etapa 586) antes de sair.

Na Fig. 9B-1, é mostrado um processo 620 para resolver uma referência para processo virtual público ou protegido. Primeiro, o processo 620 obtém uma instância de uma classe a partir da pilha de tempo de execução (etapa 621) e determina a classe de instância (etapa 622). A seguir, o processo 620 acessa a tabela de processo virtual público da classe (etapa 624) e obtém uma entrada de tabela de processo usando o token de processo como um índice (etapa 626). Finalmente, o processo 620 encontra e executa o processo, baseado no conteúdo da entrada na tabela de processo virtual (etapa 628) e sai.

Retomando agora à Fig. 9B-2, é mostrado um processo 600 para resolver uma referência para qualquer processo virtual (incluindo visível de pacote). Primeiro, o processo 600 obtém uma instância de uma classe a partir da pilha de tempo de execução (etapa 601) e determina a classe da instância (etapa 602). A seguir, o processo 600 determina se o bit alto do token de processo é ajustado para um (etapa 604). Caso negativo, o processo 60 obtém uma tabela de processo virtual público (etapa 606) e usa o token de processo como um índice na tabela de processo virtual (etapa 608). A partir da etapa 604, no caso em que o bit alto do token de processo é igual a um, o processo 600 então ajusta o bit alto para zero (etapa 610) e obtém a tabela de processo virtual de pacote (etapa 612) antes de proceder à etapa 608. Finalmente, o processo 600 encontra e executa o processo, com base no conteúdo da entrada na tabela de processo virtual (etapa 614) e sai.

Fig. 9B-3 mostra um processo otimizado 670 para resolver uma referência para qualquer processo virtual, usando tabelas de processo virtual otimizadas, conforme descrito na Fig. 8G-2. Primeiro, o processo 670 obtém uma instância de uma classe a partir da pilha de tempo de execução (etapa 671) e ajusta a classe corrente para ser a classe da instância (etapa 672). Um índice de tabela de processo é inicializado para o valor de token de processo (etapa 674). O processo -670- determina então se o bit alto do token de processo é igual a um (etapa 676). Caso negativo, o referido processo 670 estabelece um valor base para a base da tabela de processo público da classe corrente (etapa 678). A seguir, a tabela de processo é ajustada para a tabela de processo virtual público da classe corrente (etapa 680). O processo 670 verifica então se o índice de tabela de processo é menor que o valor base (etapa 682) e caso afirmativo, ajusta a classe corrente para ser a super classe da classe corrente (etapa 684). A partir da etapa 684, o processo 670 retoma na malha à etapa 676, para continuar o processamento.

Na etapa 676, se o bit alto é igual a um, o processo 670 ajusta o bit alto do índice de tabela de processo para zero (etapa 690). Ajusta o valor base para a base da tabela do processo de pacote da classe corrente (etapa 692) e ajusta a tabela de processo para a tabela de processo virtual de pacote da classe corrente (etapa 694) antes de continuar para a etapa 682. A partir da etapa 682, se o índice de tabela de processo é maior que a base, o processo 670 obtém uma entrada de tabela de método usando o índice de tabela de método mais o valor da base (etapa 686). O processo 670 encontra então o processo com base no conteúdo da entrada na tabela de método da classe corrente (etapa 688). Subsequentemente, o processo 670 sai.

Referindo-se agora à Fig. 9C, é mostrado um processo 650 para resolver referência de processo de interface. Primeiro, o processo 650 obtém uma instância de uma classe a partir da pilha de tempo de execução (etapa 651) e ajusta a classe corrente para a classe da instância (etapa 652). A seguir, o processo 650 busca a interface especificada na tabela de interface da classe corrente (etapa 654). O processo determina então se a interface foi encontrada (etapa 656). Caso negativo, o processo então ajusta a classe corrente para a super classe da classe corrente (etapa 660), antes de retomar na malha à etapa 654. A partir da etapa 656, no caso em que a interface especificada é encontrada, o processo 650 obtém a tabela de método de interface correspondente na classe corrente (etapa 662). Obtém-se, então, token do processo virtual a partir da entrada na tabela, cujo índice é igual à token de processo de interface (etapa 664). O processo 650 obtém então a tabela de método virtual público da classe da instância (etapa 666). O processo 650 obtém a localização do processo virtual a partir da entrada na tabela associada à token de processo virtual (etapa 668). O processo 650 localiza então o processo, com base no conteúdo da entrada na tabela de processo virtual (etapa 669). Uma vez que isto é feito, o processo 650 sai.

Embora a invenção tenha sido ilustrada com respeito a uma implementação de cartão inteligente, a invenção se aplica a outros dispositivos de base pequena, tais como dispositivos que são relativamente restritos ou limitados em memória ou potência de computação ou velocidade. Tais dispositivos de recursos restritos podem incluir dispositivos de varredura de contorno, dispositivos programáveis de campo, “pagers” e telefones celulares, entre muitos outros. A invenção pode provar ser vantajosa ao usar “servlets”, se há compartilhamento de objeto entre eles. Certos sistemas de mesa podem também utilizar as técnicas da invenção. A presente invenção também ser relaciona a aparelho para efetuar estar operações. Este aparelho pode ser especialmente construído para a finalidade requerida, ou pode compreender um computador de uso geral seletivamente ativado ou reconfigurado por um programa de computador armazenado no computador. Os procedimentos aqui apresentados não são inerentemente relacionados a um computador particular ou outros aparelhos. Várias máquinas de uso geral podem ser usadas com programas escritos de acordo com os ensinamentos aqui, ou pode ser verificar ser mais conveniente construir aparelho especializado para executar as etapas do processo exigidas. A estrutura requerida para uma variedade destas máquinas, surgirá a partir da descrição dada. Ademais, será verificado que uma máquina virtual consistente com a invenção pode prover funcionalidade além daquela das primeiras máquinas virtuais, tais como as máquinas virtuais descritas na Especificação de Máquina Virtual JavaTM.

Enquanto a linguagem de programação e plataforma JavaTM são adequadas para a invenção, qualquer linguagem ou plataforma possuindo certas características deveria ser bem adequada para implementar a invenção. Estas características incluem segurança de tipo, segurança de apontador, orientada a objeto, conectada dinamicamente, e baseada em máquina virtual. Nem todas estas características precisam estar presentes numa implementação particular. Em algumas realizações, linguagens ou plataformas faltando uma ou mais destas características, podem ser utilizadas. Uma “máquina virtual” podería ser implementada em bits (máquina virtual) ou em silício (circuitos integrados específicos para aplicação/máquinas físicas/reais). Também, ainda que a invenção tenha sido ilustrada exibindo segurança objeto por objeto, outras abordagens tais como segurança classe por classe poderíam ser utilizadas. O sistema da presente invenção pode ser implementado em hardware ou em programa de computador. Cada um de tais programas de computador podem ser armazenados em um meio de armazenagem ou dispositivo (por exemplo, CD ROM, disco rígido ou disquete magnético) que é legível por um computador programável geral ou de finalidade especial, para configurar e operar o computador quando o meio de armazenagem ou dispositivo é lido pelo computador para efetuar os procedimentos escritos. O sistema pode também ser implementado como um meio de armazenagem legível por computador, configurado com um programa de computador, onde o meio de armazenagem assim configurado faz com que uni computador opere de uma maneira específica e predefinida. O programa é aqui, e em geral, concebido para ser uma seqüência auto consistente de etapas conduzindo a um resultado desejado. Estas etapas são aquelas requerendo manipulações físicas de quantidades físicas. Usualmente, embora não necessariamente, estas quantidades tomam a forma de sinais elétricos ou magnéticos capazes de serem armazenados, transferidos, combinados, comparados e caso contrário manipulados. É provado ser conveniente por vezes, principalmente por razões de uso comum, referir-se a estes sinais como bits, valores, elementos, símbolos, caracteres, termos, números, ou similares. Deveria ser notado, entretanto, que todos estes e termos similares devem ser associados às quantidades físicas apropriadas e são meramente rótulos convenientes aplicados a estas quantidades.

Enquanto a invenção foi mostrada e descrita com referência a uma realização desta, aqueles versados na arte entenderão que as modificações acima e outras, na forma e detalhe, podem ser feitas sem se afastar do escopo das reivindicações seguintes. Outras realizações estão dentro do escopo das reivindicações seguintes.

Claims (17)

1. Processo para conexão de código neutro de arquitetura transferido para um computador de recursos restritos (40), o código neutro de arquitetura sendo separável em diversos pacotes que têm pelo menos um item referenciável, o dito processo compreendendo as etapas de: formar os diversos pacotes a partir do código (10); para cada um do pelo menos um item referenciável dentro dos diversos pacotes, formar um mapeamento de cada item referenciável dentro dos diversos pacotes para um token correspondente (84), em que cada token possui um tipo de token associado com o mesmo, em que cada token que apresenta um mesmo tipo de token representa uma mesma espécie de item referenciável, e em que cada espécie de item referenciável nos diversos pacotes possui um escopo independente de capacidade limitada para tokcns daquela espécie; caracterizado pelo feto de que compreende ainda as etapas de: ordenar os tokens para se corresponderem a um modo de tempo de execução; transferir os diversos pacotes para o computador de recursos restritos (40); e conectar os diversos pacotes num código executável usando os tokens ordenados.

2. Processo de acordo com a reivindicação 1, caracterizado pelo feto de compreender adicional mente: descrever o mapeamento num arquivo de exportação armazenado em um computador remoto; e gerar os pacotes no computador remoto com base no arquivo de exportação.

3. Processo de acordo com a reivindicação 2, caracterizado pelo fato de compreender adicionalmente designar um token para cada pacote.

4. Processo de acordo com a reivindicação 2, caracterizado pelo fato de compreender adicionalmente designar tokens para uma ou mais classes de interface públicas e interfaces.

5. Processo de acordo com a reivindicação 4, caracterizado pelo fato de compreender adicionalmente designar um token para cada: campo estático público; processo estático; campo de instância; processo virtual; e processo de interface.

6. Processo de acordo com a reivindicação 2, caracterizado pelo fato de compreender ainda publicar os tokens no arquivo de exportação.

7. Processo de acordo com a reivindicação 4, caracterizado pelo fato de compreender adicionalmente mapear um token de processo de interface para um token de processo de implementação.

8. Processo de acordo com a reivindicação 7, caracterizado pelo fato de o item ser uma interface de classe, compreendendo adicionalmente gerar uma lista de processos de interface para cada interface implementada na classe.

9. Processo de acordo com a reivindicação 8, caracterizado pelo fato de compreender adicionalmente: localizar uma implementação de um processo na classe ou em sua super classe; obter um token associado com o processo; e associar o token de processo de interface ao token de processo de implementação.

10. Processo de acordo com a reivindicação 2, caracterizado pelo fato de que a etapa de geração compreende ainda converter um arquivo de classe e o arquivo de exportação em um arquivo transferível, onde dito arquivo transferível é um de um arquivo applet convertido e um arquivo de biblioteca.

11. Processo de acordo com a reivindicação 10, caracterizado pelo fato de compreender adicionalmente instalar o pacote.

12. Processo de acordo com a reivindicação 1, caracterizado pelo fato de a etapa de conexão ser realizada durante a etapa de transferência.

13. Processo de acordo com a reivindicação 12, caracterizado pelo fato de a etapa de conexão incluir conexão parcial.

14. Processo de acordo com a reivindicação 1, caracterizado pelo fato de a etapa de conexão ser realizada em uma operação contínua.

15. Processo de acordo com a reivindicação 1, caracterizado pelo fato de compreender adicionalmente execução do código executável no modo de tempo de execução.

16. Processo de acordo com a reivindicação 15, caracterizado pelo fato de a etapa de conexão ser realizada antes da etapa de execução.

17. Processo de acordo com a reivindicação 15, caracterizado pelo fato de a etapa de execução e de a etapa de conexão serem realizadas ao mesmo tempo.