BRPI0806879A2

BRPI0806879A2 - Negociação de boot entre múltiplos boots-dispositivos capazes

Info

Publication number: BRPI0806879A2
Application number: BRPI0806879-8A
Authority: BR
Inventors: Vladimir Sadovsky; Hugh A Teegan; Robin A Alexander; Robert Hasbun
Original assignee: Microsoft Corp
Priority date: 2007-02-28
Filing date: 2008-01-23
Publication date: 2014-04-29
Also published as: JP4738534B2; RU2009132388A; EP2132626A1; EP2132626B1; KR101251710B1; CN101622600A; TWI368169B; EP2132626A4; US7818559B2; KR20090118941A; JP2010520528A; RU2456662C2; US20080209199A1; TW200839615A; WO2008106253A1; BRPI0806879A8; CN101622600B

Description

“NEGOCIAÇÃO DE BOOT ENTRE MÚLTIPLOS BOOTs - DISPOSITIVOS CAPAZES”

FUNDAMENTO

Dispositivos móveis são frequentemente conectados a outros dispositivos de com- putação. Tradicionalmente, a relação entre os dispositivos é assumida antes de os dispositi- vos serem conectados. Por exemplo, quando um usuário conecta um telefone móvel a um computador pessoal, a hipótese é frequentemente que o computador pessoal atue como um hospedeiro para o telefone móvel. Os sistemas atuais não negociam as funções dos disposi- tivos baseados nas capacidades dos dispositivos.

SUMÁRIO

O seguinte apresenta um sumário simplificado da descrição a fim de prover um en- tendimento básico ao leitor. Este sumário não é uma visão geral extensiva da descrição e não identifica elementos da invenção ou delineia o escopo da invenção. Sua única finalidade é apresentar alguns conceitos descritos aqui de uma forma simplificada como uma introdu- ção à descrição mais detalhada que é apresentada a seguir.

As modalidades da invenção capacitam múltiplos dispositivos capazes de boot para determinar qual dispositivo irá executar um controle da imagem de boot com base nas ne- gociações de boot. O dispositivo restante pode servir como um recurso para o controle da imagem de boot. A determinação pode ser baseada em cada recurso do dispositivo, política predefinida, e/ou interação de usuário.

Muitas das características criadas serão prontamente apreciadas como as mesmas que se tornam melhor entendidas por referência à descrição detalhada a seguir considerada em conexão com os desenhos em anexo.

BREVE DESCRIÇÃO DOS DESENHOS

Números de referência similares são utilizados para designar partes similares nos desenhos acompanhae em anexo.

A Figura 1 é um diagrama em blocos de um dock conectado a um dispositivo móvel de acordo com uma modalidade da invenção.

A figura 2 é um diagrama em blocos de um dispositivo móvel de acordo com uma modalidade da invenção.

A Figura 3 é um fluxograma mostrando a lógica e operações de um dispositivo mó- vel e um dock desempenhando negociação de boot de acordo com uma modalidade da in- venção.

A Figura 4 é uma continuação do fluxograma da Figura 3 de acordo com uma mo- dalidade da invenção.

A Figura 5 é um diagrama em blocos de um telefone móvel provendo uma imagem de boot de máquina virtual de acordo com uma modalidade da invenção. A Figura 6 é um diagrama em blocos de um telefone móvel e um Iaptop desempe- nhando negociação de boot de acordo com uma modalidade da invenção.

A Figura 7 é uma tabela de registro de capacidades de acordo com uma modalida- de da invenção.

A Figura 8 é um diagrama em blocos de um telefone móvel e um computador pes-

soal desempenhando negociação de boot de acordo com uma modalidade da invenção.

A Figura 9 é um diagrama em blocos de um dispositivo de computação de exemplo para implementação das modalidades da invenção.

DESCRIÇÃO DETALHADA A descrição detalhada provida abaixo em conexão com os desenhos em anexo é

pretendida como uma descrição dos presentes exemplos e não é pretendida para represen- tar as formas somente nas quais os presentes exemplos podem estar construídos ou utiliza- dos. A descrição expõe as funções dos exemplos e as seqüências de etapas para construir e operar os exemplos. No entanto, as mesmas ou equivalentes funções e seqüências po- dem ser acompanhadas por diferentes exemplos.

Na descrição e reivindicações a seguir, o termo “acoplado” e seus derivados podem ser utilizados. “Acoplado” pode significar que dois ou mais elementos estão em contado (fi- sicamente, eletricamente, magneticamente, oticamente, etc.). “Acoplado” pode também sig- nificar que dois ou mais elementos não estão em contato um com o outro, mas ainda coope- ram ou interagem um com o outro (por exemplo, acoplado comunicativamente).

A Figura 1 e a discussão a seguir são pretendidas para prover um resumo, descri- ção geral de um ambiente de computação adequável para implementar modalidades da in- venção. O ambiente de operação da Figura 1 é apenas um exemplo de um ambiente de operação e não é pretendido para sugerir qualquer limitação como ao escopo do uso ou 25 funcionalidade do ambiente de operação. Apesar de não requeridas, as modalidades da invenção serão descritas no contexto geral de “instruções legíveis por computador” sendo executadas por um ou mais dispositivos de computação. As instruções legíveis por compu- tador podem ser distribuídas através de uma mídia legível por computador. As instruções legíveis por computador podem ser implementadas como módulos de programas, tais como 30 funções, objetos, Interfaces de Programação de Aplicação (APIs), estruturas de dados, e os similares, que desempenham tarefas específicas ou implementam tipos de dados de resumo específico. Tipicamente, a funcionalidade das instruções legíveis por computador pode ser combinada ou distribuída como desejada nos vários ambientes.

A Figura 1 mostra um dock 102 conectado a um dispositivo móvel 120 via conexão 116. Como utilizado aqui, um dock refere-se a um dispositivo de computação que pode ser conectado a um dispositivo móvel, tal como dispositivo móvel 120. As modalidades da in- venção avaliam as capacidades do dock e a habilidade do dock para inicializar a partir de uma imagem de boot armazenada no dispositivo móvel 120. Por exemplo, o dock 102 pode incluir um dock “burro”, tal como berço do dispositivo móvel, que replica meramente portas do dispositivo móvel para facilitar a conexão para outros dispositivos de computação. Em outro exemplo, o dock 102 pode incluir um dock “inteligente”, tal como um laptop, que possui sua própria unidade de processamento, memória, armazenamento, e assim por diante.

