(12) TŁUMACZENIE PATENTU EUROPEJSKIEGO (19) PL (11) PL/EP (96) Data i numer zgłoszenia patentu europejskiego:

Transkrypt

1 RZECZPOSPOLITA POLSKA (12) TŁUMACZENIE PATENTU EUROPEJSKIEGO (19) PL (11) PL/EP (96) Data i numer zgłoszenia patentu europejskiego: (13) (51) T3 Int.Cl. H04L 12/58 ( ) Urząd Patentowy Rzeczypospolitej Polskiej (97) O udzieleniu patentu europejskiego ogłoszono: Europejski Biuletyn Patentowy 2013/11 EP B1 (54) Tytuł wynalazku: Pobieranie wiadomości błyskawicznych offline (30) Pierwszeństwo: US P US (43) Zgłoszenie ogłoszono: w Europejskim Biuletynie Patentowym nr 2008/27 (45) O złożeniu tłumaczenia patentu ogłoszono: Wiadomości Urzędu Patentowego 2013/07 (73) Uprawniony z patentu: Nokia Corporation, Espoo, FI (72) Twórca(y) wynalazku: PL/EP T3 MIGUEL A. GARCIA-MARTIN, Helsinki, FI ADAMU HARUNA, Tampere, FI (74) Pełnomocnik: rzecz. pat. Anna Stenzel JAN WIERZCHOŃ & PARTNERZY BIURO PATENTÓW I ZNAKÓW TOWAROWYCH ul. Żurawia 47/ Warszawa Uwaga: W ciągu dziewięciu miesięcy od publikacji informacji o udzieleniu patentu europejskiego, każda osoba może wnieść do Europejskiego Urzędu Patentowego sprzeciw dotyczący udzielonego patentu europejskiego. Sprzeciw wnosi się w formie uzasadnionego na piśmie oświadczenia. Uważa się go za wniesiony dopiero z chwilą wniesienia opłaty za sprzeciw (Art. 99 (1) Konwencji o udzielaniu patentów europejskich).

2 16205/13/P-RO/AS EP Opis Tło Wynalazku Dziedzina Wynalazku Pobieranie wiadomości błyskawicznych offline [0001] Wynalazek dotyczy wiadomości błyskawicznych opartych na protokołach SIP (protokół inicjowania sesji, ang. Session Initiation Protocol)/SIMPLE (protokół komunikacji w czasie rzeczywistym oparty na protokole SIP, ang. SIP for Instant Messaging and Presence Leveraging Extensions). Wynalazek dotyczy zwłaszcza problemu, który pojawia się, gdy serwer poczty przechowuje wiadomości błyskawiczne w sieci dla dalszego ich doręczenia do użytkownika końcowego (przypuszczalnie, gdy użytkownik łączy się z siecią w późniejszym czasie). [0002] Zakłada się, że użytkownik A wysyła jedną lub większą liczbę wiadomości błyskawicznych do użytkownika B. Technologia zastosowana do dostarczania tych wiadomości może być oparta na sposobie SIP MESSAGE (WIADOMOŚĆ) lub protokole MSRP (ang. Message Session Relay Protocol, protokół transmisji danych błyskawicznych). Zakłada się również, że użytkownik B nie jest zarejestrowany na swoim serwerze SIP, i że serwer aplikacji pocztowej przechowuje rzeczywiste wiadomości tekstowe dla późniejszego dostarczenia do użytkownika B. [0003] Gdy użytkownik B rejestruje się do swojej sieci SIP, to Klient Użytkownika SIP zapisuje się na pakiet Podsumowanie Wiadomości i Wskaźnik Oczekiwania i otrzymuje powiadomienia o wiadomościach oczekujących na pobranie. Zakłada się, że serwer poczty przechowuje olbrzymie ilości wiadomości błyskawicznych, tak więc użytkownik B otrzymuje powiadomienie, które zawiera podsumowanie tych przechowywanych wiadomości błyskawicznych. [0004] Artykuł Myers et al.: "RFC 1939: Post Office Protocol Version 3" Network Working Group Request for Comments, XX, XX, Maj 1996 ( ), strony 1-20, XP , dotyczy protokołu węzłów poczty w wersji 3 (POP3, ang. Post Office Protocol Version 3), który umożliwia stacji roboczej dynamiczny dostęp do poczty na serwerze, tzn. umożliwia stacji roboczej pobieranie poczty, którą serwer dla niej przetrzymuje. W rozdziale 10 podany jest przykład sesji POP3, w której podsumowanie wiadomości przechowywanych na serwerze jest udostępniane klientowi a klient pobiera wiadomości poprzez wskazanie serwerowi numeru wiadomości, która jest umieszczona w podsumowaniu. [0005] US 2003/ A1 ujawnia system telefonii sieciowej, który umożliwia ujednolicone usług wiadomości. Ogólnie, system obejmuje co najmniej jednego klienta użytkownika funkcjonalnie sprzężonego z siecią danych i serwer powiadamiający funkcjonalnie sprzężony z siecią danych. Klienci użytkownika to telefoniczne punkty końcowe, takie jak autonomiczne urządzenia telefoniczne lub komputery osobiste z odpowiednim oprogramowaniem telefonicznym. Zapewnia się serwer wiadomości, który jest funkcjonalnie sprzężony z siecią danych i odpowiada serwerowi sygnalizującemu. System

3 - 2 - zawiera również serwer mediów, który jest funkcjonalnie sprzężony z siecią i zawiera komputerowe media przechowywania danych do przechowywania plików wiadomości. Serwer mediów odpowiada serwerowi wiadomości i, w momencie wystąpienia warunku wiadomości, jest bezpośrednio dostępny dla strony dzwoniącej do przechowywania pliku wiadomości dla następującego pobrania jej przez stronę, do której zadzwoniono. STRESZCZENIE WYNALAZKU [0006] Wynalazek powinien umożliwić usprawnione pobieranie wiadomości błyskawicznych offline. [0007] Osiąga się to za pomocą urządzenia końcowego według zastrzeżenia 1, sposobu według zastrzeżenia 10, urządzenia sieciowego według zastrzeżenia 4, sposobu według zastrzeżenia 13, urządzenia sieciowego według zastrzeżenia 19 i sposobu według zastrzeżenia 21. [0008] Fig. 1 przedstawia schematycznie schemat blokowy pokazujący konfigurację urządzenia końcowego i urządzenia sieciowego według wynalazku. [0009] Urządzenie końcowe 10 zawiera blok odbierający 11, blok wybierający 12, blok ustalający 13 i blok wysyłający 14. Blok odbierający 11 odbiera podsumowanie wiadomości przechowywanych na serwerze poczty takim jak urządzenie sieciowe 20 i oczekujących na odebranie przez użytkownika, przy czym każda wiadomość jest powiązana z unikalnym identyfikatorem. Blok wybierający 12 wybiera, na podstawie podsumowania wiadomości, co najmniej jedną z wiadomości do pobrania przez serwer poczty. Blok ustalający 13 ustala identyfikator kwalifikujący do pobrania co najmniej jednej wiadomości na podstawie unikalnego identyfikatora powiązanego z co najmniej jedną wiadomością, tym samym otrzymując co najmniej jeden identyfikator kwalifikujący do pobrania. Blok wysyłający 14 wysyła żądanie pobrania z co najmniej jednym identyfikatorem kwalifikującym do pobrania przez serwer poczty. [0010] Unikalnym identyfikatorem może być identyfikator wiadomości udostępniony przez serwer poczty lub jednolity identyfikator zasobów (URI, ang. Uniform Resource Identifier). [0011] Urządzenie sieciowe 20 takie jak serwer poczty przechowuje wiadomości oczekujące na pobranie przez użytkownika, i zawiera blok odbierający 21 i blok wysyłający 22. Blok odbierający 21 odbiera żądanie pobrania z co najmniej jednym identyfikatorem kwalifikującym do pobrania co najmniej jednej z przechowywanych wiadomości, a blok wysyłający 22 wysyła co najmniej jedną wiadomość w kierunku urządzenia końcowego (np. urządzenie końcowe 10) użytkownika inicjującego żądanie pobrania. [0012] Blok wysyłający 22 może wysyłać co najmniej jedną wiadomość w wiadomości protokole MSRP (ang. Message Session Relay Protocol) wiadomości SEND (WYŚLIJ). [0013] Według pierwszego przykładu wykonania, urządzenie sieciowe 20 może również zawierać blok dostarczający 23, który zapewnia identyfikator wiadomości dla każdej z przechowywanych wiadomości, gdzie blok wysyłający 22 wysyła do użytkownika

