BRPI0710719A2

BRPI0710719A2 - método para deletar um item de uma conta de usuário em um ambiente multimìdea sip; produto de programa de computador e dispositivo eletrÈnico

Info

Publication number: BRPI0710719A2
Application number: BRPI0710719-6A
Authority: BR
Inventors: Adamu Haruna; Arto Leppisaari
Original assignee: Nokia Corp
Priority date: 2006-04-03
Filing date: 2007-04-03
Publication date: 2012-02-28
Also published as: AU2007232195B2; US20070233682A1; CA2661954C; ZA200809301B; EP2008425A2; JP2009532795A; JP4775490B2; RU2404549C2; BRPI0710719B1; EP2008425A4; WO2007113770A2; AU2007232195A1; KR20090006154A; MX2008012811A; RU2008140278A; CN101455050A; US7805490B2; WO2007113770A3; KR100977188B1; EP2008425B1

Abstract

MéTODO PARA DETELAR UM ITEM DE UMA CONTA DE USUáRIO EM UM AMBIENTE MULTIMìDIA SIP; PRODUTO DE PROGRAMA DE COMPUTADOR E DISPOSITIVO ELETRÈNICO. Trata-se de um método para deletar um item de uma conta de usuário em um ambiente multimídia SIP. Quando um item, tal como uma mensagem instantânea, é para ser deletado, uma mensagem SIP REFER é transmitida de um dispositivo de usuário para deletar o item da conta de usuário, com a mensagem incluindo um identificador único para o item. Em resposta ao pedido transmitido, uma seção SIP INVITE é estabelecida entre um agente virtual e uma localização de itens deletados com base em rede. Após a seção SIP INVITE ser estabelecida, o item é transferido da conta de usuário para a localização de itens deletados com base em rede e é deletado da conta de usuário.

Description

"MÉTODO PARA DELETAR UM ITEM DE UMA CONTA DE USUÁRIO EM UM AMBIENTE MULTIMÍ DIA SIP; PRODUTO DE PROGRAMA DE COMPUTADOR E DISPOSITIVO ELETRÔNICO"

CAMPO DA INVENÇÃO

A presente invenção refere-se, em geral, a serviços de protocolo de iniciação de sessão (SIP) e serviços SIP para mensagens instantâneas e extensões de aproveitamento de presença (SIMPLE). Mais particularmente, a presente invenção se refere a serviços baseados em SIP/SIMPLE, como mensageiros instantâneos (IM) e serviços de pressione-para-falar (PoC).

FUNDAMENTOS DA INVENÇÃO

Esta seção é destinada a oferecer um fundamento ou contexto à invenção que seja citado nas reivindicações. A descrição pode incluir conceitos que poderiam ser seguidos, porém, não necessariamente os que foram concebidos ou seguidos anteriormente. Portanto, exceto onde indicado em contrário, o que se descreve nesta seção não pertence à técnica anterior da descrição e das reivindicações neste pedido e não se admite que pertença a técnica anterior mediante a inclusão desta seção.

A Aliança Móvel Aberta (OMA) é uma organização de padrões que desenvolve, coletivamente, padrões abertos destinos ao uso na indústria móvel. A OMA ajuda a criar possibilitadores de serviços interoperáveis para trabalharem pelos países, operadores e terminais móveise é guiada pelas exigências do mercado. Com a finalidade de expandir o mercado móvel, as companhias que suportam a Aliança Móvel Aberta trabalham para auxiliar no rápido e amplo desenvolvimento e desdobramento de uma variedade de novos serviços aprimorados de comunicação e entretenimento de informações móveis.

Atualmente, a OMA está desenvolvendo os serviços IM com base no SIP, Protocolo de Restabelecimento de Sessão de Mensagem (MSRP) e no Protocolo de Acesso de Configuração (XCAP) de Linguagem de Marcação Extensível (XML) desenvolvidos pelo grupo de trabalho SIMPLE da Força-Tarefa de Engenharia Internacional (IETF). Os serviços de Mensageiro Instantâneo já são implementados utilizando-se diversas tecnologias proprietár ias e especificações Wireless Village. Atualmente, há uma necessidade por um Mecanismo de deletação no ambiente de serviço multimídia SIP. Em um ambiente http, se houver necessidade de deletar um documento, um comando "deletar http" é simplesmente emitido. No entanto, atualmente, não existem características ou funções de deletação correspondentes para o ambiente SIP. De fato, mesmo as extensões SIP para serviços não apresentam tais características definidas. Nos serviços multimídia atuais, particularmente OMA SIP/SIMPLE IM, existem diversas exigências acerca do armazenamento e recuperação de mensagens. Embora haja uma necessidade por deletar e seletivamente deletar mensagens armazenadas, esse mecanismo ainda precisa ser definido.

SUMÁRIO DA INVENÇÃO

A presente invenção compreende um mecanismo de deletação inusitado para uso em serviços multimídia SIP. A presente invenção envolve o uso de vária s características de ambiente de serviço multimídia SIP destinadas para este propósio. Em uma modalidade, define-se uma "lixeira " na rede e a mesma é associada a um identificador de recurso uniforme SIP. As mensagens que ficam armazenadas na rede são atribuídas a um identificador exclusivo. Se um usuário desejar deletar a mensagem, ele ou ela solicita que uma função SIP/MSRP seja estabelecida entre a mensagem e a lixeira definida pela rede. Uma vez processada, a mensagem é transferida para a lixeira, deixando a conta do usuário no servidor de armazenam ento de correio do usuário.

O sistema e o método da presente invenção é simples é fácil de se adotar, já que se utilizam ferramentas definidas já existentes, como o método SIP REFER, Agente Usuário Vir tual e SIP URI.

Estas e outras vantagens e características da invenção, junto à organização e forma de operação da mesma, tornar-se-ão aparentes a partir da descrição detalhada a seguir quando tomada em conjunto com os desenhos em anexo, em que os elementos semelhantes têm referencias numéricas semelhantes ao longo dos diversos desenhos descritos abaixo.