O dock 102 pode incluir uma unidade de processamento 104 e memória 106. O dock 102 também inclui uma conexão de comunicação 114 para dados de entrada / saída provenientes do dispositivo móvel 120. O dock 102 pode também incluir armazenamento 108, tal como Drive de Disco Rígido (HDD) ou memória flash.

O dock 102 pode incluir Armazenamento Não-Volátil (NVS) 110, tal como ROM,

memória flash, e os similares. O NVS 110 pode possuir Firmware (F/W) armazenado 112 para execução na unidade de processamento 104. Em uma modalidade, o firmware 112 inclui instruções para rotinas de reinicializações anteriores a uma carga do Sistema opera- cional (OS) e execução no dock 102. O Firmware 112 pode também incluir instruções de 15 entrada / saída de nível baixo para comunicação com dispositivos do dock 102 durante o tempo de execução de OS. O firmware 112 pode também ser referido como Sistema Básico de entrada / saída (BIOS).

Em estrutura típica, a inicialização e configuração de um dispositivo de computação são comumente referidas como uma fase de reinicialização. A fase de reinicialização é ge- 20 ralmente definida como firmware que executa entre o reajuste do processador e a primeira instrução do carregador do Sistema operacional (OS). As instruções que executam durante a reinicialização são frequentemente referidas como Sistema Básico de Entrada /saída (BIOS). No início da reinicialização, ele está acima das instruções no firmware para iniciali- zar o sistema para o ponto que um OS carregado de mídia, tal como um disco rígido, pode 25 assumir a direção. O início do carregamento de OS inicia o período comumente referido co- mo tempo de execução de OS. As instruções para implementação do OS e/ou aplicações podem ser referidas como uma imagem de boot.

Durante o tempo de execução, o BIOS pode agir como uma interface entre os com- ponentes de software e hardware de um sistema de computador. O ambiente operacional 30 entre o nível de OS e o nível de hardware é geralmente referido como o BIOS (algumas ve- zes referido como o ambiente de firmware). Também, a atividade de OS pode ser suspensa quando o OS entra em um estado ocioso, tal como estado ocioso definido no relatório de Interface de Potência e Configuração Avançada (ACPI). O BIOS pode estar envolvido no despertar do OS a partir de um estado ocioso.

Com referência ao dispositivo móvel 120, em uma modalidade, o dispositivo móvel

120 pode incluir um dispositivo de computação permanente livre, tal como um telefone mó- vel, um tocador de mídia, e os similares. Em outra modalidade, o dispositivo móvel 120 pode incluir um dispositivo móvel dependente de hospedeiro, tal como um Drive Flash de Barra- mento Serial Universal (USB), um cartão de memória, um cartão inteligente, e os similares. Como utilizado aqui, “dependente de hospedeiro” refere-se a um dispositivo móvel que pode não ser utilizado a menos que o dispositivo móvel esteja conectado a um hospedeiro.

O dispositivo móvel 120 pode incluir um controlador para o armazenamento 126. O

controlador 124 pode gerenciar a leitura / escrita de dados no armazenamento 126 bem co- mo desempenhar outras funções. O armazenamento 126 pode incluir um drive de disco magnético, um drive ótico, um armazenamento não-volátil, tal como memória flash, e os si- milares. O dispositivo móvel 120 pode também incluir uma ou mais conexões de comunica- ção 122 para conectar o dispositivo móvel 120 a outros dispositivos de computação.

A conexão 116 pode incluir uma conexão com fio ou sem fio entre o dock 102 na conexão de comunicação 114 e o dispositivo móvel 120 na conexão de comunicação 122. Em uma modalidade, o dock 102 e o dispositivo móvel 120 em proximidade junto a um outro como parte de uma Rede de Área Pessoal do usuário (PAN). Exemplos de uma conexão 15 116 inclui USB (com fio ou sem fio), firewire (IEEE 1394), radiofreqüência (por exemplo, Bluetooth, Wi-Fi, etc.), infravermelho, e os similares.

De volta à Figura 2, uma modalidade do dispositivo móvel 120 é mostrada. O con- trolador 124 pode incluir uma unidade de processamento 202 e Armazenamento Não-Volátil (NVS) 204. A unidade de processamento 202 pode incluir um processador geral, tal como 20 um processador computando ajuste de instrução reduzida de 32 bits. Enquanto uma única unidade de processamento 202 é mostrada, as modalidades do dispositivo móvel 120 po- dem incluir múltiplas unidades de processamento tais como múltiplos processadores, múlti- plas cores, e os similares. Em uma modalidade, o controlador 124 pode incluir conjunto de circuitos dedicados (não mostrado) para conduzir operações especializadas tais como crip- 25 tografia, gerenciamento de direitos digitais, processamento de sinal digital, e os similares.

Em uma modalidade, NVS 204 tem armazenado firmware 206 que pode ser execu- tado pela unidade de processamento 202. O firmware 206 pode incluir uma imagem de boot do dispositivo. A imagem de boot do dispositivo pode incluir um sistema operacional (tal co- mo um Sistema operacional em Tempo Real (RTOS)), uma ou mais aplicações, e os simila- 30 res, para execução no dispositivo móvel 120. O firmware 206 pode também incluir instru- ções para executar modalidades da invenção.

A modalidade da Figura 2 mostra o armazenamento 126 dividido em partição 230 e partição 240. Um versado na técnica possuindo o benefício desta descrição entenderá que o armazenamento 126 pode incluir mais que duas partições. A partição 230 inclui instruções 35 e/ou dados para o dispositivo móvel 120, tal como dados do dispositivo 231. O dispositivo móvel 120 pode executar software nativo ou em uma máquina virtual. Mensagens de segu- rança podem ser utilizadas para proteger acesso à partição 230 através dos dispositivos de computação conectados, tais como dock 102.