4 - 3 - podsumowanie przechowywanych wiadomości, np. do urządzenia końcowego 10, przy czym każda wiadomość jest powiązana z ustalonym identyfikatorem wiadomości. [0014] Blok dostarczający 23 może korzystać z pola nagłówka Call-ID zawartego w żądaniu protokołu inicjowania każdej sesji z przechowywanych wiadomość jako identyfikatora wiadomości lub generować unikalny jednolity identyfikator zasobów (URI, ang. Uniform Resource Identifier), przy czym URI może zostać przekierowane do urządzenia sieciowego gdzie identyfikator wiadomości jest częścią URI. [0015] Blok dostarczający 23 może używać pola nagłówka Message-ID żądania protokołu MSRP dla każdej z przechowywanych wiadomości jako identyfikatora wiadomości. [0016] Według drugiego przykładu wykonania, urządzenie sieciowe 20 może zawierać serwer konferencyjny i wirtualne punkty końcowe takie jak wirtualni Klienci Użytkownika SIP odpowiadające przechowywanym wiadomościom. Serwer konferencyjny może odbierać pobrane żądania od użytkownika zawierające listę identyfikatorów wskazujących na wybrane z przechowywanych wiadomości, przy czym żądanie pobrania ustanawiające pierwszą sesję dostarczania wybranych wiadomości ustanawia drugie sesje dla każdej z wybranych wiadomości zidentyfikowanych na liście z wirtualnymi punktami końcowymi odpowiadającymi wybranym wiadomościom, i odbiera wybrane wiadomości w trakcie drugich sesji i przesyła dalej wybrane wiadomości do użytkownika w pierwszej sesji. [0017] Należy zaznaczyć, że konfiguracja przedstawiona na Fig. 1 służy przedstawieniu wynalazku, a urządzenia końcowe i urządzenia sieciowe mogą zawierać kolejne bloki realizujące kolejne funkcje (takie jak przechowywanie bloku w urządzeniu sieciowym 20 do przechowywania wiadomości), które nie są istotne dla zrozumienia wynalazku i opisu, co jest tutaj pominięte. [0018] Fig. 2 przedstawia schemat technologiczny pokazujący sposób pobierania wiadomości z serwera pocztowego od strony urządzenia końcowego 10. W etapie S31, podsumowanie wiadomości przechowywanych na serwerze poczty i oczekujących na pobranie przez użytkownika jest odbierane na urządzeniu końcowym, przy czym każda wiadomość jest powiązana z unikalnym identyfikatorem. W etapie S32, co najmniej jedna z wiadomości do odebrania z serwera pocztowego jest wybierana na podstawie podsumowania wiadomości odebranego w etapie S31. W etapie S33, identyfikator kwalifikujący do pobrania co najmniej jednej wiadomości jest ustalany na podstawie unikalnego identyfikatora powiązanego z co najmniej jedną wiadomością do, tym samym otrzymując co najmniej jeden identyfikator kwalifikujący do pobrania, i w etapie S34 żądanie pobrania z identyfikatorem kwalifikującym do pobrania jest wysyłane do serwera pocztowego. [0019] Fig. 3 przedstawia schemat technologiczny pokazujący sposób pobierania wiadomości z serwera pocztowego od strony urządzenia sieciowego 20. W etapie S41, żądanie pobrania z co najmniej jednym identyfikatorem kwalifikującym do pobrania co najmniej jednej przechowywanej wiadomości jest odbierane, a w etapie S42 co najmniej jedna wiadomość jest wysyłana w kierunku urządzenia końcowego użytkownika inicjującego żądanie pobrania.

5 - 4 - [0020] Według drugiego przykładu wykonania, żądanie pobrania od użytkownika, zawierające listę identyfikatorów wskazujących na wybrane z przechowywanych wiadomości, jest odbierane przez urządzenie sieciowe 20, przy czym żądanie pobrania ustanawia pierwszą sesję dla dostarczenia wybranych wiadomości. Drugie sesje są ustanawiane dla każdej z wybranych wiadomości zidentyfikowanych na liście, a wybrane wiadomości są odbierane w drugiej sesji, wybrane wiadomości są przesyłane dalej do użytkownika w drugiej sesji. Wynalazek może zostać zrealizowany jako produkt w postaci programu komputerowego. [0021] Serwer poczty może zostać zrealizowany jako serwer aplikacji przechowującej pocztę lub serwer poczty wiadomości błyskawicznych. [0022] Według pierwszego przykładu wykonania wynalazku, użytkownik odbiera powiadomienie o podsumowaniu wiadomości, które zawiera unikalną tożsamość wiadomości adresowaną do każdej z przechowywanych wiadomości. Dla każdej z wiadomości, którą użytkownik chce pobrać, klient użytkownika SIP tworzy sesję SIP wiadomości przeznaczonych dla tożsamości wiadomości, np. po dokonaniu jakiś przekształceń. Serwer, podczas odbierania żądania INVITE (ZAPROŚ), jest zdolny do ustalenia w unikalny sposób rzeczywistej wiadomości, którą użytkownik chce odebrać. [0023] Rozwiązanie to umożliwia użytkownikowi wybranie tych przechowywanych wiadomości błyskawicznych, które powinny zostać pobrane. Korzyść jest olbrzymia w sytuacjach mobilnych, gdzie szerokość pasma jest ograniczona a szczególnie w przypadkach, gdzie liczba i rozmiar przechowywanych wiadomości błyskawicznych ma znaczenie. Tak więc, użytkownik może wybrać wiadomości wybrane jako pilne, lub które zostały odebrane od określonego użytkownika, a następnie przeczytać pozostałe wiadomości później. [0024] Według drugiego przykładu wykonania wynalazku, zapewnia się mechanizm, w którym użytkownik, po wybraniu wiadomości błyskawicznych, które chce pobrać z serwera pocztowego, tworzy pojedynczą sesję (SIP INVITE) adresowaną dla wybranych wiadomości, poprzez zastosowanie koncepcji URI-list. Ten przykład wykonania modeluje serwer poczty jako złożony z serwera konferencyjnego i szeregu wirtualnych klientów użytkownika SIP, z których każdy reprezentuje przechowywaną wiadomość błyskawiczną. [0025] Według tego przykładu wykonania, zapewnia się mechanizm wybierania i pobierania wiadomości już przechowywanych na serwerze poczty w optymalny sposób, który może być zastosowany w środowisku mobilnym. Według tego rozwiązania, użytkownik może pobrać nieograniczoną wybraną liczbę przechowywanych wiadomości podczas pojedynczego uruchomienia protokołu. [0026] Rozwiązanie to umożliwia użytkownikowi minimalizację sygnałów i czynności dla pobrania wybranych wiadomości poprzez zastosowanie pojedynczej sesji w kierunku serwera pocztowego. Tymczasowe zgłoszenie patentowe "Method and apparatus for instant messaging" od Garcia et al. złożone w Biurze Patentów i Znaków Towarowych USA 30 września 2005, którego treść włącza się tutaj przez odniesienie i pierwszy przykład wykonania, umożliwiają masowe pobranie przechowywanych wiadomości błyskawicznych

