DE60210530T2

DE60210530T2 - System und Methode zur Bereitstellung eines vereinheitlichten Nachrichtenformats in einem mobilen Gerät

Info

Publication number: DE60210530T2
Application number: DE60210530T
Authority: DE
Inventors: Gregory M. Burgess
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2001-02-16
Filing date: 2002-02-15
Publication date: 2006-08-24
Anticipated expiration: 2022-02-16
Also published as: EP1235160A3; US7047285B2; US20020116530A1; EP1235160B1; EP1235160A2; DE60210530D1; ATE323309T1

Description

Die vorliegende Erfindung bezieht sich im Allgemeinen auf computer-ausführbare Software, und im Speziellen auf das Senden einer Nachricht über eine Vielzahl von Transportprotokollen.
Unterhaltungselektronik jeglicher Größe enthält heutzutage Controller oder Prozessoren und führt viele Funktionen aus, die innerhalb des Bereichs von Desktopcomputern exklusiv waren. Ein solches Gerät, das Mobiltelefon, welches früher nur zur Übermittlung von Sprachkommunikation bestimmt war, wird heutzutage verwendet, um andere Daten zusätzlich zur Sprachkommunikation zu übermitteln. Manche Mobiltelefone erlauben es den Benutzern heutzutage, sich mit dem Internet zu verbinden und Webseiten zu durchsuchen; andere Mobiltelefone erlauben es den Benutzern heutzutage, Emails zu überprüfen und zu senden, jedoch stellen Stromverbrauch und verfügbarer Speicher eines mobilen Gerätes Größen- und Ressourcenbedingungen an mobile Geräte, die bei einem Desktopcomputer nicht vorhanden sind.
Es stehen viele verschiedene Optionen zum Senden und Empfangen von Nachrichten und deren beigefügten Daten zur Verfügung. Aufgrund der verschiedenen Standards und Verfahren ist es schwieriger geworden, Nachrichten in der Umgebung von mobiler Kommunikationstechnologie zu senden und zu empfangen.
Bis jetzt haben die Größen und Ressourcenbedingungen von mobilen Geräten den Entwicklern von mobiler Kommunikation einen akzeptablen Kommunikationsmechanismus unerreichbar gemacht.
EP-A-1 039 768 offenbart eine Datenübermittlungs- und Empfangsvorrichtung und Verfahren für eine digitale mobile Station. Eine Datenübermittlungs- und Empfangsvorrichtung übermittelt und empfängt eine große Datenkapazität unter Verwendung eines Short Message Service. Gespeicherte Daten werden gelesen und in eine Datenübermittlungsform codiert. Aus den codierten Daten und erzeugten Datenübermittlungs-Headers wer den Benutzerdaten eines Short Message Service gebildet, und Short Message Blöcke inklusive der Benutzerdaten des Short Message Service werden übermittelt.
US-A-5 406 557 offenbart einen Emailhub zwischen Unternehmen. Eingabemodule verbinden zu einem ersten Endbenutzer und konvertieren eine Nachricht, die von dem ersten Endbenutzer in einem universellen Format gesendet wurde. Nachrichten werden durch den Hub unter Verwendung von entweder virtuellem oder physischem Adressieren weitergeleitet.
US-A-5 961 590 offenbart ein System und Verfahren zum Synchronisieren von Email zwischen einem Client-Ort und einem zentralen Ort.
US-A-6 035 327 offenbart eine SMTP-Erweiterung zum Einhalten von Eigenschaften pro Nachricht und pro Empfänger. Das SMTP-Protokoll nimmt eine Nachricht, die entsprechend einem definierten internen Standard formatiert ist, und packt die Nachricht in einen Umschlag.
SHELDON T: "MAPI BLOOMS IN CHICAGO" BYTE, MC GRAW-HILL INC. ST. PETERSBOROUGH, US, vol. 19, no. 11, 1. November 1994, Seiten 163–164, 166–169 offenbart Merkmale bezüglich einer Messaging API.
WO 97 22928 A offenbart ein Messaging-Schnittstellensystem und Verfahren basierend auf objektorientierter Programmierung.
US-A-6 057 841 offenbart ein System und Verfahren zum Verarbeiten elektronischer Nachrichten mit Regeln, die eine Kombination von Gegebenheiten, Aktivitäten oder Ausnahmen darstellen.
US-A-5 627 997 offenbart ein Verfahren und System zum Umwandeln von Computermailnachrichten unter Verwendung einer erweiterbaren Reihe von Umwandlungsroutinen.
GRATTAN N ET AL: "Windows CE Application Programming", 20. Oktober 2000, PRENTICE HALL PTR, UPPER SADDLE RIVER, NJ 07458, USA ist ein Fachbuch, das die Grundbestandteile von Windows CE Programmierung unter Verwendung des Objektspeichers zum Speichern von Dateien, Datenbanken und der Registry betrifft. Registry-Elemente und -Datensätze der Eigenschaftsdatenbank sind ebenso Objekte, die gespeichert werden können.
Es ist die Aufgabe der vorliegenden Erfindung, ein verbessertes System zu bieten, sowie entsprechende computer-lesbare Medien, die computer-ausführbare Instruktionen zum Ausführen von Schritten zum Empfangen und Speichern oder zum Abrufen von Nachrichten innerhalb eines mobilen Gerätes haben, insbesondere unter Berücksichtigung der Speichervoraussetzungen eines mobilen Gerätes, während das Speichern und Abrufen von Nachrichteneigenschaften ermöglicht wird.
Diese Aufgabe wird durch den Gegenstand der unabhängigen Ansprüche 1, 10 und 22 gelöst.
Bevorzugte Ausführungsformen sind durch den Gegenstand der abhängigen Ansprüche definiert.
Die vorliegende Erfindung stellt ein System und Verfahren zum Empfangen und Verteilen von Nachrichten unter Verwendung einer Vielzahl von Kommunikationsprotokollen in einem mobilen Gerät zur Verfügung. Die Erfindung stellt ein Verfahren zur zentralen Kontrolle des Datenstroms durch das Kommunikationssystem zur Verfügung. Die Erfindung stellt Mittel zur Verfügung, eine Nachricht über ein Kommunikationsmedium zu empfangen, es in ein erstes Format zur allgemeinen Verwendung zu übersetzen und es weiter in ein zweites Format zur Datenspeicherung zu übersetzen.
In einem Aspekt der Erfindung steht eine Datenspeicherkomponente in Kommunikation mit einer Anwendung, einem Formular, einem Transport und einem Datenspeicher. Die Anwendung, das Formular und der Transport kommunizieren jeweils mit der Speicherkomponente durch Übergeben von Eigenschaften einer Nachricht zu der Speicherkomponente in einem ersten Format. Die Speicherkomponente übersetzt die Eigenschaften von dem ersten Format in ein zweites Format. Die Speicherkomponente speichert dann die übersetzten Eigenschaften in dem Datenspeicher in dem zweiten Format.
Die Erfindung vereinfacht die Steuerung eines Messaging-Systems eher durch Aufteilen bestimmter Funktionalitäten auf verschiedene Komponenten als durch Integrieren aller Funktionalitäten in eine einzelne Komponente. Diese Vereinfachung verbessert die Fähigkeit eines externen Anbieters, neue Komponenten zu dem System hinzuzufügen. Neben anderen Vorteilen erzielt die vorliegende Erfindung eine erhöhte Effizienz dadurch, dass sie um eine zentralisierte Speicherkomponente herum erstellt ist, die die Übersetzung und den Informationsfluss steuert.
1 ist ein funktionales Blockdiagramm, das die funktionalen Komponenten eines mobilen berechnenden Gerätes darstellt, welches angepasst sein kann, um eine Ausführungsform der vorliegenden Erfindung umzusetzen.
2 ist ein funktionales Blockdiagramm, das ein System darstellt, welches angepasst ist, Nachrichten gemäß einer Implementierung der vorliegenden Erfindung zu organisieren und zu verteilen.
3 ist ein funktionales Blockdiagramm, welches eine Datenspeicherkomponente gemäß einer Implementierung der vorliegenden Erfindung darstellt.
4 ist ein funktionales Blockdiagramm, das eine Nachrichtenspeicherkomponente gemäß einer Implementierung der vorliegenden Erfindung darstellt.
5 zeigt gemäß einer Implementierung der vorliegenden Erfindung eine Nachrichteneigenschaft, die einen Eigenschaftsnamen hat, welcher in eine Eigenschafts-ID und einen Eigenschaftstyp zerlegt ist.
6 zeigt gemäß einer Implementierung der vorliegenden Erfindung die Umformung eines Feldes, welche eine Vielzahl von Steuerungsprogrammübersetzungen erfordert.
7 ist ein logisches Flussdiagramm, das gemäß einer Implementierung der vorliegenden Erfindung einen Prozess zum Setzen von Eigenschaften einer Nachricht innerhalb eines zentralisierten Datenspeichers zeigt.
8 ist ein logisches Flussdiagramm, das gemäß einer Implementierung der vorliegenden Erfindung einen Prozess zum Übersetzen von Eigenschaften von einem allgemein verwendeten Format zu einem Datenspeicherungsformat zeigt.
9 ist ein logisches Flussdiagramm, das gemäß einer Implementierung der vorliegenden Erfindung einen Prozess zum Speichern übersetzter Eigenschaften zeigt.
10 ist ein logisches Flussdiagramm, das gemäß einer Implementierung der vorliegenden Erfindung einen Prozess zum Erlangen von Eigenschaften einer Nachricht innerhalb eines zentralisierten Datenspeichers zeigt.
11 ist ein logisches Flussdiagramm, das gemäß einer Implementierung der vorliegenden Erfindung einen Prozess zum Abrufen von Eigenschaften von einem Speicher zeigt.
12 ist ein logisches Flussdiagramm, das gemäß einer Implementierung der vorliegenden Erfindung einen Prozess zum Übersetzen von Eigenschaften von einem Datenspeicherungsformat zu einem allgemein verwendeten Format zeigt.
Die vorliegende Erfindung stellt ein System und Verfahren zum Ausführen der Organisation von elektronischen Geräten zur Verfügung. Unter anderem ist ein Protokoll offenbart, welches darauf ausgelegt ist, das Empfangen und Verteilen von Nachrichten zu organisieren, die über verschiedene Kommunikationsformate erhalten wurden. Das Protokoll ermöglicht es, Nachrichten, die erhalten wurden und von verschiedenen Kommunikationsformaten zu einem Standardformat übersetzt wurden, auf einem internen Format für einen Datenspeicher abzubilden. Dieses Abbilden zu einem internen Format reduziert die Speicheranforderungen und ermöglicht den restlichen Komponenten in dem Standardformat zu arbeiten, und ermöglicht dabei zukünftige Entwicklungen von externen Quellen.
Illustrative Arbeitsumgebung
1 ist ein funktionales Blockdiagramm, das funktionale Komponenten eines mobilen berechnenden Gerätes 100 darstellt. Das mobile berechnende Gerät 100 hat einen Prozessor 160, einen Speicher 162, einen Display 128, und ein Tastenfeld 132. Der Speicher 162 enthält im Allgemeinen sowohl flüchtigen Speicher (z.B. RAM) und nichtflüchtigen Speicher (z.B. ROM, Flashspeicher, oder ähnliches). Das Mobilgerät 100 beinhaltet ein Betriebssystem 164, wie z.B. Windows CE Betriebssystem von Microsoft Corporation oder anderen Betriebssystemen, welches in dem Speicher 162 liegt und durch den Prozessor 160 ausgeführt wird. Das Tastenfeld 132 kann ein numerisches Druckknopfwählfeld sein (wie z.B. auf einem typischen Telefon), ein Multi-Tastenkeyboard (wie z.B. ein konventionelles Keyboard) oder anderes solches Eingabegerät, welches in der erforderlichen Weise funktionieren würde. Das Display 128 kann ein Flüssigkristalldisplay sein, oder irgendein anderer Typ von Display, welcher üblicherweise in Mobilgeräten verwendet wird. Das Display 128 kann berührungssensitiv sein, und würde dann auch als Eingabegerät funktionieren.
Ein oder mehrere Anwendungsprogramme 166 werden in den Speicher 162 geladen und laufen auf dem Betriebssystem 164. Beispiele von Anwendungsprogrammen schließen Telefonwählprogramme, Emailprogramme, Terminplanungsprogramme, PIM (personal information management) Programme, Textverarbeitungsprogramme, Tabellenkalkulationsprogramme, Internetbrowserprogramme usw. ein. Das Mobilgerät 100 schließt auch nichtflüchtigen Speicher 168 innerhalb des Speichers 162 ein. Der nichtflüchtige Speicher 168 kann verwendet werden, um persistente Informationen zu speichern, welche nicht verloren gehen sollten, wenn das Mobilgerät 100 ausgeschaltet wird. Die Anwendungen 166 können Informationen in dem Speicher 168 verwenden und speichern, so wie z.B. Emails oder andere Nachrichten, die von einer Emailanwendung verwendet werden, Kontaktinformationen verwendet von einem PIM, Termininformationen verwendet von einem Terminplanungsprogramm, Dokumente verwendet von einer Textverarbeitungsanwendung, und ähnliches. Eine Synchronisierungsanwendung befindet sich ebenfalls auf dem Mobilgerät und ist programmiert, um mit einer korrespondierenden Synchronisierungsanwendung zu kommunizieren, die sich auf einem Hostcomputer befindet, um die in dem Speicher 168 gespeicherten Informationen mit den ent sprechenden Informationen, die auf dem Hostcomputer gespeichert sind, synchron zu halten.
Das Mobilgerät 100 hat eine Stromversorgung 170, welche als eine oder mehrere Batterien ausgeführt sein kann. Die Stromversorgung 170 kann des Weiteren eine externe Stromquelle einschließen, so wie z.B. einen Wechselstromadapter oder eine an Strom angeschlossene Dockingstation, welche die Batterien wieder auflädt.
Das Mobilgerät 100 ist auch mit zwei Typen von externen Benachrichtigungsmechanismen gezeigt: eine LED 140 und eine Audioschnittstelle 174. Diese Hilfsmittel können direkt an die Stromversorgung 170 angeschlossen werden, so dass bei einer Aktivierung, diese für eine Dauer eingeschaltet bleiben, die durch den Benachrichtigungsmechanismus vorgegeben ist, selbst dann, wenn der Prozessor 160 und andere Komponenten heruntergefahren sind, um Batterieenergie zu sparen. Die LED 140 kann programmiert sein, dass sie auf unbestimmte Zeit eingeschaltet bleibt, bis der Benutzer aktiv wird, um den eingeschalteten Zustand des Gerätes anzuzeigen. Die Audioschnittstelle 174 wird verwendet, um hörbare Signale dem Benutzer zur Verfügung zu stellen und akustische Signale vom Benutzer zu empfangen. Zum Beispiel kann die Audioschnittstelle 174 mit einem Lautsprecher verbunden sein, zum Erstellen einer hörbaren Ausgabe, und mit einem Mikrofon zum Empfangen einer akustischen Eingabe, sowie z.B. zum Ermöglichen eines Telefongesprächs.
Das Mobilgerät 100 enthält auch Funk 172, der die Funktion zum Übermitteln und Empfangen von Radiofrequenzübermittlungen durchführt. Der Funk 172 ermöglicht kabellose Verbindungen zwischen dem Mobilgerät 100 und der Umgebung über eine Telefongesellschaft oder Serviceanbieter. Die Übermittlungen zu und von dem Funk 172 werden unter der Kontrolle des Betriebssystems 164 ausgeführt. Mit anderen Worten, können Datenübertragungen, empfangen von dem Funk 172, zu Anwendungsprogrammen 166 über das Betriebssystem 164 verteilt werden, und umgekehrt.
Illustratives Nachrichtenorganisierungssystem
2 ist ein funktionales Blockdiagramm, das ein System darstellt, welches angepasst ist, Nachrichten durch ein geeignetes Zuordnungsprotokoll zu organisieren und zu ver teilen, entsprechend einer Ausführungsform der Erfindung. Das Nachrichtensystem 200 schließt einen Nachrichtenspeicher 210, Datenspeicher 220, Übermittlungskomponente 230, Mailanwendung 240 und Nachrichtenbildungskomponente 250 ein. Die Übermittlungskomponente schließt des Weiteren Übermittlungen 231, 232 und 233 ein. Obwohl nur drei Übermittlungen gezeigt werden, gilt es als verstanden, dass mehr Übermittlungen hinzugefügt werden können oder Übermittlungen entfernt werden können, ohne von dem Umfang der Erfindung abzuweichen. Die Nachrichtenbildungskomponente 250 schließt des Weiteren verschiedene Nachrichtenformulare ein, sowie z.B. SMS-Mailformular 251, Internetmailformular 252, und Konferenzanfrageformular 253. In dieser Implementierung ist jedes Nachrichtenformular 250 zugehörig zu einer bestimmten Klasse von Kommunikationsnachrichten. Zum Beispiel ist das SMS-Mail-formular 251 zugehörig zu eingehenden Nachrichten, die über die SMS-Übermittlung 231 geliefert wurden. Obwohl nur drei Nachrichtenformulare gezeigt sind, gilt es als verstanden, dass mehr Nachrichtenformulare hinzugefügt werden können oder Nachrichtenformulare entfernt werden können, ohne von dem Umfang der Erfindung abzuweichen.
Nachrichtenspeicher 210 ist detaillierter in 4 dargestellt und unterhalb beschrieben. Kurz beschrieben, ist der Nachrichtenspeicher 210 eine Softwarekomponente, die Nachrichtenverkehr in einem Nachrichtenformat (z.B. MAPI) zu einem anderen Format (z.B. Windows CE Datenbankformat) zur Speicherung abbildet. Zusätzlich benachrichtigt der Nachrichtenspeicher 210 die andere Komponente von anderen Ereignissen, die in dem System 200 passieren, sowie z.B. die Erzeugung, Modifizierung oder das Löschen eines Nachrichtenobjekts.
Der Datenspeicher 220 ist detaillierter in 3 dargestellt und unterhalb beschrieben. Kurz beschrieben ist der Datenspeicher 220 eine Softwarekomponente, welche als Speichergebiet für Nachrichten agiert. Der Datenspeicher 220 empfängt und speichert Nachrichtenobjektdaten von dem Nachrichtenspeicher 210 in einem Format übereinstimmend mit dem zugrunde liegenden Datenspeichermechanismus, in diesem Fall einer Windows CE Datenbank. Alternativ können andere mögliche Datenbankformate verwendet werden, einschließlich einer Textdatei, Access, SQL und ähnlichem.
Die Übermittlungskomponente 230 schließt verschiedene spezialisierte Nachrichtenübermittlungen ein, wobei jede programmiert ist, zum Kommunizieren mit lokalen Kom ponenten im MAPI Format, und externen Geräten über bestimmte Protokolle (z.B. SMS, SMTP, IMAP, POP, FAX, etc.). Zum Beispiel ist die SMS Übermittlung 231 eine Softwarekomponente, gekoppelt zum Empfangen von Nachrichten im SMS Format. Die SMTP Übertragung 232 ist eine andere Softwarekomponente, gekoppelt zum Übermitteln von Nachrichten im SMTP Format. Die zusätzliche Übermittlung 233 kann gekoppelt sein zum Empfangen irgendeiner von verschiedenen unterschiedlichen Übertragungsformaten, so wie z.B. Faxdatenübertragungen, POP3, IMAP oder ähnliches.
Die Mailanwendung 240 ist eine Softwarekomponente, die als eine prinzipielle Schnittstelle zwischen dem Benutzer und dem System agiert. Die Anwendung ist programmiert zum Kontrollieren einer speziellen Funktion, so wie z.B. Emailverwendung oder Kontaktpflege. Es sollte beachtet werden, dass während der Benutzer in erster Linie durch die Mailanwendung 240 mit dem Nachrichtensystem 200 interagiert, kann es zahlreiche Anwendungen geben, die gleichzeitig zu der Mailanwendung laufen, so wie z.B. einer Textverarbeitung, einem Kalender, etc. Diese anderen Anwendungen sind hier nicht detaillierter beschrieben, da sie nicht sachdienlich zu der vorliegenden Erfindung sind, wie sie in ihrer vorliegenden Form besteht, obwohl sie diese unterstützen können oder durch diese derzeit oder zukünftig unterstützt werden können.
Die Nachrichtenbildungskomponente 250 ist eine Gruppe von speziellen Anzeigeformularen, von denen jedes eine spezialisierte Funktion ausführt. Mit anderen Worten ist jedes Nachrichtenformular eine Softwarekomponente, die programmiert sein kann, um entweder Information für den Benutzer anzuzeigen oder Information von dem Benutzer zu empfangen. Zum Beispiel ermöglicht das SMS Nachrichtenformular 251 dem Betrachter SMS Nachrichten zu empfangen und anzusehen. Ebenso ist das Standardinternetnachrichtenformular 252 ein Nachrichtenformular, das es dem Benutzer erlaubt, Standardinternetnachrichten zu empfangen und anzusehen. Gleichermaßen ist das Nachrichtenformular für Konferenzanfragen 253 ein Nachrichtenformular, das es dem Benutzer erlaubt, Konferenzen anzufragen. Jede Anzahl von anderen Nachrichtenformularen kann eine Anzahl von verschiedenen Nachrichten repräsentieren, die empfangen werden können, so wie z.B. eine Faxnachricht, Sprachnachrichtmeldungen, und ähnliches.
Jede der verschiedenen Komponenten, ausgenommen der Datenspeicher 220, kommuniziert mit jeder anderen unter Verwendung eines standardisierten Nachrichtenprotokolls, so wie z.B. MAPI oder einem Teil von MAPI. Jedoch kommuniziert der Datenspeicher 220 wie oben erwähnt gemäß einem ursprünglichen Format des Betriebssystems. In dieser Ausführungsform verhindert die Verwendung des ursprünglichen Formats des Betriebssystems den Bedarf, neue spezialisierte Datenspeichermechanismen zu erzeugen speziell für das Nachrichtensystem 200. Dieses Merkmal liefert den Vorteil, die Duplizierung von Ressourcen zu reduzieren, was hilft, Platz zu sparen.
3 ist ein funktionales Blockdiagramm, welches den Datenspeicher 220 gemäß einer Ausführungsform der Erfindung detaillierter darstellt. Der Datenspeicher 220 schließt eine Ordnerhierarchietabelle 305, Unterordnertabellen 310, eine Nachrichteneigenschaftstabelle 320, und ein Dateisystem 330 ein. Jede dieser Komponenten wird unterhalb detaillierter beschrieben.
Die Ordnerhierarchietabelle 305 ist eine Softwarekomponente, ausgerichtet zum Identifizieren und Aufrechterhalten der Hierarchie von verschiedenen Nachrichtenordnern, die von dem System verwendet werden können. Die Ordnerhierarchietabelle 305 schließt Pointer zu jeder der verschiedenen Unterordnertabellen ein. Zum Beispiel der Inboxeintrag 306 in der Ordnerhierarchietabelle 305 zeigt auf die Inbox-tabelle 311 der Unterordnertabellen 310. Ebenso zeigt der Outbox-eintrag 307 in der Ordnerhierarchietabelle 305 zu der Outbox-tabelle 312 der Unterordnertabellen 310. Gleichermaßen zeigt der gespeicherte Nachrichteneintrag 308 in der Ordnerhierarchietabelle 305 zu der gespeicherten Nachrichtentabelle 312 der Unterordnertabellen 310. Jede Anzahl von anderen Einträgen, die in der Ordnerhierarchietabelle 305 aufgelistet sind, würde einen entsprechenden Ordner in den Unterordnertabellen 310 aufweisen. Solche Einträge/Unterordner können gelöschte Nachrichten, benutzerdefinierte Ordner und Unterordner und ähnliches einschließen.
Unterordnertabellen 310 sind im Wesentlichen eine Gruppe von Tabellen, die zur Speicherung von Eigenschaften jeder Nachricht verwendet wird, während jede Nachricht in dem Nachrichtensystem 220 verbleibt. In dieser Ausführung werden separate Tabellen verwendet, um jeden Unterordner in der Ordnerhierarchie zu repräsentieren. In dieser Ausführung wird jeder Unterordner gekoppelt, um Nachrichtendaten in dem ursprüngli chen Format des Betriebssystems zu empfangen. Zusätzlich empfängt und speichert jeder Unterordner bestimmte Eigenschaften einer Nachricht aus dem Nachrichtenspeicher 210. Jede Unterordnertabelle ist zum Speichern einer Teilmenge der Eigenschaften für jede Nachricht konfiguriert. Die Teilmenge der Eigenschaften, die zum Speichern in den Unterordnertabellen ausgewählt wird, basiert darauf, welche Eigenschaften zum Anzeigen der Inhalte der Ordner in der Nachrichtenanwendung benötigt werden. Zum Beispiel kann die Eingangstabelle 311 eine Nachrichten-ID-Eigenschaft 315 einschließen, die jede Nachricht eindeutig identifiziert, eine Betreffseigenschaft 317, die Text zum Anzeigen in einer Betreffszeile der Nachricht einschließt, eine Von-Eigenschaft 319, die einen Absender der Nachricht kennzeichnet, und ähnliches. Bestimmte Eigenschaften einer Nachricht, die in den Unterordnertabellen gespeichert sind, können Von, Betreff, Datum und ähnliches einschließen. Obwohl nur drei Tabellen gezeigt werden, gilt es als verstanden, dass mehr Tabellen hinzugefügt werden können oder Tabellen entfernt werden können, ohne vom Gültigkeitsbereich der Erfindung abzuweichen. Durch das Einschließen lediglich einer Teilmenge von Eigenschaften in den Unterordnern anstatt aller Eigenschaften, erzielt die vorliegende Erfindung einen bedeutenden Leistungsvorteil.
Die Nachrichteneigenschaftstabelle 320 ist gekoppelt, um Nachrichtendaten in dem ursprünglichen Format des Betriebssystems zu empfangen, und empfängt und speichert bestimmte Eigenschaften einer Nachricht, die nicht in den Unterordnertabellen 310 gespeichert sind. In einer Ausführungsform empfängt die Nachrichteneigenschaftstabelle 320 Daten, die nicht in den Unterordnertabellen 310 gespeichert sind. Mit anderen Worten fungiert die Nachrichteneigenschaftstabelle 320 als Überlaufspeicher für die Unterordnertabellen 310. Nachrichteneigenschaften, die in der Nachrichteneigenschaftstabelle 320 gespeichert sind, können Nachrichtenhauptteil 321, Anhänge und ähnliches einschließen. Obwohl nur ein einzelner Nachrichtenhauptteil gezeigt ist, gilt es als verstanden, dass mehrere Nachrichtenhauptteile oder andere Eigenschaften hinzugefügt werden können, ohne von dem Gültigkeitsbereich der Erfindung abzuweichen. Eigenschaften, die zu groß zum Speichern in der Nachrichteneigenschaftstabelle 320 sind, können stattdessen in dem Dateisystem 330 gespeichert werden. Jedoch werden die Eigenschaftsidentifikationen ("ID") und ihre Speicherstelle in dem Dateisystem in dem Pointer 322 aufgezeichnet. Zusätzlich gilt es als verstanden, dass, obwohl nur ein einzelner Pointer gezeigt ist, mehrere Pointer hinzugefügt werden können, ohne von dem Gültigkeitsbereich der Erfindung abzuweichen.
Das Dateisystem 330 ist ein Datenspeichermechanismus, welcher von dem Betriebssystem verwendet wird, um computerlesbare Dateien zu speichern. Im Allgemeinen wird das Dateisystem 330 verwendet, um Nachrichtendaten zu speichern, die zu groß sind, um in der Nachrichteneigenschaftstabelle 320 gespeichert zu werden.
4 ist ein funktionales Blockdiagramm, welches die Nachrichtenspeicherkomponente 210 gemäß einer Ausführungsform der Erfindung detaillierter darstellt. Die Nachrichtenspeicherkomponente 210 schließt die Handler-Komponente 410, Standard-Handler 415 und Registrierungstabelle 420 ein. Handler-Komponente 410 schließt des Weiteren die Handler 411, 412 und 413 ein. Obwohl nur drei Handler gezeigt sind, gilt es als verstanden, dass mehrere Handler hinzugefügt oder entfernt werden können, ohne vom Gültigkeitsbereich der Erfindung abzuweichen.
Handler-Komponente 410 schließt mehrere Handler ein, von denen jede eine Softwarekomponente ist, die Eigenschaften von einem Typ, so wie z.B. MAPI, in einen anderen Typ, so wie z.B. Windows CE Datenbankformat, übersetzt. Zum Beispiel kann Handler 411 programmiert sein, um die Eigenschaft "Betreff" einer Nachricht von dem MAPI Format in das Windows CE Datenbankformat zu übersetzen. Ein anderes Beispiel kann der Nachrichtenklassenhandler 412 sein, der verwendet wird, um einen numerischen Kennzeichner abzurufen, der innerhalb des Nachrichtenobjekts gespeichert ist, um eine Nachrichtenklassenzeichenfolge nachzusehen, die mit einem bestimmten numerischen Kennzeichner assoziiert wird, und um eine Nachrichtenklassenzeichenfolge zu dem aufrufenden Programm zurückzugeben. Zusätzliche Handler 413 können irgendeine Anzahl von verschiedenen Handlern repräsentieren, die registriert sind zum Übersetzen bestimmter Eigenschaften einer Nachricht vom MAPI zum Windows CE Datenbankformat, sowie z.B. Von, Empfangsdatum, Hinweis auf einen Anhang oder ähnliches. Standard-Handler 415 ist ähnlich zu den anderen Handlern, wird aber aufgerufen, wenn der Nachrichtenspeicher 210 nicht in der Lage ist, die Kategorie der zu übersetzenden Eigenschaft zu erkennen. Standard-Handler 415 übersetzt die Eigenschaft in eine allgemeine Eigenschaftsform, um das Speichern in den Datenspeicher 220 zu ermöglichen.
Registrierungstabelle 420 ist eine Registrierungsdatenbank, die eine Auflistung mit registrierten Handlern 410 und den bestimmten Nachrichteneigenschaftstypen einschließt, für deren Übersetzung sie registriert sind. Der Standardhandler 415 kann in der Registrierungstabelle 420 registriert sein, um Eigenschaftstypen zu bearbeiten, die andernfalls nicht bearbeitet werden.
5 und 6 sind funktionelle Blockdiagramme, die konzeptionell eine Übersetzung einer MAPI Nachrichteneigenschaft 510 zu einer Windows CE Datenbanknachrichteneigenschaft 630 erstellen. MAPI Nachrichteneigenschaft 510 ist eine Softwarekomponente, die ein Feld mit dem Eigenschaftsnamen 511 und ein Feld mit dem Wert 512 einschließt. Ein Beispiel für den Eigenschaftsnamen 511 könnten PR_SUBJECT sein, welcher die Eigenschaft identifiziert (siehe 6), während das zugehörige Wertfeld 512 die Textzeichenfolge oder die "Nutzdaten" der Betreffszeile der Nachricht sein kann. 5 zeigt eine Zerlegung des Eigenschaftsnamens 511 in eine ID 521 und einen Eigenschaftstyp 522. Der Nachrichtenspeicher 210 ist programmiert, um den Eigenschaftsnamen 511 in die ID 521 und den Typ 522 zu zerlegen, und es dabei ermöglicht, zu ermitteln, welcher Handler instanziiert werden muss, um die Übersetzung des Wertes 512 auszuführen.
6 zeigt konzeptionell im Detail die Übersetzung einer MAPI Nachrichteneigenschaft 510 zu einer Windows CE Datenbanknachrichteneigenschaft 630. Die MAPI Nachrichteneigenschaft 510 kann mit dem Eigenschaftsnamen 511 zerlegt in ein ID Feld 521 und einen Typ 522 gesehen werden. Ebenfalls gezeigt ist der Wert 512. Aufgrund der Eigenschaft der Übersetzung, wie unten beschrieben, schließt die Windows CE Datenbanknachrichteneigenschaft 630 ein Nachrichteneigenschaftspräfix 640 und eine Nachrichteneigenschaftsbasis 650 ein.
Im Betrieb ermittelt der Nachrichtenspeicher 210 den passenden aufzurufenden Handler, um die MAPI Nachrichteneigenschaft 510 auf Grundlage des Eigenschaftstyps 522 zu übersetzen. Der Nachrichtenspeicher 210 würde dann den Handler instanziieren, der registriert ist (siehe 4 und zugehörige Diskussion), um den Wert 512 zu übersetzen. In diesem Beispiel wurde der PR_SUBJECT Handler 620 erzeugt, um die Eigenschaft 510 zu übersetzen. Wenn es keine anderen bestimmten Felder zu übersetzen gibt, gibt die Handlereigenschaft 510 die nun übersetzten Daten an den Nachrichtenspeicher 210 zum Speichern zurück.
Unter manchen Umständen kann die Übersetzung einer einzelnen Eigenschaft in zwei oder mehr übersetzten Eigenschaften (z.B. 640 und 650) resultieren. Zum Beispiel enthält die "Betreff" Eigenschaft einer Nachricht oft irrelevanten Text, der durch mehrfache Übertragung hinzugefügt wurde, wie z.B. der Text "Fw" für Nachrichten, die weitergeleitet wurden, oder der Text "Re" für Nachrichten, auf die geantwortet wurde. In so einem Fall kann der Handler 620 die einzelne Eigenschaft 510 in zwei Eigenschaften aufteilen: eine Eigenschaft 640, welche den eigentlichen Betreffstext enthält, und eine andere Eigenschaft 650, die den Text "Fw" oder "Re" enthält. Auf diese Weise kann ein Nachrichtenformular 250 mehrere Nachrichten richtig sortiert nach "Betreff" anzeigen (z.B. nach Eigenschaft 640), ohne alle Nachrichten zusammenzufassen, die weitergeleitet wurden, und alle Nachrichten zusammenzufassen, auf die geantwortet wurde.
7 ist ein logisches Flussdiagramm, das einen Prozess zum "Setzen" von Eigenschaften darstellt, die in einem Format durch eine Komponente gespeichert wurden, welche in einem anderen Format kommuniziert. Bei der Beschreibung von 7 wird auf das System 200 verwiesen, welches in Verbindung mit 2 beschrieben wurde. Verfahren 700 beginnt an dem Startblock 701, wo eine MAPI Komponente versucht, eine Eigenschaft zu speichern oder zu modifizieren. Zum Beispiel kann eine SMS Übertragung versuchen, eine Eigenschaft, wie z.B. PR_SENT_TIME an einem Nachrichtenobjekt zu verändern. Die Nachrichtendaten können dem Nachrichtenspeicher 210 durch irgendeine der vielen Komponenten (z.B. MAPI Komponenten) präsentiert werden, wie z.B. Übertragungen, Formulare, die Hauptanwendung, oder ähnliches. Ein Beispiel wäre eine SMS Übertragung 231, die SMS Nachrichtendaten empfängt, oder IMAP Nachrichtendaten, die durch eine IMAP Übertragung 232 empfangen wurden, etc..
Der Vorgang beginnt bei Block 705, wo eine oder mehrere Komponenten wie z.B. die Übertragungskomponente 230, die Nachrichtendaten zu dem Nachrichtenspeicher 210 weitergibt. Bei Block 707 bildet der Nachrichtenspeicher 210 die Nachrichtendaten vom MAPI Format auf ein Format ab, welches zu dem Datenspeicher 220 passt. Der Abbildungsvorgang wird detaillierter in 8 unterhalb beschrieben. Kurz gesagt, und auf 2 und 4 verweisend, bezieht der Abbildungsvorgang den Nachrichtenspeicher 210 mit ein, der den Eigenschaftstyp jeder Nachrichteneigenschaft ermittelt, der die Registrierungstabelle 420 befragt, und der den passenden Handler aufruft, um die Nachrichteneigenschaften vom MAPI Format zum Windows CE Datenbankformat zu übersetzen.
Bei Block 709 speichert der Nachrichtenspeicher 210 die übersetzten Nachrichteneigenschaften in den Datenspeicher 220. Der Speichervorgang wird in 9 weiter unterhalb detaillierter beschrieben. Kurz beschrieben und auf 2 und 3 verweisend, ermittelt der Nachrichtenspeicher 210 während des Speichervorgangs, welche der Tabellen (Unterordnertabellen 310, Nachrichteneigenschaftstabelle 320), oder das Dateisystem 330 zur Ablage jeder übersetzten Eigenschaft verwendet werden soll, und speichert anschließend dort die Informationen.
Bei Block 710 endet der Vorgang. An diesem Punkt wurden die in der durch die vorhergehende allgemeine Formel Nachrichtendaten in Windows CE Datenbankformat gespeichert. Es sollte beachtet werden, dass dieser Vorgang durch jede Komponente in dem Nachrichtensystem 200 verwendet werden kann, die mit dem Nachrichtenspeicher in einem Format kommuniziert, welches anders ist, als ein Format, passend zu dem Datenspeicher 220. Zum Beispiel, wenn eine Nachricht erzeugt wird (auf 2 verweisend), wird sie in einem MAPI Format erzeugt und durch den Nachrichtenspeicher 210 im Windows CE Datenbankformat im Datenspeicher 220 gespeichert, unter Verwendung des gerade beschriebenen Vorgangs.
8 ist ein logisches Flussdiagramm, das einen Vorgang zum Ausführen einer Abbildungsfunktion unter Verwendung des offenbarten Protokolls detaillierter darstellt. Bei der Beschreibung von 8 wird auf das System und den Vorgang verwiesen, der in Verbindung mit den 2, 5, 6 und 7 beschrieben wurde. Verfahren 800 beginnt an dem Startblock 801, wo Nachrichtendaten an den Nachrichtenspeicher 210 gegeben werden.
Bei Block 803 empfängt der Nachrichtenspeicher 210 die Nachrichtendaten. Die Nachrichtendaten kommen von anderen Nachrichtensystemkomponenten im MAPI Format an. Bei Block 805 teilt der Nachrichtenspeicher 210 die Nachrichteneigenschaften in abgebildete und nicht abgebildete Nachrichteneigenschaften. Nicht abgebildete Nach rich eneigenschaften werden an Hand der Priorität organisiert und eine Nachrichteneigenschaft wird für die Abbildung identifiziert.
Bei Block 807 ermittelt der Nachrichtenspeicher 210, ob die Nachrichteneigenschaften vom MAPI zum Windows CE Datenbankformat abgebildet werden müssen. Wenn keine Nachrichteneigenschaften zur Abbildung übrig sind, schreitet der Vorgang zu Block 815 weiter. Wenn irgendeine Nachrichteneigenschaft noch nicht vom MAPI zum Windows CE Datenbankformat abgebildet wurde, schreitet der Vorgang zu Block 809 weiter.
Bei Block 809 empfängt der Nachrichtenspeicher eine erste Eigenschaft und ermittelt, ob sie eine Übersetzung vom MAPI zum Windows CE Datenbankformat benötigt. Wenn die Eigenschaft eine Übersetzung nicht benötigt, dann kehrt der Vorgang zu Block 805 zurück. Wenn die Eigenschaft nicht vom MAPI zum Windows CE Datenbankformat übersetzt wurde, schreitet der Prozess zu Block 811 weiter.
Bei Block 811 zerlegt der Nachrichtenspeicher 210 das Eigenschaftsfeld 511 in ein ID Feld 521 und ein Typfeld 522, um den passenden aufzurufenden Handler zu ermitteln. Bei Bock 813 ermittelt der Nachrichtenspeicher 210 auf Basis des Typfeldes 522, welcher Handler aufzurufen ist. Der Nachrichtenspeicher 210 instanziiert anschießend den Handler, welcher das Wertfeld 512 übersetzt. Falls das Wertfeld 512 ein komplexes Feld ist (wie oberhalb detailliert beschrieben und in 6 dargestellt), kann der Handler das Feld in zwei oder mehr andere Eigenschaften übersetzen. Der Vorgang kehrt dann zu Block 809 zurück, um zu ermitteln, ob es zusätzliche Eigenschaften zu übersetzen gibt. Wenn es mehr Eigenschaften zu übersetzen gibt, setzt der Vorgang bei Block 811 fort. Wenn es keine zusätzlichen Eigenschaften zu übersetzen gibt, setzt der Vorgang bei Block 807 fort.
Bei Block 807, wenn alle Nachrichteneigenschaften übersetzt worden sind, schreitet der Vorgang zu Block 815. Bei Block 815 endet der Vorgang. An diesem Punkt sind die Nachrichtendaten durch den Nachrichtenspeicher empfangen worden und in das Windows CE Datenbankformat abgebildet worden.
9 ist ein logisches Flussdiagramm, das einen Vorgang zum Speichern von Informationen in einem Datenspeicher gemäß der Erfindung darstellt. Bei der Beschreibung von
9 wird auf das System und den Vorgang verwiesen, die in Verbindung mit den 2, 3 und 7 beschrieben wurden. Das Verfahren 900 beginnt an dem Startblock 901, wo der Nachrichtenspeicher 210 das Speichern von Daten vorbereitet, die vorher vom MAPI Format zum Windows CE Datenbankformat abgebildet wurden.
Bei Entscheidungsblock 903 ermittelt der Nachrichtenspeicher 210, ob es Nachrichteneigenschaften gibt, die in dem Nachrichtenspeicher 220 gespeichert werden müssen. Wenn alle Nachrichteneigenschaften gespeichert wurden, fährt der Vorgang bei Block 920 weiter und kehrt zu Block 709 des Setzen-Vorgangs 700 von 7 zurück. Wenn irgendwelche Nachrichteneigenschaften nicht gespeichert wurden, fährt der Prozess bei Block 905 fort.
Bei Block 905 erzeugt der Nachrichtenspeicher 210 ein WRITE Objekt 1, um das eigentliche Schreiben von passenden Nachrichteneigenschaften in die passenden Tabellen der Unterordnertabellen 310 auszuführen. Der Nachrichtenspeicher 210 bestückt dann das WRITE Objekt 1 mit den Eigenschaften, die zu den empfangenen Nachrichtendaten korrespondieren.
Bei Block 907 erzeugt der Nachrichtenspeicher 210 ein WRITE Objekt 2, zum Schreiben der passenden Nachrichtendateien an den passenden Orten in der Nachrichteneigenschaftstabelle 320 oder Dateisystem 330. Der Nachrichtenspeicher 210 bestückt dann das WRITE Objekt 2 mit den Nachrichtendaten, die zu den Eigenschaften korrespondieren, die sich in der Nachrichteneigenschaftstabelle 320 befinden.
Bei Block 909 ermittelt der Nachrichtenspeicher 210, ob das WRITE Objekt 1 irgendwelche Eigenschaften enthält, die in Tabellen der Komponente der Unterordnertabellen 310 gespeichert werden müssen. Wenn es keine Eigenschaften zum Speichern in den Tabellen von Unterordnertabellen 310 gibt, dann schreitet der Vorgang zu Block 913 fort. Wenn es Eigenschaften zum Speichern in den Tabellen der Unterordnertabellen 310 gibt, schreitet der Prozess zu Block 911 fort. Bei Block 911 weist der Nachrichtenspeicher 210 das WRITE Objekt 1 an, die identifizierten Eigenschaften in die Tabellen der Unterordnertabellen 310 zu schreiben.
Bei Block 913 ermittelt der Nachrichtenspeicher 210, ob das WRITE Objekt 2 irgendwelche Eigenschaften enthält, die in der Komponente der Nachrichteneigenschaftstabelle 320 gespeichert werden müssen. Wenn es keine Eigenschaften zum Speichern in der Nachrichteneigenschaftstabelle 320 gibt, schreitet der Prozess zu Block 903 fort. Wenn es Eigenschaften zum Speichern in der Nachrichteneigenschaftstabelle 320 gibt, schreitet der Prozess zu Block 915 fort. Bei Block 915 ermittelt der Nachrichtenspeicher 210, ob die Eigenschaftsdaten in den zugewiesenen Platz passen, der in der Nachrichteneigenschaftstabelle 320 verfügbar ist. Wenn dort nicht genügend Platz zum Speichern der Nachrichteneigenschaften verfügbar ist, schreitet der Vorgang zu Block 919 fort. Wenn genügend Platz in der Nachrichteneigenschaftstabelle 320 zum Speichern der Nachrichteneigenschaften verfügbar ist, schreitet der Vorgang zu Block 917 fort.
Bei Block 917 weist der Nachrichtenspeicher 210 das WRITE Objekt 2 an, die identifizierten Eigenschaften in die Nachrichteneigenschaftstabelle 320 zu schreiben. Bei Block 919 weist der Nachrichtenspeicher 210 das WRITE Objekt 2 an, die identifizierten Eigenschaften in das Dateisystem 330 zu schreiben. Zusätzlich fügt das WRITE Objekt 2 einen Pointer in die Nachrichteneigenschaftstabelle 320 zu dem Ort der Datei ein, die die Eigenschaft enthält (siehe 3 und Diskussion oberhalb).
Als nächstes kehrt der Vorgang zu Block 903 zurück, wo er ermittelt, ob es mehr Nachrichteneigenschaften zu speichern gibt. Wenn es Nachrichteneigenschaften zu speichern gibt, wiederholt sich der Vorgang wie oben beschrieben. Wenn es keine weiteren Eigenschaften zu speichern gibt, fährt der Prozess bei Block 920 fort und kehrt zum Hauptprogramm in 7 zurück. An diesem Punkt wurden die Nachrichtendaten empfangen und durch den Datenspeicher 220 im Windows CE Datenbankformat gespeichert.
10 ist ein logisches Flussdiagramm, das allgemein einen Prozess zum Abrufen von Nachrichteneigenschaften von einem Datenspeicher darstellt. Bei der Beschreibung von 10 wird auf das System verwiesen, das in Verbindung mit 2 beschrieben wurde. Verfahren 1000 beginnt bei dem Startblock 1001, wo Nachrichtendaten üblicherweise schon gespeichert sind, so wie z.B. in dem Datenspeicher 220. Die Daten sind üblicherweise auch in einem Format übereinstimmend mit dem Betriebssystem, z.B. Windows CE Datenbankformat. Nachrichtendaten können von einer oder vielen Komponenten angefordert werden (z.B. MAPI Geräte), sowie z.B. Übertragungen, Formulare, die Mailapplikation oder ähnliches. Beispiele von Komponenten, die solche Anfragen machen, können SMS Übertragung 231 oder SMTP Übertragung 232, etc. sein.
Der Vorgang beginnt bei Block 1005, wo eine oder mehrere Komponenten, wie z.B. die Übertragungskomponente 230, eine Nachrichtenanfrage an Nachrichtenspeicher 210 ausgibt. Bei Block 1007 ruft der Nachrichtenspeicher 210 die übersetzten Nachrichteneigenschaften von dem Datenspeicher 220 ab. Die Funktionen, die während des Abrufens der Daten ausgeführt werden, sind in 11 unterhalb dargestellt und beschrieben. Kurz beschrieben und auf 2 und 3 verweisend, ermittelt der Datenspeicher 210, von welchen der Tabellen, Unterordnertabellen 310, Nachrichteneigenschaftstabelle 320, oder dem Dateisystem 330 jede übersetzte Eigenschaft abzurufen ist und ruft dann die Daten ab.
Bei Block 1009 bildet der Nachrichtenspeicher 210 die Nachrichtendaten von dem Format übereinstimmend mit Datenspeicher 220 auf das Format, übereinstimmend mit den anderen Komponenten ab, in diesem Beispiel MAPI. Der Abbildungsvorgang ist detaillierter in 12 dargestellt und unterhalb beschrieben. Kurz beschrieben und auf 2 und 4 verweisend, führt der Abbildungsvorgang den Nachrichtenspeicher 210 dazu, den Eigenschaftstyp jeder Nachrichteneigenschaft zu ermitteln, die Handlerregistrierungstabelle 420 zum Identifizieren des passenden Handlers aufzusuchen, und den passenden Handler aufzurufen, um die Nachrichteneigenschaften von Windows CE Datenbankformat zum MAPI Format zu übersetzen.
Bei Block 1010 endet der Prozess. An diesem Punkt wurden die Nachrichtendaten abgerufen und im MAPI Format der abfragenden Komponente zur Verfügung gestellt. Es sollte beachtet werden, dass dieser Vorgang jederzeit verwendet wird, wenn Daten für das Nachrichtensystem 200 abgerufen werden und diese nicht in einem Format übereinstimmend mit dem Datenspeicher 220 sind. Zum Beispiel, wenn eine Nachricht außerhalb des Mobilgerätes (verweisend auf 2) unter Verwendung der Übertragung 230 übermittelt wurde, wird die Nachricht in einem Windows CE Datenbankformat von dem Datenspeicher 220 abgerufen und wird über den Nachrichtenspeicher 210 auf das MAPI Format abgebildet unter Verwendung des eben beschriebenen Vorgangs.
11 ist ein logisches Flussdiagramm, das einen Vorgang zum Abrufen von Nachrichteneigenschaften von dem Datenspeicher 220 unter Verwendung des offenbarten Protokolls darstellt. Bei der Beschreibung von 11 wird auf das System und den Vorgang verwiesen, der in Verbindung mit den 2, 3 und 10 beschrieben ist. Verfahren 1100 beginnt bei Startblock 1101, wo der Datenspeicher 220 Nachrichtendaten enthält, die vorher vom MAPI Format auf das Windows CE Datenbankformat abgebildet wurden.
Bei Block 1103 ermittelt der Datenspeicher 210, ob Nachrichteneigenschaften zum Abrufen vom Datenspeicher 220 übrig sind. Wenn alle Nachrichteneigenschaften abgerufen worden sind, schreitet der Vorgang zu Block 1120 und kehrt zu Block 1007 von Vorgang 1000 zurück, der in 10 dargestellt ist. Wenn irgendeine Nachrichteneigenschaft noch nicht abgerufen wurde, schreitet der Prozess zu Block 1105 weiter. Bei Block 1105 erzeugt der Nachrichtenspeicher 210 ein READ Objekt, zum Lesen der entsprechenden Nachrichtendateien von den entsprechenden Tabellen in Unterordnertabellen 310 oder Nachrichteneigenschaftstabelle 320, oder zum Lesen der entsprechenden Nachrichtendateien von dem Dateisystem 330. Der Nachrichtenspeicher 210 bestückt dann das READ Objekt mit den abzurufenden Eigenschaften.
Bei Block 1111 weist der Nachrichtenspeicher 210 das READ Objekt an, identifizierte Eigenschaften von den Tabellen in den Unterordnertabellen 310 und Nachrichteneigenschaftstabelle 320 zu lesen und identifizierte Eigenschaften von dem Dateisystem 330 zu lesen.
Als nächstes schreitet der Vorgang zu Block 1103 fort, wo ermittelt wird, ob es mehr Nachrichteneigenschaften zum Abrufen gibt. Wenn es Nachrichteneigenschaften zum Abrufen gibt, kehrt der Vorgang zu Block 1105 (siehe Diskussion oberhalb) zurück. Wenn es keine Eigenschaften zum Abrufen gibt, schreitet der Vorgang zu Block 1120 fort und kehrt zu Block 1007 des Hauptprogramms in 10 zurück. An diesem Punkt sind die Nachrichtendaten abgerufen worden und zu dem Nachrichtenspeicher 210 im Windows CE Datenbankformat zurückgegeben worden.
12 ist ein logisches Flussdiagramm, das allgemein einen Vorgang zum Ausführen einer Abbildungsfunktion unter Verwendung des offenbarten Protokolls darstellt. In der Beschreibung von 12 wird auf das System und den Prozess verwiesen, der in Ver bindung mit 2, 5, 6 und 10 beschrieben ist. Verfahren 1200 beginnt bei dem Startblock 1201, wo Nachrichtendaten fertig zum Abrufen durch den Nachrichtenspeicher 210 sind.
Bei Block 1203 empfängt der Nachrichtenspeicher 210 Nachrichtendaten. Die Nachrichtendaten kommen von dem Datenspeicher 220 im Windows CE Datenbankformat. Bei Block 1205 trennt der Nachrichtenspeicher 210 die Nachrichteneigenschaften in abgebildete und nicht abgebildete Nachrichteneigenschaften. Nicht abgebildete Nachrichteneigenschaften werden nach der Priorität organisiert und eine Nachrichteneigenschaft wird zum Abbilden identifiziert.
Bei Block 1207 ermittelt der Nachrichtenspeicher 210, ob alle Nachrichteneigenschaften vom Windows CE Datenbankformat zu MAPI abgebildet worden sind. Wenn alle Nachrichteneigenschaften abgebildet worden sind, schreitet der Vorgang zu Block 1215 fort. Wenn irgendwelche Nachrichteneigenschaften noch nicht vom Windows CE Datenbankformat zu MAPI abgebildet worden sind, schreitet der Prozess zu Block 1211 weiter.
Bei Block 1211, beginnend mit einer ersten nicht abgebildeten Eigenschaft, befragt der Nachrichtenspeicher 210 das Typfeld 522, um den passenden Handler zum Aufrufen zu ermitteln. Der Nachrichtenspeicher instanziiert dann den aufgerufenen Handler, und der Handler übersetzt die Daten in dem Wertfeld 512, soweit für diesen Handler erforderlich. Der Vorgang kehrt dann zu Block 1207 zurück, um zu ermitteln, ob irgendwelche weiteren Eigenschaften zu übersetzen übrig sind. Wenn es mehr Eigenschaften zu übersetzen gibt, führt der Vorgang die Funktionen bei Block 1211 erneut aus. Wenn es keine zusätzlichen Eigenschaften zu übersetzen gibt, endet der Vorgang. Der Vorgang endet, wenn es ermittelt wurde, dass bei Block 1207 keine weiteren Eigenschaften zu übersetzen übrig sind.
Die oben genannten Spezifikationen, Beispiele und Daten bieten eine vollständige Beschreibung der Erzeugung und Verwendung der Anordnung der Erfindung an. Weil viele Ausführungsformen der Erfindung gemacht werden können, ohne von dem Gültigkeitsbereich der Erfindung abzuweichen, liegt die Erfindung in den hier anhängigen Ansprüchen.