BREVE DESCRIÇÃO DOS DESENHOS

A Figura 1 é um fluxograma que mostra a operação de um mecanismo de deletação para serviços multimídia SIP de acordo com uma modalidade da presente invenção;

A Figura 2 é um fluxograma que mostra a operação de um mecanismo de deletação para serviços multimídia SIP que serve para deletar uma mensagem selecionada de acordo com outra modalidade da presente invenção;

A Figura 3 é um fluxograma que mostra a operação de um mecanismo de deletação para serviços multimídia SIP que serve para deletar uma mensagem selecionada ainda de acordo com outra modalidade da presente invenção;

A Figura 4 é um fluxograma que mostra a operação de um mecanismo de deletação para serviços multimídia SIP que serve para deletar múltiplas mensagens selecionadas de acordo com uma modalidade da presente invenção;

A Figura 5 é um fluxograma que mostra a operação de um mecanismo de deletação para serviços multimídia SIP que serve para deletar múltiplas mensagens selecionadas de acordo com uma modalidade da presente invenção;

A Figura 6 é um fluxograma que mostra a operação de um mecanismo de deletação para serviços multimídia SIP que serve para deletar múltiplas mensagens selecionadas de acordo com uma modalidade da presente invenção;

A Figura 7 é um fluxograma que mostra a operação de um mecanismo de deletação para serviços multimídia SIP que serve para deletar todas as mensagens em uma conta de armazenamento de correio do usuár io de acordo com uma modalidade da presente invenção;

Figura 8 é um diagrama global de um sistema no qual a presente invenção pode ser implementada;

A Figura 9 é uma vista em perspectiva de um telefone móvel que pode ser usado na implementação da presente invenção;

A Figura 10 é uma representação esquemática do circuito elétrico telefônico do telefone móvel da Figura 9;

DESCRIÇÃO DETALHADA DAS MODALIDADES PREFERENCIAIS

A presente invenção compreende um mecanismo de deletação inusitado para uso em serviços multimídia SIP. A presente invenção envolve o uso de vária s características de ambiente de serviço multimídia SIP para este propósito. Em uma modalidade, define-se uma "lixeira" ou local similar destinado a itens deletados na rede e é associada a um identificador de recurso uniforme SIP. As mensagens que devem ser armazenadas na rede são atribuídas a um identificador exclusivo. Se um usuário desejar deletar a mensagem, ele ou ela solicita que uma função SIP/MSRP seja estabelecida entre a mensagem e a lixeira definida pela rede. Uma vez processada, a mensagem é transferida para a lixeira, deixando a conta do usuário no servidor de armazenamento de correio do usuário.

A Figura 1 é um fluxograma que mostra a operação de um mecanismo de deletação para serviços multimídia SIP de acordo com uma modalidade da presente invenção. Em particular, a Figura 1 mostra a interação entre um dispositivo usuário/cl iente 100, uma conta do usuário no armazenamento de correio 110 e uma lixeira 120 conforme definido no presente documento. Tanto a conta do usuário 110 com a lixeira 120 ficam situados remotos em relação ao dispositivo usuário/cliente. Na modalidade mostrada na Figura 1, o SIP URl para o dispositivo usuário/cl iente é "User@Sonera.com." O SIP URI para a conta do usuário é "User@ mailserver57.Sonera.com." O SIP URI para a lixeira é "RecycleBin@ mailserver. sonera. com".

Conforme discutido anteriormente, as mensagens armazenadas na rede podem ser atribuídas a identificadores exclusivos de mensagem. Três dessas mensagens são mostradas em 130 na Figura 1 com os identificadores de "13242@mailserver57.Sonera.com" (MSG 1) "13243@mailserver57.Sonera.com" (MSG 2) e "13244@mailserver57.Sonera.com" (MSG 3). Alternativamente, as mensagens podem ser armazenadas como arquivos. Em uma modalidade, cada mensagem pode ser determinada por um nome de arquivo, um tipo de arquivo e um valor hash. Três dessas mensagens são mostradas na Figura 2 com os identificadores de "Arquivo 1 = (novo do arquivo, tipo do arquivo, valor hash exclusivo)", "Arquivo 2 = (novo do arquivo, tipo do arquivo, valor hash exclusivo)" e "Arquivo 3 = (novo do arquivo, tipo do arquivo, valor hash exclusivo)".

Em 140 na Figura 1, um usuário decide deletar a MSG 2. Neste ponto, o dispositivo cliente do usuário 100 envia uma solicitação SIP REFER com INVITE 150 ao identificador de mensagem 13243@mailserver57.Sonera.com, que serve como um agente usuário virtual 155, na conta do usuário 110. A solicitação SIP REFER tem o endereço da lixeira com base na rede (RecycleBin@mailserver.sonera.com) no cabeçalho Refer-to.

A solicitação SIP REFER com INVITE 150 serve para solicitar que uma Sessão SIP seja estabelecida à lixeira baseada na rede 120 (RecycleBin@mailserver.sonera.com). O agente usuário virtual 155 responde mediante a aceitação da solicitação SIP REFER a partir do dispositivo usuário/cl iente 100 com uma mensagem "202 ACCEPT" em 160. O agente usuário virtual 155 também envia uma solicitação INVITE para estabelecer uma sessão SIP à lixeira 120 em 170. A lixeira 120 aceita esta sessão em 180. Em 190, uma sessão SIP é oficialmente estabelecida ao agente usuário virtual 155 sob a forma de um Protocolo de Restabelecimento de Sessão de Mensagem (MSRP), sendo que o atributo de mídia do protocolo de descrição de sessão (SDP) é ajustado para a=SendOnly. O agente usuário virtual 155 procede para notificar o usuário/cliente 100 da sessão SIP em 200, e o dispositivo usuár io/cliente 100 reconhece essa notificação em 210. Na sessão SIP/MSRP, a MSG 2 é enviada a partir da conta do usuário 110 até a lixeira baseada na rede 120, fazendo com a MSG 2 desapareça da conta do usuár io 110. Após a transmissão bem-sucedida da mensagem MSG2, a sessão SIP entre o agente usuá rio virtual 155 e a lixeira 120 é destruída. O resultado final, descrito em 220, é a presença de apenas MSG 1 e MSG 3 na conta do usuário 110 no servidor d e armazenamento de correio do usuário.

