BRPI0706518A2 - modelo de sincronização de participantes de rede não hierárquica - Google Patents

Abstract

MODELO DE SINCRONIZAçAO DE PARTICIPANTES DE REDE NAO HIERáRQUICA. São apresentadas várias tecnologias e técnicas que aperfeiçoam a sincronização de dados entre diversos tipos de dispositivos e/ou serviços. Um participante cheio recebe uma solicitação de um outro participante no sentido de realizar uma operação de sincronização. O mecanismo de sincronização determina se o dispositivo ou serviço é um participantecheio, parcial, ou simples. O dispositivo ou serviço será um participante simples quando tem um armazenador de dados para dados sincronizados, porém nenhum armazenador de conhecimento. O dispositivo ou serviço será um participante parcial quando tem um armazenador de dados para dados sincronizados e um armazenador de conhecimento, mas não entende o conhecimento. O dispositivo ou serviço será um tipo participante cheio quando tem um armazenador de dados para dados sincronizados e um armazenamento de conhecimento, e entende o conhecimento. O mecanismo de sincronização realiza a operação de sincronização com o dispositivo ou serviço utilizando um conjunto de lógicas apropriadas para o tipo de dispositivo ou serviço.

Description

"MODELO DE SINCRONIZAÇÃO DE PARTICIPANTES DE REDENÃO HIERÁRQUICA"

FUNDAMENTOS DA -INVENÇÃO

No mundo da tecnologia e da manipulação de infor-mações digitais de hoje em dia, as pessoas podem armazenarinformações ou dados em uma variedade de dispositivos e lo-cais diferentes. Muitas vezes, o usuário armazena as mesmasinformações em mais de um dispositivo e/ou local. O usuáriogostaria que todos os diversos armazenamentos de dados ti-vessem as mesmas informações sem ter de entrar manualmenteas mesmas alterações em cada armazenamento de dados. A du-plicação é um processo utilizado para assegurar que cada ar-mazenamento de dados tenha a mesma informação.

Por exemplo, um usuário pode manter uma agenda deendereços eletrônicos em uma grande variedade de dispositi-vos ou locais diferentes. 0 usuário pode manter a agenda deendereços, por exemplo, em um gerenciador de informaçõespessoais armazenado em seu computador de mesa, em seu compu-tador portátil, em um assistente digital pessoal (PDA), emum gerenciador de contatos on-line, ou coisas do gênero. 0usuário pode modificar as agendas de endereço eletrônico emcada local, por exemplo, ao adicionar um contato, ao apagarum contato, ou ao alterar as informações de contato. A du-plicação é usada no sentido de garantir que a alteração fei-ta em um dispositivo em especial, em última análise, se re-flita nos armazenamentos de dados dos outros dispositivos dousuário.

A duplicação torna-se cada vez mais complicada àmedida que o número de dispositivos e/ou serviços que um de-terminado usuário utiliza aumenta e/ou o tamanho ou as capa-cidades de processamento desses dispositivos diminuem. Porexemplo, muitos usuários têm mini-unidades thumb drives, me-mória removível, assistentes PDA, telefones, dispositivosportáteis de música, e assim por diante. Informações, taiscomo registros de contatos, seriam úteis de se ter em muitosdesses dispositivos e/ou sincronizados entre esses disposi-tivos, no entanto, muitos desses tipos de dispositivos nãotêm sequer um processador de computador que muitas vezes éobrigado a participar de um processo de sincronização típi-co. Estes problemas de sincronização podem ser ainda maisagravados quando um compartilhamento de dados em grupo é en-volvido, como, por exemplo, quando múltiplos usuários com-partilham um calendário de grupo.

SUMÁRIO DA INVENÇÃO

Várias tecnologias e técnicas divulgadas melhorama sincronização de dados entre diversos tipos de dispositi-vos e/ou serviços. Um dispositivo ou serviço participantecheio recebe uma solicitação de um outro dispositivo ou ser-viço no sentido de realizar uma operação de sincronizaçãoutilizando um mecanismo de sincronização. 0 outro dispositi-vo ou serviço se comunica com o mecanismo de sincronizaçãodo participante cheio através da implementação de uma inter-face de tratador (handler). O mecanismo de sincronização or-questra a comunicação entre os diferentes tratadores insta-lados em um sistema a fim dê acionar a sincronização entreextremidades. Uma vez conectados ao mecanismo de sincroniza-ção, os tratadores são inspecionados de modo a determinar oscenários de sincronização nos quais eles conseguem partici-par, ou simplesmente, os seus níveis de participação, talcomo definido em um modelo de participantes de rede não hie-rárquica.

Em uma implementação, o mecanismo de sincronizaçãodetermina se o dispositivo ou serviço é um participantecheio, um participante parcial, ou um participante simples.

O dispositivo ou serviço será um participante simples quandotiver um armazenador de dados para os dados sincronizados enenhum armazenador de conhecimento. O participante simplesnão é responsável pelo monitoramento das alterações que opróprio faz aos dados. O dispositivo ou serviço será um par-ticipante parcial quando tiver um armazenador de dados paraos dados sincronizados e um armazenador de conhecimento, maspoderá não entender o conhecimento. O participante parcial éresponsável pelo monitoramento das alterações que o própriofaz aos dados. O dispositivo ou serviço será um tipo de par-ticipante cheio quando tiver um armazenador de dados para osdados sincronizados e um armazenador de conhecimento, e en-tende os conhecimentos e algumas ou todas as operações sobreos mesmos. O conhecimento se refere a um "metadado de sin-cronização". O mecanismo de sincronização executa a operaçãode sincronização com o dispositivo, utilizando um conjuntode lógica apropriada para o tipo de dispositivo ou serviço.

Uma implementação desta arquitetura provê uma comunidade desincronização bidirecional multi-mestre, e permite que osdispositivos e/ou serviços com processamento limitado e/oucapacidades de armazenamento limitadas (como, por exemplo,as mini-unidades thumb drives, alguns assistentes digitaispessoais e/ou telefones, etc.) para participar em algum ní-vel do processo de sincronização. A sincronização multi-mestre significa permitir que dois ou mais participantes,cada qual tendo duplicações graváveis dos mesmos dados, seunam e se sincronizem quer já tenham se comunicado antes oununca antes tenham se comunicado.

Como um exemplo não limitante, um dispositivo ouserviço participante parcial pode participar de uma operaçãode sincronização bidirecional multi-mestre em uma implemen-tação, devido ao conhecimento armazenado sobre o participan-te parcial, ainda que o participante parcial não entenda oconhecimento.

Como um outro exemplo não limitante, um parti-cipante simples que tem um armazenador de dados para o arma-zenamento de dados duplicados, mas nenhum conhecimento (co-mo, por exemplo, uma mini-unidade thumb drive), poderá par-ticipar de um processo de sincronização com um participantecheio em uma implementação.

0 presente Sumário foi provido no sentido de apre-sentar uma seleção de conceitos de uma forma simplificada,os quais serão descritos em mais detalhes a seguir, na seção"Descrição Detalhada''. 0 presente Sumário não se destina aidentificar as principais características ou as caracterís-ticas essenciais da matéria reivindicada, nem se destina aser utilizado como um auxiliar na determinação do âmbito deimplementação da matéria reivindicada.

BREVE DESCRIÇÃO DOS DESENHOSA Figura 1 é uma vista diagramática de um modelode sincronização de participante de rede não hierárquica deuma implementação, mostrando uma representação gráfica de umparticipante cheio, de um participante parcial, e de um par-ticipante simples.

A Figura 2 é uma vista diagramática de um modelode sincronização de participante de rede não hierárquica deuma implementação, mostrando uma representação tabular de umparticipante cheio, de um participante parcial, e de um par-ticipante simples.

A Figura 3 é um vista diagramática de um sistemade sincronização de uma implementação com tratadores parafazer interface com dispositivos participantes.

A Figura 4 ilustra um sistema de computador exem-plar que vem a ser um ambiente operacional adequado para umaou mais implementações, como, por exemplo, para a operaçãode uma aplicação de sincronização em um dispositivo partici-pante cheio.

A Figura 5 é uma vista diagramática de uma aplica-ção de sincronização de uma implementação.

A Figura 6 é um fluxograma de processo de alto ní-vel para uma implementação do sistema.

A Figura 7 é um fluxograma de processo para umaimplementação que ilustra as etapas envolvidas na atualiza-ção e sincronização de dados usando um dispositivo partici-pante parcial.

A Figura 8 é um fluxograma de processo para umaimplementação que ilustra as etapas envolvidas no monitora-mento de alterações nos dados por parte de um dispositivoparticipante parcial por meio da atualização do registro comum novo contador (tick count) ou outro identificador.

A Figura 9 é um fluxograma de processo para umaimplementação que ilustra as etapas envolvidas no monitora-mento de alterações por parte do dispositivo participanteparcial feitas nos dados por meio do armazenamento separadode um identificador de registro e a data / hora da alteração.

As Figuras 10 e 11 ilustram um registro exemplarem um dispositivo participante parcial antes e após a modi-ficação por parte do dispositivo participante parcial.

A Figura 12 ilustra um registro exemplar em umdispositivo participante parcial antes da modificação.

A Figura 13 ilustra um registro de monitoramentode alteração exemplar em um dispositivo participante parcialno sentido de monitorar as alterações feitas ao registro daFigura 12.

A Figura 14 ilustra o registro exemplar da Figura12 atualizado por um dispositivo participante cheio depoisde determinar que o participante parcial modificou os dados,conforme descrito no registro de monitoramento de alteraçãoda Figura 13.

A Figura 15 é um exemplo de um registro de conhe-cimento armazenado em um dispositivo participante parcial ouem um dispositivo participante cheio para uma implementação.

A Figura 16 é um fluxograma de processo para umaimplementação que ilustra as etapas envolvidas na atualiza-ção e sincronização de dados usando um dispositivo partici-pante simples.

A Figura 17 é uma vista diagramática de uma comu-nidade de sincronização exemplar para uma implementação ten-do múltiplos dispositivos e tratadores.

A Figura 18 ilustra um exemplo de uma comunidadede sincronização para uma implementação.

A Figura 19 mostra um participante e uma ilustra-ção com relação ao momento de uma implementação, mostrandouma alteração que é adicionada ao participante e o conheci-mento do participante que é atualizado no sentido de incluira alteração.

A Figura 20 ilustra uma implementação de um cená-rio de duplicação com relação ao momento entre dois partici-pantes.

A Figura 21 ilustra uma implementação de um cená-rio de detecção de conflito com relação ao momento.