Claims

Nachrichtentransfersystem (200), welches Softwarekomponenten zum Empfangen und Verteilen einer Nachricht innerhalb eines Mobilgeräts (199) umfasst; wobei das Nachrichtentransfersystem umfasst: eine Speicherkomponente (210), die mit mindestens einer Nachrichtentransferkomponente (230) und einem Datenspeicher (220) in Kommunikation steht, die Nachrichtentransferkomponente (230) kommuniziert mit der Speicherkomponente (210) durch Übergeben von Eigenschaften einer Nachricht, die von einem externen Gerät empfangen wurde, an die Speicherkomponente (210), wobei die empfangene Nachricht in einem Kommunikationsformat entsprechend einem Protokoll, das zur Kommunikation zwischen dem Mobilgerät (100) und dem externen Gerät verwendet wird, vorliegt, dadurch gekennzeichnet, dass die Eigenschaften, die zu der Speicherkomponente (210) übergeben wurden, in ein erstes Format übersetzt werden, das zur Kommunikation zwischen der Nachrichtentransferkomponente (230) und der Speicherkomponente (210) verwendet wird, und die Speicherkomponente (210) konfiguriert ist zum Übersetzen der Eigenschaften von dem ersten Format zu einem zweiten Format, und zum Übergeben der übersetzten Eigenschaften zu dem Datenspeicher (220), wobei das zweite Format ein internes Format des Betriebssystems (164) von dem Mobilgerät (100) ist, das zur Datenspeicherung verwendet wird.
Nachrichtentransfersystem (200) nach Anspruch 1, wobei die mindestens eine Nachrichtentransferkomponente (230) eine Email-Anwendung umfasst.
Nachrichtentransfersystem (200) nach Anspruch 1, wobei die mindestens eine Nachrichtentransferkomponente (230) ein Nachrichtenformular umfasst.
Nachrichtentransfersystem (200) nach Anspruch 1, wobei die mindestens eine Nachrichtentransferkomponente (230) eine Nachrichtenübermittlung umfasst.
Nachrichtentransfersystem (200) nach Anspruch 1, das des Weiteren eine andere Nachrichtentransferkomponente umfasst, die mit der mindestens einen Nachrichtentransferkomponente (230) und der Speicherkomponente (210) unter Verwendung des ersten Formats kommuniziert.
Nachrichtentransfersystem (200) nach Anspruch 1, wobei die Speicherkomponente (210) des Weiteren mindestens ein Steuerprogramm umfasst, das konfiguriert ist zum Ausführen der Übersetzung der Eigenschaften von dem ersten Format zu dem zweiten Format.
Nachrichtentransfersystem (200) nach Anspruch 6, wobei das Steuerprogramm registriert ist zum Übersetzen eines bestimmten Eigenschaftstyps, und wobei die Speicherkomponente (210) das Steuerprogramm verwendet, wenn eine Eigenschaft der Nachricht dem bestimmten Eigenschaftstyp entspricht.
Nachrichtentransfersystem (200) nach Anspruch 6, wobei das Steuerprogramm des Weiteren konfiguriert ist zum Erzeugen einer neuen Eigenschaft aus einer Eigenschaft, die an die Speicherkomponente (210) übergeben wurde.
Nachrichtentransfersystem (200) nach Anspruch 8, wobei das Steuerprogramm des Weiteren konfiguriert ist zum Erzeugen einer zusätzlichen neuen Eigenschaft basierend auf der Eigenschaft, die an die Speicherkomponente (210) übergeben wurde.
Computer-lesbares Medium, das Computer-ausführbare Instruktionen enthält zum Ausführen von Schritten, die umfassen: Empfangen einer Anfrage zum Speichern einer Eigenschaft einer Nachricht innerhalb eines Datenspeichers (220) eines Mobilgeräts (100), wobei die Nachricht in einem Kommunikationsformat entsprechend einem Protokoll, das zur Kommunikation zwischen dem Mobilgerät (100) und einem externen Gerät verwendet wird, empfangen wird, die Eigenschaft wird in ein erstes Format übersetzt, das zum Kommunizieren zwischen lokalen Komponenten (210, 230, 240, 250) des Mobilgeräts (100) verwendet wird, der Datenspeicher (220) konfiguriert ist zum Speichern von Daten in einem zweiten Format, die Anfrage in dem ersten Format ist und Daten zugehörig zu der Eigenschaft einschließt, und das zweite Format ein internes Format des Betriebssystems (164) von dem Mobilgerät (100) ist, das zur Datenspeicherung verwendet wird; Übersetzen der zu der Eigenschaft zugehörigen Daten von dem ersten Format in das zweite Format; und Speichern der Daten in dem Datenspeicher (220) in dem zweiten Format.
Computer-lesbares Medium nach Anspruch 10, wobei die Eigenschaft einen Deskriptor einschließt, der die Eigenschaft von anderen Eigenschaften unterscheidet.
Computer-lesbares Medium nach Anspruch 11, wobei der Deskriptor einen Eigenschaftstyp umfasst.
Computer-lesbares Medium nach Anspruch 11, wobei das Übersetzen der Daten das Übergeben der Daten zu einem Steuerprogramm zur Verarbeitung umfasst, das Steuerprogramm ist zugehörig zu dem Deskriptor.
Computer-lesbares Medium nach Anspruch 13, wobei das Steuerprogramm registriert ist, um Daten eines Typs zugehörig zu dem Deskriptor zu verarbeiten.
Computer-lesbares Medium nach Anspruch 14, wobei das Steuerprogramm des Weiteren konfiguriert ist zum Umwandeln der Eigenschaft von dem ersten Format in das zweite Format.
Computer-lesbares Medium nach Anspruch 15, wobei das Steuerprogramm des Weiteren konfiguriert ist zum Übersetzen der Eigenschaft in mindestens eine an dere Eigenschaft, die mindestens eine andere Eigenschaft stimmt mit dem zweiten Format überein.
Computer-lesbares Medium nach Anspruch 10, wobei das Speichern der Daten in dem Datenspeicher (220) das Speichern der Daten in einer Vielzahl von Tabellen umfasst.
Computer-lesbares Medium nach Anspruch 17, wobei jede der Vielzahl von Tabellen einem Nachrichtenordner entspricht.
Computer-lesbares Medium nach Anspruch 17, wobei eine der Vielzahl von Tabellen konfiguriert ist zum Enthalten bestimmter Eigenschaften, und eine andere der Vielzahl von Tabellen konfiguriert ist zum Enthalten bestimmter anderer Eigenschaften.
Computer-lesbares Medium nach Anspruch 17, wobei eine Tabelle innerhalb der Vielzahl von Tabellen konfiguriert ist als ein Überlaufmechanismus für eine andere der Tabellen innerhalb der Vielzahl von Tabellen.
Computer-lesbares Medium nach Anspruch 20, wobei der Überlaufmechanismus ein Dateisystem umfasst.
Computer-lesbares Medium, das Computer-ausführbare Instruktionen enthält zum Ausführen von Schritten, die umfassen: Empfangen einer Anfrage zum Abrufen einer Eigenschaft einer Nachricht von einem Datenspeicher (220) eines Mobilgeräts (100), wobei die Anfrage in einem ersten Format ist, das zum Kommunizieren zwischen lokalen Komponenten (210, 230, 240, 250) des Mobilgeräts (100) verwendet wird, der Datenspeicher (220) konfiguriert ist zum Speichern von Daten in einem zweiten Format, wobei das zweite Format ein internes Format des Betriebssystems (164) von dem Mobilgerät (100) ist, das zur Datenspeicherung verwendet wird; Abrufen der Daten aus dem Datenspeicher (220) in dem zweiten Format; und Übersetzen der Daten, die zugehörig zu der angefragten Eigenschaft sind, von dem zweiten Format in das erste Format; und wobei die Nachrichten zwischen dem Mobilgerät (100) und externen Geräten in einem Kommunikationsformat entsprechend einem Protokoll kommuniziert werden, das zur Kommunikation zwischen dem Mobilgerät (100) und den externen Geräten verwendet wird; wobei die Eigenschaft einer empfangenen Nachricht von dem Kommunikationsformat in das erstes Format umgewandelt wird.
Computer-lesbares Medium nach Anspruch 22, wobei das Computer-lesbares Medium des Weiteren das Übergeben der umgewandelten Daten zu einer der Anfrage zugehörigen Komponente umfasst.
Computer-lesbares Medium nach Anspruch 22, wobei die Daten von mindestens einer Tabelle in einer Vielzahl von Tabellen abgerufen werden.
Computer-lesbares Medium nach Anspruch 22, wobei die Eigenschaft einen Deskriptor einschließt, der die Eigenschaft von anderen Eigenschaften unterscheidet.
Computer-lesbares Medium nach Anspruch 25, wobei der Deskriptor einen Eigenschaftstyp umfasst.
Computer-lesbares Medium nach Anspruch 25, wobei das Übersetzen der Daten das Übergeben der Daten zu einem Steuerprogramm zur Verarbeitung umfasst, das Steuerprogramm ist zugehörig zu dem Deskriptor.
Computer-lesbares Medium nach Anspruch 27, wobei das Steuerprogramm registriert ist, um Daten eines Typs zugehörig zu dem Deskriptor zu verarbeiten.
Computer-lesbares Medium nach Anspruch 28, wobei das Steuerprogramm des Weiteren konfiguriert ist zum Konvertieren der Eigenschaft von dem ersten Format in das zweite Format.
Computer-lesbares Medium nach Anspruch 29, wobei das Steuerprogramm des Weiteren konfiguriert ist zum Übersetzen der Eigenschaft in mindestens eine andere Eigenschaft, die mindestens eine andere Eigenschaft stimmt mit dem zweiten Format überein.