6 - 5 - albo wybranych wiadomości jedna po drugiej (co oznacza, że każda wiadomość wymagała osobnej sesji SIP). [0027] Tym samym, drugi przykład wykonania wynalazku zwiększa zadowolenie użytkownika w związku z mniejszymi opóźnieniami podczas ustanawiania sesji i optymalizuje operowanie zasobami w kanałach o małej szerokości pasma, takich jak interfejs powietrzny. Na rysunkach: [0028] Fig. 1 przedstawia schematyczny schemat blokowy ilustrujący konfigurację urządzenia końcowego i urządzenia sieciowego według wynalazku. [0029] Fig. 2 przedstawia schemat technologiczny pokazujący sposób pobierania według wynalazku. [0030] Fig. 3 przedstawia schemat technologiczny pokazujący sposób pobierania według wynalazku. [0031] Fig. 4 przedstawia schemat sygnałów według pierwszego przykładu wykonania wynalazku. [0032] Fig. 5 przedstawia schemat blokowy ilustrujący serwer poczty według drugiego przykładu wykonania wynalazku. [0033] Fig. 6 przedstawia schemat sygnałów według drugiego przykładu wykonania wynalazku. Opis Przykładu Wykonania Wynalazku [0034] Zakładając, że wiadomości błyskawiczne były przechowywane w skrzynce pocztowej użytkownika, gdy telefon użytkownika zostaje włączony, wysyła on zapisanie się na pakiet zdarzeń podsumowania wiadomości, i odbiera powiadomienie z oczekującą wiadomością; według RFC3842 "Pakiet Zdarzeń Podsumowanie Wiadomości i Wskazanie Oczekującej Wiadomości dla protokołu inicjowania sesji (SIP)." Treść RFC 3842 jest tutaj włączona przez odniesienie. Mechanizm dotyczy również POCZTY GŁOSOWEJ, FAXU itd. Element powiadamiający (klient użytkownika SIP działający w imieniu systemu wiadomości użytkownika) wysyła podsumowanie wiadomości przechowywanych w treści NOTIFY (POWIADOM) np. "są 4 stare wiadomości i 3 nowe wiadomości oczekujące". [0035] Ewentualnie, po zliczeniu wiadomości, nagłówki wiadomości takie jak Do (To), Od (From), Data (Date), Temat (Subject) oraz ID Wiadomości (Message-ID) mogą zostać załączone do każdej wiadomości. [0036] Po powiadomieniu Użytkownika/UE (Urządzenie Użytkownika, ang. User Equipment), może ono wysłać INVITE do serwera zawierające typ żądanych mediów do pobrania (dla powiadomienia grupy Wiadomości w organizacji OMA (ang. Open Mobile Alliance), INVITE musi zawierać opis SDP (Protokół Opisu Sesji) MSRP, lecz może zawierać również inne typy mediów).

7 - 6 - [0037] Dodatkowo, użytkownik może zastosować mechanizm jak opisano w tymczasowym zgłoszeniu patentowym "Method and Apparatus for Instant Messaging" do pobierania wszystkich przechowywanych wiadomości błyskawicznych z serwera pocztowego, w tym informacji z metadanymi (np. wysyłający, czas dostarczenia, itd.). W tym celu, zapewnia się mechanizm SIP do pobierania wiadomości błyskawicznych, które poprzednio były przechowywane na serwerze aplikacji, który działał jako serwer aplikacji przechowywania wiadomości. Można to osiągnąć poprzez zachowywanie istotnych nagłówków wiadomości SIP poprzez enkapsulację ich jako wiadomość/sip, na przykład, jak określono w Paragrafie 27,5 RFC 3261, lub jako wiadomość/sipfrag, jak określono w RFC 3420, a następnie wysyłanie jej jako zawartości żądania MSRP SEND. Zawartość RFC 3261 i 3420 są tutaj włączone przez odniesienie. Dodatkowo, serwer aplikacji przechowywania może następnie dodać nagłówek do wiadomości MSRP SEND i do enkapsulowanej wiadomości SIP zawierającej czas i datę odebrania wiadomości. W szczególności, nagłówek z datą/czasem jest wprowadzany do każdej przechowywanej wiadomości SIP i MRSP. Do enkapsulacji przechowywanych wiadomości błyskawicznych może zostać zastosowana nowatorska semantyka, a wiadomość/sip i wiadomość/sipfrag są używane w MRSP, poza pierwotnym kontekstem. Tym samym, zapewnia się sposób dostarczania enkapsulowanych wiadomości SIP, zawierających informację nagłówka, jako zawartość wiadomości MSRP. [0038] W związku z powyższym mechanizmem, zapewnia się sposób i urządzenie, za pomocą których użytkownik może kontaktować się ze swoim serwerem poczty i pobierać istniejące wiadomości błyskawiczne, które są już przechowywane na serwerze aplikacji przechowującej wiadomości. Wiadomości błyskawiczne mogą być przechowywane na serwerze aplikacji przechowującej wiadomości przy użyciu żądań SIP MESSAGE (jak w IETF RFC 3428) lub wiadomościach MSRP (np. żądania MSRP SEND), które są częścią sesji SIP. Zawartość RFC 3428 jest tutaj włączona przez odniesienie. Metadane i/lub informacja o nagłówku może umożliwić użytkownikowi ustalanie źródła wiadomości, czas o której wiadomość wyszła itd. [0039] Po ustanowieniu sesji SIP z mediami MSRP, wszystkie przechowywane wiadomości zostaną przekazane z serwera do użytkownika/ue. Każda z przechowywanych wiadomości zostanie wysłana w osobnym żądaniu MSRP SEND (zanim odbędzie się podział żądania MSRP SEND na porcje), i każda będzie identyfikowana za pomocą oryginalnego Message- ID. W ten sposób, użytkownik pobiera wszystkie wiadomości naraz, lecz wciąż jest w stanie klasyfikować wszystkie wiadomości za pomocą Message-ID. [0040] Jednym z niedociągnięć niektórych rozwiązań jest to, że oryginalna identyfikacja wysyłającego (informacja użytkownika) przepada, ponieważ nagłówki MSRP nie mają jakiegokolwiek związku z SIP URI, który przechowuje wiadomość. Tak więc, powiązanie wysyłających z ich poszczególnymi wiadomościami już dostępnymi w skrzynkach odbiorczych aplikacji wiadomości takich jak , wiadomości błyskawiczne, MMS itd. przepadnie. Dotyczy to również żądań SIP MESSAGE pod tym względem, że mogą one zostać wysłane, ale odbiorca nie będzie w stanie zidentyfikować wysyłającego, ponieważ jest umieszczana na serwerze aplikacji przechowującej wiadomości.