A Figura 22 ilustra um exemplo de identificadoresID de atribuição de alteração às alterações em um partici-pante de uma implementação.

A Figura 23 ilustra uma implementação de um cená-rio de duplicação com relação ao momento utilizando vetoresde conhecimento.

A Figura 24A ilustra uma implementação de atuali-zação de conhecimento em um participante subseqüente a umaduplicação usando uma lista de exceções.

A Figura 24B ilustra uma implementação de atuali-zação de conhecimento em um participante subseqüente a umaduplicação usando um par máximo de vetores de conhecimento.

A Figura 24C ilustra uma implementação de atuali-zação de conhecimentos em um participante subseqüente a umaduplicação quando há exceções no conhecimento atualizado.

A Figura 25 ilustra uma topologia de hub e spokede uma implementação para a implementação de uma duplicação,incluindo uma duplicação substituta.

A Figura 26A ilustra exemplos de cenários de reso-lução de conflito em uma implementação.

A Figura 26B ilustra outros cenários de resoluçãode conflito em uma implementação.

DESCRIÇÃO DETALHADA DA INVENÇÃO

Com a finalidade de promover o entendimento dosprincípios da presente invenção, será feita a seguir refe-rência às modalidades ilustradas nos desenhos e uma lingua-gem específica será utilizada no sentido de descrever asmesmas. No entanto, deve-se entender que esta linguagem nãodetermina nenhuma limitação ao âmbito de aplicação da pre-sente invenção. As eventuais modificações e outras mudançasnas modalidades descritas, ou quaisquer outras aplicaçõesdos princípios conforme descritas no presente documento sãocontempladas, tal como normalmente ocorre a uma pessoa ver-sada na técnica.

0 sistema pode ser descrito no contexto geral comouma ou mais técnicas que melhoram a sincronização de dadosentre vários dispositivos com diferentes capacidades, mas osistema também serve a outros fins além desse. Em uma imple-mentação, uma ou mais dentre as técnicas descritas no pre-sente documento podem ser implementadas como funções dentrode um programa de sincronização, como, por exemplo, o Acti-veSync® da Microsoft®, ou de qualquer outro tipo de programaou serviço que participe de um processo de sincronização en-tre dispositivos. Em outra implementação, uma ou mais dentreas técnicas descritas no presente documento são implementa-das como recursos com outras aplicações que tratam de dadosde sincronização entre dispositivos e/ou serviços. 0 termo"dispositivo móvel", conforme aqui usado, entende incluirtelefones celulares, assistentes digitais pessoais, tocado-res de midia (media players) portáteis, telefones de voz so-bre IP (VoIP) (voice-over-IP) , e muitos outros tipos de dis-positivos móveis com vários níveis de capacidades.

A Figura 1 é uma vista diagramática de um modelode sincronização de participantes de rede não hierárquica deuma implementação mostrando uma representação gráfica de umparticipante cheio 10, um participante parcial 20, e um par-ticipante simples 30. 0 termo "participante" é também aquireferido como "duplicador".

"Participante" ou "duplicador"se referem a dispositivos e/ou serviços que participam deuma comunidade de sincronização. 0 participante cheio 10 temum armazenador de dados de conhecimento 12 e a capacidade deentender o conhecimento 14. Ele tem também um armazenador dedados de sincronização 16 para armazenar os dados correntesque são sincronizados, tais como as informações de contatoou outras informações que são sincronizadas entre outrosdispositivos. Alguns exemplos não limitantes de participan-tes cheios incluem os computadores pessoais, alguns assis-tentes PDA, alguns telefones, alguns outros dispositivos mó-veis, e/ou outros dispositivos capazes de armazenar e enten-der conhecimentos.

Cada participante cheio mantém o "conhecimento" emum armazenador de dados de conhecimento que facilita uma du-plicação eficaz e aperfeiçoada. Em uma implementação, o co-nhecimento vem a ser os metadados que descrevem as altera-ções conhecidas para um determinado participante. 0 conheci-mento pode ser representado como um vetor de pares ou de IDsde alteração, no qual cada par ou ID de alteração representaum ID de duplicador ou uma versão máxima (ID de duplicador,versão max). O número de pares de um determinado vetor deconhecimento pode mudar à medida que participantes são adi-cionadas ou removidos da comunidade de sincronização. Emborao vetor de conhecimento possa também ser expresso de maneiradiferente, é vantajoso representar de maneira concisa as al-terações das quais um participante em particular está cien-te. Não se faz nenhuma exigência que o conhecimento em ques-tão contenha especificamente um ID de alteração para cadaparticipante na comunidade de sincronização. Os participan-tes são dispensados de monitorar o que os outros participan-tes já sabem, uma vez que esta informação é efetivamente re-presentada pelo conhecimento do participante.

Do mesmo modo que participante cheio 10, o parti-cipante parcial 20 também contém um armazenador de dados deconhecimento 22. Ao contrário do participante cheio 10, po-rém, o participante parcial 20 não tem capacidade (ou temuma capacidade limitada) de entender o conhecimento 24. 0participante parcial inclui um armazenador de dados de sin-cronização 26 para armazenar os dados sincronizados. 0 par-ticipante parcial inclui um armazenador de dados de versão25 para armazenar informações relacionadas às alterações quefaz no armazenador de dados de sincronização 26. Exemplosnão limitantes de participantes parciais podem incluir al-guns assistentes digitais pessoais, telefones, alguns outrosdispositivos móveis, e/ou outros tipos de dispositivos capa-zes de operar um programa simples que monitora as alteraçõesfeitas no armazenador de dados de sincronização 26.

0 participante simples 30 tem um armazenador dedados de sincronização 36, e nenhum armazenador de conheci-mento. Exemplos de participantes simples podem incluir, masnão estão limitados a, algumas mini-unidades thumb drives,alguns cartões de memória, e/ou outros dispositivos não ca-pazes de operar um programa simples que monitora as altera-ções feitas em um armazenador de dados de sincronização 36.

Passando agora para a Figura 2, é mostrada uma re-presentação tabular 50 de modelo de participantes de redenão hierárquica. O participante simples 52, o participanteparcial 54, e o participante cheio 56 têm uma ou mais carac-terísticas. Algumas destas características foram descritasna apresentação da Figura 1. O participante simples 52, porexemplo, não consegue armazenar o conhecimento 58. 0 parti-cipante simples é capaz de se sincronizar 60 com um únicoparticipante cheio através de um tratador. O participanteparcial 54 armazena, mas não entende o conhecimento 62. Oparticipante parcial 54 é capaz de participar de uma sincro-nização bidirecional multi-mestre 64. De maneira alternativaou adicionalmente, o participante parcial 54 é capaz de sesincronizar 66 através de um tratador em um participantecheio. Deste modo, o participante parcial 54 é capaz de par-ticipar de um cenário de rede não hierárquica gerenciado a-través de um ou mais dispositivos participantes cheios. Eassim, os participantes parciais poderão se sincronizar unscom os outros através do uso de um participante cheio. Oparticipante cheio 56 entende e armazena conhecimento 68,pode participar de um destino de sincronização bidirecionalmulti-mestre 70, e executar sincronizações de rede não hie-rárquica 72.

A Figura 3 é um vista diagramática de um sistemade sincronização 80 de uma implementação com tratadores parafazer interface com um ou mais dispositivos participantes. Aaplicação de sincronização 82 inclui um mecanismo de orques-tração de sincronização 84 responsável pelo término do laçode sincronização entre os participantes e pela transferênciade alterações atualizadas entre outros participantes conec-tados. Diversos tratadores 86, 88, e 90 são utilizados demodo a permitir que outros participantes da comunidade desincronização se comuniquem com o mecanismo de sincronização 84.

0 mecanismo de sincronização 84 se comunica com os tra-tadores 86, 88, e 90 através das interfaces de tratador 91,92 e 97, respectivamente. Os tratadores 86, 88, e 90, em se-guida, se comunicam com os armazenadores de conhecimento 93e 95, com o armazenador de dados de sincronização local 94,e com o armazenador de dados de sincronização remoto 96 afim de acessar dados, se for o caso. Em uma implementação,um ou mais dentre os armazenadores de dados mostrados na Fi-gura 1, como, por exemplo, o armazenador de dados de sincro-nização remoto 96, se localizam em um ou mais computadoresou dispositivos separados.

Tal como mostrado na Figura 4, um sistema de com-putador exemplar para uso na implementação de uma ou maispartes do sistema inclui um dispositivo de computação, como,por exemplo, o dispositivo de computação pessoal 100. Em suaconfiguração mais básica, o dispositivo de computação 100inclui tipicamente, pelo menos, uma unidade de processamento102 e uma memória 104. Dependendo da configuração exata e dotipo de dispositivo de computação, a memória 104 pode servolátil (tal como a memória RAM), não-volátil (tal como amemória ROM, a memória flash, etc.) ou alguma combinação dasduas. Esta configuração mais básica é ilustrada na Figura 4,na linha tracejada 106.

Além disso, o dispositivo 100 também pode ter re-cursos / funcionalidade adicionais. Por exemplo, o disposi-tivo 100 também pode incluir um armazenamento adicional (re-movível e/ou não-removível), incluindo, mas não limitado a,discos magnéticos ou óticos ou fita. Tal armazenamento adi-cional é ilustrado na Figura 4 por meio do armazenamento re-movível 108 e do armazenamento não removível 110. Os meiosde armazenamento em computador incluem os meios voláteis enão voláteis, removíveis e não removíveis implementados emqualquer método ou tecnologia para o armazenamento de infor-mações, tais como as instruções legíveis em computador, asestruturas de dados, os módulos de programa ou outros dados.A memória 104, o armazenamento removível 108 e o armazena-mento não removível 110 são exemplos de meios de armazena-mento em computador. Os meios de armazenamento em computadorincluem, mas não se limitam a, memória RAM, memória ROM, me-mória EEPROM, memória flash ou outra tecnologia de memória,unidade de CD-ROM, discos versáteis digitais (DVD) ou outroarmazenamento ótico, cassetes magnéticos, fitas magnéticas,dispositivos de armazenamento magnético em disco ou outrosdispositivos de armazenamento magnético, ou qualquer outromeio que possa ser usado para armazenar as informações dese-jadas e que possa ser acessado pelo dispositivo 100. Cada umdesses meios de armazenamento em computador podem fazer par-te do dispositivo 100.

