BRPI0604937B1

BRPI0604937B1 - Monofone de telefone, base, e método associado para a atualização do software do monofone

Info

Publication number: BRPI0604937B1
Application number: BRPI0604937-0A
Authority: BR
Inventors: Olivier Amberny; Herve Artus; Matthieu Dumont
Original assignee: Inventel
Priority date: 2005-12-05
Filing date: 2006-11-24
Publication date: 2019-02-26
Also published as: BRPI0604937A; CN1980440A; JP2007159120A; US9191479B2; EP1793573A2; EP1793573A3; FR2894420A1; EP1793573B1; CN1980440B; US20070169105A1

Abstract

monofone de telefone, base, e método associado para a atualização do software do monofone. a presente invenção refere-se a um monofone de telefone, uma base, e a um método associado para a atualização do software do monofone. a base de comunicação (1.11) compreende uma interface de rádio (1.14) a fim de se comunicar com um dispositivo de comunicação (1.1) que opera por meio de um aplicativo de software, um circuito carregador (1.12) e um meio (1.22) para detectar uma versão nova do software. a base de comunicação compreende um meio (1.23) para notificar o dispositivo, via o meio de rádio, sobre a disponibilidade da versão nova de software, e um meio para transmitir a versão nova de software para o dispositivo quando o circuito carregador (1.12) é conectado à bateria (1.21) crie carrega o circuito (1.2) do dispositivo. (figura 1).

Description

MONOFONE DE TELEFONE, BASE, E MÉTODO ASSOCIADO PARA A ATUALIZAÇÃO DO SOFTWARE DO MONOFONE

A presente invenção refere-se a um monofone de telefone, uma base, e a um método associado para a atualização do software do monofone.

A presente invenção se refere a um monofone de telefone que opera com um aplicativo de software e uma base que permite a atualização do software quando o monofone está carregando na base. Se esta base for conectada a uma rede, o software do monofone de telefone poderá receber a atualização do software via a rede.

A presente invenção também diz respeito a um método para a execução do dito carregamento do novo software do monofone por meio da base.

Para este fim, o objeto da presente invenção é uma base de comunicação compreendendo uma interface de rádio para se comunicar com um dispositivo de comunicação que opera por meio de um aplicativo de software, um circuito carregador e um meio de detecção de uma versão nova do software.

De acordo com a presente invenção, a base compreende um meio para notificar o dispositivo, via o meio de rádio, sobre a disponibilidade de uma versão nova de software e um meio para a transmissão da versão nova de software para o dispositivo quando o circuito carregador se encontra conectado a um circuito de carga de bateria do dispositivo.

De uma maneira surpreendente, a base não transmite automaticamente a versão nova do software por meio de um enlace de rádio. Contudo, a base notifica ao monofone de que > · ·

I» ··· • 9 4 •

4

4 » 9

9 •

• 4 u

J *

> β *

• a ♦ »

4

9 • · •9

4♦

4;

• •4 disponível corrente do monosoftwa* » • * * · »» *

uma versão nova de software encontra-se fone permanece operacional com a versão re; a versão nova de software só é transferida quando o monofone é conectado à base via o circuito de carga de batería.

De acordo com uma modalidade, o meio para a transmissão da versão nova de software para o dispositivo utiliza o circuito carregador.

Os mecanismos implementados utilizam contatos de carga entre a base e o monofone, não havendo, portanto, ne10 nhum conector adicional. Não se faz necessário solicitar ao usuário que execute nenhuma manipulação em particular. A atualização pode ser feita de uma maneira totalmente transparente ao usuário. Os mecanismos implementados não requerem que nenhuma memória extra seja adicionada ao monofone. A 15 vantagem de se operar por meio de um circuito de carga é que o mesmo não necessita de uma memória extra para armazenar temporariamente o novo aplicativo. Além disso, o espaço ocupado pelo programa de transferência é também muito reduzido, não havendo necessidade de se suportar um protocolo de rádio 20 especificamente para transferir a versão nova do software.

