PT1938536E - Recuperação de mensagens instantâneas offline - Google Patents

Recuperação de mensagens instantâneas offline Download PDF

Info

Publication number
PT1938536E
PT1938536E PT68095900T PT06809590T PT1938536E PT 1938536 E PT1938536 E PT 1938536E PT 68095900 T PT68095900 T PT 68095900T PT 06809590 T PT06809590 T PT 06809590T PT 1938536 E PT1938536 E PT 1938536E
Authority
PT
Portugal
Prior art keywords
message
messages
user
session
stored
Prior art date
Application number
PT68095900T
Other languages
English (en)
Inventor
Adamu Haruna
Miguel A Garcia-Martin
Original Assignee
Nokia Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Corp filed Critical Nokia Corp
Publication of PT1938536E publication Critical patent/PT1938536E/pt

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/04—Real-time or near real-time messaging, e.g. instant messaging [IM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
    • H04L12/1831—Tracking arrangements for later retrieval, e.g. recording contents, participants activities or behavior, network status
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21—Monitoring or handling of messages
    • H04L51/224—Monitoring or handling of messages providing notification on incoming messages, e.g. pushed notifications of received messages

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Telephonic Communication Services (AREA)
  • Information Transfer Between Computers (AREA)

Description

ΕΡ1938536Β1
DESCRIÇÃO RECUPERAÇÃO DE MENSAGENS INSTANTÂNEAS OFFLINE Antecedentes da Invenção Campo da Invenção A presente invenção refere-se a mensagens instantâneas com base em tecnologia SIP (Protocolo de Iniciação de Sessão)/ SIMPLE (SIP para Mensagens Instantâneas e Extensões de Aproveitamento de Presença). Em particular, esta invenção trata do problema que surge quando um servidor de correio armazena mensagens instantâneas na rede para entrega posterior a um utilizador final (presumivelmente quando o utilizador liga à rede mais tarde). É assumido que um utilizador A envia uma ou mais mensagens instantâneas a um utilizador B. A tecnologia usada para entregar estas mensagens pode ser baseada em método SIP MESSAGE ou no Protocolo de Retransmissão de Sessão de Mensagem (MSRP). É ainda assumido que o utilizador B não está registado para o seu servidor SIP, e que um servidor de aplicação de correio está a armazenar as mensagens instantâneas actuais para entrega posterior a utilizador B mais tarde.
Quando o utilizador B registra para a sua rede SIP, o Agente Utilizador SIP assina um pacote de evento de Sumário de Mensagem e Indicador de Espera e recebe notificações das 1 ΕΡ1938536Β1 mensagens que estão pendentes de serem recuperadas. É assumido que o servidor de correio armazena uma grande quantidade de mensagens instantâneas, assim utilizador B recebe uma notificação que contém sumário dessas mensagens instantâneas armazenadas. 0 artigo de Myers et al.: RFC 1939: Post Office Protocol Version 3" NetWork Working Group Request for Comments, XX, XX,, Maio de 1996 (1996-05), páginas 1-20, XP002197697, refere-se ao Protocolo de Posto de Correio Versão 3 (POP3) que permite que uma estação de trabalho dinamicamente aceda a uma caixa postal num anfitrião de servidor, isto é permite que uma estação de trabalho recupere correio que o servidor está a reter para isso. No capitulo 10 é dado um exemplo de uma sessão POP3 em que é fornecido um sumário de mensagens armazenadas no servidor a um cliente e o cliente recupera as mensagens indicando um número de mensagem ao servidor que está incluído no sumário. O documento US 2003/0165231 Al revela um sistema de telefonia de rede que permite serviços de mensagens unificadas. O sistema geralmente inclui pelo menos um agente utilizador operacionalmente acoplado a uma rede de dados e a um servidor de sinalização operacionalmente acoplado à rede de dados. Os agentes utilizadores são pontos de extremidade de telefonia, como aplicações de telefonia de Internet independentes ou computadores pessoais com software de telefonia apropriado. Um servidor de mensagens é fornecido que está operacionalmente acoplado à rede de dados e é responsivo ao servidor de sinalização. 2 ΕΡ1938536Β1 0 sistema também inclui um servidor de media que está operacionalmente acoplado à rede e inclui meios de armazenamento de dados de computador para armazenar ficheiros de mensagem. 0 servidor de media é responsivo ao servidor de mensagens e, em ocorrência de uma condição de mensagem, é directamente acessível a uma parte chamadora para armazenar um ficheiro de mensagem para recuperação subsequente por uma chamada parte.
SUMÁRIO DA INVENÇÃO A presente invenção deveria permitir uma recuperação melhorada de mensagens instantâneas offline.
Isto é realizado por um dispositivo terminal da reivindicação 1, um método da reivindicação 10, um dispositivo de rede da reivindicação 4, um método da reivindicação 13, um dispositivo de rede da reivindicação 19 e um método da reivindicação 21. A Fig. 1 mostra um diagrama em bloco esquemático que ilustra uma configuração de um dispositivo terminal e de um dispositivo de rede de acordo com a invenção. 0 dispositivo terminal 10 compreende um bloco de recepção 11, um bloco de selecção 12, um bloco de determinação 13 e um bloco de envio 14. O bloco de recepção 11 recebe um sumário de mensagens armazenadas num servidor de correio como o dispositivo de rede 20 e pendentes de serem recuperadas por um utilizador, cada mensagem associada a um identificador único. O bloco de selecção 12 3 ΕΡ1938536Β1 selecciona pelo menos uma das mensagens a ser recuperada do servidor de correio, com base no sumário de mensagens. 0 bloco de determinação 13 determina um identificador válido para recuperação da pelo menos uma mensagem com base no identificador único associado à pelo menos uma mensagem, obtendo assim pelo menos um identificador válido para recuperação. E o bloco de envio 14 envia um pedido de recuperação com o pelo menos um identificador válido para recuperação ao servidor de correio. 0 identificador único pode ser um identificador de mensagem fornecido pelo servidor de correio ou um Identificador Uniforme de Recurso (URI). 0 dispositivo de rede 20 como um servidor de correio armazena mensagens pendentes de serem recuperadas por um utilizador, e compreende um bloco de recepção 21 e um bloco de envio 22. 0 bloco de recepção 21 recebe um pedido de recuperação com pelo menos um identificador válido para recuperar pelo menos uma das mensagens armazenadas, e o bloco de envio 22 envia a pelo menos uma mensagem a um dispositivo terminal (por exemplo o dispositivo terminal 10) do utilizador que origina o pedido de recuperação. 0 bloco de envio 22 pode enviar a pelo menos uma mensagem numa mensagem SEND de Protocolo de Retransmissão de Sessão de Mensagem (MSRP).
De acordo com uma primeira forma de realização, o dispositivo de rede 20 pode ainda compreender um bloco de fornecimento 23 que fornece um identificador de mensagem 4 ΕΡ1938536Β1 para cada uma das mensagens armazenadas, em que o bloco de envio 22 envia um sumário das mensagens armazenadas ao utilizador, por exemplo o dispositivo terminal 10, cada mensagem associada ao identificador de mensagem determinado. O bloco de fornecimento 23 pode usar um campo de cabeçalho Call-ID incluído num pedido de Protocolo de Iniciação de Sessão de cada das mensagens armazenadas para o identificador de mensagem ou gerar um identificador Uniforme de Recurso (URI) único, o URI que é encaminhável ao dispositivo de rede em que o identificador de mensagem é parte do URI. 0 bloco de fornecimento 23 pode usar um campo de cabeçalho Message-ID de um pedido de Protocolo de Retransmissão de Sessão de Mensagem de cada das mensagens armazenadas para o identificador de mensagem.
De acordo com uma segunda forma de realização, o dispositivo de rede 2 0 pode compreender um servidor de conferência e pontos de extremidade virtuais como Agentes Utilizadores SIP virtuais correspondentes às mensagens armazenadas. O servidor de conferência pode receber um pedido de recuperação do utilizador que compreende uma lista de identificadores apontando a umas seleccionadas das mensagens armazenadas, o pedido de recuperação que estabelece uma primeira sessão para entregar as mensagens seleccionadas, estabelecer segundas sessões para cada uma das mensagens seleccionadas identificadas na lista com os pontos de extremidade virtuais correspondentes às mensagens 5 ΕΡ1938536Β1 seleccionadas, e receber as mensagens selecionadas dentro de ditas segundas sessões e reencaminhar as mensagens selecionadas ao utilizador dentro de dita primeira sessão. É para ser notado que a configuração mostrada na Fig. 1 é para ilustrar a invenção, e o dispositivo terminal e o dispositivo de rede podem compreender ainda blocos que implementam ainda funções (como um bloco de armazenamento no dispositivo de rede 20 para armazenar as mensagens) que não são relevantes para compreender a invenção e cuja descrição é omitida aqui. A Fig. 2 mostra um fluxograma que ilustra um método de recuperar mensagens de um servidor de correio num lado do dispositivo terminal 10. Na etapa S31, um sumário de mensagens armazenadas no servidor de correio e pendentes de serem recuperadas por um utilizador é recebido no dispositivo terminal, cada mensagem associada a um identificador único. Na etapa S32, pelo menos uma das mensagens a ser recuperada do servidor de correio é seleccionada com base no sumário de mensagens recebido em etapa S31. Na etapa S33, um identificador válido para recuperação da pelo menos uma mensagem é determinado com base no identificador único associado à pelo menos uma mensagem, obtendo assim, pelo menos um identificador válido para recuperação, e em etapa S34 um pedido de recuperação com o identificador válido para recuperação é enviado ao servidor de correio. A Fig. 3 mostra um fluxograma que ilustra um método de recuperar mensagens de um servidor de correio num lado do 6 ΕΡ1938536Β1 dispositivo de rede 20. Na etapa S41, um pedido de recuperação com pelo menos um identificador válido para recuperar pelo menos uma das mensagens armazenadas é recebido, e em etapa S42 a pelo menos uma mensagem é enviada a um dispositivo terminal do utilizador que origina o pedido de recuperação.
De acordo com a segunda forma de realização, um pedido de recuperação do utilizador que compreende uma lista de identificadores apontando a umas selecionadas das mensagens armazenadas é recebido no dispositivo de rede 20, o pedido de recuperação que estabelece uma primeira sessão para entregar as mensagens seleccionadas. Segundas sessões são estabelecidas para cada uma das mensagens seleccionadas identificadas na lista, e as mensagens selecionadas são recebidas dentro de ditas segundas sessões e as mensagens seleccionadas são reencaminhadas ao utilizador dentro de dita primeira sessão. A invenção pode ser implementada também como produto de programa de computador. O servidor de correio pode ser implementado como um servidor de aplicação de armazém de correio ou servidor de correio de mensagem instantânea.
De acordo com a primeira forma de realização da invenção, um utilizador recebe uma notificação de sumário de mensagem que inclui uma única identidade de mensagem alocada a cada mensagem armazenada. Para cada mensagem que o utilizador queira recuperar, o Agente Utilizador SIP cria 7 ΕΡ1938536Β1 uma sessão de mensagens SIP endereçadas à identidade da mensagem, por exemplo, depois de fazer alguma transformação. 0 servidor, depois de receber o pedido INVITE, é capaz de unicamente determinar a actual mensagem que o utilizador quer recuperar.
Esta solução permite que o utilizador selecione essas mensagens instantâneas armazenadas que deveriam ser recuperadas. A vantagem é enorme em cenários móveis, onde a largura de banda é limitada, e especialmente em casos onde o número e tamanho de mensagens instantâneas armazenadas é relevante. Assim o utilizador pode selecionar recuperar essas mensagens apontadas como urgente, ou que tenham sido recebidas de um utilizador particular, e então ler as mensagens que faltam mais tarde.
De acordo com a segunda forma de realização da invenção, um mecanismo é fornecido pelo que o utilizador, depois de ter selecionado as mensagens instantâneas que ele quer recuperar do servidor de correio, cria uma única sessão (SIP INVITE) endereçada às mensagens seleccionadas, fazendo uso do conceito de lista URI. Esta forma de realização modela o servidor de correio como composto por um servidor de conferência e um número de agentes utilizadores SIP virtuais, cada um representando uma mensagem instantânea armazenada.
De acordo com esta forma de realização, um mecanismo é fornecido para selecionar e recuperar mensagens seleccionadas já armazenadas no servidor de correio de uma maneira optimizada que pode ser usado em ambientes móveis. 8 ΕΡ1938536Β1
De acordo com esta solução, o utilizador pode recuperar um ilimitado número selecionado de mensagens armazenadas numa única operação de protocolo.
Esta solução permite que o utilizador minimize a sinalização e idas e voltas para recuperar mensagens seleccionadas usando uma única sessão para o servidor de correio. 0 pedido provisório de patente "Method and apparatus for instant messaging " por Garcia et al. depositado no U.S. Patent and Trademark Office a 30 de Setembro de 2005, cujo conteúdo é incorporado no presente documento por referência, e a primeira forma de realização permite recuperar quer o todo volume de mensagens instantâneas armazenadas, quer mensagens seleccionadas uma por uma (significando, cada mensagem requereu uma sessão SIP separada).
Assim, a segunda forma de realização desta invenção aumenta a experiência de utilizador devido aos atrasos mais baixos em configurar sessões, e optimiza tratamento de recurso sobre os canais de largura de banda baixa, como a interface de ar.
Nos desenhos: A Fig. 1 mostra um diagrama em bloco esquemático que ilustra uma configuração de um dispositivo terminal e de um dispositivo de rede de acordo com a invenção. A Fig. 2 mostra um fluxograma que ilustra um método de recuperação, de acordo com a invenção. 9 ΕΡ1938536Β1 A Fig. 3 mostra um fluxograma que ilustra um método de recuperação de acordo com a invenção. A Fig. 4 mostra um diagrama de sinalização de acordo com uma primeira forma de realização da invenção. A Fig. 5 mostra um diagrama em bloco esquemático que ilustra um anfitrião de servidor de correio de acordo com uma segunda forma de realização da invenção. A Fig. 6 mostra um diagrama de sinalização de acordo com a segunda forma de realização da invenção.
Descrição das Formas de Realização da Invenção
Assumindo que mensagens instantâneas têm sido depositadas numa caixa de correio de utilizador, quando o telefone de utilizador liga, o telefone envia uma assinatura a um pacote de evento de sumário de mensagem, e recebe uma notificação com a mensagem pendente; de acordo com RFC3842 "Um Pacote de Evento de Sumário de Mensagem e Indicação de Espera de Mensagem para o Protocolo de Iniciação de Sessão (SIP) ." 0 conteúdo de RFC 3842 é por este meio incorporado por referência. Este mecanismo é também aplicação a CORREIO DE VOZ, FAX, etc. o Notificador (um Agente Utilizador SIP que actua em nome do sistema de mensagens de utilizador) envia um sumário de mensagem das mensagens armazenadas no corpo de um NOTIFY por exemplo "há 4 mensagens antigas e 3 mensagens novas à sua espera". 10 ΕΡ1938536Β1
Opcionalmente, depois das contagens de sumário, cabeçalhos de mensagem como Para, De, Data, Assunto, e Message-ID podem ser anexos a cada mensagem.
Depois de o Utilizador/UE (Equipamento de Utilizador) ser notificado, pode enviar um INVITE ao servidor incluindo o tipo de media desejado para recuperar (para o propósito do grupo de Mensagens em OMA (Aliança Móvel Aberta), 0 INVITE deve incluir uma descrição SDP (Protocolo de Descrição de Sessão) de MSRP, mas pode incluir também outros tipos de media).
Adicionalmente, o utilizador pode aplicar um mecanismo como descrito no pedido provisório de patente "Método e Aparelho para Mensagens Instantâneas" para recuperar todas as mensagens instantâneas armazenadas do servidor de correio, incluindo informação de metadados (por exemplo, remetente, tempo de entrega, etc.). Para este propósito, um mecanismo SIP é fornecido para recuperar mensagens instantâneas que estavam previamente depositadas num servidor de aplicação que esteve a actuar como um servidor de aplicação de armazém de mensagem. Isto pode ser realizado mantendo os cabeçalhos relevantes da mensagem SIP encapsulando-a como uma mensagem/sip, por exemplo, como definido em RFC 3261 Secção 27.5, ou como uma mensagem/sipfrag, como definido em RFC 3420, e então enviá-la como a carga útil de um pedido MSRP SEND. Os conteúdos de RFC 3261 e 3420 são por este meio incorporados por referência. Adicionalmente, um servidor de aplicação de armazenamento pode então adicionar um cabeçalho à mensagem MSRP SEND e à mensagem SIP encapsulada contendo a hora e 11 ΕΡ1938536Β1 data quando a mensagem foi recebida. Mais particularmente, um cabeçalho de data/hora é inserido em cada mensagem MSRP e SIP armazenada. Semânticas novas podem ser usadas para a encapsulação das mensagens instantâneas armazenadas, e a mensagem/sip e mensagem/sipfrag são usadas em MSRP, fora do seu contexto original. Assim, um método de entregar mensagens SIP encapsuladas é fornecido, incluindo a informação de cabeçalho, como a carga útil de uma mensagem MSRP .
Com o supramecanismo, um método e aparelho são fornecidos pelo que um utilizador pode contactar o seu servidor de correio e recuperar mensagens instantâneas existentes já depositadas no servidor de aplicação de armazenar mensagem. As mensagens instantâneas podem ser depositadas no servidor de aplicação de armazenar mensagem usando pedidos SIP MESSAGE (como por IETF RFC 3428) ou mensagens MSRP (por exemplo, pedidos MSRP SEND) que são parte de uma sessão SIP. 0 conteúdo de RFC 3428 é por este meio incorporado por referência. A informação de metadados e/ou cabeçalho podem permitir que o utilizador determine a fonte da mensagem, a hora em que a mensagem foi deixada, etc.
Depois de a sessão SIP ser estabelecida com os media MSRP, todas mensagens armazenadas serão transferidas do servidor ao utilizador/UE. Cada mensagem armazenada vai ser enviada num pedido MSRP SEND separado (antes de fragmentação de pedidos MSRP SEND terem lugar), e cada uma vai ser identificada pela sua própria original Message-ID. Desta maneira o utilizador recupera todas as mensagens de 12 ΕΡ1938536Β1 uma vez, mas ainda é capaz de as classificar todas as mensagens por Message-ID.
Um dos defeitos de algumas soluções é que a identificação de remetente original (informação de utilizador) é necessariamente perdida porque os cabeçalhos MSRP não contêm qualquer relação com o SIP URI que deposita a mensagem. Assim, a associação de remetentes às suas mensagens particulares já disponíveis em caixas de entrada de aplicação de mensagens como correio electrónico, mensagens instantâneas, MMS, etc., vai perder-se. Isto também se aplica a pedidos SIP MESSAGE, pois podem ser enviados mas o destinatário não vai ser capaz de identificar o remetente, porque está configurado para o servidor de aplicação de armazenar mensagem.
Um mecanismo é proposto pelo que o utilizador, quando ele ou ela quer recuperar as suas mensagens instantâneas armazenadas, estabelece uma sessão MSRP com o seu servidor de aplicação de armazenar mensagem. 0 AS de armazenar mensagem encapsula cada sessão recebida ou MENSAGEM independente num pedido MSRP SEND. Assim cada pedido MSRP SEND representa uma sessão SIP ou MENSAGEM que contém uma carga útil (um ou mais pedidos MSRP SEND, ou algum outro tipo no caso de mensagem).
Contudo, com os supramecanismos o utilizador B não está autorizado a recuperar uma mensagem seleccionada (por exemplo, enviada por um dado utilizador, durante uma trama de tempo específica, cujo assunto é um especifico, ou com uma dada prioridade). Particularmente, não há mecanismo 13 ΕΡ1938536Β1 onde utilizador B possa indicar ao servidor de correio qual mensagem o utilizador está interessado em receber.
Primeira Forma de Realização A Fig. 4 mostra um diagrama de sinalização que ilustra mensagens trocadas entre utilizadores e um servidor de aplicação (AS) de armazenar mensagem de acordo com uma primeira forma de realização. Como mostrado na Fig. 4, Alice envia uma Mensagem Instantânea a Charlie usando um pedido SIP MESSAGE (fluxo 1). Este pedido de MESSAGE contém texto, chamado aqui Texto #1. Assumindo que Charlie está offline, a mensagem é recebida e armazenada no Servidor de Aplicação(AS) de armazenar mensagem.
Outro utilizador, Bob, cria uma sessão SIP enviando um pedido INVITE (fluxo 3) a Charlie. 0 pedido INVITE contém uma descrição de sessão que inclui um descritor MSRP para o propósito de enviar mensagens instantâneas com base em sessão. Como Charlie está offline, o AS de armazenar mensagem intercepta o pedido INVITE e estabelece a sessão. Então Charlie deposita duas mensagens em conta de mensagens de Charlie, usando pedidos MSRP SEND (fluxos 5 e 7, incluindo um Texto #2 e Texto #3, respectivamente). Isto é, as mensagens actuais são enviadas com pedidos MSRP SEND. Mensagem #9 é um pedido SIP BYE que termina a sessão de mensagens instantâneas.
Mais tarde, Charlie liga à rede e assina notificações de sumário de mensagem, enviando um pedido SIP SUBSCRIBE (mensagem #11) ao seu servidor de correio, isto é o AS de 14 ΕΡ1938536Β1 armazenar mensagem.
As notificações estão incluídas no pedido NOTIFY (mensagem #13) . As notificações que o utilizador recebe da assinatura do pacote de evento de sumário de mensagem e indicador de espera de mensagem contêm, entre outros exemplos, um identificador único de cada mensagem, no formato de um cabeçalho Message-ID. 0 servidor de correio selecciona a Message-ID para cada mensagem. Num mapeamento típico, a Message-ID na notificação pode conter o mesmo valor como o campo de cabeçalho Call-ID nos pedidos SIP MESSAGE ou SIP INVITE (que iniciaram a sessão MSRP), ou a Message-ID na notificação pode conter o mesmo valor como o campo de cabeçalho Message-ID no pedido MSRP SEND. Depois de Charlie ter selecionado a mensagem a ser recuperada, ele cria um pedido INVITE (mensagem #15) endereçado à mensagem específica a ser recuperada. Há dois exemplos de implementação alternativos e similares da primeira forma de realização:
Exemplo de Implementação A: 0 servidor de correio copia o campo de cabeçalho Call-ID incluído em SIP para o cabeçalho Message-ID do sumário de mensagem, ou copia o cabeçalho Message-ID do pedido MSRP SEND para o cabeçalho Message-ID do sumário de mensagem. Assim, cada SIP MESSAGE armazenada, sessão MSRP completa (que tem sido iniciada por um SIP INVITE) , ou pedido MSRP SEND individual é unicamente identificado pela Message-ID. Agora, quando o utilizador selecciona uma mensagem 15 ΕΡ1938536Β1 particular a ser recuperada, do sumário de mensagem, a mensagem armazenada é alocada um único SIP URI que está integrado no cabeçalho Message-ID no sumário de mensagem.
Isto permite recuperar mensagens uma por uma se fossem depositadas com um pedido SIP MESSAGE. Se as mensagens fossem depositadas com uma colecção de pedidos MSRP SEND (dentro de uma sessão INVITE-BYE), então a solução permite recuperar quer todas as mensagens MSRP que foram parte da sessão identificada pelo Call-ID do SIP INVITE, quer cada pedido MSRP SEND individual armazenado. 0 seguinte é um exemplo da notificação de sumário de mensagem que utilizador B recebe. A notificação indica que duas novas mensagens de texto estão à espera de ser recuperadas. NOTIFY sip:charlie0pc.exemplo.com SIP/2.0 Para: <sip:charlie@exemplo.com>;tag=7 8 92 3 De: <sip:servidordecorreio.exemplo.com>; tag=4 4 42 Data: Seg, 10 de Jul 2000 04:28:53 GMT Contacto: <sip:servidordecorreio.exemplo.com>
Call-ID: adsf0923jsdjw CSeq: 31 NOTIFY Evento: sumário de mensagem Estado de Assinatura: activa
Tipo de Conteúdo: aplicação/sumário de mensagem simples
Tamanho de Conteúdo: 503 Espera de Mensagens: sim
Conta de Mensagem: sip:charlie@servidordecorreio. 16 ΕΡ1938536Β1 exemplo.com
Mensagem de texto: 2/0 (1/0)
Para: <charlie@exemplo.com>
De: <alice@exemplo.org>
Assunto: partilhar carro amanhã?
Data: Dom, 09 de Jul de 2000 21:23:01 -0700 Prioridade: normal
Message-ID: 32098d@alicepc.exemplo.org
Para: <charlie@exemplo.com>
De: <bob@exemplo.com>
Assunto: AJUDA! em casa doente, apresenta por mim por favor
Data: Dom, 09 de Jul de 2000 21:25:12 -0700 Prioridade: urgente
Message-ID: d0982dkjs@bobmobile.exemplo.com É assumido que Charlie quer recuperar apenas a segunda mensagem, que tem sido enviada por bob@exemplo.com e está identificada por um cabeçalho Message-ID cujo valor é 0982dkjs@bobmobile.exemplo.com. Charlie então cria um pedido S IP INVITE endereçado a um SIP URI (cujo formato geral é "sip:nomedeutilizador@nomedeanfitrião") composto como segue:
- o valor escapado da Message-ID seleccionada, como o nome de utilizador no URI - o nome de anfitrião do servidor de correio (isto é 17 ΕΡ1938536Β1 tipicamente pré-configurado no Agente Utilizador SIP).
Isto é, o utilizador (isto é Charlie) mapeia o identificador único da mensagem instantânea armazenada num identificador válido para recuperação.
Continuando com nosso exemplo, Charlie cria um pedido SIP INVITE (por exemplo mensagem #15 na Fig. 4) cujo Request-URI é: sip:dO 982dkj s%4 Obobmobile.exemplo.comQservidordecorrei o.exemplo.com 0 "%40" é o caracter escapado correspondente a um sinal "@" (isto é prática padrão em SIP).
Por exemplo, o utilizador (isto é Charlie) vai enviar o seguinte INVITE (apenas cabeçalhos relevantes são impressos) ao servidor de correio de voz (o AS de armazenar mensagem) em mensagem #15.
INVITE sip:dO 982dkj s%4 Obobmobile.exemplo.com@servidordecorrei o.exemplo.com SIP/2.0
De: <sip:charlie@exemplo.com>
Para: <sip:dO 982dkj s%4 Obobmobile.exemplo.com@servidordecorre io.exemplo.com>
Este pedido INVITE é encaminhado ao servidor de correio (o AS de armazenar mensagem) de acordo com 18 ΕΡ1938536Β1 procedimentos SIP regulares. 0 servidor de correio extrai o "nome de utilizador", desprotege-o para obter a ID de mensagem original, recupera essa mensagem, e envia-a a Charlie. Para este propósito, os mecanismos descritos no pedido provisório de patente "Método e Aparelho para Mensagens Instantâneas" podem ser aplicados.
Por exemplo, o AS de armazenar mensagem pega na mensagem #3 SIP INVITE armazenada na Figura 4, nos pedidos #5 e #7 MSRP SEND armazenados, e na mensagem #9 SIP BYE armazenada, e encapsula-os num pedido MSRP SEND (não mostrado), também com o tipo de mensagem configurado para mensagem/sip (Secção 27.5 de RFC 3261) ou mensagem/sipfrag (RFC 3420).
Exemplo de Implementação B:
Esta implementação é essencialmente a mesma como A. A única diferença é que o servidor de correio povoa o cabeçalho Message-ID, não com o valor do cabeçalho Call-ID da SIP MESSAGE ou INVITE que depositou a mensagem instantânea, mas em vez disso, com um único URI que aponta ao servidor de correio e identifica a mensagem.
Por exemplo, o seguinte é o mesmo pedido NOTIFY como indicado com o exemplo de implementação A, mas modificado para exemplo de implementação B: NOTIFY sip:charlieQpc.exemplo.com SIP/2.0 Para: <sip:charlie®exemplo.com>;tag=78 923 De: <sip:servidordecorreio.exemplo.com>;tag=4442 19 ΕΡ1938536Β1
Data: Seg, 10 de Jul de 2000 04:28:53 GMT Contacto: <sip:servidordecorreio.exemplo.com>
Call-ID: adsf0923jsdjw CSeq: 31 NOTIFY Evento: sumário de mensagem Estado de Assinatura: activa
Tipo de Conteúdo: aplicação/ sumário de mensagem simples
Tamanho de Conteúdo: 503 Espera de Mensagens: sim
Conta de Mensagem: sip:charlieQservidordecorreio.exemplo.com Mensagem de texto: 2/0 (1/0)
Para: <charlie0exemplo.com>
De: <alice@exemplo.org>
Assunto: partilhar carro amanhã?
Data: Dom, 09 de Jul de 2000 21:23:01 -0700 Prioridade: normal
Message-ID: 1209320servidordecorreio.exemplo.com
Para: <charlie@exemplo.com>
De: <bob@exemplo.com>
Assunto: AJUDA! Em casa doente, apresenta por mim por favor
Data: Dom, 09 de Jul de 2000 21:25:12 -0700 Prioridade: urgente
Message-ID: 12O9330servidordecorreio.exemplo.com
Assim, se Charlie quer recuperar a mesma segunda 20 ΕΡ1938536Β1 mensagem entregue por Bob, vai criar um pedido INVITE endereçado ao valor da Message-ID alocado pelo servidor de correio a essa mensagem, gue unicamente identifica a mensagem no servidor. Nesta alternativa, não é preciso traduzir a Message-ID recebida para algo, antes de criar o Request-URI da mensagem SIP, isto é, o valor da Message-ID da mensagem a ser recuperada é copiada para o Request-URI do pedido SIP. INVITE sip:12 0933@servidordecorreio.exemplo.com SIP/2.0
De: <sip:charlie@exemplo.com>
Para: <sip:120933@servidordecorreio.exemplo.com> Segunda Forma de Realização
Similar ao de cima é assumido que um utilizador tem estado offline durante algum tempo, e alguns outros utilizadores têm depositado uma ou mais mensagens instantâneas no AS de armazenar mensagem, tipicamente usando uma combinação de SIP (Protocolo de Iniciação de Sessão, RFC 3261) e MSRP (Protocolo de Retransmissão de Sessão de Mensagem, Rascunho de Internet draft-ietfsimple-message-sessions-12.txt) como protocolos. Quando o utilizador está online (ligado à rede) o utilizador pode recuperar todas as mensagens instantâneas armazenadas, por exemplo, aplicando os mecanismos descritos no pedido provisório de patente "Método e Aparelho para Mensagens Instantâneas". Contudo, este mecanismo opera em TODAS as mensagens instantâneas armazenadas. 21 ΕΡ1938536Β1 A primeira forma de realização supradescrita permite que o utilizador seleccione quer uma e exactamente uma mensaqem instantânea para recuperação (se a mensagem foi entregue com um pedido SIP MESSAGE) , uma e exactamente uma sessão de mensagens instantâneas (se fossem depositadas usando SIP INVITE e um número de pedidos MSRP SEND), ou uma e exactamente uma mensagem MSRP SEND. Este mecanismo apresenta um problema se o utilizador quer recuperar mais de uma mensagem instantânea ou mais de uma sessão de mensagens instantâneas ou mais de uma (mas não todas) mensagens MSRP SEND pertencentes à mesma sessão, porque para cada acção de recuperação o utilizador tem de estabelecer uma sessão SIP separada (isto é, o utilizador tem que enviar um pedido SIP INVITE separado) ao servidor de correio.
Isto obviamente apresenta problemas, especialmente em ambientes móveis. Por um lado, isto cria atrasos em entre mensagens recuperadas consecutivas, devido à adição 1.5 idas e voltas (INVITE-200-ACK) ao fluxo de sinalização. Adicionalmente, cada destes pedidos INVITE pode conter um grande número de cabeçalhos, assim ai número de bytes transferidos entre o agente utilizador e o servidor de correio não é negligivel.
De acordo com a segunda forma de realização é assumido que: - Mensagens instantâneas endereçadas a um utilizador particular têm sido depositadas num servidor de correio. 22 ΕΡ1938536Β1 - Há um mecanismo em lugar pelo qual o utilizador é informado de um sumário das mensagens instantâneas pendentes de serem recuperadas. Este mecanismo inclui um identificador único de cada mensagem no servidor de correio. Um exemplo de tal mecanismo é descrito em RFC 3842, " Pacote de Evento de Sumário de Mensagem e Indicação de Espera de Mensagem para o Protocolo de Iniciação de Sessão (SIP)". - Há um mecanismo que permite que o utilizador mapeie o identificador único das mensagens instantâneas armazenadas num identificador válido para recuperação. Um exemplo de tal mecanismo é descrito na primeira forma de realização. Há um mecanismo pelo que o utilizador pode estabelecer uma sessão para recuperar uma ou mais mensagens instantâneas armazenadas. Um exemplo de tal mecanismo é descrito no pedido provisório de patente "Método e Aparelho para Mensagens Instantâneas".
De acordo com a segunda forma de realização, um AS de armazenar mensagem ou anfitrião de servidor de correio é modelado como uma entidade virtual que compreende:
Um explorador de servidor de lista URI para transacções SIP INVITE, também conhecido como um servidor de conferência de acordo com "Estabelecimento de Conferência Usando Listas Contidas com pedidos no Protocolo de Iniciação de Sessão (SIP)", draft-ietf- 23 ΕΡ1938536Β1 sipping-uri-list-conferencing-03.txt, cujo conteúdo é incorporado no presente documento por referência.
Um ou mais Agentes Utilizadores SIP virtuais, também contidos no mesmo anfitrião de servidor de correio. Cada destes Agentes Utilizadores SIP virtuais representa um recurso, que no caso da invenção, é efectivamente uma armazenada mensagem instantânea ou sessão de mensagens instantâneas. Uma caracteristica é que cada mensagem instantânea ou sessão de mensagens instantâneas é identificada por um identificador uniforme de recurso (URI) único. A Fig. 5 esquematicamente mostra o modelo do anfitrião de servidor de correio (servidor de correio de mensagem instantânea), integrando um servidor de conferência e um número de Agentes Utilizadores SIP virtuais, cada um representando uma mensagem instantânea armazenada . A Fig. 6 mostra um diagrama de sinalização que ilustra mensagens trocadas entre um utilizador e o servidor de correio de mensagem instantânea de acordo com a segunda forma de realização.
Tendo modelado o servidor de correio como indicado, quando um utilizador quer recuperar uma selecção de mensagens instantâneas armazenadas configurando uma única sessão SIP, o agente utilizador envia um único pedido SIP INVITE (mensagem #1) que contém dois corpos de mensagem: 0 Protocolo de Descrição de Sessão (RFC 2327) para configurar a sessão de mensagem instantânea, e uma lista URI (como 24 ΕΡ1938536Β1 indicado em draft-ietf-sippinguri-list-conferencing-03.txt) . 0 SDP indica a vontade de estabelecer pelo menos um fluxo de media de mensagem com base em MSRP (draft-ietf-simple-mensage-sessionsl2.xt). A lista URI contém um ou mais URIs, cada um unicamente identificando uma mensagem instantânea armazenada no servidor que o utilizador quer recuperar. 0 servidor de correio responde com uma resposta 200 OK (mensagem #2) que contém SDP que indica um fluxo de media de mensagem com base em MSRP.
Depois de receber tal pedido INVITE, a parte de servidor de conferência do servidor de correio exploda o pedido INVITE para cada dos Agentes Utilizadores SIP virtuais que identificam a mensagem armazenada. 0 servidor de conferência envia um pedido INVITE que inclui SDP para cada dos URIs indicados na lista URI do INVITE recebido. Por outras palavras, o servidor de conferência do servidor de correio envia um pedido INVITE a cada dos URIs contidos na lista URI do INVITE (#1) . Estes são pedidos INVITE #4, #5, um #6 na Figura 6. Cada um contém um corpo SDP que indica a vontade de estabelecer pelo menos um fluxo de media de mensagem com base em MSRP.
Isto cria uma conferência centralizada virtual entre o utilizador final e cada dos Agentes Utilizadores SIP virtuais que identificam uma dada mensagem. Então cada destes Agentes Utilizadores SIP virtuais envia a mensagem instantânea armazenada ao servidor de conferência, que por seu turno, as retransmite ao utilizador final. Por outras palavras, os Agentes Utilizadores SIP virtuais respondem com uma mensagem 200 OK contendo o seu próprio SDP 25 ΕΡ1938536Β1 (mensagens #7, #8, e #9 na Figura 6), e então enviam a armazenada mensagem (ou sessão de mensagens instantâneas), por exemplo, aplicando os procedimentos indicados no pedido provisório de patente "Método e Aparelho para Mensagens Instantâneas" (isto correspondes às restantes mensagens #13 a #24 na Figura 6).
Em particular, cada Agente Utilizador SIP virtual pode pegar na MENSAGEM armazenada, reter os cabeçalhos relevantes de pedidos SIP MESSAGE (por exemplo, De, Para, Call-ID, P-Asserted-Identity, etc.)λ encapsula-a como ou uma mensagem/sip (Secção 27.5 de RFC 3261) ou mensagem/sipfrag (RFC 3420), e envia-a como a carga útil de um pedido MSRP SEND (mensagens #13, #17, #21 na Figura 6).
Similarmente, cada agente utilizador SIP virtual pode pegar na mensagem SIP INVITE armazenada, nos correspondentes pedidos MSRP SEND, e na correspondente mensagem SIP BYE armazenada, e encapsulá-los noutro pedido MSRP SEND (mensagens #13, #17, #21), também com o tipo de mensagem configurado para mensagem/sip ou mensagem/sipfrag. Similarmente, cada agente utilizador SIP virtual pode pegar no pedido MSRP SEND armazenado, encapsulá-lo como mensagem/msrp, e enviá-lo como a carga útil de um pedido MSRP SEND (#13, #17, #21) .
A invenção cobre todas combinações e permutações possíveis. Por exemplo, o pedido MSRP SEND #13 pode encapsular um pedido MSRP SEND armazenado, enquanto o pedido MSRP SEND #15 pode encapsular um pedido SIP MESSAGE, ou o pedido MSRP SEND #17 pode encapsular um pedido SIP 26 ΕΡ1938536Β1 INVITE que inclui todos os pedidos MSRP SEND enviados como parte dessa sessão e um pedido SIP BYE.
Depois de um SIP UA virtual ter entregue a sua mensagem instantânea armazenada ao servidor, envia um pedido BYE (mensagens #25, #27, e #29 na Figura 6) ao servidor de conferência para terminar a sessão. Depois de o último SIP UA virtual ter desligado, o servidor de conferência envia um pedido BYE (mensagem #31) ao utilizador para terminar a sessão.
No fim, o utilizador final tem recuperado uma selecção das mensagens instantâneas armazenadas em apenas uma sessão de sinalização. É para ser notado que o servidor de correio é considerado para ser composto por um servidor de conferência e um número de Agentes Utilizadores SIP virtuais, cada um representando uma mensagem instantânea armazenada. Uma implementação monolítica do servidor de correio é considerada, que é ainda decomposta para melhor compreensão. Contudo, isto não impõe uma restrição de uma implementação, e implementações podem decidir separar em diferentes anfitriões cada dos componentes do servidor de correio. Em tal caso, o termo "servidor de correio" é usado para referir à colecção destes anfitriões.
Também é para ser notado que, no caso da implementação monolítica do servidor de correio, as interfaces que são definidas entre o servidor de conferência e cada do Agente Utilizador SIP virtual tornam-se chamadas internas ou uma 27 ΕΡ1938536Β1 AP I definida, mas não precisam de ser necessariamente implementadas com SIP. É importante notar que formas de realização da invenção também são aplicáveis a mecanismos de entrega "push" de mensagem offline. Em sistemas de entrega push, o servidor de aplicação de armazenar mensagens sabe quando um utilizador offline volta a online, isto é quer por SIP SUBSCRIBE/NOTIFY e/ou qualquer outro mecanismo.
Deve ser entendido que a supradescrição é ilustrativa da invenção e não é para ser construída como limitando a invenção. Várias modificações e aplicações podem ocorrer a esses peritos na tecnologia sem se afastarem do âmbito da invenção como definido pelas reivindicações em anexo.
Lisboa, 12 de Abril de 2013 28

Claims (12)

  1. ΕΡ1938536Β1 REIVINDICAÇÕES 1. Um dispositivo terminal (10) que compreende: meios (11) para receber um sumário de mensagens pendentes de serem recuperadas por um utilizador, cada mensagem associada a um identificador único; meios (12) para seleccionar pelo menos uma das mensagens a ser recuperada, com base no sumário de mensagens; meios (13) para determinar um identificador válido para recuperação da pelo menos uma mensagem com base no identificador único associado à pelo menos uma mensagem, obtendo assim pelo menos um identificador válido para recuperação; e meios (14) para enviar um pedido de recuperação com pelo menos um identificador válido para recuperação, o pedido de recuperação que estabelece uma sessão para entregar a pelo menos uma mensagem ao utilizador; caracterizado por as mensagens pendentes de serem recuperadas serem mensagens instantâneas, uma sequência de mensagens de protocolo de iniciação de sessão relacionadas com as mensagens instantâneas, respectivamente, ter sido interceptada e armazenada 1 ΕΡ1938536Β1 por um servidor de aplicação, o pedido de recuperação ser uma mensagem invite de protocolo de iniciação de sessão, e em resposta ao pedido de recuperação os meios de recepção estarem configurados para receber mensagens de protocolo de iniciação de sessão encapsuladas das mensagens de protocolo de iniciação de sessão armazenadas pelo servidor de aplicação, que estão relacionadas com a pelo menos uma mensagem. 2. 0 dispositivo terminal da reivindicação 1, em que o identificador único é um identificador de mensagem. 3. 0 dispositivo terminal da reivindicação 1, em que o identificador único é um Identificador Uniforme de Recurso (URI).
  2. 4. Um dispositivo de rede (20) para armazenar mensagens pendentes de serem recuperadas por um utilizador, o dispositivo de rede que compreende: meios de recepção (21) para receber um pedido de recuperação com pelo menos um identificador válido para recuperar pelo menos uma mensagem das mensagens armazenadas, o pedido de recuperação que estabelece uma sessão para entregar a pelo menos uma mensagem ao utilizador; e meios de envio (22) para enviar a pelo menos uma mensagem ao utilizador que origina o pedido de 2 ΕΡ1938536Β1 recuperação dentro da sessão; o dispositivo de rede caracterizado por as mensagens pendentes de serem recuperadas serem mensagens instantâneas; o dispositivo de rede (20) que está adaptado para interceptar e armazenar uma sequência de mensagens de protocolo de iniciação de sessão relacionadas com as mensagens instantâneas, respectivamente; o pedido de recuperação ser uma mensagem invite de protocolo de iniciação de sessão; e os meios de envio (22), para enviar a pelo menos uma mensagem ao utilizador que origina o pedido de recuperação dentro da sessão, estar configurado para encapsular e enviar mensagens de protocolo de iniciação de sessão das mensagens de protocolo de iniciação de sessão armazenadas, que estão relacionadas com a pelo menos uma mensagem, em resposta à mensagem invite de protocolo de iniciação de sessão.
  3. 5. O dispositivo de rede da reivindicação 4, em que os meios de envio estão configurados para enviar a pelo menos uma mensagem numa mensagem SEND de Protocolo de Retransmissão de Sessão de Mensagem (MSRP).
  4. 6. O dispositivo de rede da reivindicação 4, que ainda 3 ΕΡ1938536Β1 compreende : meios de fornecimento (23) para fornecer um identificador de mensagem para cada uma das mensagens armazenadas, em que os meios de envio estão configurados para enviar um sumário das mensagens armazenadas ao utilizador, cada mensagem associada ao identificador de mensagem fornecido. 7. 0 dispositivo de rede da reivindicação 6, em que os meios de fornecimento estão configurados para usar um campo de cabeçalho CA11-ID incluído num pedido de Protocolo de Iniciação de Sessão de cada das mensagens armazenadas para o identificador de mensagem fornecido. 8. 0 dispositivo de rede da reivindicação 6, em que os meios de fornecimento estão configurados para usar um campo de cabeçalho Message-ID de um pedido de Protocolo de Retransmissão de Sessão de Mensagem de cada das mensagens armazenadas para o identificador de mensagem fornecido. 9. 0 dispositivo de rede da reivindicação 6, em que os meios de fornecimento estão configurados para gerar um Identificador Uniforme de Recurso (URI) único, o URI que é encaminhável ao dispositivo de rede e em que o identificador de mensagem fornecido é parte do URI.
  5. 10. Um método de recuperar mensagens pendentes de serem 4 ΕΡ1938536Β1 recuperadas por um utilizador, o método que compreende: receber (S31) um sumário das mensagens armazenadas no servidor de correio e pendentes de serem recuperadas pelo utilizador, cada mensagem associada a um identificador único; selecionar (S32) pelo menos uma mensagem das mensagens a ser recuperada do servidor de correio, com base no sumários de mensagens; determinar (S33) um identificador válido para recuperação da pelo menos uma mensagem com base no identificador único associado à pelo menos uma mensagem, obtendo assim pelo menos um identificador válido para recuperação; e enviar (S34) um pedido de recuperação com o pelo menos um identificador válido para recuperação, o pedido de recuperação que estabelece uma sessão para entregar a pelo menos uma mensagem ao utilizador, caracterizado por as mensagens pendentes de serem recuperadas serem mensagens instantâneas, uma sequência de mensagens de protocolo de iniciação de sessão relacionadas com as mensagens instantâneas, respectivamente, ter sido interceptada e armazenada por um servidor de aplicação, 5 ΕΡ1938536Β1 o pedido de recuperação ser uma mensagem invite de protocolo de iniciação de sessão, e em resposta ao pedido de recuperação mensagens de protocolo de iniciação de sessão encapsuladas das mensagens de protocolo de iniciação de sessão armazenadas pelo servidor de aplicação, que estão relacionadas com a pelo menos uma mensagem, serem recebidas. 11. 0 método da reivindicação 10, em que o identificador único é um identificador de mensagem.
  6. 12. O método da reivindicação 10, em que o identificador único é um Identificador Uniforme de Recurso (URI).
  7. 13. Um método de recuperar mensagens armazenadas pendentes de serem recuperadas por um utilizador, o método que compreende: receber (S41) um pedido de recuperação com pelo menos um identificador válido para recuperar pelo menos uma mensagem das mensagens armazenadas, o pedido de recuperação que estabelece uma sessão para entregar a pelo menos uma mensagem ao utilizador; e enviar (S42) a pelo menos uma mensagem ao utilizador que origina o pedido de recuperação dentro da sessão, caracterizado por 6 ΕΡ1938536Β1 as mensagens pendentes de serem recuperadas serem mensagens instantâneas, uma sequência de mensagens de protocolo de iniciação de sessão relacionadas com as mensagens instantâneas, respectivamente, ter sido interceptada e armazenada, o pedido de recuperação ser uma mensagem invite de protocolo de iniciação de sessão, e por enviar (S42) a pelo menos uma mensagem ao utilizador que origina o pedido de recuperação dentro da sessão, mensagens de protocolo de iniciação de sessão das mensagens de protocolo de iniciação de sessão armazenadas, que estão relacionadas com a pelo menos uma mensagem, serem encapsuladas e enviadas em resposta à mensagem invite do protocolo de iniciação de sessão. 14. 0 método da reivindicação 13, que ainda compreende: fornecer um identificador de mensagem para cada uma das mensagens armazenadas; e enviar um sumário das mensagens armazenadas ao utilizador, cada mensagem associada ao identificador de mensagem fornecido. 15. 0 método da reivindicação 13, em que a pelo menos uma mensagem é enviada numa mensagem SEND de Protocolo de Retransmissão de Sessão de Mensagem (MSRP). 7 ΕΡ1938536Β1 16. 0 método da reivindicação 14, em que um campo de cabeçalho Call-ID incluido num pedido de Protocolo de Iniciação de Sessão de cada das mensagens armazenadas é usado para o identificador de mensagem fornecido. 17. 0 método da reivindicação 14, em que o campo de cabeçalho Message-ID de um pedido de Protocolo de Retransmissão de Sessão de Mensagem de cada das mensagens armazenadas é usado para o identificador de mensagem fornecido. 18. 0 método da reivindicação 14, que compreende: gerar um Identificador Uniforme de Recurso (URI) único, o URI que é encaminhável a um dispositivo de rede que armazena as mensagens pendentes de serem recuperadas pelo utilizador, em que o identificador de mensagem fornecido é de parte do URI.
  8. 19. Um dispositivo de rede para armazenar mensagens pendentes de serem recuperadas por um utilizador, o dispositivo de rede que compreende: um servidor de conferência; e pontos de extremidade virtuais correspondentes às mensagens instantâneas armazenadas; em que o servidor de conferência está configurado para receber um pedido de recuperação do utilizador que compreende uma lista de identificadores cada apontando 8 ΕΡ1938536Β1 a uma mensagem seleccionada das mensagens instantâneas armazenadas, o pedido de recuperação gue estabelece uma primeira sessão de protocolo de iniciação de sessão para entregar as mensagens seleccionadas, para estabelecer segundas sessões para cada uma das mensagens selecionadas identificadas na lista com os pontos de extremidade virtuais correspondentes às mensagens selecionadas, e para receber as mensagens selecionadas dentro de ditas segundas sessões e reencaminhar as mensagens seleccionadas ao utilizador dentro de dita primeira sessão de protocolo de iniciação de sessão.
  9. 20. O dispositivo de rede da reivindicação 19, em gue os pontos de extremidade virtuais são Agentes Utilizadores de Protocolo de Iniciação de Sessão (SIP) virtuais.
  10. 21. Um método de recuperar mensagens instantâneas armazenadas num servidor de correio e pendentes de serem recuperadas por um utilizador, o método gue compreende: receber um pedido de recuperação do utilizador que compreende uma lista de identificadores cada apontando a uma mensagem seleccionada das mensagens instantâneas armazenadas, o pedido de recuperação que estabelece uma primeira sessão de protocolo de iniciação de sessão para entregar as mensagens seleccionadas, estabelecer segundas sessões para cada uma das mensagens seleccionadas identificadas na lista com os pontos de extremidade virtuais correspondentes às 9 ΕΡ1938536Β1 mensagens seleccionadas; e receber as mensagens seleccionadas dentro de ditas segundas sessões e reencaminhar as mensagens seleccionadas ao utilizador dentro de dita primeira sessão de protocolo de iniciação de sessão.
  11. 22. Um produto de programa de computador que inclui um programa para um dispositivo de processamento, compreendendo partes de código de software para realizar as etapas de qualquer uma das reivindicações 10 a 18 ou 21 quando o programa é corrido no dispositivo de processamento. 23. 0 produto de programa de computador de acordo com a reivindicação 22, em que o produto de programa de computador compreende um meio legível de computador em que as partes de código de software estão armazenadas.
  12. 24. O produto de programa de computador de acordo com a reivindicação 22, em que o programa é directamente carregável numa memória interna do dispositivo de processamento. Lisboa, 12 de Abril de 2013 10
PT68095900T 2005-10-19 2006-10-13 Recuperação de mensagens instantâneas offline PT1938536E (pt)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US72787005P 2005-10-19 2005-10-19
US11/350,088 US9258259B2 (en) 2005-09-30 2006-02-09 Retrieval of offline instant messages

Publications (1)

Publication Number Publication Date
PT1938536E true PT1938536E (pt) 2013-04-18

Family

ID=37769349

Family Applications (1)

Application Number Title Priority Date Filing Date
PT68095900T PT1938536E (pt) 2005-10-19 2006-10-13 Recuperação de mensagens instantâneas offline

Country Status (9)

Country Link
US (1) US9258259B2 (pt)
EP (1) EP1938536B1 (pt)
JP (1) JP2009512931A (pt)
KR (1) KR100966959B1 (pt)
DK (1) DK1938536T3 (pt)
ES (1) ES2403188T3 (pt)
PL (1) PL1938536T3 (pt)
PT (1) PT1938536E (pt)
WO (1) WO2007046046A1 (pt)

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7561595B2 (en) * 2005-09-30 2009-07-14 Nokia Corporation Method and apparatus for instant messaging
CN100514968C (zh) 2005-10-11 2009-07-15 华为技术有限公司 离线消息的处理方法和即时消息服务器
US20070115926A1 (en) * 2005-10-27 2007-05-24 3Com Corporation System and method for receiving a user message at a packet-network telephone
BRPI0520621A2 (pt) * 2005-10-28 2009-06-13 Ericsson Telefon Ab L M método para distribuir mìdia de um servidor de conteúdo baseado em rede para dois ou mais clientes participantes, terminal cliente, servidor de conteúdo, servidor de controle de sessão, e, terminal de usuário
TWI407740B (zh) * 2006-03-13 2013-09-01 Nokia Corp 對話啟始協定多媒體服務之刪除機構
RU2404549C2 (ru) * 2006-04-03 2010-11-20 Нокиа Корпорейшн Механизм удаления сообщения или файла в мультимедийных службах, работающих по протоколу sip
JP4910542B2 (ja) * 2006-07-27 2012-04-04 富士通株式会社 Ｓｉｐメッセージ引渡プログラム
CN101207577B (zh) * 2006-12-19 2011-04-13 华为技术有限公司 消息系统间的互连方法及消息互连网关
US8606861B2 (en) * 2007-04-27 2013-12-10 Cellco Partnership Method, apparatus, and computer program product for reducing session related message size
CN101110792A (zh) * 2007-08-08 2008-01-23 腾讯科技（深圳）有限公司 一种即时通信终端中管理会话消息的系统和方法
JP5226798B2 (ja) * 2007-11-16 2013-07-03 テレフオンアクチーボラゲット エル エム エリクソン（パブル） イベントパケット処理の方法
WO2010019205A1 (en) * 2008-08-12 2010-02-18 Google Inc. Touring in a geographic information system
JP5522985B2 (ja) * 2009-06-30 2014-06-18 パナソニック株式会社 通信装置、通信システム及びセッション制御方法
US20110053565A1 (en) * 2009-08-26 2011-03-03 Telefonaktiebolaget Lm Ericsson (Publ) System and method for delivering a message digest
US8495153B1 (en) * 2009-12-14 2013-07-23 Emc Corporation Distribution of messages in nodes connected by a grid architecture
CN101895842B (zh) * 2010-08-09 2014-06-04 华为终端有限公司 一种唤醒离线移动终端的方法、装置和系统
CN101964717A (zh) * 2010-10-18 2011-02-02 苏州阔地网络科技有限公司 一种基于即时通群组发起会议的方法
US8861509B2 (en) * 2011-06-27 2014-10-14 Intel Mobile Communications GmbH Communication devices and methods for generating a message
ES2751133T3 (es) * 2011-06-29 2020-03-30 Orange Motor de notificaciones
CN103369121B (zh) * 2012-04-09 2015-10-28 腾讯科技（深圳）有限公司 未读消息显示方法和装置
CN104518953B (zh) * 2013-09-30 2019-12-24 腾讯科技（深圳）有限公司 删除消息的方法、即时通信终端及系统
CN103812762B (zh) * 2013-11-27 2017-12-01 大唐移动通信设备有限公司 一种发送即时消息的方法和系统
US9871753B2 (en) 2015-04-08 2018-01-16 Blackberry Limited Method, device and system for distinct forwarding of a plurality of messages selected as a group
US10649609B2 (en) * 2016-03-31 2020-05-12 Microsoft Technology Licensing, Llc Universal notification pipeline
US11005802B1 (en) * 2020-06-25 2021-05-11 Sony Corporation Importance determination for undelivered messages
CN115002137B (zh) * 2022-08-03 2022-10-21 广州此声网络科技有限公司 离线消息处理方法、装置、计算机设备和存储介质

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5923848A (en) * 1996-05-31 1999-07-13 Microsoft Corporation System and method for resolving names in an electronic messaging environment
US6052709A (en) * 1997-12-23 2000-04-18 Bright Light Technologies, Inc. Apparatus and method for controlling delivery of unsolicited electronic mail
US5999932A (en) * 1998-01-13 1999-12-07 Bright Light Technologies, Inc. System and method for filtering unsolicited electronic mail messages using data matching and heuristic processing
US6493007B1 (en) * 1998-07-15 2002-12-10 Stephen Y. Pang Method and device for removing junk e-mail messages
US6728714B1 (en) * 1999-11-30 2004-04-27 International Business Machines Corporation System and method for assigning unique identifier to deleted unopened original sender e-mail after delivery
US6981041B2 (en) * 2000-04-13 2005-12-27 Aep Networks, Inc. Apparatus and accompanying methods for providing, through a centralized server site, an integrated virtual office environment, remotely accessible via a network-connected web browser, with remote network monitoring and management capabilities
CN101695058A (zh) * 2000-08-11 2010-04-14 纽约市哥伦比亚大学托管会 在数据网络通话系统中提供通信服务的方法
DE60144097D1 (de) * 2000-09-13 2011-04-07 Entegris Inc Vorrichtung zum filtern von flüssigen medien
US7174368B2 (en) * 2001-03-27 2007-02-06 Xante Corporation Encrypted e-mail reader and responder system, method, and computer program product
US7058687B2 (en) * 2001-04-03 2006-06-06 Sendmail, Inc. E-mail system with methodology for accelerating mass mailings
US7194252B1 (en) * 2001-12-13 2007-03-20 Bellsouth Intellectual Property Corp. Remote electronic mailbox access
JP2004342098A (ja) 2003-04-25 2004-12-02 Daiwa Securities Group Inc 情報配信システム、方法及びプログラム
KR100877745B1 (ko) 2003-05-08 2009-01-12 빔플리시티 엘티디. 인스턴트 음성 메시징 및 인스턴트 음성 메시지 검색 방법및 시스템, ｉｖｍ 서버
JP2005073160A (ja) 2003-08-27 2005-03-17 Nippon Telegr & Teleph Corp <Ntt> セッション制御方法及びシステム装置
JP4264016B2 (ja) * 2004-03-22 2009-05-13 株式会社日立製作所 通信制御装置及び通信制御装置におけるフィルタリング方法
CA2603149C (en) * 2005-03-24 2014-08-26 Telefonaktiebolaget Lm Ericsson (Publ) Method and arrangement in a communication system for delivering messages to a recipient
US8533271B2 (en) * 2006-02-10 2013-09-10 Oracle International Corporation Electronic mail recovery utilizing recorded mapping table

Also Published As

Publication number Publication date
EP1938536B1 (en) 2013-03-13
ES2403188T3 (es) 2013-05-16
DK1938536T3 (da) 2013-05-13
JP2009512931A (ja) 2009-03-26
US9258259B2 (en) 2016-02-09
US20070078935A1 (en) 2007-04-05
EP1938536A1 (en) 2008-07-02
WO2007046046A1 (en) 2007-04-26
KR20080048078A (ko) 2008-05-30
PL1938536T3 (pl) 2013-07-31
KR100966959B1 (ko) 2010-06-30

Similar Documents

Publication Publication Date Title
PT1938536E (pt) Recuperação de mensagens instantâneas offline
US5826039A (en) Universal connection point for resources and communication unrelated to a physical endpoint
US5742763A (en) Universal message delivery system for handles identifying network presences
US5832221A (en) Universal message storage system
EP0782315B1 (en) Universal directory service
KR100936189B1 (ko) 저장 메시지 전달 방법과 저장 메시지 애플리케이션 서버로사용하기 위한 장치와 컴퓨터 판독가능 매체
EP1861970B1 (en) Method and arrangement in a communication system for delivering messages to a recipient
US8170189B2 (en) Cross-platform message notification
EP1635521A1 (en) Reducing storage requirement for route information
US7249161B2 (en) Method and system for facilitating instant messaging transactions between disparate service providers
CN110933180B (zh) 一种通信建立方法、装置、负载设备及存储介质
JP2014241641A (ja) セッション開始プロトコルアダプタ
US20100331021A1 (en) Method and system for interworking between instant messaging service and short message service
EP2560329A1 (en) Method and processing system for routing message request
BRPI0717609A2 (pt) Sistema e método para fornecer serviços combinacionais a chamadores anônimos
US20100201686A1 (en) Method, apparatus, computer-readable medium and use for pharmacokinetic modeling
US8738718B2 (en) Systems and methods for facilitating creating calendar entries in client devices
WO2008100019A1 (en) Method for providing cpm service using device profile
CN101292480A (zh) 脱机即时消息的取回