8 - 7 - [0041] Proponuje się mechanizm za pomocą którego użytkownik, gdy on lub ona chce pobrać swoją przechowywaną wiadomość błyskawiczną, ustanawia sesje MSRP ze swoim serwerem aplikacji przechowującej wiadomości. Wiadomość przechowania AS enkapsuluje każdą pobraną sesję lub MESSAGE autonomiczną w żądaniu MSRP SEND. Tak więc każde żądanie MSRP SEND reprezentuje sesję SIP lub MESSAGE, która zawiera zawartość (jedno lub większa liczba żądań MSRP SEND lub inny typ w przypadku wiadomości). [0042] Mimo to, za pomocą powyższych mechanizmów użytkownik B nie może pobierać wybranej wiadomości (np. wysłanej przez danego użytkownika, podczas określonego okresu czasu, o określonym temacie lub z danym priorytetem). Szczególnie, nie istnieje mechanizm, w którym użytkownik B może wskazać serwerowi poczty, którą wiadomość użytkownik chciałby pobrać. Pierwszy Przykład Wykonania [0043] Fig. 4 przedstawia schemat sygnałów pokazujący wiadomości wymieniane między użytkownikami a serwerem aplikacji (AS, ang. application server) przechowującym wiadomości według pierwszego przykładu wykonania. Jak przedstawiono na Fig. 4, Alice wysyła wiadomość błyskawiczną do Charliego przy użyciu żądania SIP MESSAGE (przepływ 1). Żądanie tej MESSAGE zawiera tekst, nazwany tu Tekst #1. Zakładając, że Charlie jest offline, wiadomość jest odbierana i przechowywana na serwerze aplikacji (AS) przechowującym wiadomości. [0044] Inny użytkownik, Bob, tworzy sesję SIP poprzez wysłanie żądania INVITE (przepływ 3) do Charliego. Żądanie INVITE zawiera opis sesji, który zawiera deskryptor MSRP dla wysłania wiadomości błyskawicznych opartych o sesję. Ponieważ Charlie jest offline, AS przechowujący wiadomość przechwytuje żądanie INVITE i ustanawia sesję. Następnie, Charlie przechowuje dwie wiadomości na koncie wiadomości Charliego przy użyciu żądań MSRP SEND (przepływ 5 i 7, zawierające odpowiednio Tekst #2 i Tekst #3). To znaczy, rzeczywiste wiadomości są wysyłane z żądaniami MSRP SEND. Wiadomość #9 jest żądaniem SIP BYE (ŻEGNAJ), które kończy sesję wiadomości błyskawicznych. [0045] Później, Charlie łączy się z siecią i zapisuje się na powiadomienia o podsumowaniu wiadomości, poprzez wysłanie żądania SIP ZAPISZ SIĘ (wiadomość #11) w kierunku swojego serwera pocztowego, tzn. AS przechowującego wiadomość. [0046] Powiadomienia są zawarte w żądaniu NOTIFY (wiadomość #13). Te powiadomienia, które użytkownik pobiera z zapisania się na pakiet zdarzeń, podsumowanie wiadomości i wskaźnik oczekującej wiadomości zawierają, wśród innych elementów, unikalny identyfikator każdej wiadomości w formacie nagłówka Message-ID. Serwer poczty wybiera Message-ID dla każdej wiadomości. Podczas typowego mapowania, Message-ID w powiadomieniu może zawierać tę samą wartość jak pole nagłówka Call-ID w żądaniach SIP MESSAGE lub SIP INVITE (które rozpoczęły sesję MSRP) lub Message-ID w powiadomieniu może zawierać tę samą wartość jak pole nagłówka Message-ID w żądaniu MSRP SEND. Po wybraniu przez Charliego wiadomości do pobrania, tworzy on żądanie INVITE (wiadomość #15) adresowane do określonej wiadomości do pobrania.

9 - 8 - [0047] Istnieją dwie alternatywne i podobne realizacje przykładów pierwszego przykładu wykonania: Przykład wykonania A: [0048] Serwer poczty kopiuje pole nagłówka Call-ID zawarte w SIP do nagłówka Message- ID podsumowania wiadomości lub kopiuje nagłówek Message-ID żądania MSRP SEND do nagłówka Message-ID podsumowania wiadomości. Tak więc, każda przechowywana SIP MESSAGE, pełna sesja MSRP (która został zapoczątkowana przez SIP INVITE ) lub pojedyncze żądanie MSRP SEND jest unikalnie identyfikowane przez Message-ID. Teraz, gdy użytkownik wybiera określoną wiadomość do pobrania z podsumowania wiadomości, przechowywanej wiadomości jest przypisywane unikalne SIP URI, które jest budowane na nagłówku Message-ID w podsumowaniu wiadomości. [0049] Umożliwia to pobieranie wiadomości jedna po drugiej tak jakby były przechowywane z żądaniem MESSAGE SIP. Jeżeli wiadomości byłyby przechowywana ze zbiorem żądań MSRP SEND (w sesji INVITE-BYE), to rozwiązanie umożliwia pobieranie albo wszystkich wiadomości MSRP, które były częścią sesji identyfikowanej przez Call-ID SIP INVITE lub każdego poszczególnego przechowywanego żądania MSRP SEND. [0050] Poniżej znajduje się przykład powiadomienia o podsumowaniu wiadomości, które otrzymuje użytkownik B. Powiadomienie wskazuje, że dwie nowe wiadomości tekstowe czekają na pobranie. POWIADOM sip:charlie@pc.example.com SIP/2.0 Do: <sip:charlie@example.com>;tag=78923 Od: <sip:mailserver.example.com>;tag=4442 Data: Pon, 10 Lip :28:53 GMT Kontakt: <sip:mailserver.example.com> Call-ID: adsf0923jsdjw CSeq: 31 POWIADOM Zdarzenie: podsumowanie-wiadomości Stan-Zapisania Się: aktywny Typ Zawartości: aplikacja/proste-podsumowanie-wiadomości Długość-Zawartości: 503 Wiadomości-Oczekiwanie: tak Wiadomość-Konto: sip:charlie@mailserver.example.com Tekst-Wiadomość: 2/0 (1/0) Do: <charlie@example.com> Od: <alice@example.org> Temat: jedziemy jutro razem samochodem? Data: Niedz, 09 Lip :23: Priorytet: normalny