Em uma modalidade, a base de comunicação compreende um meio de verificação da compatibilidade do dispositivo com o novo software.

Com efeito, não se pressupõe que todos os monofo25 nes conectados à base sejam compatíveis com as mesmas versões de software, e que a versão nova possa se referir apenas a alguns monofones.

De acordo com uma modalidade, a comunicação por ·· «

·· • · • *

Μ · • · • · • · * · • ' · • · • ♦ ··' ·· * · ··· » t »

• W • · • « * · ··· • ·

meio de um circuito de carga é feita por meio do protocolo de comunicação de Transmissor Receptor Assíncrono Universal.

De acordo com uma modalidade, a base de comunicação é uma base para um telefone sem fio doméstico.

De acordo com uma modalidade, o enlace via rádio g

atende ao padrão de comunicação sem fio aperfeiçoado digital.

De acordo com uma modalidade, a base de comunicação compreende uma interface com uma rede de comunicação para detectar e transferir a versão nova do software.

O objeto da presente invenção é também um dispositivo de comunicação que opera por meio de um aplicativo de software, que compreende uma interface de rádio para se comunicar com uma base, um circuito carregador, e uma interface com o usuário.

O software não é transferido automaticamente via um enlace sem fio. Por outro lado, o monofone é notificado da disponibilidade da versão nova. 0 usuário poderá também saber se a versão nova se encontra disponível via a interface com o usuário do monofone. O usuário não precisa verifi20 car se uma versão nova se encontra disponível; esta verificação ocorre automaticamente por meio da base.

De acordo com uma modalidade, o dispositivo compreende um meio para o recebimento da versão nova do software quando o circuito de carga é conectado ao circuito carre25 gador da base.

De acordo com uma modalidade, o meio para receber a versão nova de software usa o circuito carregador.

De acordo com uma modalidade, o dispositivo é um

4 4	4 4 4	4	4 4
4 4	4	4 ·	4
_Λ ♦ ·	4	4 4	4 4
4 ··	4	4 4	4 4
4	4	4 4	4 4
4	4 · ·	4	4

4	4	4	4 4*	4 4·
4	4	4	4 4	4	4
4	4	4 4	4 4	4	4
4	4	4 4 4	4 4	4	4
4	4	4	4	4 4	4
*	4	4 ·	4	•

monofone de telefone.

obj eto da presente invenção é também um método em um monofone de telefone que opera com um aplicativo de software de modo a transferir uma versão nova do software, o dito monofone compreendendo uma interface de rádio para comunicação com uma base, um circuito de carga e uma interface com o usuário. 0 método compreende a etapa de receber informações sobre a disponibilidade da versão nova do software a partir da base.

De acordo com a presente invenção, o método compreende uma etapa de indicação na interface com o usuário do monofone quando à disponibilidade do novo software.

De acordo com uma modalidade, o método compreende uma etapa para a transferência da versão nova do software 15 quando o circuito de carga do monofone é conectado ao circuito carregador da base.

O objeto da presente invenção é ainda um método em uma base que se comunica com um monofone de telefone que opera com um aplicativo de software de modo a transferir uma 20 versão nova do software. A base compreende uma interface de rádio para se comunicar com o monofone, um circuito carregador, uma interface com uma rede de comunicação, e um meio para detectar uma versão nova do software. 0 método compreende as etapas de detectar uma versão nova de software, ve25 rificar se a versão nova de software é suportada pelo monofone, e informar ao monofone sobre a disponibilidade da versão nova de software por meio da base.

De acordo com a presente invenção, quando o cir• ··· · ·* · · · • · ··· ··· · « • · · · ·· ······ • · ········· ·· * ······ · « ··· · · · · ·· cuito de carga do monofone é conectado ao circuito carregador da base, o método compreende as etapas de verificar se o software do monofone deve ser atualizado, e transferir a versão nova da base para o monofone.