Em uma modalidade alternativa da presente invenção, as funções da conta do usuár io 110 e da lixeira 120 são dispostas juntamente. Nesta situação, o envio de uma solicitação INVITE para estabelecer uma sessão SIP 170, o reconhecimento desta solicitação 180 e o estabelecimento da sessão SIP ao MSRP 190 não são necessários.

Ilustra-se na Figura 2 uma modalidade alternativa na qual as mensagens são armazenadas como arquivos. Nesta modalidade, o mecanismo para restaurar as mensagens armazenadas ou selecionadas à lixeira pode ser baseado no projeto de transferência de arquivos anexado como Anexo B, que se encontra incorporado neste pedido. Nesta modalidade, a solicitação REFER pode incluir as descrições SDP do(s) arquivo(s) a ser(em) deletado(s).

Em 140 na Figura 2, um usuário decide deletar a MSG 2 (Arquivo 2). Neste ponto, o dispositivo usuário/cl iente 100 envia uma solicitação SIP REFER com INVITE 150 ao servidor de armazenamento de correio, que serve como um agente usuário virtual 155, na conta do usuário 110. A solicitação SIP REFER tem o endereço da lixeira baseada na rede (RecycleBin@ mailserver.sonera.com) no cabeçalho Refer-to.

A solicitação SIP REFER com INVITE 150 serve para solicitar que uma Sessão SIP seja estabelecida à lixeira baseada na rede 120 (RecycleBin@mailserver.sonera.com). O agente usuário virtual 155 responde mediante a aceitação da solicitação SIP REFER a partir do dispositivo usuário/cliente 100 com uma mensagem "202 ACCEPT" em 160. O agente usuário virtual 155 também envia uma solicitação INVITE para estabelecer uma sessão SIP à lixeira 120 em 170. A lixeira 120 aceita a sessão em 180. Em 190, uma sessão SIP é oficialmente estabelecida ao agente usuári o virtual 155 sob a forma de um Protocolo de Restabelecimento de Sessão de Mensagem (MSRP), sendo que o atributo de mídia do protocolo de descrição de sessão (SDP) é ajustado para a=SendOnly. O agente usuário virtual 155 procede para notificar o usuário/cliente 100 da sessão SIP em 200, e o dispositivo usuário/cliente 100 reconhece essa notificação em 210. Na sessão SIP/MSRP, o arquivo 2 é enviado a partir da conta do usuá rio 110 até a lixeira baseada na rede 120, fazendo com a MSG 2 desapareça da conta do usuário 110. Após a transmissão bem-sucedida da mensagem Arquivo 2 (MSG2), a sessão SIP entre o agente usuário virtual 155 e a lixeira 120 é destruída. O resultado final, descrito em 220, é a presença de apenas MSG 1 (Arquivo 1) e MSG 3 (Arquivo 3) na conta do usuári o 110 no servidor de armazenamento de correio do usuári o.

Ilustra-se na Figura 3 uma modalidade alternativa da invenção. Nesta modalidade, a solicitação SIP REFER com INVITE é enviada diretamente à lixeira baseada na rede desviando do agente usuári o virtual. Por exemplo, em 340 na Figura 3, um usuári o decide deletar a MSG 2. Neste ponto, o dispositivo usuário /cliente 100 envia uma solicitação SIP REFER com INVITE 350 à lixeira 120 (RecycleBin@mailscrvcr.sonera.com). A solicitação SIP REFER com INVITE 350 serve para solicitar que uma Sessão SIP seja estabelecida entre a lixeira baseada na rede 120 (RecycleBin@ mailserver.sonera.com) e a conta do usuário 110 ou, se for usado, o agente usuário virtual 155. A lixeira 120 responde mediante a aceitação da solicitação SIP REFER a partir do dispositivo usuário /cliente 100 com uma mensagem "202 ACCEPT" em 360. A lixeira 120 também envia uma solicitação INVITE para estabelecer uma sessão SIP ao agente usuár io virtual 155 em 370. O agente usuário virtual 155 aceita esta sessão em 380. Em 390, uma sessão SIP é oficialmente estabelecida ao agente usuário virtual 155 sob a forma de um Protocolo de Restabelecimento de Sessão de Mensagem (MSRP), sendo que o atributo de mídia do protocolo de descrição de sessão (SDP) é ajustado para a=RecvOnly. A lixeira 120 procede para notificar o usuário/cl iente 100 da sessão SIP em 400, e o dispositivo usuár io/cliente 100 reconhece essa notificação em 410. Na sessão SIP/MSRP, a MSG 2 é enviada a partir da conta do usuário 110 até a lixeira baseada na rede 120, fazendo com a MSG 2 desapareça da conta do usuário 110. Αρά a transmissão bem-sucedida da mensagem MSG2, a sessão SIP entre o agente usuário virtual 155 e a lixeira 120 é destruída. O resultado final, descrito em 420, é a presença de apenas MSG 1 e MSG 3 na conta do usuári o 110 no servidor de armazenamento de correio do usuário.

De forma similar à modalidade anterior, alternativamente, as funções da conta do usuár io 110 e da lixeira 120 são dispostas juntamente. Nesta situação, o envio de uma solicitação INVITE para estabelecer uma sessão SIP 370, o reconhecimento desta solicitação 380 e o estabelecimento da sessão SIP ao MSRP 390 não são necessários.