A partição 240 pode incluir instruções e/ou dados para uso por outro dispositivo de computação, tal como dock 102. A Figura 2 mostra a partição 240 possuindo imagens de boot 241, 242, e 243. Uma imagem de boot pode incluir instruções para executar um OS 5 e/ou aplicações em um dispositivo de computação. Imagens de boot exemplares incluem um OS da Microsoft Windows® e/ou aplicações Office, um ambiente de estrutura .Net, um am- biente Java®, e os similares. Como descrito acima, o dispositivo móvel 120 pode enviar uma imagem de boot para o dock 102 para execução no dock 102. Em uma modalidade, o aces- so para a partição 240 pode ser restrita a um círculo de docks confiados.

De volta à Figura 3, um fluxograma 300 mostra a lógica e operações de um disposi-

tivo móvel e um dock desempenhando uma negociação de boot de acordo com uma moda- lidade da invenção. Em uma modalidade, pelo menos uma parte da lógica do fluxograma 300 pode ser conduzida pelo dispositivo OS do dispositivo móvel 120. O dispositivo móvel e o dock vem de um para outro sem sugestões sobre sua relação ou sobre cada uma das ou- 15 tras capacidades. A determinação de qual dispositivo irá executar uma imagem de boot de controle não é feita até depois das negociações terem sido completadas.

Como utilizado aqui, “imagem de boot de controle” refere-se à imagem executando em um dispositivo de computação que pode gerenciar pelo menos alguns dos recursos dos outros dispositivos de computação. Por exemplo, quando o dock inicializa a partir de uma 20 imagem de boot provida pelo dispositivo móvel, o dock pode utilizar recursos do dispositivo móvel, tal como armazenamento. Quando o dispositivo móvel executa a imagem de boot de controle (por exemplo, o OS do dispositivo móvel), então o dispositivo móvel pode utilizar os recursos do dock, tal como o teclado, monitor de vídeo, e mouse (KVM) para entrada / saída humana para o dispositivo móvel.

A negociação de boot pode ser conduzida utilizando um protocolo de negociação.

Em uma modalidade, o protocolo de negociação inclui um nível de lógica executando um protocolo de nível físico bem-conhecido. O protocolo de negociação pode ser utilizado para comunicações de negociação tais como recursos de registro e suas capacidades, assegu- rando a sessão de negociação, enviando imagens de boot do dispositivo para o dock, e os 30 similares. Em uma modalidade, a negociação de boot entre o dispositivo móvel e o dock toma lugar entre o BIOS do dock e o OS do dispositivo móvel (adicionalmente discutido a- baixo em conjunto com a Figura 8).

Iniciando no bloco 302 do fluxograma 300, o dispositivo e o dock fazem uma cone- xão inicial. Por exemplo, o dispositivo e o dock podem ser conectados fisicamente por um fio, eles podem ser dados em proximidade física de uma outra para uma conexão sem fio estar disponível. No bloco 302, o dispositivo e o dock podem desempenhar alguma sincroni- zação para estabelecer a conexão inicial. Em uma modalidade, fazer a conexão inicial inclui estabelecer uma conexão segura entre o dispositivo móvel e o dock.

Procedendo ao bloco de decisão 304, o dispositivo questiona o dock para determi- nar se o dock suporta a negociação de boot como descrito acima aqui. Em uma modalidade, este questionamento é conduzido utilizando um protocolo de negociação entendido por am- 5 bos o dispositivo e o dock. Em uma modalidade, o dock BIOS conduz as negociações de boot com o OS do dispositivo móvel. Neste caminho, a negociação de boot pode ser condu- zida durante a reinicialização do dock sem necessidade de um OS executando no dock. As tarefas de negociação de boot do dock BIOS incluem a descoberta do dispositivo móvel co- nectado, estabelecendo comunicações (em alguns casos comunicações seguras), e regis- 10 trando as capacidades do dock.

É notado que o dispositivo e o dock não assumem suas funções quando conecta- dos. Em alguns sistemas de comunicação (por exemplo, USB), um dispositivo conectado pode ser assumido para sempre ser um dispositivo (por exemplo, um escravo) para outro dispositivo de computação. Similarmente, os dispositivos de computação, tal como compu- 15 tador laptop, pode assumir para ser um hospedeiro (isto é, um mestre) quando conectado a um dispositivo USB. Para suportar a negociação de boot, os componentes de BIOS e hard- ware de um dispositivo de computação permitem um dispositivo conectado para assumir o controle. Nas modalidades aqui, as comunicações de hardware (por exemplo, conjunto de chips) e BIOS dos dispositivos de computação não fazem nenhuma sugestão sobre sua fun- 20 ção (por exemplo, mestre ou escravo) quando conectando a outro dispositivo de computa- ção. Como descrito acima, as modalidades da invenção podem incluir medidas de seguran- ça para evitar que um dispositivo de má qualidade comprometa a segurança dos outros dis- positivos de computação.

Se a resposta para o bloco de decisão 304 for não, então a lógica procede para o 25 bloco 306. No bloco 306, o dock e o dispositivo irão interagir um com o outro utilizando hipó- teses pressupostas. Por exemplo, se o dispositivo for pressuposto como um dispositivo es- cravo, então o dispositivo irá tomar a função pressuposta de dispositivo escravo sem nego- ciação. O dock pode executar uma imagem de boot pressuposta se esta estiver armazena- da.

Se a resposta para o bloco de decisão for sim, então a lógica continua para o bloco

308. No bloco 308, o dispositivo e o dock podem autenticar um ao outro. Em modalidades alternativas, a autenticação pode ser apenas de uma maneira. Por exemplo, apenas o dis- positivo autentica o dock ou apenas o dock autentica o dispositivo. A autenticação pode ser implementada utilizando uma assinatura, certificado, ou os esquemas de autenticação bem- conhecidos.