De acordo com uma modalidade, o método compreende a etapa de transferir a versão nova do software quando o circuito de carga do monofone é conectado ao circuito carregador da base.

De acordo com uma modalidade, a etapa de transfβίο rir ocorre entre um servidor localizado na rede e o monofone.

A presente invenção será melhor entendida e ilustrada por meio das modalidades e implementações a seguir, de forma alguma limitantes, com referência às figuras anexadas ao presente documento, nas quais:

A Figura 1 é um diagrama em blocos de um monofone e uma base de acordo com a modalidade.

A Figura 2 é um diagrama funcional do monofone e da base.

A Figura 3 é um diagrama representando as trocas entre a base e o monofone via o enlace de rádio.

A Figura 4 especifica as etapas de atualização do software.

A Figura 5 mostra o circuito carregador da base.

A Figura 6 mostra o circuito de carga do monofone.

Na Figura 1, os módulos mostrados não as unidades funcionais que podem ou não corresponder a unidades fisicamente distinguíveis. Por exemplo, estes módulos ou alguns dos mesmos podem ser agrupados entre si em um único compo • «·· ··· · · • ···· *····· • ········· ·· • ······ _t » ··· · · · ··· nente, ou constituem funções do mesmo software. Em contrapartida, alguns módulos podem possivelmente ser compostos de entidades físicas separadas. As mesmas referências designam elementos idênticos ou similares nas diferentes figuras.

A Figura 1 mostra um monofone 1.1 e uma base 1.11 de acordo com a modalidade.

monofone 1.1 compreende um processador 1.3, tambem referido como CPU, que controla uma memória 1.5, e uma memória 1.10, uma interface de rádio 1.4 e um circuito de 10 carga 1.2 conectado por meio de um barramento interno de comunicação 1.8. A memória 1.5 compreende um aplicativo de software 1.6. A memória 1.10 chamada doravante de memória boot pode ser, por exemplo, uma memória flash. A mesma compreende um software de partida 1.7. O software de partida é 15 executado automaticamente no processador quando o monofone é iniciado. No modo operacional do monofone, o software de partida verifica se o aplicativo de software se encontra integral. Em seguida, este software é carregado para o processador de modo a fazer com que o monofone opere com todas as 20 suas funcionalidades em seu modo normal, as funcionalidades sendo, entre outras coisas, o protocolo e o aplicativo DECT, a interface com o usuário, e os serviços telefônicos.

monofone compreende ainda uma interface com o usuário 1.9. Na modalidade, esta interface consiste de uma 25 tela e um teclado. O monofone compreende ainda uma bateria 1.21 que é recarregada a partir da base via o circuito de carga 1.2. A bateria provê a energia necessária para a correta operação do monofone.

A base 1.11 compreende um processador 1.13, também chamado CPU, uma memória 1.15, uma interface de rádio .14, um circuito carregador 1.12, um modem 1.16, e uma interface de rede 1.17 conectada por meio de um barramento de comunicação interno 1.18.

A memória 1.15 compreende um módulo de identificação para o monofone e para a versão do software 1.21 suportado pelo monofone, um módulo de detecção para uma versão nova de software disponível 1.22, e um módulo para a atualização do software do monofone 1.23, o módulo de atualização sendo ainda designado a notificar o monofone sobre a disponibilidade da versão nova do software.

A interface de rede permite que a base seja conectada a uma rede do tipo internet (protocolo TCP/IP) via um enlace do tipo DSL. A mesma pode também enlaçar a base a uma rede de telefone de modo a permitir a implementação de aplicativos de telefone.

Na modalidade, a interface de rádio é compatível com o padrão DECT. O monofone é um telefone DECT.

De acordo com outras modalidades, a interface de rádio pode ser compatível com um outro tipo de rede local sem fio, compatível com o Bluetooth ou com o padrão Wi-Fi, por exemplo.