A modalidade da invenção ilustrada na Figura 4 é uma alternativa à modalidade da Figura 3. De forma similar à Figura 3, nesta modalidade, a solicitação SIP REFER com INVITE é enviada diretamente à lixeira baseada na rede desviando do agente usuári o virtual. No entanto, na modalidade da Figura 4, o mecanismo para restaurar as mensagens armazenadas ou selecionadas à lixeira é baseado no projeto de transferência de arquivos anexado como Anexo B. Nesta modalidade, a solicitação REFER inclui as descrições SDP do(s) arquivo(s) a ser(em) deletado(s).

Em 340 na Figura 4, um usuário decide deletar MSG 2 (Arquivo 2). Neste ponto, o dispositivo usuário/cliente 100 envia uma solicitação SIP REFER com INVITE 350 à lixeira 120 (RecyclcBin@mailserver.sonera.com). A solicitação SIP REFER com INVITE 350 serve para solicitar que uma Sessão SIP seja estabelecida à lixeira baseada na rede 120 (RecycleBin@ mailserver.sonera.com). A lixeira 120 responde mediante a aceitação da solicitação SIP REFER a partir do dispositivo usuá rio/cliente 100 com uma mensagem "202 ACCEPT" em 360. A lixeira 120 também envia uma solicitação INVITE para estabelecer uma sessão SIP ao agente usuário virtual 155 em 370. O agente usuári o virtual 155 aceita esta sessão em 380. Em 390, uma sessão SIP é oficialmente estabelecida ao agente usuário virtual 155 sob a forma de um Protocolo de Restabelecimento de Sessão de Mensagem (MSRP), sendo que o atributo de mídia do protocolo de descrição de sessão (SDP) é ajustado para a=RecvOnly. A lixeira 120 procede para notificar o usuário/clien te 100 da sessão SIP em 400, e o dispositivo usuário/cl iente 100 reconhece essa notificação em 410. Na sessão SIP/MSRP, o Arquivo 2 (MSG 2) é enviado a partir da conta do usuár io 110 até a lixeira baseada na rede 120, fazendo com o Arquivo 2 (MSG 2) desapareça da conta do usuá rio 110. Αρά a transmissão bem-sucedida da mensagem Arquivo 2 (MSG2), a sessão SIP entre o agente usuário virtual 155 e a lixeira 120 é destruída. O resultado final, descrito em 420, é a presença de apenas MSG 1 (Arquivo 1) e MSG 3 (Arquivo 3) na conta do usuári o 110 no servidor de armazenamento de correio do usuári o.

Em outra modalidade, múltiplas mensagens armazenadas podem ser selecionadas e deletadas pelo usuário. Nesta modalidade, ilustrada na Figura 5 uma solicitação Multiple-REFER pode ser enviada à lixeira 120 de modo a deletar as múltiplas mensagens selecionadas. O Anexo A, que está incorporado a este pedido, ilustra uma modalidade ou implementação da solicitação Multiple-REFER. Na modalidade mostrada na Figura 5, a solicitação SIP Multiple-REFER com INVITE é enviada diretamente à lixeira baseada na rede desviando do agente usuário virtual. Alternativamente, a solicitação SIP Multiple-REFER com INVITE pode ser enviada ao agente usuário virt uai conforme descrito em relação à modalidade ilustrada na Figura 1.

Em 540 na Figura 5, um usuário decide deletar MSG 2 e MSG 3. neste ponto, o dispositivo usuário/cliente 100 envia uma solicitação SIP Multiple-REFER com INVITE 550 à lixeira 120 (RecycleBin@mailserver.sonera.com) incluindo uma lista URI que contém os URIs das mensagens armazenadas a serem deletadas (neste caso MSG 2 e MSG3). A solicitação SIP Multiple-REFER com INVITE 550 serve para solicitar que as Sessões SIP sejam estabelecidas à lixeira baseada na rede 120 (RecycleBin@mailserver.sonera.com). A lixeira 120 envia solicitações INVITE para estabelecer sessões SIP aos agentes usuários virtuais 155 e 156 em 570 e 571, respectivamente, um para cada mensagem deletada. Neste caso, a solicitação INVITE 570 corresponde à MSG2 e a solicitação INVITE 571 corresponde à MSG3. Os agentes usuário s virtuais 155 e 156 aceitam essas sessões em 580 e 581, respectivamente. Em 590, uma sessão SIP é oficialmente estabelecida ao agente usuário virtual 155 sob a forma de um Protocolo de Restabelecimento de Sessão de Mensagem (MSRP), sendo que o atributo de mídia do protocolo de descrição de sessão (SDP) é ajustado para a=RecvOnly e em 591 uma sessão SIP é estabelecida ao agente usuár io virtual 156. Nas sessões SIP/MSRP, a MSG 2 e a MSG 3 são enviadas a partir da conta do usuár io 110 até a lixeira baseada na rede 120, fazendo com a MSG 2 e a MSG 3 desapareçam da conta do usuário 110. Αρά a transmissão bem-sucedida das mensagens MSG2 e MSG3, a sessão SIP entre os agentes usuár ios virtuais 155 e 156 e a lixeira 120 são destruídas. O resultado final, descrito em 620, é a presença de apenas MSG 1 na conta do usuár io 110 no servidor de armazenamento de correio do usuário.

De forma similar à s modalidades anteriores, as funções da conta do usuário 110 e da lixeira 120 também podem ser dispostas juntamente. Nesta situação, o envio de uma solicitação INVITE para estabelecer uma sessão SIP 570 e 571, os reconhecimentos destas solicitações 580 e 581 e o estabelecimento das sessões SIP ao MSRP 590 e 591 não sã o necessários.