10 - 9 - Message-ID: 32098d@alicepc.example.org Do: <charlie@example.com> Od: <bob@example.com> Temat: POMOCY! Chory w domu, zrób za mnie prezentację proszę Data: Niedz, 09 Lip :25: Priorytet: pilne Message-ID: d0982dkjs@bobmobile.example. com [0051] Zakłada się, że Charlie chce pobrać tylko drugą wiadomość, która została wysłana przez bob@example.com i jest identyfikowana przez nagłówek Message-ID, którego wartość wynosi d0982dkjs@bobmobile.example.com. Charlie tworzy następnie żądanie SIP INVITE adresowane do URI SIP (którego format ogólny to "sip:username@ hostname") złożone następująco: - wyjściowa wartość wybranego Message-ID, jako nazwa użytkownika w URI - Nazwa hosta serwera pocztowego (jest to zazwyczaj konfigurowane wcześniej w Kliencie Użytkownika SIP). [0052] To znaczy, użytkownik (np. Charlie) mapuje unikalny identyfikator przechowywanej wiadomości błyskawicznej na identyfikator kwalifikujący do pobrania. [0053] Kontynuując nasz przykład, Charlie tworzy żądanie SIP INVITE (np. wiadomość #15 na Fig. 4), którego Żądanie-URI to: sip:d0982dkjs%40bobmobile.example. com@mailserver.example.com [0054] "%40" to zakodowany symbol odpowiadający znakowi "@" (jest to standardowa praktyka w SIP). [0055] Na przykład, użytkownik (tzn. Charlie) będzie wysyłał następujące INVITE (tylko istotne nagłówki są drukowane) do serwera poczty głosowej (AS przechowującego wiadomości) w wiadomości #15. INVITE sip:d0982dkjs%40bobmobile.example.com@mailserver.example.com SIP/2.0 Od: <sip:charlie@example.com> Do: <sip:d0982dkjs%40bobmobile.example. com@mailserver.exampl e.com> [0056] Te żądanie INVITE jest przekierowywane do serwera pocztowego (AS przechowującego wiadomości) według zwykłych procedur SIP. Serwer poczty wydobywa "nazwę użytkownika", odzyskuje ją dla uzyskania oryginalnego ID wiadomości, pobiera tę wiadomość i wysyła do Charliego. W tym celu można zastosować mechanizm opisany w tymczasowym zgłoszeniu patentowym "Method and Apparatus for Instant Messaging". [0057] Na przykład, AS przechowujący wiadomość bierze przechowywaną wiadomość #3 SIP INVITE na Fig. 4, przechowywane żądania #5 i #7 MSRP SEND i przechowywaną wiadomość #9 SIP BYE i inkapsuluje je w żądaniu MSRP SEND (nie pokazano) również z

11 typem wiadomości ustawionym na wiadomość/sip (Paragraf 27,5 RFC 3261) lub wiadomość/sipfrag (RFC 3420). Przykład realizacji B: [0058] Realizacja jest zasadniczo taka sama jak A. Jedyną różnicą jest to, że serwer poczty wypełnia nagłówek Message-ID nie wartością nagłówka Call-ID SIP MESSAGE lub INVITE, która przechowywała wiadomość błyskawiczną, ale unikalnym URI, które wskazuje na serwer poczty i identyfikuje wiadomość. [0059] Na przykład, poniżej znajduje się takie samo żądanie NOTIFY jak wskazano w przykładzie realizacji A, ale zmodyfikowane do realizacji przykładu B: POWIADOM sip:charlie@pc.example.com SIP/2.0 Do: <sip:charlie@example.com>;tag=78923 Od: <sip:mailserver.example.com>;tag=4442 Data: Pon, 10 Lip :28:53 GMT Kontakt: <sip:mailserver.example.com> Call-ID: adsf0923jsdjw CSeq: 31 POWIADOM Zdarzenie: podsumowanie-wiadomości Stan-Zapisania Się: aktywny Typ Zawartości: aplikacja/proste-podsumowanie-wiadomości Długość-Zawartości: 503 Wiadomości-Oczekiwanie: tak Wiadomość-Konto: sip:charlie@mailserver.example.com Tekst-Wiadomość: 2/0 (1/0) Do: <charlie@example.com> Od: <alice@example.org> Temat: jedziemy razem samochodem jutro? Data: Niedz, 09 Lip :23: Priorytet: normalny Message-ID: @mailserver.example.com Do: <charlie@example.com> Od: <bob@example.com> Temat: POMOCY! Chory w domu, zrób za mnie prezentację proszę Data: Niedz, 09 Lip :25: Priorytet: pilne Message-ID: @mailserver.example.com [0060] Tak więc, jeżeli Charlie chce pobrać tę samą drugą wiadomość dostarczoną przez Boba, stworzy on żądanie INVITE adresowane do wartości Message-ID przypisanej przez

12 serwer poczty do tej wiadomości, który unikalnie identyfikuje wiadomość na serwerze. W tej alternatywie, nie ma potrzeby tłumaczenia odebranego Message-ID na coś innego, przed stworzeniem Żądania-URI SIP MESSAGE, tzn., wartość Message-ID wiadomości do pobrania jest kopiowana do Żądania-URI żądania SIP. ZAPROŚ sip:120933@mailserver.example.com SIP/2.0 Od: <sip:charlie@example.com> Do: <sip:120933@mailserver.example.com> Drugi Przykład Wykonania [0061] Podobnie jak w powyższym, zakłada się, że użytkownik był offline przez jakiś czas, a inni użytkownicy przechowywali jedną lub większą liczbę wiadomości błyskawicznych w AS przechowującym wiadomości, zazwyczaj przy użyciu połączenia SIP (protokół inicjowania sesji, RFC 3261) i MSRP (ang. Message Session Relay Protocol, Internet-Draft draftietfsimple- message-sessions-12.txt) jako protokoły. Gdy użytkownik będzie online (połączony z siecią) użytkownik może pobrać wszystkie przechowywane wiadomości błyskawiczne, np. poprzez stosowanie mechanizmów opisanych w tymczasowym zgłoszeniu patentowym "Method and Apparatus for Instant Messaging". Mimo to, mechanizm ten działa dla WSZYSTKICH przechowywanych wiadomości błyskawicznych. [0062] Opisany powyżej pierwszy przykład wykonania umożliwia użytkownikowi wybranie albo jednej i tylko jednej wiadomości błyskawicznej do pobrania (jeżeli wiadomość została dostarczona z żądaniem SIP MESSAGE), jednej i tylko jednej sesji wiadomości błyskawicznych (jeżeli byłby przechowywane przy użyciu SIP INVITE i kilku żądań SEND MSRP) albo jednej i tylko jednej wiadomości MSRP SEND. Mechanizm sprawia problem, jeżeli użytkownik chce pobrać więcej niż jedną wiadomość błyskawiczną lub więcej niż jedną sesję wiadomości błyskawicznych lub więcej niż jedną (ale nie wszystkie) wiadomość MSRP SEND należącą do tej samej sesji, ponieważ dla każdej akcji pobierania użytkownik musi ustanawiać osobną sesję SIP (tzn. użytkownik musi wysłać osobne żądanie SIP INVITE) do serwera pocztowego. [0063] To wyraźnie sprawia problemy, szczególnie w środowisku mobilnym. Z jednej strony, tworzy to opóźnienia między następującymi po sobie pobranymi wiadomościami, w związku z dodatkowymi 1,5 czynnościami (INVITE-200-ACK) do przepływu sygnałów. Dodatkowo, każde z tych żądań INVITE może zawierać dużą liczbę nagłówków, tak wiec ilość bajtów przekazywanych między klientem użytkownika a serwerem poczty nie jest zaniedbywalna. [0064] Według drugiego przykładu wykonania wynalazku zakłada się, że: - Wiadomości błyskawiczne adresowane do określonego użytkownika mogą być przechowywane na serwerze poczty - Na miejscu istnieje mechanizm, dzięki któremu użytkownik jest informowany o podsumowaniu wiadomości błyskawicznych oczekujących na pobranie. Mechanizm zawiera unikalny identyfikator każdej z wiadomości na serwerze poczty. Przykład takiego mechanizmu jest opisany w RFC 3842 "Pakiet Zdarzeń Podsumowanie

13 Wiadomości i Wskazanie Oczekującej Wiadomości dla protokołu inicjowania sesji (SIP)". - Istnieje mechanizm, który umożliwia użytkownikowi mapowanie unikalnych identyfikatorów przechowywanych wiadomości błyskawicznych do identyfikatora kwalifikującego do pobrania. Przykład takiego mechanizmu jest opisany w pierwszym przykładzie wykonania. - Istnieje mechanizm, za pomocą którego użytkownik może ustanowić sesję do pobrania jednej lub większej liczby wiadomości błyskawicznych. Przykład takiego mechanizmu jest opisany w tymczasowym zgłoszeniu patentowym "Method and Apparatus for Instant Messaging". [0065] Według drugiego przykładu wykonania, AS przechowujący wiadomości lub serwer poczty jest modelowany jako jednostka wirtualna zawierająca: - serwera typu eksploder URI-list do transakcji SIP INVITE, znany również jako serwer konferencyjny według "Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)", draft-ietf-sipping-uri-list-conferencing-03.txt, którego treść włącza się tutaj przez odniesienie. - Jednego lub większą liczbę wirtualnych Klientów Użytkownika SIP, również zawartych na serwerze poczty. Każdy z tych wirtualnych Klientów Użytkownika SIP reprezentuje zasób, który w przypadku wynalazku jest skutecznie przechowaną wiadomością błyskawiczną lub sesją wiadomości błyskawicznych. Cechą charakterystyczną jest to, że każda wiadomość błyskawiczna lub sesja wiadomości błyskawicznych jest identyfikowana za pomocą unikalnego jednolitego identyfikatora zasobu (URI). [0066] Fig. 5 przedstawia schematycznie model hosta serwera pocztowego (serwer poczty wiadomości błyskawicznych), integrujący serwer konferencyjny i szereg wirtualnych Klientów Użytkownika SIP, z których każdy reprezentuje przechowywaną wiadomość błyskawiczną. [0067] Fig. 6 przedstawia schemat sygnałów pokazujący wiadomości wymieniane między użytkownikiem a serwerem poczty wiadomości błyskawicznych według drugiego przykładu wykonania. [0068] Po modelowaniu serwera pocztowego jak wskazano, gdy użytkownik chce pobrać zestaw przechowywanych wiadomości błyskawicznych poprzez ustanowienie pojedynczej sesji SIP, klient użytkownika wysyła pojedyncze żądanie SIP INVITE (wiadomość #1), które zawiera dwie treści wiadomości: Protokół Opisu Sesji (RFC 2327) dla ustanowienia sesji wiadomości błyskawicznych oraz URI-list (jak wskazano w draft-ietf-sippinguri- listconferencing-03.txt). SDP wskazuje gotowość do ustanowienia co najmniej strumienia mediów wiadomości opartego o MSRP (draft-ietf-simple-message-sessions- 12.txt). URI-list zawiera jeden lub większą liczbę URI, z których każdy unikalnie identyfikuje przechowywane wiadomości błyskawiczne na serwerze, które użytkownik chce pobrać.