O dispositivo de computação 100 inclui uma ou maisconexões de comunicação 114 que permitem que o dispositivode computação 100 se comunique com outros dispositivos 115,como, por exemplo, com os participantes cheios, os partici-pante parciais, e/ou os participantes simples. O dispositivode computação 100 também pode se comunicar com outros compu-tadores e/ou aplicações 113. 0 dispositivo 100 também podeter dispositivos de entrada 112, tais como teclado, mouse,caneta, dispositivo de entrada de voz, dispositivo de entra-da de toque, etc. Dispositivos de saída 111, tais como ummonitor, alto-falantes, impressora, etc., podem também serincluídos. Estes dispositivos são bem conhecidos na técnicae não precisam ser apresentados com mais delonga no presentedocumento.Em uma implementação, o dispositivo de computação100 serve como um dispositivo participante cheio para a im-plementação de uma ou mais dentre as técnicas aqui apresen-tadas. Em tal implementação, o dispositivo de computação 100contém uma aplicação de sincronização 122 com um mecanismode orquestração de sincronização 124, bem como um armazena-dor de dados de conhecimento 125, e um armazenador de dadosde sincronização 12 6. Em uma implementação, o armazenador dedados de conhecimento 125 e/ou o armazenador de dados desincronização 126 são incluídos como parte dos meios de ar-mazenamento em computador, conforme aqui descrito, tais comoa memória 104, o armazenamento removível 108, o armazenamen-to não removível 110, e/ou outros meios de armazenamento emcomputador. Em uma implementação, a aplicação de sincroniza-ção 122 é a mesma aplicação de sincronização 82 mostrada naFigura 3.

Passando agora para a Figura 5, com referênciacontinuada à Figura 4, é ilustrada uma aplicação de sincro-nização 200 de uma implementação. Em uma implementação, aaplicação de sincronização 200 vem a ser um dentre os pro-gramas aplicativos que residem em dispositivo de computação 100.

De maneira alternativa ou adicionalmente, uma ou maispartes da aplicação de sincronização 200 podem fazer parteda memória de sistema 104, em outros computadores e/ou apli-cações 113, ou em outras variações similares, tal como ocor-reria a uma pessoa da técnica de softwares de computador.

A aplicação de sincronização 200 inclui uma lógicade programa 204, que é responsável pela execução de algumasou todas as técnicas descritas no presente documento. A ló-gica de programa 204 inclui a lógica para registrar os tra-tadores para cada dispositivo e/ou serviço de modo a parti-cipar do processo de sincronização 206; a lógica para detec-tar o tipo de dispositivo e/ou serviço conectado (partici-pante simples, parcial ou cheio) 208; a lógica para receberconhecimento de um participante parcial, fazer modificaçõesno caso de haver exceções, e transferir conhecimento de vol-ta para o participante parcial 210; a lógica para detectaralterações em participantes simples e armazenar os conflitosem seu próprio armazenador de dados local 212; a lógica paratrabalhar com outros participantes cheios de modo a sincro-nizar os conjuntos de dados alterados usando o conhecimento214; a lógica para realizar uma orquestração de modo a com-pletar o laço de sincronização e recuperar as alterações a-tualizadas entre outros dispositivos e/ou serviços conecta-dos 216; e outra lógica para operar a aplicação 220.

Em uma implementação, a lógica de programa 204 éoperável no sentido de ser chamada programaticamente a par-tir de outro programa, como, por exemplo, usando uma únicachamada para um procedimento em uma lógica de programa 204.De maneira alternativa ou adicionalmente, deve-se entenderque a lógica de programa 204 pode ser incorporada como umaalternativa ou em adição às instruções executáveis em compu-tador em um ou mais computadores e/ou em diferentes varia-ções às mostradas na Figura 4.

A Figura 6 é um fluxograma de um processo de altonível para a aplicação de sincronização 200. Em uma forma, oprocesso da Figura 6 é pelo menos parcialmente implementadona lógica operacional do dispositivo de computação 100, emoutros computadores / aplicações 113, e/ou em outros dispo-sitivos participantes 115. O procedimento começa no ponto deinicialização 240 com o dispositivo ou serviço participanteconectando-se a um participante cheio (como, por exemplo, aodispositivo de computação 100 ou a algum dispositivo móvel)com o mecanismo de sincronização (etapa 242). O dispositivoou serviço registra um tratador ou de outra forma se comuni-ca com o mecanismo de sincronização do participante cheio(etapa 244). O mecanismo de sincronização detecta o tipo dedispositivo ou serviço (etapa 246), e executa a lógica desincronização adequada com base no tipo de participante:simples (ponto de decisão 248), parcial (ponto de decisão250), ou cheio (ponto de decisão 252). Por exemplo, quando odispositivo ou serviço é um participante simples tendo umarmazenador de dados de sincronização, mas nenhum conheci-mento (ponto de decisão 248), o mecanismo de sincronizaçãodetecta as alterações no participante simples e. armazena to-dos os conflitos em seu próprio armazenador de dados localno participante cheio (etapa 254).

Quando o dispositivo ou serviço é um participanteparcial tendo um armazenador de dados de sincronização e co-nhecimento armazenado, mas não entendido (ponto de decisão250), o dispositivo ou serviço, neste caso, provê o seu ar-mazenador de conhecimento para o mecanismo de sincronizaçãono participante cheio (etapa 258). 0 participante cheio fazmodificações no conhecimento, como, por exemplo, no caso dehaver exceções (etapa 260), e o participante cheio transfereo conhecimento modificado de volta para o participante par-cial (etapa 262). O conhecimento carregado no dispositivo ouserviço participante parcial permite ao mesmo se sincronizarcom segurança com múltiplos mestres, mesmo quando ocorremexceções (etapa 264). Quando o dispositivo ou serviço é umparticipante total tendo um armazenador de dados de sincro-nização e também armazena e entende o conhecimento (ponto dedecisão 252), ambos os participantes, neste caso, sabem comosincronizar de maneira ótima os conjuntos de dados alteradosusando o conhecimento (etapa 2 66) . Uma ou mais implementa-ções para a sincronização de dados entre os participantescheios são descritas em detalhe na apresentação das Figuras18 a 26.

Após a determinação do tipo de participante que éo dispositivo ou serviço, e ao tratar alterações e conflitosnesse sentido, o mecanismo de sincronização, em seguida, se-gue a orquestração de modo a completar o laço de sincroniza-ção e recuperar as alterações atualizadas entre outros dis-positivos e/ou serviços participantes conectados (etapa256). O processo termina no ponto de finalização 268.