Continuando ao bloco 310, o dispositivo e o dock desempenham descoberta de ca- pacidades. Em uma modalidade, o dispositivo questiona o dock para registrar seus recursos e as capacidades do recurso utilizando o protocolo de negociação como descrito acima. Ca- pacidades exemplares incluem capacidades de processamento (por exemplo, tipo de pro- cessador, velocidade de processador, etc.) e capacidades de memória (por exemplo, tama- nho de memória, velocidade de memória, etc.). As capacidades podem também incluir quaisquer dispositivos de armazenamento, seus tipos, capacidades, espaço de armazena- mento disponível, sistemas de arquivo, e os similares. As capacidades podem também inclu- ir o vídeo e/ou capacidades de áudio do dock. As capacidades podem também incluir cone- xões de comunicação e a largura de banda de quaisquer tais conexões.

Com referência à Figura 7, uma tabela de registro de capacidades 700 de acordo com uma modalidade da invenção é mostrada. Em uma modalidade, o dock BIOS gera a tabela 700 e envia a tabela 700 para o dispositivo móvel utilizando o protocolo de negocia- ção. O dispositivo móvel gera sua própria tabela de registro de capacidades para compara- ção à tabela recebida do dock.

A tabela 700 inclui colunas para componentes 702, atribuições 704 para os compo- nentes, e valores 706 para aquelas atribuições. Por exemplo, sob o processador, atribuições de velocidade do tempo, cache L2, e velocidade de barramento são registradas. Em uma modalidade, a informação na tabela 700 pode ser organizada em um ou mais esquemas para passar informação de recurso entre o dock e o dispositivo móvel. O(s) esquema(s) po- de(m) ser parte do protocolo de negociação utilizado pelo dock e pelo dispositivo móvel.

Após o bloco 310, a lógica procede ao bloco 312 para determinar se o dock é com- patível à imagem de boot armazenada no dispositivo utilizando as capacidades de registro do dock. Por exemplo, nas Figuras 1 e 2, a lógica determina se o dock 102 pode executar quaisquer das imagens de boot 241 a 243 armazenadas no dispositivo móvel 120. Se a res- posta ao bloco de decisão 312 for não, então a lógica procede ao bloco 314. Em uma moda- lidade, a imagem de boot compativelmente pode ser baseada na velocidade do processador do dock, tamanho de memória, capacidades de vídeo, e os similares.

No bloco 314, o dispositivo executa a imagem de boot de controle. Em uma modali- dade, o OS do dispositivo móvel, que já está executando, adota os recursos de hardware do dock. Por exemplo, se o dock tiver um dispositivo de armazenamento, tal como um HDD, então o HDD do dock é acessível pelo OS do dispositivo móvel. Em outro exemplo, o KVM de um Iaptop (isto é, dock) pode ser utilizado para interagir com um dispositivo móvel.

Se a resposta ao bloco de decisão 312 for sim, então a lógica procede ao bloco 316. No bloco 316, a lógica atualiza a política de boot armazenada no dispositivo móvel an- tes da aplicação da política de boot no bloco 318. Em uma modalidade, o dispositivo móvel contacta um sítio de atualização central, tal como Atualização Microsoft Windows®. O dis- positivo móvel pode utilizar sua própria conexão de comunicação ou uma conexão de co- municação no dock para checar atualizações. Continuando ao bloco 318, a lógica aplica política de boot. A política de boot deter- mina se inicializar o dock com uma ou mais imagens de boot compatíveis provenientes do dispositivo móvel está de acordo com a política. A política pode ser modificável por um usu- ário e/ou administrador de sistema. Em uma modalidade, a política é armazenada no dispo- sitivo. Em outra modalidade, a política armazenada no dock é passada ao dispositivo duran- te a negociação de boot. A política do dispositivo e do dock pode ser aplicada em combina- ção.

Em uma modalidade, as capacidades do dispositivo e do dock são comparadas pa- ra determinar se o dock ou o dispositivo móvel irá executar a imagem de boot de controle. Por exemplo, uma política pode indicar que o dispositivo de computação com o processador mais rápido deverá sempre assumir o controle. Outra política pode analisar uma faixa de capacidades (tal como velocidade do processador, tamanho de memória, capacidade de largura de banda) na determinação da máquina de controle. Por exemplo, a informação pro- veniente da tabela 700 para o dispositivo e o dock pode ser colocada em uma equação que atribui pontos aos vários componentes e seus valores de atribuição. Na equação, algumas atribuições dos componentes podem ser pesadas. O dispositivo de computação (dispositivo móvel ou dock) com a pontuação mais alta é determinado para ser o dispositivo de compu- tação para executar a imagem de boot de controle.

Em outra modalidade, a política pode incluir referência à última atividade de usuário para determinar se o dock ou o dispositivo móvel irá executar a imagem de boot de controle. Por exemplo, se o dock teve inicialização previamente a partir de uma imagem de boot no dispositivo, então o dock é inicializado novamente a partir daquela imagem de boot.

A política pode também incluir determinar qual imagem de boot o dock é para inicia- lizar de quando múltiplas imagens de boot compatíveis são armazenadas no dispositivo.

Em uma modalidade, a lógica determina qual imagem de boot irá prover o melhor desempenho. Por exemplo, a imagem de boot que irá prover o melhor desempenho basea- do na velocidade do processador do dock e capacidade de memória pode ser escolhida.

Em uma modalidade alternativa, todas as imagens compatíveis são exibidas a um usuário. O usuário pode escolher a imagem de boot desejada para o dock. Em uma modali- dade, a seleção de usuário da imagem de boot pode ocorrer no bloco de decisão 320 descri- to abaixo.

No bloco de decisão 320, a lógica determina se o usuário confirma a determinação de se o dispositivo ou o dock estão para executar a imagem de boot de controle. Em uma modalidade, uma interface de usuário é apresentada para capacitar um usuário para confir- mar a determinação feita no bloco 318. A interface de usuário pode ser exibida no dispositi- vo, no dock, ou em ambos. Em uma modalidade, se a política determinar que o dock é para executar uma imagem de boot a partir do dispositivo móvel, o dispositivo pode exibir o nome da imagem de boot que o inicializará com o dock. Em ainda outra modalidade, se múltiplas imagens de boot forem compatíveis com o dock, então as múltiplas imagens de boot compa- tíveis serão exibidas e o usuário pode selecionar a imagem de boot desejada para o dock.