Na modalidade, o circuito de carga é usado como um enlace de comunicação entre a base e o monofone quando os mesmos são conectados pelo circuito de carga. A interface física do circuito de carga é constituída de 2 contatos de carga, presentes, de um lado, na base, e de um outro lado,

• 9	9 9 9	9	9 9	9	9	•	• *4	9 9 9
• ·	9	9 9	•	9 9	9	9 9	•	4
9 9	•	• 9	9 9	• 9	9 9	9 9	9	•
9 9	9	9 9	9 9	9 4	9 9 9	9 9	9	9
	9	9 9	9 9	9 9	•	9	9 4	4
	9 9 9	9	9	9	4	9 9	9	4

no monofone, indicado pelos

Acima desta camada física, o sinais ' + ' e ' - ' na Figura 1.

Transmissor Receptor Assíncrono

Universal, conhecido como UART, é implementado um protocolo de corrente alternada bidirecional, também chamado meio du5 plex. 0 fluxo sobre este enlace pode atingir ou exceder 115 kbps. A camada física principal é descrita em mais detalhes adiante nesta descrição.

protocolo usado acima do transmissor UART a fim de implementar a atualização do software no monofone garante a integridade do software mesmo no caso de um erro na manipulação e não requer que uma memória extra sej a adicionada ao monofone. O software que implementa este protocolo e o controle da interface física fica fisicamente armazenado na memória boot. Esta memória boot é muito pequena em relação à 15 memória que contém o aplicativo de software.

A Figura 2 mostra a base 1.11 e o monofone 1.1. A base é conectada à rede 2.1 via a interface de rede 1.17. Isto oferece acesso ao servidor 2.2 que inclui as novas versões de software. Na modalidade, a base consulta regularmen20 te o servidor de modo a detectar as novas versões de software disponíveis. Em uma outra modalidade, o servidor informa à base quando uma versão nova de software se encontra disponível .

A Figura 3 mostra as trocas entre a base e o mono2 5 fone via o enlace de rádio quando a base recebe informações sobre a disponibilidade de uma versão nova do software, ou firmware, usada pelo monofone. Nestas trocas, o monofone se encontra em seu modo operacional normal.

•·· ···

A versão nova do software não é transferida por padrão pela base. A base consulta um servidor localizado na rede de internet a fim de determinar as novas versões de software disponíveis. Quando uma versão nova de software se encontra disponível 3.1, a base consulta os monofones 3.2 a fim de determinar se alguns dos monofones foram afetados pela versão nova, sabendo que estes monofones podem ser de modelos diferentes e, portanto, suportam versões que diferem entre si. A base arrasta uma lista dos monofones em questão

3.3, em seguida alerta os monofones em questão 3.4. O alerta nos monofones é um balão de fala que aparece na tela em repouso, a qual exibe a fala Atualização disponível. Instalar agora?. A base carrega o novo software depois da aceitação por parte dos monofones.

Finalmente, a base tomará a decisão de atualizar os monofones 3.5. Ou seja, a atualização acontece quando os monofones são conectados à base.

Quando a base toma conhecimento de que uma versão nova do software se encontra disponível, a mesma não trans20 fere esta versão automaticamente. A base antes se certificará se a versão nova é de interesse dos monofones. Em uma outra modalidade, a base transfere a versão nova do software antes de verificar se os monofones foram afetados.

Durante a verificação dos monofones afetados pela versão nova do software, a base solicita informação dos monofones no sentido de estabelecer a compatibilidade com a versão nova do software. Para cada monofone, a base verifica o identificador do monofone e a versão do software suporta-

	• · · · · • * ·	• ♦ *	• ♦ •	♦ ·	• •	• • ·	•·· ··· • ·
10	• · ·	• · • ·	• ·	• · • ·	• · • · ·	• · ♦ ♦	• · • ·
	• ·	• ·	• ·	• ·	•	♦	♦ · ·
	• ♦ ♦ ·	•	•	•	•	• ·	• ·