A modalidade mostrada na Figura 6 ilustra a deletação de múltiplas mensagens quando o mecanismo para restaurar as mensagens armazenadas ou selecionadas à lixeira é baseado no projeto de transferência de arquivos anexado como Anexo B. Nesta modalidade, a solicitação REFER inclui, novamente, as descrições SDP dos arquivos a serem deletados. Em 540 na Figura 6, um usuá rio decide deletar a MSG 2 (Arquivo 2) e a MSG 3 (Arquivo 3). Neste ponto, o dispositivo usuári o/cliente 100 envia uma solicitação SIP REFER com INVITE 550 à lixeira 120 (RecycleBin@mailserver.sonera.com) utilizando-se a sintaxe descrita no Anexo B para as mensagens (arquivos) armazenadas a serem deletadas (neste caso MSG 2 e MSG 3). Neste caso, os parâmetr os SDP para cada arquivo (mensagem) a ser deletado precisam ser enviados em uma linha de mídia separada "m =". A solicitação SIP REFER com INVITE 550 serve para solicitar que as Sessões SIP sejam estabelecidas entre a lixeira baseada na rede 120 (RecycleBin@mailserver.sonera.com) e a conta do usuári o 110 ou, se for usado, o agente usuário virtual 155. A lixeira 120 envia solicitações INVITE para estabelecer as sessões SIP ao agente usuário virtual 155 em 570. O agente usuário virtual 155 aceita uma sessão para cada arquivo a ser deletado em 580 e 581, respectivamente. Em 590, uma sessão SIP é oficialmente estabelecida ao agente usuári o virtual 155 sob a forma de um Protocolo de Restabelecimento de Sessão de Mensagem (MSRP), sendo que o atributo de mídia do protocolo de descrição de sessão (SDP) é ajustado para a=RecvOnly e em 591 uma sessão SIP é estabelecida ao agente usuár io virtual 156. Nas sessões SIP/MSRP, o arquivo 2 (MSG 2) e o arquivo 3 (MSG 3) são enviados a partir da conta do usuário 110 até a lixeira baseada na rede 120, fazendo com a MSG 2 (Arquivo 2) e a MSG 3 (Arquivo 3) desapareçam da conta do usuário 110. Após a transmissão bem-sucedida do Arquivo 2 (MSG2) e do Arquivo 3 (MSG3), as sessões SIP entre o agente usuá rio virtual 155 e a lixeira 120 são destruídas. O resultado final, descrito em 620, é a presença apenas do Arquivo 1 (MSG 1) na conta do usuár io 110 no servidor de armazenamento de correio do usuário.

De forma similar à s modalidades anteriores, as funções da conta do usuário 110 e da lixeira 120 também podem ser dispostas juntamente. Nesta situação, o envio de uma solicitação INVITE para estabelecer uma sessão SIP 570 e 571, os reconhecimentos destas solicitações 580 e 581 e o estabelecimento das sessões SIP ao MSRP 590 e 591 não sã o necessários. Ainda em outra modalidade, todas as mensagens armazenadas podem ser selecionadas e deletadas pelo usuário. Nesta modalidade, ilustrada na Figura 7 uma solicitação REFER pode ser enviada à lixeira 120 para deletar todas as mensagens referindo-se ao SIP URI para a conta de armazenamento de correio do usuário ao invés de uma mensagem individual ou lista URI de mensagens. Novamente, na modalidade mostrada na Figura 7, a solicitação SIP REFER com INVITE é enviada diretamente à lixeira baseada na rede desviando do agente usuár io virtual. Alternativamente, a solicitação SIP REFER com INVITE pode ser enviada ao agente usuári o virtual conforme descrito em relação à modalidade ilustrada na Figura 1.

Em 740 na Figura 7, um usuário decide deletar todas as mensagens da sua conta de armazenamento de correio. Neste ponto, o dispositivo usuá rio/cliente 100 envia uma solicitação SIP REFER com INVITE 750 à lixeira 120 (RecycleBin@mailserver.sonera.com) que inclui o SIP URI para a conta de armazenamento de correio do usuár io (neste caso User@mailserver57.Sonera.com). A solicitação SIP REFER com INVITE 750 serve para solicitar que uma Sessão SIP seja estabelecida entre a lixeira baseada na rede 120 (RecycleBin@mailserver.sonera.com) e a conta do usuário 110 ou, se for usado, o agente usuário virtual 155. A lixeira 120 responde mediante a aceitação da solicitação SIP REFER a partir do dispositivo usuário/cl iente 100 com uma mensagem "202 ACCEPT" em 760. A lixeira 120 também envia uma solicitação INVITE para estabelecer uma sessão SIP ao agente usuári o virtual 155 em 770. O agente usuár io virtual 155 aceita esta sessão em 780. Em 790, uma sessão SIP é oficialmente estabelecida ao agente usuári o virtual 155 sob a forma de um Protocolo de Restabelecimento de Sessão de Mensagem (MSRP), sendo que o atributo de mídia do protocolo de descrição de sessão (SDP) é ajustado para a=RecvOnly. A lixeira 120 procede para notificar o dispositivo usuári o/cliente 100 da sessão SIP em 800, e o dispositivo usuár io/cliente 100 reconhece esta notificação em 810. Nas sessões SIP/MSRP, todas as mensagens na conta de armazenamento de correio do usuár io (MSG 1, MSG 2 e MSG3 neste caso) são enviadas a partir da conta do usuário 110 até a lixeira baseada na rede 120, fazendo com que todas as mensagens desapareçam da conta do usuário 110. Após a transmissão bem-sucedida de todos as mensagens existentes na conta de armazenamento de correio do usuár io, a sessão SIP entre o agente usuário virtual 155 e a lixeira 120 é destruída. O resultado final em 820 é que não resta nenhuma mensagem na conta do usuário 110 no servidor de arma zenamento de correio do usuário.

De forma similar às modalidades anteriores, as funções da conta do usuário 110 e da lixeira 120 também podem ser dispostas juntamente. Nesta situação, o envio das solicitações INVITE para estabelecer uma sessão SIP 770, os reconhecimentos da solicitação 780 e o estabelecimento da sessão SIP ao MSRP 790 não são necessários.