14 Serwer poczty odpowiada za pomocą odpowiedzi 200 OK (wiadomość #2), która zawiera SDP wskazujący strumień mediów wiadomości oparty o MSRP. [0069] Po odebraniu takiego żądania INVITE, serwer konferencyjny będący częścią serwera poczty wysyła żądanie INVITE do każdego z wirtualnych Klientów Użytkownika SIP, które identyfikują przechowywaną wiadomość. Serwer konferencyjny wysyła żądanie INVITE, które zawiera SDP do każdego z URI wskazanego na liście URI przychodzących INVITE. Innymi słowy, serwer konferencyjny serwera poczty wysyła żądanie INVITE do każdego z URI będącego na liście URI INVITE (#1). Są to żądania INVITE #4, #5 i #6 na Fig. 6. Każdy zawiera treść SDP, która wskazuje gotowość do ustanowienia co najmniej jednego strumienia mediów wiadomości w oparciu o MSRP. [0070] Tworzy to wirtualną, scentralizowaną konferencję między użytkownikiem końcowym a każdym z wirtualnych Klientów Użytkownika SIP, który identyfikuje daną wiadomość. Następnie, każdy z tych wirtualnych Klientów Użytkownika SIP wysyła przechowywaną wiadomość błyskawiczną do serwera konferencyjnego, który z kolei przekazuje je do użytkownika końcowego. Innymi słowy, wirtualni Klienci Użytkownika SIP odpowiadają za pomocą wiadomości 200 OK zawierających swoje własne SDP (wiadomości #7, #8, i #9 na Fig. 6), a następnie wysyłają przechowywane wiadomości (lub sesję wiadomości błyskawicznych), np. poprzez stosowanie procedur wskazanych w tymczasowym zgłoszeniu patentowym "Method and Apparatus for Instant Messaging" (odpowiada to pozostałym wiadomościom od #13 do #24 na Fig. 6). [0071] W szczególności, każdy wirtualny klient użytkownika SIP może wziąć przechowywaną MESSAGE, zatrzymać istotne nagłówki żądań SIP MESSAGE (np., Od, Do, Call-ID, P-Asserted-Identity, itd.), enkapsulować ją albo jako wiadomość/sip (Paragraf 27,5 RFC 3261) lub wiadomość/sipfrag (RFC 3420) i wysłać ją jako zawartość żądania MSRP SEND (wiadomości #13, #17, #21 na Fig. 6). [0072] Podobnie, każdy z wirtualnych klientów użytkownika SIP może wziąć drugą przechowywaną wiadomość SIP INVITE, odpowiadające przechowywane żądania MSRP SEND i odpowiadającą przechowywaną wiadomość SIP BYE i enkapsulować je w innym żądaniu MSRP SEND (wiadomości #13, #17, #21), z typem wiadomości ustawionym na wiadomość/sip lub wiadomość/sipfrag. Podobnie, każdy wirtualny klient użytkownika SIP może wziąć przechowywane żądanie MSRP SEND, enkapsulować je jako wiadomość/msrp i wysłać je jako zawartość żądania MSRP SEND (#13, #17, #21). [0073] Wynalazek obejmuje wszystkie możliwe kombinacje i permutacje. Na przykład, żądanie MSRP SEND #13 może enkapsulować przechowywane żądanie MSRP SEND, podczas gdy żądanie MSRP SEND #15 może enkapsulować żądanie SIP MESSAGE, albo żądanie MSRP SEND #17 może enkapsulować żądanie SIP INVITE, które zawiera wszystkie żądania MSRP SEND wysyłane jako część sesji oraz żądanie SIP BYE. [0074] Po dostarczeniu przez wirtualny SIP UA swojej przechowywanej wiadomości błyskawicznej na serwer, wysyła on żądanie BYE (wiadomość #25, #27 i #29 na Fig. 6) do serwera konferencyjnego dla zakończenia sesji. Po rozłączeniu się ostatniego wirtualnego SIP

15 UA, serwer konferencyjny wysyła żądanie BYE (wiadomość #31) do użytkownika dla zakończenia sesji. [0075] Ostatecznie, użytkownik końcowy pobrał zestaw przechowywanych wiadomości błyskawicznych w jednej sesji sygnałów. [0076] Należy zaznaczyć, że rozważany serwer jest złożony z serwera konferencyjnego i szeregu wirtualnych Klientów Użytkownika SIP, z których każdy reprezentuje przechowywaną wiadomość błyskawiczną. Rozważa się monolityczną realizację serwera pocztowego, który jest rozkładany dla lepszego zrozumienia. Mimo to, nie nakłada to ograniczeń realizacji, a realizując można zdecydować o rozdzieleniu komponentów serwera poczty na różne hosty. W takim przypadku, używane określenie "serwer poczty" odnosi się do zbioru tych hostów. [0077] Należy również zaznaczyć, że w przypadku monolitycznej realizacji serwera pocztowego, interfejsy określone między serwerem konferencyjnym a każdym z wirtualnych Klientów Użytkownika SIP stają się wewnętrznymi wyborami lub określoną API ale nie muszą być koniecznie realizowane za pomocą SIP. [0078] Należy podkreślić, że przykłady wykonania wynalazku stosują się również do mechanizmu dostarczania wiadomości offline typu "push". W systemach dostarczania typu push, serwer aplikacji przechowującej wiadomości wie, kiedy użytkownik offline wraca online, tzn. albo dzięki SIP SUBSCRIBE (ZAPISZ SIĘ)/NOTIFY i/lub dowolnemu innemu mechanizmowi. [0079] Należy zrozumieć, że powyższy opis przedstawia jedynie wynalazek i nie powinien być interpretowany jako ograniczanie wynalazku. Różne modyfikacje i zastosowania mogą przyjść na myśl znawcom, bez odchodzenia od zakresu wynalazku określonego w załączonych zastrzeżeniach. Sporządziła i zweryfikowała Anna Stenzel Rzecznik patentowy

16 Zastrzeżenia patentowe 1. Urządzenie końcowe (10) zawierające: środek (11) do odbierania podsumowania wiadomości oczekujących na pobranie przez użytkownika, przy czym każda wiadomość jest powiązana z unikalnym identyfikatorem; środek (12) do wybierania co najmniej jednej wiadomości do pobrania na podstawie podsumowania wiadomości; środek (13) do ustalania identyfikatora kwalifikującego do pobrania co najmniej jednej wiadomości na podstawie unikalnego identyfikatora powiązanego z co najmniej jedną wiadomością, tym samym otrzymując co najmniej jeden identyfikator kwalifikujący do pobrania; i środek (14) do wysyłania żądania pobrania z co najmniej jednym identyfikatorem kwalifikującym do pobrania, przy czym żądanie pobrania ustanawia sesję dla dostarczenia co najmniej jednej wiadomości do użytkownika; znamienne tym, że wiadomościami oczekującymi na pobranie są wiadomości błyskawiczne, kolejność wiadomości protokołu inicjowania sesji powiązanych z wiadomościami błyskawicznymi jest, odpowiednio, przechwytywana i przechowywana na serwerze aplikacji, żądaniem pobrania jest wiadomość zaproś protokołu inicjowania sesji, a w odpowiedzi na żądanie pobrania, środek odbierający jest skonfigurowany do pobierania enkapsulowanych wiadomości protokołu inicjowania sesji wiadomości protokołu inicjowania sesji przechowywanych przez serwer aplikacji, które są powiązane z co najmniej jedną wiadomością. 2. Urządzenie końcowe według zastrz. 1, w którym unikalny identyfikator jest identyfikatorem wiadomości. 3. Urządzenie końcowe według zastrz. 1, w którym unikalnym identyfikatorem jest jednolity identyfikator zasobu, URI. 4. Urządzenie sieciowe (20) do przechowywania wiadomości oczekujących na pobranie przez użytkownika, przy czym urządzenie sieciowe zawiera: środek odbierający (21) do odbierania żądania pobierania z co najmniej jednym identyfikatorem kwalifikującym do pobrania co najmniej jednej wiadomości z przechowywanych wiadomości, przy czym żądanie pobrania ustanawia sesję dla dostarczenia co najmniej jednej wiadomości do użytkownika; i środek wysyłający (22) do wysyłania co najmniej jednej wiadomości do użytkownika inicjującego żądanie pobrania w sesji; urządzenie sieciowe

17 znamienne tym, że wiadomościami oczekującymi na pobranie są wiadomości błyskawiczne; urządzenie sieciowe (20) jest dostosowane do, odpowiednio, przechwytywania i przechowywania kolejności wiadomości protokołu inicjowania sesji powiązanych z wiadomościami błyskawicznymi; żądaniem pobrania jest wiadomość zaproś protokołu inicjowania sesji; i środek wysyłający (22), do wysyłania co najmniej jednej wiadomości do użytkownika inicjującego żądanie w sesji, jest skonfigurowany do enkapsulacji i wysyłania wiadomości protokołu inicjowania sesji przechowywanych wiadomości protokołu inicjowania sesji, które są powiązane z co najmniej jedną wiadomością, w odpowiedzi na wiadomość zaproś protokołu inicjowania sesji. 5. Urządzenie sieciowe według zastrz. 4, w którym środek wysyłający jest skonfigurowany do wysyłania co najmniej jednej wiadomości w wiadomości SEND protokołu MSRP. 6. Urządzenie sieciowe według zastrz. 4, zawierające ponadto: środek dostarczający (23) służący dostarczaniu identyfikatora wiadomości dla każdej z przechowywanych wiadomości, przy czym środek wysyłający jest skonfigurowany do wysyłania podsumowania przechowywanych wiadomości do użytkownika, przy czym każda wiadomość jest powiązana z zapewnionym identyfikatorem wiadomości. 7. Urządzenie sieciowe według zastrz. 6, w którym środek dostarczający jest skonfigurowany do stosowania pola nagłówka Call-ID zawartego w żądaniu protokołu inicjowania sesji każdej z przechowywanych wiadomości dla zapewnionego identyfikatora wiadomości. 8. Urządzenie sieciowe według zastrz. 6, w którym środek dostarczający jest skonfigurowany do stosowania pola nagłówka Message-ID żądania protokołu MSRP każdej z przechowywanych wiadomości dla zapewnionego identyfikatora wiadomości. 9. Urządzenie sieciowe według zastrz. 6, w którym środek dostarczający jest skonfigurowany do generowania unikalnego jednolitego identyfikatora zasobu, URI, przy czym URI jest przekierowywany do urządzenia sieciowego i w którym zapewniony identyfikator wiadomości jest częścią URI. 10. Sposób pobierania wiadomości oczekujących na pobranie przez użytkownika, przy czym sposób obejmuje: pobieranie (S31) podsumowania wiadomości przechowywanych na serwerze poczty i oczekujących na pobranie przez użytkownika, przy czym każda wiadomość jest powiązana z unikalnym identyfikatorem;

18 wybieranie (S32) co najmniej jednej wiadomość z wiadomości do pobrania z serwera pocztowego na podstawie podsumowania wiadomości; ustalanie (S33) identyfikatora kwalifikującego do pobrania co najmniej jednej wiadomości na podstawie unikalnego identyfikatora powiązanego z co najmniej jedną wiadomością, tym samym otrzymując co najmniej jeden identyfikator kwalifikujący do pobrania; i wysyłanie (S34) co najmniej jednego żądania pobrania z co najmniej jednym identyfikatorem kwalifikującym do pobrania, przy czym żądanie pobrania ustanawia sesję dla dostarczenia co najmniej jednej wiadomości do użytkownika, znamienny tym, że wiadomościami oczekującymi na pobranie są wiadomości błyskawiczne, kolejność wiadomości protokołu inicjowania sesji powiązanych z wiadomościami błyskawicznymi jest, odpowiednio, przechwytywana i przechowywana na serwerze aplikacji, żądaniem pobrania jest wiadomość zaproś protokołu inicjowania sesji, a w odpowiedzi na żądanie pobrania enkapsulowanych wiadomości protokołu inicjowania sesji wiadomości protokołu inicjowania sesji przechowywanych przez serwer aplikacji, które są powiązane z co najmniej jedną wiadomością, są odbierane. 11. Sposób według zastrz. 10, w którym unikalnym identyfikatorem jest identyfikator wiadomości. 12. Sposób według zastrz. 10, w którym unikalnym identyfikatorem jest jednolity identyfikator zasobu, URI. 13. Sposób pobierania przechowywanych wiadomości oczekujących na pobranie przez użytkownika, przy czym sposób obejmuje: odbieranie (S41) żądania pobierania z co najmniej jednym identyfikatorem kwalifikującym do pobrania co najmniej jednej wiadomości z przechowywanych wiadomości, przy czym żądanie pobrania ustanawia sesję dla dostarczenia co najmniej jednej wiadomości do użytkownika; i wysyłanie (S42) co najmniej jednej wiadomości do użytkownika inicjującego żądanie pobrania w sesji, znamienny tym, że wiadomościami oczekującymi na pobranie są wiadomości błyskawiczne, kolejność wiadomości protokołu inicjowania sesji powiązanych z wiadomościami błyskawicznymi jest, odpowiednio, przechwytywana i przechowywana, żądaniem pobrania jest wiadomość zaproś protokołu inicjowania sesji, i

19 dla wysłania (S42) co najmniej jednej wiadomości do użytkownika inicjującego żądanie pobrania w sesji, wiadomości protokołu inicjowania sesji przechowywanych wiadomości protokołu inicjowania sesji, które są powiązane z co najmniej jedną wiadomością, są enkapsulowane i wysyłane w odpowiedzi na wiadomość zaproś protokołu inicjowania sesji. 14. Sposób według zastrz. 13, obejmujący ponadto: zapewnianie identyfikatora wiadomości dla każdej z przechowywanych wiadomości; i wysyłanie podsumowania przechowywanych wiadomości do użytkownika, przy czym każda wiadomość jest powiązana z zapewnionym identyfikatorem wiadomości. 15. Sposób według zastrz. 13, w którym co najmniej jedna wiadomość jest wysyłana w wiadomości SEND protokołu MSRP. 16. Sposób według zastrz. 14, w którym pole nagłówka Call-ID zawarte w żądaniu protokołu inicjowania sesji każdej z przechowywanych wiadomości jest stosowane do zapewnionego identyfikatora wiadomości. 17. Sposób według zastrz. 14, w którym pole nagłówka Message-ID żądania protokołu MSRP każdej z przechowywanych wiadomości jest stosowane dla zapewnionego identyfikatora wiadomości. 18. Sposób według zastrz. 14, obejmujący: generowanie unikalnego jednolitego identyfikatora zasobu, URI, przy czym URI jest przekierowywany do urządzenia sieciowego przechowującego wiadomości oczekujące na pobranie przez użytkownika, przy czym zapewniony identyfikator wiadomości jest częścią URI. 19. Urządzenie sieciowe do przechowywania wiadomości oczekujących na pobranie przez użytkownika, przy czym urządzenie sieciowe zawiera: serwer konferencyjny; i wirtualne punkty końcowe odpowiadające przechowywanym wiadomościom błyskawicznym; przy czym serwer konferencyjny jest skonfigurowany do odebrania żądania pobrania od użytkownika zawierającego listę identyfikatorów, z których każdy wskazuje na wybraną wiadomość z przechowywanych wiadomości błyskawicznych, przy czym żądanie pobrania ustanawia pierwszą sesję protokołu inicjowania sesji dla dostarczenia wybranych wiadomości, dla ustanowienia drugich sesji dla każdej z wybranych wiadomości zidentyfikowanych na liście z wirtualnymi punktami końcowymi odpowiadającymi wybranym wiadomościom, i do odebrania wybranych wiadomości w drugich sesjach i przesłania dalej

20 wybranych wiadomości do użytkownika w pierwszej sesji protokołu inicjowania sesji. 20. Urządzenie sieciowe według zastrz. 19, w którym wirtualnymi punktami końcowymi są Klienci Użytkownika protokołu inicjowania sesji, SIP. 21. Sposób pobierania wiadomości błyskawicznych przechowywanych na serwerze poczty i oczekujących na pobranie przez użytkownika, przy czym sposób obejmuje: odebranie żądania pobrania od użytkownika zawierającego listę identyfikatorów, z których każdy wskazuje na wybraną wiadomość z przechowywanych wiadomości błyskawicznych, przy czym żądanie pobrania ustanawia pierwszą sesję protokołu inicjowania sesji dla dostarczenia wybranych wiadomości, ustanawianie drugich sesji dla każdej z wybranych wiadomości zidentyfikowanych na liście z wirtualnymi punktami końcowymi odpowiadającymi wybranym wiadomościom; i odbieranie wybranych wiadomości w drugiej sesji i przesyłanie wybranych wiadomości do użytkownika w pierwszej sesji protokołu inicjowania sesji. 22. Produkt w postaci programu komputerowego zawierający program do urządzenia przetwarzającego, zawierający części kodu oprogramowania do wykonywania etapów według któregokolwiek z zastrz. od 10 do 18 albo 21 gdy program jest uruchamiany na urządzeniu przetwarzającym. 23. Produkt w postaci programu komputerowego według zastrz. 22, przy czym produkt w postaci programu komputerowego zawiera czytane przez komputer nośnik, na którym przechowywane są części kodu. 24. Produkt w postaci programu komputerowego według zastrz. 22, w którym program jest bezpośrednio ładowany do pamięci wewnętrznej urządzenia przetwarzającego. Sporządziła i zweryfikowała Anna Stenzel Rzecznik patentowy

21 - 20 -

22 - 21 -

23 - 22 -

24 - 23 -

25 - 24 -