do. Na modalidade, o identificador do monofone corresponde ao que é definido no padrão DECT, este vindo a ser a Identidade do Equipamento Pessoal Internacional, representado pela sigla IPEI.

A Figura 4 mostra as etapas de atualização do software, quando a decisão é tomada pela base no sentido de continuar com a atualização.

A cinemática da atualização ocorre como se segue:

O monofone se conecta à base por meio o circuito 10 de carga. Quando o monofone se conecta ã base 4.1., a base verifica se o monofone faz parte de fato da lista dos monofones relativos à atualização 4.2 e 4.3. Se for este o caso, o monofone prossegue para a partida 4.4. Caso contrário, o monofone não é atualizado e permanece operacional 4.12, ou 15 seja, fica em seu modo normal de operação.

Depois da partida, o monofone, que não mais se encontra em seu modo operacional normal, aguarda uma mensagem de solicitação de transferência 4.5 por um período que pode ser de 100 ms, por exemplo. Se não for recebida nenhuma men20 sagem durante este período, a atualização não acontece, e o software inteiro é verificado 4.10. Se uma mensagem for recebida 4.6, ocorre uma negociação 4.7 do modo de transferência de dados entre a base e o monofone. Esta negociação compreende, por exemplo, a determinação do tipo de monofone, o 25 tipo do aplicativo para transferência, e a determinação do tamanho dos blocos de transmissão.

Os dados são transmitidos 4.8 e 4.9. Esta trans75 missão ocorre em blocos sucessivos. A recepção de cada bloco

• 4	• ··	4	• 4	4	• ·	444 444
4 *	4	4 4	• 4	•	4	• « · *	4	4
• 4	4	4 4	4 4	4	4	·· · ·«	• 4
	4	• 4	4 4	4	4	• *	4 4	4
	• 4 4	4	4		4	• ··	• 4

é validade pelo monofone por meio de um reconhecimento de recibo.

Quando todos os blocos são transmitidos, a integridade do software é verificada 4.10. Se a assinatura for negativa, o monofone vai para um estado de aguardar uma mensagem de transferência 4.5. Se a assinatura for positiva, o software pode em seguida iniciar 4.11. Em seguida, o monofone torna-se operacional novamente 4.12.

Em uma outra modalidade, quando o circuito de cir10 cuito de carga conecta os mesmos, o enlace de comunicação usado entre o monofone e a base será diferente do enlace do circuito de carga. O enlace de comunicação pode ser, por exemplo, um enlace de rádio.

O princípio operacional da interface de comunicais ção entre a base e o monofone por meio de contatos de carga de bateria é como se segue: a voltagem de carga da base é controlada pelo processador da base, através do circuito carregador da base. A corrente arrastada pelo monofone é controlada pelo processador do monofone, através do circuito 20 de carga do monofone.

A Figura 5 e a Figura 6 mostram o circuito carregador da base e o monofone por meio de transistores e resistores. Conforme mostrado na Figura 5, no circuito carregador da base, o sinal CHARGER_DIALOG_ENABLE que vem do processa25 dor da base normalmente se encontra em um nível lógico baixo. Desta maneira, o transistor Q4 fica saturado, o que tem o efeito de saturar o transistor Q1. A voltagem de carga (de modo geral em um valor de 9V) se encontra presente entre os

• ♦ • · • ·	• ·· « *	• • · • ·	9 9 9 * «	9 9 9 9 9	« • •	9	9 9 9 9 9	•·· ··· • · • ·
	•	9 9	9 9	9 9		9	9	>99
	9 9«	9	•	9		9	9 9	9 9

contatos positivo e negativo da base, e o transmissor UART do processador pode ser usado para outras funções. O transistor bloqueado Q3 deixa o sinal de recepção do transmissor UART, CPU_UART_RXD, em um nível alto independente da corrente de carga de bateria do monofone.