A Figura 8 mostra um sistema 10 no qual a presente invenção pode ser utilizada, compreendendo múltiplos dispositivos de comunicação que podem se comunicar através de uma rede. O sistema 10 pode compreender qualquer combinação de redes com ou sem fio incluindo, mas sem limitar-se a, uma rede telefônica móvel, uma Rede de Área Local (LAN) sem fio, uma rede de área pessoal Bluetooth, uma LAN Ethernet, uma LAN de redes em anel, uma área de rede ampliada, a Internet, etc. O sistema 10 pode incluir tanto dispositivos de comunicação com fio como sem fio.

A título de exemplo, o sistema 10 mostrado na Figura 8 inclui uma rede telefônica móvel 11 e a Internet 28. A conectividade à Internet 28 pode incluir, mas sem limitar-se a, conexões sem fio de longo alcance, conexões sem fio de curto alcance, e várias conexões com fio incluindo, mas sem limitar-se a, linhas telefônicas, linhas de comunicação por cabo, linhas de transmissão de energia, e similares.

Os dispositivos de comunicação exemplares do sistema 10 podem incluir, mas sem limitarem-se a, um telefone móvel 12, uma combinação de PDA e telefone móvel 14, um PDA 16, um dispositivo mensageiro integrado (IMD) 18, um computador de mesa 20 e um computador portáti 1 22 Os dispositivos de comunicação podem ser estacionário s ou móveis quando transportados por um indivíduo em movimento. Os dispositivos de comunicação também podem estar situados em um meio de transporte que inclui, mas sem limitar-se a, um automórel, um caminhão, um taxi, um ônibus,um barco, um avião, uma bicicleta, uma motocicleta, etc. Alguns ou todos os dispositivos de comunicação podem enviar e receber chamadas e mensagens e se comunicarem com prestadores de serviços através de uma conexão sem fio 25 até uma estação base 24 A estação base 24 pode estar conectada a um servidor de rede 26 que permite comunicação entre a rede telefônicamóvel 11 e a Internet 28. O sistema 10 pode incluir dispositivos de comunicação adicionais e dispositivos de comunicação de diferentes tipos.

As Figuras 9 e 10 mostram um telefone móvel representativo 12 no qual a presente invenção pode ser implementada. Deve-se compreender que, no entanto, não se pretende que a presente invenção seja limitada a um tipo particular de telefone móvel 12 ou outro dispositivo eletrônico. Outros tipos de dispositivos eletrôricos que podem ser usados incluem, mas não se limitam a, um PDA 16, uma combinação de PDA e telefone móvel 14, um IMD 18, um computador de mesa 20 e um computador portáti 1 22 os dispositivos de comunicação podem ser estacionários ou móvefe quando transportados por um indivíduo em movimento. Os dispositivos de comunicação também podem estar situados em um meio de transporte que inclui, mas sem limitar-se a, um automóvel, um caminhão, um taxi, um ônibus, um barco, umavião, uma bicicleta, uma motocicleta, etc.

O telefone móvel 12 das Figuras 9 e 10 inclui um gabinete 30, uma tela 32 sob a forma de uma tela de cristal líquido, um teclado numérico 34, um microfone 36, um fone de ouvido 38, uma bateria 40, uma porta infravermelha 42, uma antena 44, um cartão inteligente 46 sob a forma de um UICC de acordo com uma modalidade da invenção, um leitor de cartão 48, um conjunto de circuitos de interface de rádi o 52, um conjunto de circuitos codec 54, um controlador 56 e uma memória58. Todos os circuitos e elementos individuais são de um tipo bem-conhecido na técnica, por exemplo, na gama de telefones móveis da Nokia. A título de exemplo, o sistema 10 mostrado na Figura 8 inclui uma rede telefônicamóvd Ilea Internet 28. A conectividade à Internet 28 pode incluir, mas não se limita a, conexões sem fio de longo alcance, conexões sem fio de curto alcance, e várias conexões com fio incluindo, mas sem limitar-se a, linhas telefôricas, linhas de comunicação por cabo, linhas de transmissão de energia, e similares.

A presente invenção é descrita no contexto geral de etapas de método, que podem ser implementadas em uma modalidade por um produto de programa que inclui instruções executáve is por computadores, como código de programa, executadas por computadores nos ambientes conectados em rede. Em geral, os módulos de programa incluem rotinas, programas, objetos, componentes, estruturas de dados, etc. que realizam 30 tarefas particulares ou implementam tipos de dados abstratos particulares. As instruções executáveis por computadores, associadas às estruturas de dados, e módilos de programa representam exemplos de código de programa que serve para executar etapas dos métodos aqui descritos. A seqü ência particular dessas instruções executáveis ou estruturas de dados associadas representam exemplos de ações correspondentes para implementação das funções descritas nessas etapas.

As implementações de software e web da presente invenção podem ser realizadas por técnicas de programação padrão com lógica baseada em regras e outra lógica para executar as várias etapas de busca em banco de dados, etapas de correlação, etapas de comparação e etapas de decisão. Deve-se notar, também, que as palavras "componente" e "módulo", conforme o uso na descrição e nas reivindicações, são destinadas a abranger implementações que usam uma ou mais linhas de código de software, e/ou implementações de hardware, e/ou equipamento para receber entradas manuais.

A descrição anterior das modalidades da presente invenção foi apresentada por propóstos ilustrativos e descritivos. A descrição não se destina a ser exaustiva ou limitar a presente invenção à forma precisa revelada, e são possíveis modificações e variações levando-se em consideração os ensinamentos anteriores ou podem ser adquiridas a partir da prát ica da presente invenção. As modalidades foram escolhidas e descritas com a finalidade de explicar os princípios da presente invenção e sua aplicação prática de modo a permitir que os versados na técnica utilizem a presente invenção nas várias modalidades e com várias modificações conforme são adequadas ao uso particular contemplado.

Claims

1. Método para deletar um item de uma conta de usuário em um ambiente multimídia SIP, CARACTERIZADO por compreender; - receber um pedido de um dispositivo de usuário para deleiar o item a partir da conla de usuários estabelecer uma seção SIP entre unia localização de itens deletados com base em rede e a conta de usuário; - apóscstabelecer a seção STP, transferir o item da conta de usuário para a localização de itens deletados com base em rede; e - deletar o item da conta de usuário

2. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que em que o pedido compreende um pedido SIP REFER.

3. Método, de acordo eom 3 reivindicação 2, CARACTERIZADO pelo fato que o pedido SIP REFER inclui um endereço para a localização de itens deletados com base em rede em seu cabeçalho Reter-to.

4. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato que o pedido compreende um pedido SiP Multiple-RFFER

5. Método, de acordo com a reivindicação 1, CARACTERIZADO por compreender adicionalmente, em resposta ao recebimento do pedido, a transmissão de uma confirmação do pedido para o dispositivo de usuário.

6. Método, de acordo com a reivindicação 1, CΛRACTERIZADO pelo fato que a seção SIP é estabelecida com um atributo direcional SDP ajustado para a = SendOnly.

7. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato que a seção SIP é estabelecida com um atributo direcional SDP ajustado para a = RecvOnly

8. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato que o item inclui um identificador de mensagem único, e em que o identificador de mensagem único é incluído no pedido pelo dispositivo de usuário.

9. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato que o pedido é para dcleiar itens múltiplas da conta de usuário, e em que uma lista URI de itens múltiplos é incluída no pedido pelo dispositivo de usuário.

10. Metodo, de acorda com a reivindicação 1, CARACTERIZADO pelo fato que o pedido é para ddetar todos os itens da corna de usuário, e em que uma SlP URI para a coma de usuário é incluída no pedido pela coiua de usuário,

11. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato que o item ó armazenado como um arquivo tendo descrições SDP, e em que as descrições de arquivo SDP são incluídas no pedido pelo dispositivo de usuário.

12. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato que o pedido é para deIetar itens mültiplos da conta de usuário, e em que as descrições de arquivo SDF para cada um dos itens múltiplos são incluídas no pedido pelo dispositivo de usuário, as descrições de arquivo SDP para cada arquivo sendo Incluídas em uma linha de mídia separada no pedido.

13. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato que cada um dos dispositivos de üsuário, conta de usuário e localização de itetis deletados com base em rede possui um único identificador de recursos uniforme.

14. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo lato que um protocolo MSRP é usado para transferir o liem da conta de usuário para a localização de itens deletados com base em rede.

15. Prodmo de programa de computador, incorporado em um meio legível por computador, para detelar um item de uma conta de usuário em um ambiente multimídia SIP, CARACTERIZADO por compreender: - um código de computador para receber um pedido de um dispositivo de usuário para ddetar o item da conta de usuário; - um código de computador para esLabelecer uma seção SIP entre uma localização de itens deletados com base em rede e a conta de usuários - um código de computador para, após estabelecer a seção SIP, transferir o item da conta de usuário para a localização de itens deletados com base em rede; e - um código de computador para deletar o item da conta de usuário.

16. Produto de programa de computador, de acordo com a reivindicação -15, em que o pedido compreende um pedido 5ΪΡ REFER,

17. Produto de programa de computador, de acordo com a reivindicação CARACTERlZADO pelo Tato que o pedido SIP RES1-ER inclui um endereço para a localização de itens delctados com base em rede em seu cabeçalho Refer-to.

18. Produto de programa de computador de acordo com a reivindicação -15, CARACTERIZADO pelo fato que o pedido compreende um pedido SlP Multiple- REFER.

19. Produto de programa de computador, de acordo com a reivindicação -15, CARACTERiZADO peío tato qtie a seçào SIP é estabelecida com um atributo direciona] SDP ajustado para a = SendOnly.

20. Produto <de programa de computador, de acordo com a reivindicação -15, CARACTERIZADO pelo fato que a seção SIP £ estabelecida com um atnhtito direciona I SDP ajustado para a-RecvOnly.

21. Prtfduto de programa de computador, de acordo com a reivindicação -15, pelo fato que o item inclui um identificador de mensagem único, e em que o identificador de mensagem único é incluído tio pedido pelo dispositivo de usuário.

22. Produto de programa de computador, de acordo com a reivindicação CARACTERIZADO pelo fato que o pedido é para itens múltiplos deletados da conta de usuário, e em que a lista URi dos itens múltiplos é incluída no pedido a partir do dispositivo de usuário.

23. Produto de programa de computador, de acordo com a reivindicação -15, CARACTERIZADO pelo fato que o pedido é para deIetar todos os itens da conta de usuário, e em que uma SIP URI para a conta de usuário ê inetuída no pedido a partir da coma de usuário.

24. Produto de programa de computador, de acordo com a reivindicação -15, CARACTERIZAJÍO pelo tato que o item é armazenado como um arquivo tendo descrições SDP e em que as descrições SDP são incluídas no pedido a partir do dispositivo de usuário.

25. Produto de programa de computador, de acordo com a reivindicação - 23, CARACTERIZADO pelo fato que o pedido é para itens múltiplos deletados tia conta de usuário, e em que as descrições do arquivo SIP para cada um dos itens múltiplos são incluídas no pedido a partir do dispositivo de usuário para as descrições do arquivo SDP para cada arquivo sendo incluído em uma Einha de mídia separada no pedido.

26. Produto de programa de computador, de acordo com a reivindicação 15, CARACTERIZADO pelo fato que cada um dos dispositivos de usuário, conta de usuário e localização de itens deletados com base em redes possui um identificador único de recurso uniforme.

27. Produto de programa de computador, de acordo com a reivindicação 15, CARACTEIUZADO pelo fato que um protocolo MSRP é usado para transferir o item da conta de usuário para a localização de itens deletados com base em rede,

28. Dispositivo eletrônico, CARACTERIZADO por compreender: - um processador; e - uma unidade de memória conectada de forma comunicativa ao processador e incluindo: - um código de computador para receber um pedido SIP de um dispositivo de usuário para deletar um item de uma conta de usuário; - um código de computador para estabelecer uma seção SIP entre uma localização de itens deletados com base em rede e a conta de usuário, - um côdigode computador para, após estabelecer a seção SIP, transferir o item da coma de usuário para a localização de itens deletados com base em rede e - um código de computador para dcletar o item da conta de usuário.