No bloco 320, se o usuário não confirmar a inicialização do dock, então a lógica procede para o bloco 314. Se o usuário confirmar a inicialização do dock no bloco de deci- são 320, então a lógica continua para o bloco 322.

Em uma modalidade alternativa, a confirmação do usuário como descrita no bloco de decisão 320 não é utilizada. Nesta modalidade específica, o processo de negociação será escondido do usuário. Por exemplo, um usuário pode conectar um telefone móvel a um 10 computador pessoal e empurrar um botão de “negociação” no telefone móvel para iniciar as negociações. O processo de negociação é conduzido. O usuário pode então utilizar o KVM do computador pessoal para conduzir seu trabalho. Não é necessário para o usuário perce- ber qual dispositivo de computação está executando a imagem de boot de controle. A nego- ciação de boot pode ocorrer de forma transparente ao usuário.

De volta à Figura 4, no bloco 322, o dispositivo atualiza a imagem de boot antes de

enviar a imagem de boot para o dock para execução. Em uma modalidade, o dispositivo utiliza sua própria conexão de comunicação para se conectar a uma rede, tal como a inter- net, para checagem de quaisquer atualizações. Em outra modalidade, o dispositivo pode utilizar uma conexão de comunicação do dock para checar quaisquer atualizações para a imagem de boot.

Após o bloco 322, a lógica continua para o bloco 324 onde o dispositivo móvel en- via a imagem de boot para o dock. A seguir, no bloco 326, o dock inicializa a partir da ima- gem de boot. Uma vez que o dock é inicializado com a imagem de boot, o dispositivo é dis- ponível para o dock. Por exemplo, após um Iaptop (dock) inicializar a partir de uma imagem 25 de boot armazenada em um telefone móvel conectado (dispositivo), o Iaptop pode gerenciar recursos do telefone móvel. Por exemplo, um dispositivo de armazenamento do telefone móvel pode ser utilizado pelo dock. As mensagens de segurança podem ser utilizadas para acesso restrito para alguns dados armazenados no dispositivo, tal como na partição 230, pelo dock.

A seguir, no bloco 328, o OS do dispositivo móvel passa a ocioso. O OS do disposi-

tivo móvel pode despertar e reassumir o controle do dispositivo enquanto a conexão para o dock foi interrompida e/ou não pôde ser restabelecida após um limite específico. O limite pode incluir um número de tentativas de re-conexão ou uma quantidade predefinida de tem- po.

De volta à Figura 5, uma modalidade de um ambiente de Máquina Virtual (VM) é

mostrado. Na Figura 5, um dispositivo móvel, mostrado como telefone móvel 502, pode en- viar uma imagem de boot 503 para o dock 504. O dock 504 está executando um ambiente de VM. No dock 504, o hardware do dock 512 é gerenciado por um Gerenciador de Máquina Virtual (VMM) 510. O VMM 510 pode suportar uma ou mais VMs, tal como VM 506 e VM 508. A VM 506 executa o OS de acesso de visitante 505. Em geral, as VMs podem ser cria- das e desfeitas como desejado em um ambiente de VM. Também, cada VM opera indepen- 5 dentemente do modo que um erro de sistema em uma VM, tal como uma quebra do sistema operacional, não afeta as outras VMs.

De acordo com modalidades aqui, uma negociação pode ocorrer entre o telefone móvel 502 e o dock 504 enquanto o dock 504 estiver executando um ambiente de VM. O telefone móvel 502 pode enviar imagem de boot 503 para o dock 504 para execução em VM 508. A execução da imagem de boot 503 é mostrada como OS de acesso de visitante 507.

Em um exemplo, o uso de um ambiente de VM permite o uso de uma imagem de boot proveniente do telefone móvel 502 sem ter que inicializar todo o dock 504. A VM 508 pode ser criada no dock 504 para execução da imagem de boot 503. Adicionalmente, a VM 508 pode ser derrubada, porém a VM 506 pode se refazer, quando o usuário tiver terminado com o OS de acesso de visitante 507.

De volta à Figura 6, uma modalidade de um telefone móvel 602 (dispositivo) e um Iaptop 604 (dock) desempenhando negociação de boot é mostrada. Em uma modalidade, a negociação de boot é conduzida utilizando um protocolo de negociação. Em 610, um telefo- ne móvel 602 pergunta ao Iaptop 604 se é capaz de negociação. O Iaptop 604 fornece uma 20 resposta positiva 611 ao telefone móvel 602. Em 612, o telefone móvel 602 e o Iaptop 604 autenticam um ao outro.

Em 613, o telefone móvel 602 questiona o Iaptop 604 para suas capacidades. Em 614, o Iaptop 604 responde registrando suas capacidades. O Iaptop 604 pode registrar suas capacidades utilizando uma modalidade da tabela 700.

Em 615, o telefone móvel 602 determina se a imagem de boot executada no telefo-

ne móvel 602 ou uma imagem de boot executada no Iaptop 604 irá assumir o controle. Na troca 616, o dispositivo móvel 602 envia uma imagem de boot (mostrada em 617) para o Iaptop 604. Em uma modalidade, o dispositivo móvel 602 checa para atualizações à imagem de boot antes de enviar a imagem de boot ao Iaptop 604. Em 618, o Iaptop 604 executa a 30 imagem de boot a partir do telefone móvel 602. Em uma modalidade, a imagem de boot é executada em um ambiente de VM no Iaptop 604.

Em 619, o OS do telefone móvel 602 passa a um estado ocioso após enviar a ima- gem de boot para o Iaptop 604. Desse modo, quando a conexão entre o telefone móvel 602 e o Iaptop 604 for cortada, o telefone móvel 602 pode continuar operando utilizando seu próprio OS sem ter que reinicializar o OS do telefone móvel.

Alternativamente, na troca 620, o OS do telefone móvel 602 gerencia os recursos do Iaptop 604 (mostrado em 612). O telefone móvel 602 pode comutar seu estado de soft- ware para acessar equipamentos periféricos no Iaptop 604 sem reinicialização do OS do telefone móvel. Por exemplo, o telefone móvel 602 pode utilizar o KVM do Iaptop 604 (mos- trado em 622). Quando a conexão entre o telefone móvel 602 finaliza, então o telefone mó- vel 602 pode comutar de volta utilizando seus próprios dispositivos de entrada / saída. Uma reinicialização do telefone móvel 602 é desnecessária.