A Figura 7 é um fluxograma de processo ilustrandoas etapas envolvidas na atualização e sincronização de dadosusando um dispositivo participante parcial. Em uma forma, oprocesso da Figura 7 é pelo menos parcialmente implementadona lógica operacional do dispositivo de computação 100, emoutros computadores e/ou aplicações 113, e/ou em outros dis-positivos participantes 115. O procedimento começa no pontode inicialização 280 com a provisão de um dispositivo ouserviço participante parcial tendo um armazenador de dadospara armazenar os dados recuperados durante um processo desincronização, e um armazenador de dados de versão para ar-mazenar informações relativas às alterações feitas nos dados(por exemplo, em um vetor, uma cadeia, e/ou outra forma demonitorar as alterações que os participantes cheios / mes-tres observaram (etapa 282). Alguns exemplos não limitantes,alguns dispositivos móveis, tais como alguns assistentes PDAe/ou alguns telefones, e/ou outros dispositivos ou serviçosque podem armazenar conhecimento, mas não entendem o mesmo.

O participante parcial não sabe como entender oconhecimento, mas simplesmente armazena o mesmo (etapa 284).O participante parcial recebe uma solicitação de um usuáriorio sentido de alterar alguns ou todos os dados no armazena-dor de dados de sincronização (etapa 286) . O participanteparcial altera os dados no armazenador de dados conforme so-licitado pelo usuário (etapa 288). O participante parcial éresponsável pelo monitoramento das alterações que fez nosdados, e, deste modo, armazena as informações relativas àsalterações que fez com base na solicitação do usuário (etapa2 90). Em uma implementação, quando o participante parcial sesincroniza com um participante cheio, a sincronização ocorredo cheio para o parcial e do parcial para o cheio (etapa292). Em uma implementação, há duas sincronizações bidire-cionais separadas. Em outras implementações, outras ordense/ou cenários de sincronização são igualmente possíveis,tais como uma única sincronização unidirecional. Durante asincronização, todas as alterações feitas pelo participanteparcial são recuperadas pelo participante cheio (etapa 294).0 participante cheio atualiza o armazenador de dados e o co-nhecimento no participante parcial após solucionar todos osconflitos (etapa 296). 0 processo termina em um ponto de fi-nalização 298.

A Figura 8 é um fluxograma de processo para umaimplementação ilustrando as etapas envolvidas quando o par-ticipante parcial monitora alterações nos dados por meio daatualização do registro com um contador ou outro identifica-dor. Em uma forma, o processo da Figura 8 é pelo menos par-cialmente implementado na lógica operacional do dispositivode computação 100, em outros computadores / aplicações 113,e/ou em outros dispositivos participantes 115. O procedimen-to começa no ponto de inicialização 300 com o participanteparcial sendo responsável pelo monitoramento das alteraçõesque fez nos dados (etapa 302). O participante parcial atua-liza o registro do armazenador de dados de versão de modo aindicar a ocorrência de uma alteração (etapa 304). Assim co-mo em alguns exemplos não limitantes, o armazenador de dadosde versão pode ser atualizado com um novo contador, versão,ou outro identificador que identifica a alteração do regis-tro e/ou identifica o último dispositivo ou serviço que feza alteração.

O participante cheio lê o contador modificadoou outro identificador a fim de saber qual registro em par-ticular foi modificado pelo participante parcial (etapa306). O processo termina no ponto de finalização 308.

A Figura 9 é um fluxograma de processo ilustrandoas etapas envolvidas em uma implementação na qual o partici-pante parcial monitora as alterações feitas nos dados pormeio do armazenamento separado de um identificador de regis-tro e a data / hora da alteração. Em uma forma, o processoda Figura 9 é pelo menos parcialmente implementado na lógicaoperacional do dispositivo de computação 100, em outros com-putadores e/ou aplicações 113, e/ou em outros dispositivosparticipantes 115. O procedimento começa no ponto de inicia-lização 310 com o participante parcial sendo responsável pe-lo monitoramento das alterações que fez nos dados (etapa312). O participante parcial monitora um identificador únicoque identifica o registro de duplicador e um carimbo de data/ hora indicando a data / hora quando o registro foi altera-do (etapa 314). O participante cheio lê o identificador úni-co e o carimbo de data / hora a fim de saber que registro emparticular mudou (etapa 316). O participante cheio atualizao contador ou outro identificador que identifica o últimodispositivo ou serviço para mudar o registro, que, neste ca-so, é o participante parcial (etapa 318). 0 processo terminaem um ponto de finalização 320.

As Figuras 10 e 11 ilustra um registro exemplar emum dispositivo participante parcial antes da modificação ouapós a modificação pelo dispositivo participante parcial deacordo com as etapas descritas na Figura 8. Em uma implemen-tação, o registro 330 da Figura 10 inclui um campo de ID deduplicador 332, um campo de contador 334 do último partici-pante que alterou o registro, e um campo de contador localquando o registro veio do participante cheio 336. Os respec-tivos valores 338, 340, e 342 nos campos 332, 334, e 336,respectivamente, podem ser armazenados em uma cadeia, em umvetor, e/ou em qualquer outro tipo de representação adequadapara armazenamento em dispositivo ou serviços com uma capa-cidade e/ou recursos limitados de armazenamento. Conformepreviamente descrito, inúmeras outras variações podem tambémser usadas para indicar que um registro em particular noparticipante parcial foi alterado.

Voltando-se, a seguir, para a Figura 11, o regis-tro 343 mostra os dados depois de serem revisados pelo e noparticipante parcial. 0 campo de ID de duplicador 332 conti-nua com um valor de "XI" (350), uma vez que este é um iden-tificador único para o registro. 0 campo de contador 334 doúltimo computador que alterou o registro é modificado de umvalor de "G66" (340 na Figura 10) para um valor de "G67"(352). O "G" representa o participante que fez a alteração,e "67" é o número mais alto seguinte disponível na seqüênciado contador. 0 contador local quando vem do campo de parti-cipante cheio 336 permanece no mesmo valor de "34" (354).

A Figura 12 ilustra um registro exemplar em umdispositivo participante parcial antes da modificação de a-cordo com as etapas descritas na Figura 9. Similar ao exem-plo das Figuras 10 e 11, o registro 360 inclui um valor 368para o campo de ID de Duplicador 362, um valor 370 para ocampo de contador 364 do último participante que alterou oregistro, e um valor 372 para o campo de contador local 366quando veio do participante cheio. Na presente implementa-ção, o participante parcial atualiza um registro de monito-ramento de alteração separado ao invés do registro com ocontador. 0 registro 360 mostra o registro com o contadorantes da modificação dos dados subjacentes pelo participanteparcial. O registro 375 da Figura 13 ilustra um registro demonitoramento de alteração exemplar em um dispositivo parti-cipante parcial que deve monitorar as alterações feitas aoregistro da Figura 12 de acordo com as etapas descritas naFigura 9. 0 campo de ID de duplicador 374 e o campo de data/hora 37 6 para quando o registro mudou são armazenados noparticipante parcial. Neste exemplo, o valor "XI" 378 é ar-mazenado para o ID de Duplicador 374, e "01-26-06-12:32PM"380 é armazenado para o campo de data / hora 376. Quando oparticipante parcial seguinte se conecta a um participantecheio, o participante cheio recupera e interpreta o registro375 a fim de determinar que o participante parcial fez mu-danças nos dados subjacentes no armazenador de dados de sin-cronização. Voltando-se, agora, para a Figura 14, o partici-pante parcial, em seguida, atualiza o campo de contador 390do registro 381 do último participante parcial que alterou oregistro, que, neste caso, é "G67" de modo a representar oparticipante parcial e o número de contador mais elevado se-guinte. O campo de contador local 366 é revisado para um va-lor atualizado 392, se for o caso. O valor 388 para o campode ID de duplicador 362 permanece igual.

A Figura 15 é um exemplo de um registro de conhe-cimento armazenado em um dispositivo participante parcial ouem dispositivo participante cheio para uma implementação. Noexemplo mostrado, o registro de conhecimento 396 é represen-tado como um vetor de cadeia, conforme descrito no parcial,com os valores 398, 400, 402 e 404, indicando o identifica-dor de participante e número de seqüência para as últimasalterações observadas para aquele dispositivo em particular.Por exemplo, o valor "G100" (398) significa que este parti-cipante viu todas as alterações para o dispositivo G atravésdo registro 100. Estes vetores de conhecimento são descritosem mais detalhes na apresentação das Figuras 18 a 26.

Voltando-se, a seguir, para a Figura 16, é mostra-do um fluxograma ilustrando as etapas envolvidas na atuali-zação e sincronização de dados usando um dispositivo de par-ticipante simples. Em uma forma, o processo da Figura 16 épelo menos parcialmente implementado na lógica operacionaldo dispositivo de computação 100, em outros computadores /aplicações 113, e/ou em outros dispositivos participantes115.

0procedimento começa no ponto de inicialização 420 coma provisão de um outro dispositivo ou serviço participantetendo um armazenador de dados para armazenar dados, mas semnenhum conhecimento (etapa 424). Alguns exemplos não Iimi-tantes de dispositivos simples incluem algumas mini-unidadesthumb drives, alguns cartões de memória, alguns assistentesPDA, alguns telefones celulares, e/ou outros dispositivos ouserviços que não conseguem armazenar e entender o conheci-mento. 0 participante simples não consegue armazenar e en-tender o conhecimento (etapa 426), devido às limitações dodispositivo ou serviço ou às definições do usuário. O parti-cipante simples recebe uma solicitação de um usuário no sen-tido de alterar alguns ou todos os dados no armazenador dedados de sincronização (etapa 428).

0 participante simples altera os dados no armaze-nador de dados de sincronização conforme solicitado pelo u-suário (etapa 430). Um exemplo não limitante de como o usuá-rio pode alterar o armazenador de dados de sincronização in-clui a modificação dos dados em um navegador de arquivos deum outro dispositivo, como, por exemplo, um computador pes-soal, por meio da inserção de uma mini-unidade thumb driveem um computador pessoal e em seguida alterando os conteúdosda mini-unidade thumb drive. O participante simples não éresponsável pelo monitoramento das alterações que fez nosdados, uma vez que o mesmo presumidamente não sabe nada (e-tapa 432). Quando o participante simples se sincroniza com oparticipante cheio, a sincronização ocorre do participantecheio para o participante simples e em seguida do simplespara o cheio (etapa 434). Durante a sincronização, todas asmudanças feitas pelo participante simples no armazenador dedados de sincronização ao recuperadas pelo participantecheio (etapa 436). O participante atualiza os dados de sin-cronização no participante simples após a resolução de todosos conflitos (etapa 438). O processo termina no ponto de fi-nalização 440.

A Figura 17 é uma vista diagramática de uma comu-nidade de sincronização exemplar para uma implementação ten-do múltiplos dispositivos e tratadores. A Figura 17 ilustraum participante cheio 500 chamado o computador pessoal 1, ou"PCI" (506); um participante simples chamado dispositivo 1(514); um participante parcial 502 chamado "Serviço 1"; e umsegundo participante cheio 504 chamado o computador pessoal2, ou "PC2". Para fins de ilustração, supõe-se que o dispo-sitivo 1 (514) seja uma mini-unidade thumb drive ou outrocartão de memória, o serviço 1 seja um serviço de música lo-calizado em um servidor de rede mundial, e o PCl e o PC2 se-jam computadores pessoais, similares ao dispositivo de com-putação 100. 0 participante cheio 500 tem os tratadores 508,510 e 512, e o participante cheio 504 tem os tratadores 516,518 e 520. Estes tratadores são responsáveis pela interfacecom os vários participantes que fazem parte da comunidade desincronização. Quando o dispositivo 1 (514) se conecta aopCl (506), o processo de sincronização descrito na Figura 6é executada.

0 tipo de participante é determinado, que, nes-te caso, é simples, e, em seguida, a sincronização ocorreentre o dispositivo 1 (514) e õ PCl (506) do participantecheio 500. Quando a sincronização é completada entre estesdois participantes (500 e 514), a orquestração fará com queoutros participantes (502 e 504) sejam atualizados quando osmesmos estão conectados e/ou na vez seguinte que os mesmosse conectam ao PCl (506) ou ao Dispositivo 1 (514).

Voltando-se, agora, para as Figuras 18 a 26, umaou mais implementações para a sincronização de dados entreparticipantes cheios (por exemplo, dois computadores pesso-ais, tais como o dispositivo 100) são descritas. Um ou maisdentre os exemplos apresentados nas Figuras 18 a 2 6 podemtambém se aplicar pelo menos em alguma parte a um cenário departicipante parcial ou a outros cenários descritos nas fi-guras anteriores. De maneira alternativa ou adicionalmente,uma ou mais técnicas apresentadas nas Figuras 18 a 26 podemser implementadas em um dispositivo, como, por exemplo, nodispositivo de computação 100 da Figura 4. 0 termo "duplica-dor" conforme usado na apresentação a seguir também signifi-ca "participante".

Os duplicadores / participantes em uma comunidadede sincronização se duplicam por meio da provisão de seupróprio conhecimento com o duplicador com o qual os mesmosse duplicam. A fim de reduzir a quantidade de dados que re-presentam o conhecimento que deve ser enviado entre os du-plicadores duplicantes, o conhecimento pode ser expresso co-mo um vetor de conhecimento, conforme previamente apresenta-do. Sendo assim, o conhecimento que é enviado entre os du-plicadores não precisa incluir todo ID de alteração, mas po-de estar na forma de um vetor que representa um número de IDde alteração. Por exemplo, quando um duplicador está cientede todas as mudanças feitas por um duplicador A a partir deuma primeira alteração para uma quinta alteração, o duplica-dor pode enviar um vetor de conhecimento A10B5, indicandoque o duplicador está ciente de todas as mudanças correspon-dentes aos ID de alteração Al a AlO e de todas as mudançascorrespondentes aos ID de alteração Bl a B5. Embora o conhe-cimento possa ser expresso como um vetor de conhecimento,outras implementações da presente invenção contemplam tambémoutras expressões de conhecimento. Por exemplo, algumas im-plementações da presente invenção expressam conhecimento u-tilizando qualquer expressão de conhecimento na qual se pode(1) adicionar uma alteração à expressão de conhecimento, (2)verificar se a alteração está incluída na expressão de co-nhecimento, e (3) intercalar duas expressões de conhecimentoentre si.

A Figura 18 ilustra um exemplo de comunidade desincronização 1100 com a topologia ilustrada. A comunidadede sincronização 1100 inclui diversos duplicadores e é umexemplo de um ambiente para implementar as implementações dapresente invenção. Os duplicadores da comunidade de sincro-nização 1100 representam vários armazenadores de dados oudispositivos que podem incluir, mas não se limitam a, compu-tadores, computadores de bolso, assistentes digitais pesso-ais, telefones celulares, outros dispositivos sem fio, com-putadores servidores, serviços on-line, ou coisa do gêneroou quaisquer combinações dos mesmos.

Na Figura 18, um duplicador A 1102 pode ser ele-tronicamente acoplado a um duplicador B 1104 através de umenlace de comunicação 1106. 0 duplicador A 1102 pode ser co-nectado através de um enlace de comunicação 1108 a um dupli-cador C 1110.

O duplicador C 1110 pode ser conectado ao du-plicador B 1104 através de um enlace de comunicação 1112. 0duplicador ClllO pode ser ainda conectado a um duplicadorD1114 através de um enlace de comunicação 1116. Nesta comu-nidade de sincronização 1100, embora nem todos os duplicado-res estejam diretamente conectados através de enlaces de co-municação, as alterações em qualquer um dentre os duplicado-res podem ser duplicadas para qualquer um dentre os duplica-dores dentro da comunidade de sincronização 1100.

Por exemplo, para o duplicador A 1102 ser duplica-do com o duplicador D 1114, os duplicadores A 1102 e C 1110pode ser duplicados através do enlace de comunicação 1108.

Deste modo, o duplicador C 1100 inclui as alterações feitasno duplicador A 1102. Os duplicadores C e D em seguida seduplicam através do enlace de comunicação 1116, e, assimsendo, o duplicador D 1114 inclui as alterações do duplica-dor A 1102. Desta maneira, o duplicador A 1102 poderá se du-plicar com o duplicador D 1114 sem nenhum tipo de enlace di-reto. Com efeito, os duplicadores A 1102 e D 1114 não pode-rão ainda ter ciência da existência um do outro dentro dacomunidade de sincronização 1100. Os enlaces de comunicaçãoilustrados podem ser enlaces com fio e/ou sem fio.

Com referência, a seguir, à Figura 19, uma imple-mentação da presente invenção ilustra como as alterações sãogerenciadas em um duplicador. A Figura 19 mostra a progres-são com relação ao momento (timewise) de um duplicador A1200. O duplicador A 1200 inclui o conhecimento 1202, nestecaso rotulado com Ka, e as alterações 1204, neste caso, ro-tuladas com Δα. Toda mudança nas alterações 1204 vem a ser oconteúdo de dados correntes de um item. Uma alteração podeser um novo item adicionado a um duplicador mesmo que nenhumitem tenha sido modificado por si só, a exclusão de um item,ou coisa do gênero. Cada uma das alterações 1204 é associadaa uma versão que, em uma implementação da presente invenção,é um ID de alteração. Notavelmente, um aspecto vantajoso dapresente invenção é que não há nenhuma necessidade de semanter um registro (lógico) de alteração incluindo informa-ções sobre alterações anteriores. Ao invés disso, cada du-plicador inclui conhecimento e um banco de dados de altera-ções (isto é, os itens correntes), no qual cada alteraçãotem uma versão correspondente. No momento (1), o duplicadorA 1200 se encontra em um estado estacionário. No momento(2), um usuário entra uma alteração rotulada X que é adicio-nada como um elemento das alterações 1204. 0 conhecimento1202 é atualizado de modo a incluir um ID de alteração, oChangeID(X), que é associado à alteração X e identifica aadição da alteração X às alterações 1204. Esta implementaçãoilustra uma maneira na qual as alterações no duplicador sãoassociadas a identificadores ID de alteração específicos. 0conhecimento 1202 pode se um vetor de conhecimento e repre-senta as alterações das quais o duplicador A 1200 tem ciên-cia.

Em uma implementação da presente invenção, as versõesou identificadores ID de alteração são mantidos nos itens ouobjetos de um banco de dados, e as versões podem ser usadasno sentido de identificar o que precisa ser duplicado. Demaneira alternativa, um registro de alterações pode tambémser mantido.

A Figura 20 ilustra o uso do conhecimento para e-numerar as alterações durante uma duplicação. A Figura 20mostra dois duplicadores, ou seja, o duplicador A 1302 e oduplicador B 1304. 0 duplicador A 1302 inclui um conjunto dealterações 1306, neste exemplo rotulado com ΔΑ. 0 duplicadorA 1302 inclui ainda o conhecimento 1308, neste exemplo rotu-lado com KA. 0 conhecimento 1308 inclui uma lista de identi-ficadores ID de alteração, tais como os descritos acima. Demaneira similar, o duplicador B 1304 inclui um conjunto dealterações 1310, cada qual associada a uma versão que vem aser um ID de alteração. Para se iniciar a duplicação, no mo-mento (1), o duplicador A 1302 envia uma solicitação de sin-cronização de sincronização para o duplicador B 1304 que in-clui o conhecimento 1308. O duplicador B 1304, por meio dacomparação do conhecimento 1308 com as versões associadas acada uma das mudanças no conjunto de alterações 1310, podetomar decisões com relação a quais dentre as alterações 1310do duplicador Β, o duplicador A 1302 já tem em suas altera-ções 1306 e as alterações sobre as quais o duplicador A jáestá ciente. De maneira alternativa, o duplicador B 1304compara o conhecimento 1308 com cada versão do item. Destemodo, o duplicador B 1304 envia para o duplicador A 1302 nomomento (2) apenas a porção das alterações do Duplicador B1310 associada às versões que não estão incluídas no conhe-cimento 1308 do duplicador A 1302, conforme ilustrado pelasalterações 1314. Por exemplo, quando o vetor de conhecimentodo duplicador A é A3B12 e o duplicador B tem as alteraçõescorrentes associadas às versões que são os identificadoresID de alteração B13 e B14, as alterações enviadas para o du-plicador A, neste caso, incluiriam as associadas aos identi-ficadores ID de alteração B13 e B14. Em uma implementação,apenas B14 é enviada quando B13 e B14 são produzidas para omesmo item.

Em adição, o duplicador B 1304 também envia o co-nhecimento do duplicador B 1312 para o duplicador A 1302.Uma vez que o duplicador B1304 envia todas as alterações1310 disponíveis no duplicador B 1304 e não ainda no Dupli-cador A 1302 para o duplicador A 1302, o duplicador A 1302passa a ter naquele momento todas as alterações 1306 que es-tavam originalmente no duplicador A 1302, uma vez que as al-terações 1310 não foram superadas pelas alterações enviadaspelo duplicador B 1304, além das alterações 1310 que estavamoriginalmente no duplicador B 1304. O duplicador A 1302 temainda informações sobre todas as alterações que o duplicadorB 1304 tem ciência. Sendo assim, o duplicador A 1302 podeatualizar o seu conhecimento 1308 de modo a refletir a adi-ção das alterações 1310. Isto é feito simplesmente ao se a-dicionar o conhecimento 1308 do duplicador A ao conhecimento1312 do duplicador B e ao se definir este valor como o co-nhecimento 1308 do duplicador A, tal como mostrado no momen-to (3) da Figura 20.

Assim sendo, uma duplicação eficaz é realizada, naqual apenas as alterações necessárias são duplicadas e naqual os duplicadores individuais que duplicam precisam ape-nas manter as informações relativas às alterações que resi-dem dentro do duplicador em questão e as alterações anterio-res sobre as quais o mesmo tem ciência. Embora este exemplomostre uma duplicação completa de todas as alterações no du-plicador B para o duplicador A, existem casos nos quais ape-nas as porções das alterações são duplicadas. Por conseguin-te, apenas os identificadores ID de alteração que correspon-dem às alterações que são duplicadas são adicionados para oconhecimento do duplicador que recebe atualizações.

Além de enumerar as alterações, o conhecimento deum duplicador pode também ser usado na detecção de confli-tos. Com referência a seguir à Figura 21, uma implementaçãoda presente invenção ilustra como a detecção de conflitospode ser realizada. A Figura 21 mostra dois duplicadores co-nectados por um enlace eletrônico (sem fio e/ou com fio) pa-ra comunicação e duplicação. 0 duplicador A 1402 inclui oconhecimento 1408 e um conjunto de alterações 1406. De acor-do com o exemplo da Figura 20, o conhecimento 1408 incluiuma coleção de identificadores ID de alteração associados àsalterações 1406 e associadas às alterações anteriores. O du-plicador A 1402 inclui ainda, para fins deste exemplo, umaalteração para um item feito no duplicador A 1402. A altera-ção é rotulada com X e X é um elemento das alterações 1406.

De maneira similar, o duplicador B 1404 inclui o conhecimen-to 1412, uma coleção de itens 1410, cada qual com a sua ver-são atual (ID de alteração). De forma ilustrativa, no momen-to (1) , o duplicador A 1402 envia a alteração X para o du-plicador B 1404.

Associados e enviados com a alteração X, há outrosdois valores, quais sejam, o ID de alteração associado à al-teração X, rotulada com ChangeID(X), e um valor feito comconhecimento, rotulado com Ka(X). 0 valor feito com conheci-mento é o conhecimento que existia no duplicador A 1402 nomomento que a alteração X foi feita para o duplicador A1402. De maneira alternativa, em algumas implementações dapresente invenção, o feito com conhecimento pode ser o co-nhecimento que existia em um duplicador quando a alteraçãofoi enviada. O conhecimento em questão do duplicador A 1408pode também ser enviado para o duplicador B 1404. Conformemostrado no momento (2), o duplicador B 1404 compara o itemmodificado pela alteração X com o item modificado pela alte-ração Y de modo a determinar se a alteração (X) de A podeconflitar com o estado de B.

Quando as alterações se referem a diferentes ver-sões do mesmo item, faz-se necessária uma outra análise,neste caso. O duplicador B 1404 verifica, então, se a alte-ração X era conhecida ao duplicador B 1404 quando a altera-ção Y foi feita no duplicador B 1404. A alteração Y tem umID de alteração, ChangeID(Y) e um valor feito com conheci-mento, Kb(Y), associado ao mesmo. Quando ChangeID(X) é umelemento de alteração Y feito com conhecimento, Kb(Y), nãohaverá, então, nenhum conflito. Ou seja, a alteração Y foifeita no duplicador B 1404 com conhecimento da alteração Xfeita no Duplicador A 1402. Assim sendo, a alteração Y re-presenta, agora, os dados mais correntes e válidos para osduplicadores AeB. Embora não mostrado no exemplo ilustradopela Figura 21, em um momento subseqüente, a alteração Y se-rá provavelmente enviada para o duplicador A 1402 e o itemassociado às alterações XeY será atualizado para a altera-ção Y do duplicador A 1402 de maneira descrita na Figura 20.

Quando as alterações XeY são para o mesmo item,e ChangeID(X) não aparece em Kb(Y), neste caso conforme mos-trado no momento (4), é feita uma verificação no sentido dever se a alteração Y era conhecida pelo duplicador A 1402quando a alteração X foi feita. Isto é tipicamente feito aose verificar se a enumeração da alteração para a alteraçãoY, ilustrada como ChangeID(Y), foi incluída no conhecimento1408 do duplicador A no momento que a alteração X foi feita,Ka(X). Quando ChangeID(Y) é um elemento de Ka(X), a altera-ção X é, neste caso, feita com conhecimento da alteração Y enão há conflito. A alteração X é a alteração mais corrente eválida para o item em particular. Como tal, o duplicador B1404 provavelmente será atualizado com a alteração X da ma-neira conforme descrita na Figura 20.

Quando as alterações XeY são para o mesmo item,o ChangeID(Y) não aparece em Ka(X), e ChangeID(X) não apare-ce em Kb(Y), e, neste caso, haverá um verdadeiro conflito.

Ou seja, a alteração Xea alteração Y foram feitas indepen-dentes entre si. Neste caso, um conflito será registrado evárias regras de resolução de conflito poderão ser aplicadasno sentido de determinar qual alteração, X ou Y, será a al-teração mais corrente e válida. Tais regras podem incluir averificação dos carimbos de hora a fim de determinar que al-teração foi feita mais recentemente, sempre resolvendo osconflitos em favor de um determinado tipo de duplicadores(tais como os armazenados nos servidores) e/ou qualquer ou-tra resolução de conflito adequada. De maneira alternativa,em uma forma de resolução de conflito, um item com altera-ções de conflito pode ser atualizado de tal modo que as al-terações de conflito se unam de modo a formar uma nova alte-ração.

Com referência, a seguir, à Figura 222, uma imple-mentação exemplar dos identificadores ID de Alteração e domonitoramento do conhecimento é mostrada. A Figura 22 mostraum duplicador 1502. 0 duplicador 1502 inclui uma coleção dealterações 1506 e de conhecimento 1508. A coleção de altera-ções 1506 inclui diversas alterações individuais 1510 nesteexemplo ilustrado como X, Y e Z. No exemplo mostrado na Fi-gura 22, o presente estado do conhecimento do duplicador éindicado por um vetor de conhecimento 1512, que, neste caso,é A4. 0 vetor de conhecimento 1512 representa todo o conhe-cimento 1508 do duplicador A.

Ainda representado na Figura 22 encontram-se vá-rios identificadores ID de alteração 1514. No exemplo da Fi-gura 22, o duplicador A 1502 inclui três itens modificados1516, Ix, Iy, e Iz, correspondentes às alterações 1510. Ao seusar os identificadores ID de alteração, pode-se discernirque o item Ix, com o ID de alteração Al, foi feito no dupli-cador A 1502 pela primeira vez. 0 Iy de alteração com o IDde alteração A2, foi feito no duplicador A 1502, em um mo-mento subseqüente ao item Ix. E o item Iz, com o ID de alte-ração A4, foi feito no duplicador A 1502 em um momento sub-seqüente a quando o item Iy foi feito. A3, embora não ilus-trado diretamente na Figura 22, pode corresponder a uma al-teração anterior, tal como em um exemplo, a uma alteraçãoque é seguida pela alteração ao item Iz rotulado como A4.

Existe uma diferença entre o ID de alteração A4 eo vetor de conhecimento do duplicador A que é também rotula-do como A4. Neste exemplo, o vetor de conhecimento A4 signi-fica que o conhecimento 1508 do duplicador A inclui as alte-rações correspondentes aos identificadores ID de alteraçãorotulados como A4, A3, A2 e Al. Dito de outra maneira, umvetor de conhecimento inclui a alteração representada peloID de alteração 1518, que é igual ao vetor de conhecimento,assim como todas as alterações com o mesmo ID de duplicadorque foram feitas antes ao ID de alteração 1518, representadono vetor de conhecimento. Por outro lado, no presente exem-plo, o ID de alteração 1518 rotulado como A4 representa ape-nas a alteração Z feita no item Iz.

Com referência, a seguir, à Figura 23, é mostradoum exemplo de dois duplicadores que se duplicam em uma topo-logia contendo diversos duplicadores. 0 duplicador A 1602contém um conjunto de alterações 1604, o conhecimento 1606 eum vetor de conhecimento 1608, que vem a ser uma representa-ção taquigráfica do conhecimento 1606. De forma ilustrativa,o vetor de conhecimento 1608 do duplicador A 1602,A5B3C1D10, mostra que o conhecimento 1606 do duplicador Ainclui as modificações feitas até uma quinta alteração noduplicador A 1602, no conhecimento até uma terceira altera-ção em um duplicador B 1610, no conhecimento até uma quintaalteração em um duplicador C e no conhecimento até uma déci-ma alteração em um duplicador D. O duplicador B 1610, no e-xemplo da Figura 23, inclui um conjunto de alterações 1612,o conhecimento 1614, e um vetor de conhecimento 1616 que vema ser uma representação taquigráfica do conhecimento 1614 doduplicador Β. O vetor de conhecimento 1616 do duplicador B,A3B3C5D8, ilustra que o duplicador B tem o conhecimento in-cluindo o conhecimento até uma terceira alteração feita peloduplicador A 1602, o conhecimento até uma terceira alteraçãofeita pelo duplicador B 1610, o conhecimento até uma quintaalteração feita pelo duplicador Ceo conhecimento até umaoitava alteração feita pelo duplicador D. Os vetores de co-nhecimento apresentados acima incluem uma representação con-tinua das enumerações de alteração feitas por um duplicadora partir de uma primeira alteração a alguma alteração subse-qüente. Como será explicado em mais detalhe aqui mais adian-te, um vetor de conhecimento pode incluir ainda um ponto deiniciação que vem a ser uma outra enumeração de alteraçãodiferente da primeira enumeração de alteração feita por umduplicador.

Uma ilustração com relação ao momento da duplica-ção do duplicador A 1602 com o duplicador B 1610 é mostradana Figura 23. No momento (1), o duplicador A 1602 envia umasolicitação de sincronização 1618 juntamente com o conheci-mento 1606 do duplicador A, que pode ser representado pelovetor de conhecimento 1608 do duplicador A, para o duplica-dor B 1610.

O duplicador B 1610 no momento (2) examina o co-nhecimento 1606 do duplicador A comparando o mesmo com osidentificadores ID de alteração associados às alterações doDuplicador Β. 0 duplicador B 1610 descobre que o duplicadorA não está ciente das alterações feitas pelo duplicador C,rotuladas com os identificadores ID de alteração C2, C3, C4e C5. Sendo assim, o duplicador B envia as alterações 1612do duplicador B correspondentes às dos identificadores ID dealteração contanto que as alterações rotuladas com os iden-tificadores ID de alteração sejam as alterações correntesaplicáveis aos itens do Duplicador B 1610. Quando um ID dealteração corresponde a uma alteração desatualizada anteri-or, nenhuma alteração correspondente àquele ID será enviada.Por exemplo, quando um item que teve uma versão C3 foi atua-lizado e atribuído uma nova versão, a alteração associada àC3 não mais existirá no duplicador B 1610 e não será enviadapara o duplicador A. Em seguida ou simultaneamente, conformeilustrado no momento (3) , o duplicador B 1610 envia para oduplicador A 1602 o conhecimento do duplicador B 1614, quepode ser representado como o vetor de conhecimento 1616.

No momento (4), o duplicador A 1602 examina o co-nhecimento 1614 enviado pelo duplicador B, comparando o mes-mo com o do ID de alteração correspondente às alterações noduplicador A 1602. O duplicador A 1602 descobre que o dupli-cador B não tem as alterações representadas pelos identifi-cadores ID de alteração A4, A5, D9 e D10, como também nãotem o conhecimento sobre estas alterações. Deste modo, o du-plicador A 1602 envia todas as alterações correntes existen-tes nas alterações 1604 do duplicador A correspondentes àsdos identificadores ID de alteração (exceto quando i ID dealteração representa uma alteração desatualizada de tal modoque nenhuma alteração seja enviada). O duplicador A 1602 po-de, em seguida, enviar uma mensagem para o duplicador B 1610indicando que todas as alterações foram enviadas de tal for-ma que o duplicador A 1602 e o duplicador B 1610 possam ago-ra atualizar seus vetores de conhecimento 1608 e 1616, res-pectivamente, de modo a incluir as alterações recentementeduplicadas. Conforme mostrado na Figura 23, no momento (5),o vetor de conhecimento do duplicador A, A5B3C5D10, é igualao vetor de conhecimento do duplicador B, que inclui todasas alterações feitas pelo duplicador A até uma quinta enume-ração de alteração, todas as alterações sendo feitas peloduplicador C até uma quinta enumeração de alteração e todasas alterações sendo feitas pelo duplicador D até uma décimaenumeração de alteração.

Com referência, a seguir, às Figuras 24A e 24B,são mostrados dois métodos de atualização dos vetores de co-nhecimento seguido de uma duplicação completa, tal como arepresentada na Figura 23. Em termos específicos, a Figura24A ilustra um método para atualização dos vetores de conhe-cimento usando uma lista de exceções 1702 armazenada em umduplicador. Para criar a lista de exceções 1702, uma vez queas alterações são enviadas entre duplicadores, as alteraçõessão enviadas com um ID de alteração associado à alteração.

Quando a alteração é adicionada a um duplicador, o ID de al-teração é adicionado como uma exceção a uma lista de exce-ções 1702. Ao se examinar agora o conhecimento para o dupli-cador A na Figura 24A, o conhecimento inclui um vetor de co-nhecimento 1608 e uma lista de exceções 1702 que inclui asexceções C2, C3, C4 e C5. Um exame da lista de exceções 1702em conjunto com o vetor de conhecimento 1608 revela que aose incluir os identificadores ID de alteração da lista deexceções 1702, o conhecimento do Duplicador A inclui todasas alterações até uma quinta alteração feita pelo duplicadorC. Sendo assim, as exceções podem ser removidas do conheci-mento do Duplicador A 1602 e o vetor de conhecimento atuali-zado de modo a incluir um elemento C5, conforme mostrado novetor de conhecimento atualizado 1704. Uma análise similarpode ser feita sobre o conhecimento 1614 do duplicador B1610. O vetor de conhecimento original 1616 combinado com asexceções A4, A5, D9 e DlO da lista de exceções 1703 permiteque o vetor de conhecimento 1616 seja atualizado para um ve-tor de conhecimento atualizado 1706.

Notavelmente, quando apenas uma duplicação parcialé realizada, tal como, por exemplo, quando as alteraçõescorrespondentes aos identificadores ID de alteração Ά4 e D9não são enviadas em uma duplicação, tal como a representadapela Figura 23, o conhecimento 1614 do duplicador B 1610,neste caso, precisaria manter as exceções A5 e DlO até umaduplicação subseqüente com um outro duplicador que transfereas alterações representadas pelos identificadores ID de al-teração A4 e D9 para o duplicador B 1610.

A Figura 24B ilustra um outro método de atualiza-ção dos vetores de conhecimento 1608 e 1616 de modo a refle-tir a duplicação mostrada na Figura 23. Neste exemplo, osvetores de conhecimento são atualizados usando um elementomáximo para cada um dos elementos dos vetores de conhecimen-to originais 1608 e 1616 de modo a formar um vetor de conhe-cimento atualizado 1708.

O primeiro elemento de cada um dosvetores de conhecimento 1608 e 1616 corresponde a um conjun-to de identificadores ID de alteração que rotulam as mudan-ças feitas no duplicador A. uma vez que A5 é o elemento má-ximo com relação aos elementos dos dois vetores de conheci-mento 1608 e 1616, o vetor de conhecimento atualizado 1708inclui um elemento A5. Da mesma forma, os elementos de vetorB3, C5 e DlO representam, cada um deles, um elemento máximo,com relação aos elementos, correspondente às alterações nosduplicadores particulares aos quais cada um dos elementoscorrespondem. 0 exame de cada um dos vetores de conhecimentoatualizados 1704, 1706 e 1708 revela que, por meio de qual-quer um dos métodos, o mesmo vetor de conhecimento atualiza-do é obtido. O método de elemento máximo da atualização devetor de conhecimento é tipicamente usado quando uma dupli-cação completa é feita, enquanto um método de lista de exce-ções de atualização do vetor de conhecimento pode ser útilquando não se tem certeza que uma duplicação completa ocor-reu (um usuário pode cancelar a duplicação, um dispositivopode dar pau, etc.). Ou seja, o método de lista de exceçõespode precisar ser usado de tal modo que as exceções possamcontinuar a compreender uma porção do conhecimento de um du-plicador em particular quando o conhecimento total do dupli-cador não pode ser representado na forma de um vetor sim-ples.

Com referência, a seguir, à Figura 24C, um exemplode atualização de conhecimento é mostrado para um duplicadorque tem informação a partir de uma duplicação incompleta. AFigura 24C inclui um vetor de conhecimento original 1710,uma lista de exceções original 1712, um vetor de conhecimen-to atualizado 1714, e uma lista de exceções atualizada 1716.Com relação ao duplicador mostrado, depois de uma duplicaçãoparcial, o duplicador tem todos os identificadores ID de al-teração rotulados como Al a A5, representados pelo elementode vetor A5, e todos os demais identificadores ID de altera-ção rotulados com A7 a AlO representados pela lista de exce-ções incluindo A7, A8, A9 e AlO. Conforme mostrado na Figura24C, em uma versão atualizada do conhecimento, a lista deexceções atualizada 1716 pode ser encurtada de modo a indi-car a inclusão de todos os elementos de A7 a A10, tal comopela expressão (A7:A10) mostrada na Figura 24C. Esta expres-são é simplesmente um vetor tal como aqueles previamente a-qui apresentados, exceto que o ponto de iniciação do vetor éoutro ponto diferente da primeira enumeração de alteraçãopara o duplicador A. Sendo assim, a representação do conhe-cimento do duplicador, quando o mesmo se refere à A, é feitapelo elemento de vetor A5 e pelo vetor de exceção (A7:A10).

No caso do conhecimento do duplicador relativo aoduplicador Β, o vetor de conhecimento 1710 pode ser atuali-zado de modo a incluir os identificadores ID de alteraçãocontínuos, subseqüentes aos identificadores ID de alteraçãoincluídos no elemento de vetor para o duplicador Β. 0 ele-mento de vetor Bl inclui apenas o ID de alteração Bi. Umavez que os identificadores de alteração B2, B3 e B4 existemna lista de exceções 1712, e que os mesmos são contínuos aoID de alteração Bl incluído no vetor de conhecimento 1710, oelemento de vetor para o duplicador B pode ser atualizadopara B4 no vetor de conhecimento atualizado 1714, que repre-senta a inclusão dos elementos Bl a BA. Uma vez que o ID dealteração B5 não consta da lista de exceções, a exceção B6deve permanecer na lista de exceções 1716 no conhecimentoatualizado.

Uma análise similar pode ser feita com relação aoconhecimento do duplicador da Figura 24C quanto às altera-ções feitas pelo duplicador C. 0 vetor de conhecimento ori-ginal 1710 inclui C5. A lista de exceções original incluiC6, Cl e C8. Uma vez que o elemento de vetor de conhecimentooriginal C5 inclui os identificadores ID de alteração Cl aC5, e que C5 é continuo com os identificadores ID de altera-ção da lista de exceções original 1712, o elemento de vetorde conhecimento atualizado para o duplicador C pode ser atu-alizado para C8.

Um desafio que pode surgir com relação ao tamanhodos vetores de conhecimento é especialmente prevalecentequando o número de duplicadores em uma comunidade de sincro-nização é grande. Em uma topologia na qual o vetor de conhe-cimento inclui um.ID de alteração ou outro elemento de vetorpara cada e todo duplicador dentro da comunidade de sincro-nização, o vetor de conhecimento aumenta com cada duplicadorque é adicionado à comunidade de sincronização. Uma otimiza-ção é reconhecer se em algumas comunidades de sincronização,nem'todo duplicador precisa ser representado no vetor de co-nhecimento.

Uma ilustração de tal caso é a comunidade desincronização mostrada na Figura 25, que representa uma to-pologia de servidor de hub e spoke. A Figura 25 mostra umservidor 1802 conectado a um número de clientes, incluindo oduplicador A 1804, o duplicador B 1806, o duplicador C 1808e o duplicador D 1810. Neste exemplo, todos os percursos deduplicação 1812 a 1818 entre os clientes são através do ser-vidor 1802 e, deste modo, o servidor 1802 pode atribuir umID de alteração que inclua o servidor 1802 como o ID de du-plicador. Todas as alterações feitas dentro dos clientes in-dividuais 1804 a 1810 permanecem dentro do respectivo clien-te no qual a alteração foi feita sem a atribuição de um IDde alteração até que uma duplicação seja feita. Sendo assim,neste exemplo, o vetor de conhecimento inclui um único ele-mento que compreende o ID de duplicador e o ID de alteraçãodo servidor 1802. De forma ilustrativa, quando uma alteraçãoé feita no duplicador A 1804 e reduplicada com o servidor1802 em um primeiro momento, o servidor 1802 atribui uma e-numeração de alteração de Sl para a alteração. Em um momentosubseqüente, uma alteração feita no duplicador B 1806 é re-duplicada com o servidor 1802. A esta alteração, é atribuídauma enumeração pelo servidor de S2. Notavelmente, enquantoneste exemplo, o servidor 1802 atribui todas as enumeraçõesde alteração, podem existir outras implementações nas quaiso servidor 1802 atribui algumas enumerações de alteração eoutros duplicadores atribuem outras enumerações de altera-ção.

As implementações da presente invenção são adaptá-veis no sentido de otimizar o vetor de conhecimento tambémem outras topologias. Por exemplo, na Figura 18, o duplica-dor D 1114 só duplica com o duplicador C 1110. Desta manei-ra, as alterações feitas por CeD podem ser enumeradas u-sando-se as enumerações de alteração que têm um único ID deduplicador. Em um exemplo, quando o ID de duplicador do du-plicador C é escolhido para fazer parte da enumeração de al-teração para todas as alterações por parte do duplicador C1110 ou do duplicador D 1114, uma primeira alteração no du-plicador C seria rotulada com a enumeração de alteração Cl.Uma alteração subseqüente no duplicador D 1114 é rotuladacom C2, e assim por diante. Quando um duplicador cria um IDde alteração para as alterações feitas em um duplicador di-ferente, o duplicador que cria o ID de alteração poderá serreferido como um autor substituto.

Ao se otimizar o vetor de conhecimento para umatopologia particular ou comunidade de sincronização, os re-cursos utilizados para armazenar o vetor de conhecimento po-dem ser conservados nas topologias que se aproximam das to-pologias de servidor - cliente hub e spoke, tais como a mos-trada na Figura 25.

Nas topologias mais parecidas com as dasredes não hierárquicas, um vetor de conhecimento maior tor-na-se necessário, mas os duplicadores individuais podem, deuma maneira efetiva e independente, se duplicar em um númeromaior de outros duplicadores, e ao mesmo tempo evitar pro-blemas, como, por exemplo, laços de sincronização, falsosconflitos, ou coisa do gênero.

Quando diferentes duplicadores são habilitados afazer mudanças nos itens, independentes uns dos outros, po-derão surgir conflitos entre as alterações feitas de maneiraindependente e devem ser resolvidos. A resolução de confli-tos tipicamente requer que haja certas regras para a deter-minação de qual versão de item deve ser escolhida como o i-tem válido. Exemplos de algumas dessas regras incluem a se-leção da alteração de item que foi feita por último ou a se-leção das alterações de item que foram feitas por tipos es-pecíficos de duplicadores, como, por exemplo, as alteraçõespreferidas feitas pelos servidores sobre as alterações fei-tas por outros tipos de duplicadores. De maneira alternati-va, todos os conflitos devem ser registrados para uma reso-lução manual. A resolução manual é feita por um usuário queprovê um novo valor ao item em conflito, que substituirá asalterações em conflito.

Quando todos os duplicadores dentro de uma comuni-dade de sincronização ou topologia resolvem os conflitos damesma maneira, nenhuma outra regra de resolução ou sistemade resolução se torna tipicamente necessária, uma vez quetodos os duplicadores dentro do sistema migrarão para umaresolução duplicada de qualquer conflito. Embora os duplica-dores dentro da comunidade de sincronização não possam serespecificamente concebidos de modo a resolver os conflitosexatamente da mesma maneira, os duplicadores dentro de umacomunidade de sincronização poderão, por outro lado, resol-ver os conflitos exatamente da mesma maneira. Tal exemplo émostrado na Figura 26A. A Figura 26A mostra um duplicador D1902. 0 duplicador D 1902 recebe um ID de alteração corres-pondente a uma alteração em um item Ix, no qual o ID de al-teração é A4. Em seguida, o duplicador D 1902 recebe um IDde alteração para o mesmo item Ix, no qual o ID de alteraçãoé B5. 0 duplicador D 1902 tem regras de resolução de confli-to a escolher, dentre as quais a alteração para o item Ix éa alteração preferida. Neste caso, o duplicador D escolhe aalteração para o item Ix rotulado pelo ID de alteração A4.Para indicar que o conflito foi resolvido pelo duplicador D1902 e como o conflito foi resolvido, um novo ID de altera-ção é atribuído ao item IX que inclui tanto os resultados daresolução do conflito, como também um novo ID de alteraçãoatribuído pelo duplicador em questão que concretizou a reso-lução do conflito. 0 novo ID de alteração inclui a próximaenumeração de alteração seqüencial para o duplicador que re-alizou a resolução do conflito. Neste caso, o novo ID de al-teração é rotulado com A4 (D7) a fim de indicar que a alte-ração rotulada com A4 foi a escolhida na resolução do con-flito e que o conflito foi resolvido pelo duplicador D 1902.

Conforme mostrado na Figura 26A, um processo similar aconte-ce quando um conflito nas alterações é detectado por um du-plicador C 1904. O duplicador C 1904 resolve o conflito damesma maneira que o duplicador 1902. Deste modo, um novo IDde alteração rotulado com A4 (C3) é atribuído à alteração doitem Ix. Neste caso, o conflito entre as alterações para oitem Ix rotulado com os identificadores ID de alteração A4 eB5 serão eventualmente resolvidos da mesma maneira em todosos duplicadores dentro da topologia.

A Figura 2 6B ilustra um exemplo no qual os confli-tos são resolvidos diferentemente por diferentes duplicado-res dentro de uma topologia. Na Figura 2 6B, no momento (1) ,o duplicador D1902 resolve o conflito de uma maneira e atri-bui um novo ID de alteração para os itens que ilustram a re-solução do conflito, B5, e o duplicador que fez a alteração,(D7). No momento (2), o duplicador C 1904 resolve o mesmoconflito de uma maneira diferente, mostrada pelo novo ID dealteração, por meio do duplicador C 1904, A4 (C3). No momen-to (3), o duplicador D 1902 recebe a resolução do conflitodo duplicador C. O duplicador D 1902, neste momento, reco-nhece que este conflito em particular foi resolvido de duasmaneiras diferentes. Algumas implementações da presente in-venção, portanto, especificam que uma resolução determinís-tica seja feita entre as alterações de conflito para o itemIx. A resolução deterministica em particular ilustrada pelaFigura 26B faz com que a alteração com o ID de duplicador devalor mais baixo seja selecionada como o resultado determi-nistico. Sendo assim, uma vez que A tem um ID de duplicadorde valor menor que o duplicador B, a resolução deterministi-ca do conflito é selecionada para ser a alteração rotuladapelo ID de alteração A4. 0 duplicador D 1902, deste modo,altera o ID de alteração associado à alteração para o item Ipara ser A4 (D7). Observa-se que, para evitar laços de du-plicação ou outros problemas de conflito, a enumeração dealteração (isto é, D7) associada ao duplicador que faz a al-teração é igual no resultado deterministico 1906, como naresolução original do conflito 1908.

Embora a matéria da presente invenção tenha sidodescrita em uma linguagem especifica aos aspectos estrutu-rais e/ou aos atos metodológicos, deve-se entender que a ma-téria definida nas reivindicações em apenso não é necessari-amente limitada aos aspectos ou atos específicos descritosacima. Em contrapartida, os aspectos e atos específicos des-critos acima são apresentados como formas exemplares de seimplementar as reivindicações. Deseja-se, portanto, que to-dos os equivalentes, mudanças, e modificações que cheguem aoespírito das implementações conforme descritas no presentedocumento e/ou pelas reivindicações a seguir sejam protegidos.Por exemplo, uma pessoa com habilidade simples natécnica de software de computadores reconhecerá que as dis-posições de cliente e/ou servidor, o conteúdo de video deinterface com o usuário, e/ou os layouts de dados conformedescritos nos exemplos aqui apresentados podem ser organiza-dos de forma diferente em um ou mais computadores de modo aincluir menos opções ou outras opções ou recursos que as re-tratadas nos exemplos.

Claims (20)

1. Método para a sincronização de dados,CARACTERIZADO pelo fato de compreender as etapas de:- prover um participante parcial, o participanteparcial tendo um armazenador de dados e um armazenador deconhecimento, o armazenador de dados sendo operável de modoa armazenar um conjunto de dados recuperados durante um pro-cesso de sincronização com um primeiro participante cheio, oarmazenador de conhecimento sendo operável de modo a armaze-nar um conjunto de conhecimentos nos dados do armazenador dedados, em que o conjunto de conhecimentos representa as al-terações nos dados que o primeiro participante cheio tem ci-ência (282), em que o participante parcial não entende oconjunto de conhecimentos (284), e em que o participanteparcial é responsável pelo monitoramento das alterações oparticipante parcial faz no conjunto de dados do armazenadorde dados (290);- receber uma solicitação de um usuário do parti-cipante parcial no sentido de alterar um registro em parti-cular no conjunto de dados do armazenador de dados (286); e- atualizar o registro em particular no armazena-dor de dados após o recebimento da solicitação do usuário(288), em que a atualização inclui o armazenamento de infor-mações que identifica a origem da alteração como o partici-pante parcial (290).

2. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que o participante parcial é ope-rável de modo a se sincronizar com um segundo participantecheio (66).

3. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que o participante parcial é sin-cronizado com o primeiro participante cheio através de umtratador (handler) do primeiro participante cheio (66).

4. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que o primeiro participante cheioé um computador pessoal.

5. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que o primeiro participante cheioé um dispositivo móvel.

6. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que o participante parcial é umdispositivo móvel.

7. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que o participante parcial é umserviço da rede mundial (web) (282).

8. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que a informação que identifica aorigem da alteração é uma versão.

9. Método, de acordo com a reivindicação 8,CARACTERIZADO pelo fato de que uma primeira porção da versãoinclui um identificador que identifica exclusivamente o par-ticipante parcial e pelo fato de que uma segunda porção daversão inclui um número que indica uma versão de registro(304).

10. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que a informação que identifica aorigem da alteração é um identificador único para o regis-tro, e identificador de data e hora de modo a indicar quandoo registro mudou (314).

11. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de compreender ainda a etapa de:- receber um conjunto atualizado de conhecimentosdo primeiro participante cheio depois que o primeiro parti-cipante cheio atualiza o conjunto de conhecimentos após oprocesso de sincronização (296).

12. Meio legível em computador, CARACTERIZADO pelofato de que ter instruções executáveis em computador de modoa fazer com que um computador execute as etapas apresentadasde acordo com a reivindicação 1.

13. Meio legível em computador, CARACTERIZADO pelofato de ter instruções executáveis em computador de modo afazer com que um computador execute etapas que compreendem:- o recebimento de uma solicitação de um partici-pante no sentido de realizar uma operação de sincronizaçãoutilizando um mecanismo de sincronização (244);- a determinação de um tipo para o participante, otipo sendo selecionados a partir do grupo constituído de umtipo de participante cheio, um tipo de participante parcial,ou um tipo de participante simples (246);- em que o participante é determinado para ser otipo de participante simples quando tem um armazenador dedados de participante simples e nenhum conhecimento (248);- em que o participante é determinado para ser otipo de participante parcial quando tem um armazenador dedados de participante parcial e conhecimento armazenado, po-rém não entendido (250);- em que o participante é determinado para ser otipo de participante cheio quando tem um armazenador de da-dos de participante cheio e conhecimento armazenado e enten-dido (252); e- em que o mecanismo de sincronização executa aoperação de sincronização com o participante utilizando umconjunto de lógica apropriada para o tipo de participante(256).

14. Meio legível em computador, de acordo com areivindicação 13, CARACTERIZADO pelo fato de que, quando otipo para o participante é determinado para ser o tipo departicipante simples, o mecanismo de sincronização, nestecaso, é operável de modo a sincronizar um conjunto de dadosno armazenador de dados de participante simples por meio dadetecção de alterações no conjunto de dados do armazenadorde dados de participante simples, e do armazenamento dequaisquer conflitos em um armazenador de dados local (254).

15. Meio legível em computador, de acordo com areivindicação 13, CARACTERIZADO pelo fato de que, iquando otipo para o participante é determinado para ser o tipo par-ticipante parcial, o mecanismo de sincronização, neste caso,recebe o conhecimento armazenado, mas não entendido do par-ticipante (258) e atualiza o conhecimento armazenado, masnão entendido no participante, quando ocorrem exceções(260).

16. Meio legível em computador, de acordo com areivindicação 15, CARACTERIZADO pelo fato de que o mecanismode sincronização atualiza o conhecimento armazenado, mas nãoentendido no participante ao modificar uma cópia local e, emseguida, transferindo a cópia local para o participante(262).

17. Meio legível em computador, de acordo com areivindicação 13, CARACTERIZADO pelo fato de que, quando otipo para o participante é determinado para ser o partici-pante parcial tipo, o participante é, neste caso, operávelde modo a participar em uma operação de sincronização bidi-recional multi-mestre, em função do conhecimento armazenado,mas não entendido no participante (264).

18. Meio legível em computador, de acordo com areivindicação 13, CARACTERIZADO pelo fato de que o mecanismode sincronização recebe uma solicitação do participante nosentido de registrar um tratador para a operação de sincro-nização (244).

19. Método para a sincronização de dados,CARACTERIZADO pelo fato de compreender as etapas de:- prover um participante simples, o participantesimples tendo um armazenador de dados e um armazenador semconhecimento, o armazenador de dados sendo operável de modoa armazenar um conjunto de dados providos durante um proces-so de sincronização com um participante cheio, e pelo fatode que o participante simples não é responsável pelo monito-ramento das alterações que o participante simples faz noconjunto de dados do armazenador de dados (424);- receber uma solicitação de um usuário do parti-cipante simples no sentido de alterar um registro em parti-cular no conjunto de dados do armazenador de dados (428); e- atualizar o registro em particular no armazena-dor de dados após o recebimento da solicitação do usuário(430).

20. Meio legível em computador, CARACTERIZADO pelofato de ter instruções executáveis em computador de modo afazer com que um computador execute as etapas de acordo coma reivindicação 19.