29. Dispositivo eletrônico, de acordo com a reivindicação 28, CARACTERIZADO pelo fato de que o pedido compreende um pedido SIP REFER.

30. Dispositivo eletrônico, de acordo tom a reivindicação 29, CARACTERIZADO pelo fato de que o pedido SIP REFER inclui um endereço para a localização de itens deletados com base em rede em seu cabeçalho Refer-to.

31. Dispositivo eletrônico, de acordo com a reivindicação 28, CARACTERIZADO pelo fato de que o pedido compreende um pedido SIP Multiple-REFER.

32. Dispositivo eletrônico, de acordo com a reivindicação 28, pelo fato de que a seção SlP é estabelecida tom um atributo direcional SDP ajudado para a-SendOnIy

33. Dispositivo cIetrftnictis de acordo com a reivindicação 28, CARACTERIZADO pelo falo tle que a seção SlP é estabelecida com um atributo direcional SDP ajustado para a-RecvOnly,

34, Dispositivo eletrônico, de acordo com a reivindicação 28, CARACTERIZADO pelo fato de que o iíem inclui um identificador de mensagem único, e em que o identificador de mensagem único é incluído tio pedido pelo dispositivo de usuário.

35, Dispositivo eletrônico, cie acordo com a reivindicação 28, CARACTERIZADO pelo fato de que ti pedido é para deletar itens múltiplos da coma de usuário, e em que uma lisia URl de itens múltiplos é inetuída no pedido peio dispositivo de usuário.

36. Dispositivo eletrônico, de acordo com a reivindicação 28. CARACTERIZADO pelo tato de que o pedido é para detmr todos os itens da conta de usuário, e em que uma SIP URI para a coma de usuário é incluída no pedido peío dispositivo de usuário.

37. Dispositivo eletrônico, de acordo com a reivindicação 28, CARACTERIZADO pelo fato de que o item é armazenado corno um arquivo tendo descrições SDP. e em que as descrições de arquivo SDP são incluídas no pedido pelo dispositivo tle usuário,

38. Dispositivo eletrônico, de acordo com a reivindicação 37, CARACTERIZADO pelo fato de que o pedido é para deletar itens múltiplos da conta de usuário, e cm que as descrições de arquivo SDP para cada um dos itens tmüúpios são incluídas ito pedido pelo dispositivo de usuário, as descrições de arquivo SIJP para cada arquivo sendo incluídas em uirta linha de mídia separada no pedido.

39. Dispositivo eletrônico, de acordo com a reivindicação 28, CARACTERIZADO pelo fato de que o protocolo MSRP é usado para transferir o item da conta de usuário para a localização de itens deletados com base em rede.

40. Método para ddetar um item de uma conta de usuário cm um ambiente multimídia SIP, CARACTERIZADO por compreender: - transmitir um pedido de um dispositivo de usuário para deletar o item de unia conta de usuário; - em resposta ao pedido transmitido, estabelecer uma seção SIP entre um agente usuário virtual e ama localização de itens deletados com base em rede; - após estabelecer a seção SIP, transferir o item da conta de usuário para a localização de itens dele lados com base em rede; a - deletar o item da conta de usuário.

41. Método, de acordo com a reivindicação 40, CARACTERIZADO pelo fato de que ei seção Slfj é estabelecida com um atributo direcional SUP ajustado para a = SendOnly.

42. Metodo1 de acordo com a reivindicação 40, CARACTERIZADO pelo fato de que a seção SIP é estabelecida com um atributo direcional SDP ajustado para a = RecvOnly

43. Método η de acordo com a reivindicação 40, CARACTERIZADO pelo fato de que o pedido compreende uni pedido SfP REFER inciuindo um identificador único para o item a ser deletado.

44. Método, de acordo com a reivindicação 40, CARACTERIZADO pelo fato de que o pedido é para deletar itens múltiplos, o pedido compreendendo um pedido SIP Multiple-REFER incluindo uma lista URl de itens a serem deletados.

45. Método, de acordo com a reivindicação 40, CARACTERIZADO pelo fato de que o pedido é para deletar todos os itens, o pedido compreendendo um pedido SiP REFER incluindo uma SIP URl para a coma de usuário.

46. Metodo, de acordo com a reivindicação 40, CARACTERlZADO pelo fato de que o item é armazenado como um arquivo tendo descrições SDP1 e em que o pedido compreende um pedido RIT-KR incluindo as descrições SDP.

47. Método, de acordo com a reivindicação 40, CARACTERIZADO pelo fato de que os itens são armazenados como arquivos tendo descrições SD P, em que o pedido é para deletar itens múltiplos, e em que as descrições de arquivo SDP dos itens a serem deIetados são incluídas no pedido pelo dispositivo de usuário, as descrições de arquivo SDP para cada um dos arquivos sendo incluídas em uma íinha de mídia separada no pedido.

48. Método, de acordo cora a reivindicação 40, ÇARACTI^IZADO pelo fato de que o pedido SlP REFER inclui ura endereço para a localização de itens deleiados com base em rede em seu cabeçalbo Refer-to.

49. Método, de acordo tom a reivindicação 40, CARACTERIZADO pelo fato de que o protocolo MSRP é usado para transferir o item da conta de usuário para a localização de itens deletados com base em rede.

50. Método para deletar um item de uma conta de usuário em um ambiente multimídia SlP, CARACTERIZADO por compreender: - transmitir um pedido SIP REFER de um dispositivo de usuário para deletar o item da conta de usuário, o pedido SIP RRi-ER incluindo um endereço para uma localização de itens deletados com base em rede em seu cabeçalho Refer-to; - em resposta ao recebimento do pedido SIP REFER, transmitir uma confirmação do pedido do dispositivo de usuário; e - deletar o item da coma de usuário.