De volta à Figura 8, cenários de convenção de acordo com as modalidades da in- venção serão descritos. Será apreciado que as modalidades da invenção não estão limita- das aos cenários descritos abaixo. A Figura 8 mostra um telefone móvel 802 (isto é, disposi- tivo móvel) conectado a um Computador Pessoal (PC) (isto é, dock). A Figura 8 mostra o 10 processo de negociação de boot tomando lugar entre o OS do telefone móvel 804 e o PC BIOS 812.

Em um cenário, as modalidades da invenção podem ser utilizadas em um ambiente de computação público. Em alguns casos, o ambiente de computação público pode ser ge- renciado por uma companhia de telefone (“Telco”) que provê serviços para ambos o telefone móvel 802 e o PC 810. O PC 810 pode ser um computador público em um quiosque de shopping, café internet, ou os semelhantes.

Por exemplo, um usuário com telefone móvel 802 em tempo de execução de OS se aproxima do PC 810. O PC 810 está atualmente desligado. O usuário coloca o telefone mó- vel 802 dentro da proximidade do PC 810 para estabelecer uma conexão sem fio ou conecta 20 o telefone móvel 802 e o PC 810 com um cabo para uma conexão com fio. O usuário então liga no PC 810. O processo de negociação de boot começa com o OS do dispositivo móvel 804 se comunicando com PC BIOS 812. Após a negociação de boot, o usuário pode então utilizar o KVM do PC 810 para interagir com o OS do dispositivo móvel 804 ou o usuário pode utilizar o KVM do PC 810 para interagir com uma imagem de boot enviada a partir do 25 telefone móvel 802 inicializado no PC 810. Nesse caso, o telefone móvel 802 pode ser utili- zado para armazenamento pelo usuário. Desse modo, o usuário pode facilmente fazer seu trabalho com eles quando eles deixam o computador público (isto é, PC 810).

Em modalidades alternativas, se o PC 810 estiver em um estado ocioso ou em tempo de execução de OS quando o usuário começar o processo de negociação, o PC pode 30 ter que ser reinicializado para executar uma imagem de boot a partir do telefone móvel 802. Em ainda outra modalidade, o PC 810 pode permanecer no tempo de execução de OS e executar uma imagem de boot recebida a partir do telefone móvel 802 em um ambiente de máquina virtual.

No cenário de convenção Telco, o usuário pode ter uma conta de minutos que pode ser utilizada com o telefone móvel 802 e o PC 810. Também, uma vez que o telefone móvel 802 e o PC 810 são parte da mesma rede Telco, as atualizações para política de boot po- dem ser empurradas para o telefone móvel 802 e/ou PC 810. Atualizações para imagens de boot no telefone móvel 802 podem ser empurradas para o telefone móvel 802 através da rede Telco.

Em outro cenário, modalidades da invenção podem ser utilizadas em uma rede ge- renciada da organização, tal como uma rede de empresa. O telefone móvel 802 e o PC 810 são parte da rede de empresa. Novamente, um usuário conecta o telefone móvel 802 ao PC 810 e começa o processo de negociação de boot. O usuário pode então utilizar o KVM do PC 810 para interagir com a imagem de boot de controle no telefone móvel 802 ou no PC 810.

O cenário da rede de empresa pode ser utilizado de várias formas. Os empregados podem ser emitidos a um dispositivo móvel, tal como telefone móvel 802. O empregado po- de então realizar várias imagens de boot com eles que podem ser utilizados com vários PCs na organização. Também, o usuário sempre tem acesso a seus dados uma vez que os da- dos do usuário estejam centralizados em seu dispositivo móvel ao invés de estarem espa- lhados através de várias máquinas (por exemplo, dispositivo móvel corporativo e vários desktops corporativos). Adicionalmente, as atualizações de política de boot e as atualiza- ções de imagens de boot podem ser facilmente empurradas para o dispositivo móvel 802.

A Figura 9 mostra um exemplo de um dispositivo de computação 900 para imple- mentação de uma ou mais modalidades da invenção. As modalidades do dispositivo de computação 900 podem ser utilizadas como dock 102 e/ou dispositivo móvel 120. Em uma configuração, o dispositivo de computação 900 inclui pelo menos uma unidade de proces- samento 902 e uma memória 904. Dependendo da configuração e tipo exatos do dispositivo de computação, a memória 904 pode ser volátil (tal como RAM), não-volátil (tal como ROM, memória flash, etc.) ou algumas combinações das duas. Esta configuração é ilustrada na Figura 9 linha tracejada 906.

Em outras modalidades, o dispositivo 900 pode incluir características adicionais e/ou funcionalidade. Por exemplo, o dispositivo 900 pode também incluir armazenamento adicional (por exemplo, removível e/ou não-removível) incluindo, mas não limitado a, arma- zenamento magnético, armazenamento ótico, e os similares. Tal armazenamento adicional é ilustrado na Figura 9 através do armazenamento 908. Em uma modalidade, as instruções legíveis por computador para implementar as modalidades da invenção podem estar no ar- mazenamento 908. O armazenamento 908 pode também armazenar outras instruções legí- veis por computador para implementar um sistema operacional, um programa de aplicação, e os similares.

O termo “mídia legível por computador” como utilizado aqui inclui mídia de armaze- namento de computador. A mídia de armazenamento de computador inclui mída volátil e não-volátil, removível e não-removível implementada em qualquer método ou tecnologia para armazenamento de informação tal como instruções legíveis por computador ou outros dados. A memória 904 e o armazenamento 908 são exemplos de mídia de armazenamento de computador. A mídia de armazenamento de computador inclui, mas não estão limitada a, RAM, ROM, EEPROM, memória flash ou outra tecnologia de memória, CD-ROM, Discos Versáteis Digitais (DVDs) ou outros armazenamentos óticos, cassetes magnéticos, fita mag- 5 nética, armazenamento de discos magnéticos ou outros dispositivos de armazenamento magnético, ou qualquer outro meio que possa ser utilizado para armazenar a informação desejada e que possa ser acessada pelo dispositivo 900. Qualquer tal mídia de armazena- mento de computador pode ser parte do dispositivo 900.