Para enviar dados para o monofone, o processador alterna o sinal CHARGER_DIALOG_ENABLE para o nível lógico elevado (no valor de 3,3 V). Nesta situação, a saída do transmissor UART (porta serial assíncrona) do processador, CPU_UART_TXD, controla a voltagem de carga de bateria.

Com relação à transmissão na base, quando o protocolo do transmissor UART da base emite um nível alto, a voltagem de carga fica presente nos contatos de carga. Ou seja, se a saída CPU_UART__TXD se encontra em um nível lógico alto, o transistor Q1 fica saturado, a voltagem de carga fica presente nos contatos da base. Quando o protocolo do transmissor UART da base emite um nível baixo, a voltagem de carga torna-se nula nos contatos de carga. Ou seja, se a saída CPU_UART__TXD se encontra em um nível lógico baixo, o transistor Q1 é bloqueado, o que corta a voltagem de carga.

Para a base receber dados, a saída CPU_UART_TXD deve estar no nível alto, e, portanto, a voltagem de carga deve estar presente. Se o monofone comuta a corrente de carga rápida (de modo geral superior a 150 mA, tipicamente um valor de 200 mA, por exemplo) , a voltagem nos terminais do resistor R5 é suficiente para saturar o transistor Q2, que envia um nível baixo na porta de entrada do transmissor UART do processador (a saída CPU_UART_TXD). Se o monofone comuta

4 4 9 * • ·	• r · • *	• 4 4	F · e • j	• * * * *	• * «	•	« • * • ·	• · 9 •	♦ 44 •
								•	•
	•	• t	< ·	• ·		•	•	4 ·	4
	• * *	4	•	*		•	« ·	4	4

a corrente de carga contínua (de modo geral abaixo de 50 mA, por exemplo, de um valor de 20 mA) , a voltagem nos terminais de R5 fica baixa demais, o transistor Q2 é bloqueado, o processador recebe um nível alto na saída CPU_UART_TXD.

Com relação ao circuito de carga do monofone, indicado na Figura 6, quando a voltagem de carga está presente nos contatos da base, o circuito de carga do monofone gera um nível alto no transmissor UART do monofone. Quando a voltagem de carga está ausente nos contatos da base, o circuito de carga do monofone gera um nível baixo no transmissor UART do monofone. Em outras palavras, quando uma voltagem suficiente (superior a 6 V) está presente nos contatos de carga, o sinal de recepção serial UART_RXD do processador do monofone recebe um nível lógico alto. 0 diodo Zener 3V CRIO permite que a voltagem nesta entrada do processador não exceda 3V quando a voltagem de carga atravessa o nível limite. Quando a voltagem é cortada, o sinal UART_RXD fica em um nível alto.

Com relação à emissão no nível do monofone, um nível alto na saída UART_TXD bloqueia o transistor Qll, que bloqueia o transistor Q12, o qual, por sua vez, bloqueia o transistor Q13, deixando apenas a carga de bateria via o resistor R13 (com um valor típico de 120 ohms), que é uma carga contínua da ordem de 3 0 mA. Um nível baixo na saída UART_TXD satura os transistores Qll, Q12 e Q13, o que permite que a bateria seja recarregada com uma alta corrente superior a 150 mA (definida pelo resistor de limitação de corrente R4 na base).

Em outras palavras, quando o transmissor UART do

	V *	· ·	Λ		• «	«	•	•	• V V	• · t
	4	♦	*	•	•	• ·		« *	•
14	( ♦ • ·	• u	« •	Λ •	·· • ·	* e ·	♦ # Λ	• ♦ ♦ <	« •	»
	•	♦	•		* ·	• *	•	•	• »	«
	f·	• · ·	**		•	•	•	• ♦	•	•

monofone emite um nível baixo, a corrente de carga arrastada pelo monofone fica igual à corrente de carga rápida. Quando o transmissor UART do monofone emite um nível alto, a corrente de carga arrastada pelo monofone é igual à corrente de carga contínua. Quando a corrente arrastada pelo monofone é superior a um limite estabelecido (de aproximadamente 100 mA) , o circuito carregador da base gera um nível baixo no transmissor UART da base. Quando a corrente arrastada pelo monofone é inferior ao limite estabelecido, o circuito carregador da base gera um nível alto no transmissor UART da base.

princípio da comunicação entre a base e o monofone é, portanto, como se segue:

- quando o transmissor da base tem uma alta voltagem, uma voltagem de 9 V está presente nos contatos, os quais enviam um nível alto para o receptor do monofone;

- quando o transmissor da base está em um nível baixo, a voltagem é cortada, o que força um nível baixo para o receptor do monofone;

- quando o transmissor do monofone tem uma alta voltagem, a corrente de carga da batería é baixa, a qual envia um nível alto para o receptor da base;

- quando o transmissor do monofone está em um nível baixo, a corrente de carga da batería fica alta, a qual envia um nível baixo para o receptor da base.

Deve-se notar que o monofone só pode transmitir dados para a base se a base não estiver transmitindo (nível

voltagem

• ·	··♦	*	«·	•	•	•	···	·· ·
	•	«	• <*	•	« ·	•	• ·	•
15	*		• V	··	*	• ·	• *	•	•
··	•	• ·	• ·	• ·	···	•	•	«
	•		• ·	« ·	• ·	•	•	• ·	•
	•	···	Γ	•	•	•	• ·	•	•

é meio duplex.

mecanismo provê uma operação de carga normal para um monofone, fora dos períodos ativos de comunicação. Com efeito, a ausência de qualquer sinal transmitido corresponde 5 a uma operação de carga padrão.

Claims

REIVINDICAÇÕES

1. Base de comunicação (1.11), compreendendo:

uma interface de rádio (1.14) para se comunicar com um dispositivo de comunicação (1.1) que opera por meio de um aplicativo de software (1.6);

um circuito carregador (1.12);

um meio (1.22) para detectar uma versão nova do aplicativo de software (1.6), a dita base de comunicação (11.11) sendo CARACTERIZADA pelo fato de compreender ainda:

um meio (1.23) para notificar o dispositivo de comunicação (1.1), através da dita interface de rádio (1.14), da disponibilidade da versão nova do aplicativo de software (1.6) ;

um meio para transmitir a versão nova do aplicativo de software (1.6) para o dispositivo de comunicação (1.1) quando o circuito carregador (1.12) é conectado ao circuito de carga (1.2) da bateria (1.21) do dispositivo de comunicação (1.1) .
2. Base de comunicação, de acordo com a reivindicação 1, CARACTERIZADA pelo fato de que o meio para transmitir a versão nova do aplicativo de software (1.6) para o dispositivo de comunicação (1.1) usa o circuito carregador (1.12).
3. Base de comunicação, de acordo com a reivindicação 1 ou 2, CARACTERIZADA pelo fato de compreender um meio (1.21) para verificar a compatibilidade do dispositivo de

Petição 870180158047, de 03/12/2018, pág. 9/13 comunicação (1.1) com a versão nova do aplicativo de software (1.6).
4. Base de comunicação, de acordo com a reivindicação 2, CARACTERIZADA pelo fato de que a transmissão por meio do circuito carregador (1.12) é feita por meio do protocolo de comunicação de Transmissor Receptor Assincrono Universal.
5. Base de comunicação, de acordo com qualquer uma das reivindicações 1 a 4, CARACTERIZADA pelo fato de que a mesma é uma base para um telefone sem fio doméstico.
6. Base de comunicação, de acordo com qualquer uma das reivindicações 1 a 5, CARACTERIZADA pelo fato de que a interface de rádio (1.14) atende ao padrão de Comunicação Sem fio Aperfeiçoado Digital.
7. Base de comunicação, de acordo com qualquer uma das reivindicações 1 a 6, CARACTERIZADA pelo fato de que compreende uma interface com uma rede de comunicação (1.17) para detectar e transferir a versão nova do aplicativo de software (1.6).
8. Dispositivo de comunicação (1.1) que opera por meio de um aplicativo de software (1.6) e compreende:

uma interface de rádio (1.1) para se comunicar com uma base, um circuito de carga (1.2), uma interface com o usuário (1.9), o dito dispositivo de comunicação (1.1) sendo

CARACTERIZADO pelo fato de que:

Petição 870180158047, de 03/12/2018, pág. 10/13 quando é notificado de uma versão nova de software a partir da dita interface de rádio (1.4), o dispositivo de comunicação (1.1) compreende um meio para indicar uma disponibilidade de uma versão nova do aplicativo de software (1.6) na interface com o usuário (1.9); e o dito dispositivo de comunicação (1.1) compreende um meio para receber a versão nova do aplicativo de software (1.6) quando um circuito de carga (1.2) é conectado a um circuito carregador (1.12) de uma base.
9. Dispositivo de comunicação, de acordo com a reivindicação 8, CARACTERIZADO pelo fato de que o meio para receber a versão nova do aplicativo de software (1.6) usa o circuito de carga (1.2) .
10. Dispositivo de comunicação, de acordo com a reivindicação 8 ou 9, CARACTERIZADO pelo fato de ser um monofone de telefone.
11. Método, para ser realizado em um dispositivo de comunicação (1.1) que opera com um aplicativo de software (1.6) e compreende:

uma interface de rádio (1.4) para se comunicar com uma base, um circuito de carga (1.2), uma interface com o usuário (1.9), o dito método compreendendo:

receber informação sobre uma disponibilidade de uma versão nova do dito aplicativo de software (1.6) a partir da dita interface de rádio (1.4), o dito método sendo CARACTERIZADO por compreender:

Petição 870180158047, de 03/12/2018, pág. 11/13 indicar a disponibilidade da versão nova do aplicativo de software (1.6) na dita interface com o usuário (1.4);

baixar a versão nova do aplicativo de software (1.6) quando o circuito de carga (1.2) é conectado ao circuito carregador (1.12) da base.
12. Método, de acordo com qualquer uma das reivindicações 8 a 11, CARACTERIZADO pelo fato de que o dito dispositivo de comunicação (1.1) é um monofone de telefone.
13. Método, para ser realizado em uma base de comunicação (1.11) que compreendendo:

uma interface de rádio (1.14) para se comunicar com um dispositivo de comunicação (1.1) operando com um aplicativo de software (1.6), um circuito carregador (1.12), uma interface (1.17) com uma rede de comunicação, um meio (1.22) para detectar uma versão nova do aplicativo de software (1.6), o dito método compreendendo:

detectar uma versão nova do dito aplicativo de software (1.6), verificar se a versão nova do dito aplicativo de software (1.6) é suportada pelo dispositivo de comunicação (1.1), informar o dispositivo de comunicação (1.1) sobre a disponibilidade da versão nova do aplicativo de software (1.6) ,

Petição 870180158047, de 03/12/2018, pág. 12/13 o dito método sendo CARACTERIZADO pelo fato de que compreende, quando o circuito de carga (1.2) do dispositivo de comunicação (1.1) é conectado ao circuito carregador (1.12) da base:

5 verificar se o software do dispositivo de comunicação (1.1) deve ser atualizado, e baixar a versão nova a partir da base para o dispositivo de comunicação (1.1).
14. Método, de acordo com a reivindicação 13,

10 CARACTERIZADO pelo fato de compreender baixar para a base a versão nova do aplicativo de software (1.6) a partir do servidor (2.2) localizado na rede de comunicação (2.1) .