O dispositivo 900 pode também incluir conexão(ões) de comunicação 912 que per- 10 mite(m) o dispositivo 900 se comunicar com outros dispositivos. A(s) conexão(ões) de co- municação 912 pode(m) incluir, mas não estar limitada a, um modem, um Cartão de Interfa- ce de Rede (NIC), uma conexão USB, uma porta infravermelha, ou outras interfaces para conectar o dispositivo de computação 900 a outros dispositivos de computação. A(s) cone- xão(ões) de comunicação 912 pode(m) incluir uma conexão com fio ou uma conexão sem 15 fio. A(s) conexão(ões) 912 pode(m) transmitir e/ou receber mídia de comunicação.

O termo “mída legível por computador” pode incluir mídia de comunicação. Mídia de comunicação tipicamente engloba instruções legíveis por computador ou outros dados em um “sinal de dados modulados” tal como uma onda de veículo ou outros mecanismos de transporte e inclui qualquer informação de mídia de entrega. O termo “sinal de dados modu- 20 lados” significa um sinal que possui um ou mais de seu conjunto de características ou troca- do de tal maneira como para codificar a informação no sinal. Por meio de exemplo, e não limitação, mídia de comunicação tal como uma rede com fio ou conexão direta com fio, e mídia sem fio tal como, acústica, radiofreqüência, infravermelho, Comunicação em Campo Próximo (NFC), e outra mídia sem fio.

O dispositivo 900 pode incluir dispositivo(s) de entrada 914 tal como teclado, mou-

se, caneta, dispositivo de entrada de voz, dispositivo de entrada de toque, câmeras infra- vermelhas, dispositivos de entrada de vídeo, e/ou qualquer outro dispositivo de entrada. O(s) dispositivo(s) de saída 916 tais como um ou mais displays, auto-falantes, impressoras, e/ou qualquer outro dispositivo de saída pode se incluído no dispositivo 900. O(s) dispositi- 30 vo(s) de entrada 914 e dispositivo(s) de saída(s) 916 podem ser conectados ao dispositivo 900 via uma conexão com fio, conexão sem fio, ou qualquer combinação dos mesmos. Em uma modalidade, um dispositivo de entrada ou um dispositivo de saída proveniente de outro dispositivo de computação pode ser utilizado como dispositivo(s) de entrada 914 ou disposi- tivo^) de saída 916 para dispositivo de computação 900.

Os componentes do dispositivo de computação 900 podem ser conectados por vá-

rias interconexões, tal como um barramento. Tais interconexões podem incluir uma interco- nexão de Componente de equipamento periférico (PCI), tal como PCI expresso, um Barra- mento de Série Universal (USB), firewire (IEEE 1394), uma estrutura de barramento ótico, e os similares. Em outra modalidade, componentes do dispositivo de computação 900 podem ser interconectados por uma rede. Por exemplo, a memória 904 pode ser compreendia de múltiplas unidades de memória física localizadas em diferentes localizações físicas interco- nectas por uma rede.

Aqueles versados na técnica irão perceber que os dispositivos de armazenamento utilizados para armazenar instruções legíveis por computador podem ser distribuídos atra- vés de uma rede. Por exemplo, um dispositivo de computação 930 acessível pela rede 920 pode armazenar instruções legíveis por computador para implementar uma ou mais modali- 10 dades da invenção. O dispositivo de computação 900 pode acessar o dispositivo de compu- tação 930 e baixar uma parte das instruções legíveis por computador para execução. Alter- nativamente, o dispositivo de computação 900 pode baixar pedaços das instruções legíveis por computador, como necessário, ou algumas instruções podem ser executadas no disposi- tivo de computação 900 e algumas no dispositivo de computação 930. Aqueles versados na 15 técnica irão perceber que todas ou uma parte das instruções legíveis por computador pode ser realizada por um circuito dedicado, tal como Processador de Sinal Digital (DSP), arranjo de lógica programável, e os similares.

Várias operações das modalidades da presente invenção estão descritas aqui. Em uma modalidade, uma ou mais das operações descritas pode constituir as instruções legí- 20 veis por computador armazenadas em uma ou mais mídias legíveis por computador, a qual se executada por um dispositivo de computação, irá fazer com que o dispositivo de compu- tação desempenhe as operações descritas. A ordem na qual algumas ou todas as opera- ções estão descritas não devem ser construídas como para implicar que estas operações sejam necessariamente dependentes de ordem. Ordem alternativa será apreciada por um 25 versado na técnica possuindo o benefício desta descrição. Adicionalmente, será entendido que nem todas as operações são necessariamente apresentadas em cada modalidade da invenção.

A descrição acima das modalidades da invenção, incluindo a que está descrita no resumo, não pretende ser exaustiva ou limitar as modalidades para precisar as formas des- 30 critas. Enquanto as modalidades e exemplos específicos da invenção estão descritos aqui para propósito ilustrativo, várias modificações equivalentes são possíveis, como aqueles versados na técnica relevante irão reconhecer na Iuz da descrição detalhada acima. Os ter- mos utilizados nas reivindicações a seguir não devem ser construídos para limitar a inven- ção às modalidades específicas descritas no relatório. De preferência, as reivindicações a 35 seguir são para ser construídas de acordo com doutrinas estabelecidas da interpretação de reivindicações.

Claims

1. Método, CARACTERIZADO pelo fato de que compreende: descobrir, através de um primeiro dispositivo, as capacidades de um segundo dis- positivo (310); determinar, através do primeiro dispositivo, qual do primeiro dispositivo e do segun- do dispositivo é para executar uma imagem de boot de controle baseada em parte nas ca- pacidades do primeiro dispositivo e no segundo dispositivo (312, 316, 318); executar uma primeira imagem de boot através do primeiro dispositivo quando o primeiro dispositivo for determinado para executar a imagem de boot de controle, o segundo dispositivo para ser um recurso para a primeira imagem de boot (314); e enviar, através do primeiro dispositivo, uma segunda imagem de boot armazenada no primeiro dispositivo para o segundo dispositivo quando o segundo dispositivo for deter- minado para executar a imagem de boot de controle, em que o primeiro dispositivo é um recurso para a segunda imagem de boot (324),

2. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que compreende adicionalmente: determinar, através do primeiro dispositivo, se a segunda imagem de boot é compa- tível com o segundo dispositivo.

3. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que compreende adicionalmente: determinar, através do primeiro dispositivo, se a execução da segunda imagem de boot no segundo dispositivo está de acordo com a política de boot armazenada no primeiro dispositivo.

4. Método, de acordo com a reivindicação 3, CARACTERIZADO pelo fato de que compreende adicionalmente: atualizar a política de boot, através do primeiro dispositivo, contactando um sítio central antes de determinar se executar a segunda imagem de boot no segundo dispositivo está de acordo com a política de boot armazenada no primeiro dispositivo.

5. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que compreende adicionalmente: atualizar, através do primeiro dispositivo, a segunda imagem de boot antes de envi- ar a segunda imagem de boot ao segundo dispositivo.

6. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que compreende adicionalmente: entrar em um estado ocioso através de um sistema operacional executando no pri- meiro dispositivo após enviar a segunda imagem de boot para o segundo dispositivo; e despertar do estado ocioso quando uma conexão entre o primeiro dispositivo e o segundo dispositivo for difícil.

7. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que compreende adicionalmente: estabelecer uma conexão entre o primeiro dispositivo e o segundo dispositivo, em 5 que o primeiro dispositivo está em tempo de execução do sistema operacional e o segundo dispositivo está em reinicialização.

8. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que descobrir as capacidades do segundo dispositivo inclui receber, no primeiro dispositivo, ca- pacidades registrando dados a partir do segundo dispositivo em resposta às capacidades questionadas a partir do primeiro dispositivo.

9. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que compreende adicionalmente: autenticar o segundo dispositivo através do primeiro dispositivo.

10. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que determinar qual dos primeiro dispositivo e segundo dispositivo é para executar uma imagem de boot de controle inclui receber, no primeiro dispositivo, confirmação da determinação a partir de um usuário

11. Método, CARACTERIZADO pelo fato de que compreende: fazer uma conexão entre um dispositivo móvel e um dock, em que o dispositivo mó- vel está executando uma primeira imagem de boot e o dock está em reinicialização (302); determinar qual dos dispositivos móveis e o dock executa uma imagem de boot de controle baseado pelo menos em parte nas capacidades do dispositivo móvel e do dock (310,312,316,318); quando o dock executar a imagem de boot de controle, enviar uma segunda ima- gem de boot a partir do dispositivo móvel para o dock e executar a segunda imagem de boot no dock, em que a segunda imagem de boot inclui a imagem de boot de controle (324); e quando o dispositivo móvel executar a imagem de boot de controle, executando a primeira imagem de boot no dispositivo móvel, em que a primeira imagem de boot inclui a imagem de boot de controle (314).

12. Método, de acordo com a reivindicação 11, CARACTERIZADO pelo fato de que determinar qual do dispositivo móvel e do dock executa uma imagem de boot de controle inclui determinar se o dock é compatível com uma ou mais imagens de boot armazenadas no dispositivo móvel.

13. Método, de acordo com a reivindicação 11, CARACTERIZADO pelo fato de que a segunda imagem de boot é executada em um ambiente de máquina virtual do dock.

14. Método, de acordo com a reivindicação 11, CARACTERIZADO pelo fato de que compreende adicionalmente: atualizar a segunda imagem de boot através do dispositivo móvel antes de enviar a segunda imagem de boot para o dock para execução no dock.

15. Método, de acordo com a reivindicação 11, CARACTERIZADO pelo fato de que quando o dock executar a imagem de boot de controle compreende adicionalmente: entrar em um estado ocioso através da primeira imagem de boot executando no dispositivo móvel.

16. Método, de acordo com a reivindicação 11, CARACTERIZADO pelo fato de que compreende adicionalmente: receber, no dispositivo móvel, capacidades de registrar dados a partir do dock em resposta à um questionamento de capacidades do dispositivo móvel.

17. Sistema, CARACTERIZADO pelo fato de que compreende: um primeiro dispositivo de computação conectado a um segundo dispositivo de computação, em que o primeiro dispositivo de computação possuindo instruções legíveis por computador armazenadas que quando executadas pelo primeiro dispositivo de computação desempenha operações compreendendo: descobrir as capacidades do segundo dispositivo de computação (310); determinar qual do primeiro dispositivo de computação e do segundo dispositivo de computação é para executar uma imagem de boot de controle baseada pelo menos em par- te nas capacidades do primeiro dispositivo de computação e no segundo dispositivo de computação (312, 316, 318); executar uma primeira imagem de boot através do primeiro dispositivo de computa- ção quando o primeiro dispositivo de computação for determinado para executar a imagem de boot de controle, o segundo dispositivo de computação para ser um recurso para a pri- meira imagem de boot (314); e enviar a segunda imagem de boot armazenada no primeiro dispositivo de computa- ção para o segundo dispositivo de computação quando o segundo dispositivo de computa- ção for determinado para executar a imagem de boot de controle, em que o primeiro disposi- tivo de computação para ser um recurso para a segunda imagem de boot (324);

18. Sistema, de acordo com a reivindicação 17, CARACTERIZADO pelo fato de que determinar qual do primeiro dispositivo de computação e do segundo dispositivo de computação é para executar uma imagem de boot de controle inclui determinar se o segun- do dispositivo de computação é compatível com uma ou mais imagens de boot armazena- das no primeiro dispositivo de computação.

19. Sistema, de acordo com a reivindicação 17, CARACTERIZADO pelo fato de que determinar qual dos primeiro dispositivo de computação e do segundo dispositivo de computação é para executar uma imagem de boot de controle inclui aplicar a política arma- zenada no dispositivo de computação.

20. Sistema, de acordo com a reivindicação 17, CARACTERIZADO pelo fato de que determinar qual do primeiro dispositivo de computação e do segundo dispositivo de computação é para executar uma imagem de boot de controle inclui receber confirmação da determinação de um usuário.