DE10040948A1

DE10040948A1 - Ein verteiltes technisches System für die Partnersuche, Partnerschaftseignungsprüfung und Bekanntmachung

Info

Publication number: DE10040948A1
Application number: DE2000140948
Authority: DE
Original assignee: ARYA RAJESH KUMAR
Current assignee: ARYA, RAJESH KUMAR, 13353 BERLIN, DE
Priority date: 2000-08-11
Filing date: 2000-08-11
Publication date: 2002-02-28

Abstract

Dieses System ist gedacht, um einen Dienst zur Partnerschaftssuche, Partnerschaftseignungsüberprüfung und Partnerschaftsvermittlung zu realisieren. Wenn jemand auf der Suche ist, eine passende Person zu finden, um eine bestimmte Beziehung bzw. Tätigkeit zusammen zu probieren bzw. auszuüben, dann ermöglicht ihm dieses System eine Umgebung mit mehreren Leuten, solch eine Person zu finden. Ein Benutzer läßt einen Dienst basiert auf diesem System von sich und seinen Wünschen wissen. DOLLAR A Der Benutzer begibt sich zu einem Ort, an dem dieser Dienst angeboten wird. Der Benutzer trägt ein Gerät mit sich. Wenn er sich an diesem Ort befindet, dann meldet er sich bei dem Dienst über sein Gerät an, und sagt Bescheid, daß er sich an diesem Ort befindet und daß er diesen Dienst in Anspruch nehmen möchte. Dann wartet er ab. Der Dienst sucht nach anderen Benutzern, die auch für diesen Ort angemeldet sind und für eine Partnerschaftsvermittlung an den Benutzer geeignet sind. Wenn einer gefunden wird, wird er dem Benutzer vorgestellt. Informationen über den Partnerschaftskandidaten bekommt der Benutzer auf seinem Gerät zu sehen. Falls der Benutzer mit dem vermittelten Partnerschaftskandidaten zufrieden ist, läßt er dies den Dienst wissen. In diesem Fall baut der Dienst eine Verbindung zwischen seinem Gerät und dem Gerät des Partnerschaftskandidaten auf, so daß die beiden miteinander sprechen können. Während des Gesprächs können die beiden einen Treffpunkt in der Nähe ihres derzeitigen ...

Description

Es gibt viele konventionelle Wege, um nach einem Partner zu suchen. Viele neue Internet Partnerschaftsvermittlungen, Internet Kataloge, Internet Chat Dienste, Internet Anzeigen, usw. sind in letzter Zeit populär geworden. Schon früher gab es Methoden wie Zeitungs- und Zeitschriftenanzeigen, Ehepartnerkataloge, Fernsehanzeigen, Dating-Shows usw. Manchmal wurde diese Rolle der Partnerschaftsanbahnung von realen Menschen übernommen, die andere Menschen zusammen gebracht haben, die ihrer Meinung nach füreinander geeignet waren, oftmals hatten die Leute einfach Glück und haben den richtigen Partner zufällig getroffen.

Abstrakt

Dieses System ist gedacht, um einen Dienst zur Partnerschaftssuche, Partnerschaftseignungsüberprüfung und Partnerschaftsvermittlung zu realisieren. Wenn jemand auf der Suche ist, eine passende Person zu finden, um eine bestimmte Beziehung bzw. Tätigkeit zusammen zu probieren bzw. auszuüben, dann ermöglicht ihm dieses System eine Umgebung mit mehreren Leuten, solch eine Person zu finden. Ein Benutzer läßt einen Dienst basiert auf diesem System von sich und seinen Wünschen wissen.

Der Benutzer begibt sich zu einem Ort, an dem dieser Dienst angeboten wird. Der Benutzer trägt ein Gerät mit sich. Wenn er sich an diesem Ort befindet, dann meldet er sich bei dem Dienst über sein Gerät an, und sagt Bescheid, daß er sich an diesem Ort befindet und daß er diesen Dienst in Anspruch nehmen möchte. Dann wartet er ab. Der Dienst sucht nach anderen Benutzern, die auch für diesen Ort angemeldet sind und für eine Partnerschaftsvermittlung an den Benutzer geeignet sind. Wenn einer gefunden wird, wird er dem Benutzer vorgestellt. Informationen über den Partnerschaftskandidaten bekommt der Benutzer auf seinem Gerät zu sehen. Falls der Benutzer mit dem vermittelten Partnerschaftskandidaten zufrieden ist, läßt er dies den Dienst wissen. In diesem Fall baut der Dienst eine Verbindung zwischen seinem Gerät und dem Gerät des Partnerschaftskandidaten auf, so daß die beiden miteinander sprechen können. Während des Gesprächs können die beiden einen Treffpunkt in der Nähe ihres derzeitigen Aufenthaltsortes vereinbaren. Kurz danach können sie sich dort treffen und ein Gespräch führen und ihre Interessen weiter erörtern.

Problematik

Die menschliche Gesellschaft ist mehr als die Summe der Menschen darin. Die Interaktionen zwischen den Menschen machen sie weitaus reicher. Viele Vergnügungen des Lebens kann man nur durch die Interaktion mit anderen Menschen erfahren. Für jede Person ist es von essentieller Wichtigkeit, welche anderen Personen er/sie kennt und mit wem sie interagiert. Viele Menschen können nicht zusammenkommen und dauerhafte Bekanntschaften aufbauen, weil sie von Anfang an füreinander die falschen Leute waren. Deswegen sind die Menschen immer auf der Suche nach anderen, mit denen es einfacher wäre, solche Bekanntschaften aufbauen zu können, und an vielen Aktivitäten teilzunehmen, die für beide Seiten von Interesse wären. Solche Personen zunächst zu finden und dann auch noch die Hemmungen, einen dementsprechenden Dialog anzufangen zu überwinden bleibt ein Problem. Man kann aber nur dann herausfinden, ob jemand der richtige ist, wenn auch eine gewisse Kommunikation zwischen den beiden stattfindet.

Obwohl die Städte immer größer werden, wächst die Anonymität immer weiter an. In vielen Gesellschaften der Welt wird es immer schwieriger, mit anderen Menschen zu reden oder sie gar anzusprechen, da mehr und mehr Menschen sich zu sehr über sich selbst und über den Eindruck den sie auf andere machen, bewußt geworden sind. Dies hat dazu geführt, daß es einen dramatischen Rückgang gibt, was die Spontaneität und Natürlichkeit bei der Annäherung an andere Menschen angeht. Dies trifft besonders auf Leute von Ende 20 bis in die 40er Jahre zu.

Es gibt einige Grundaspekte an jeder erfolgreichen Behebungsstrategie:

1. Die richtigen Leute zu finden
2. Einen Dialog aufzubauen
3. Die Infrastruktur der Kommunikation zu unterstützen
4. Anderen Menschen zu vertrauen

Konventionelle Strategien

Die Gesellschaft funktioniert in der Weise, daß man die Problematik nicht wirklich als Problematik ansieht, sondern als einen Teil des Lebens. Ebenso wird die Lösung, d. h. eine Strategie, um verschiedene Menschen zusammenzubringen, als nichts anderes als ein Teil des Lebens angesehen. Deswegen mag es nicht richtig klingen, die Lösungen als Lösungen zu betrachten, sondern als Lubrizierung der Gesellschaft. Die verschiedenen Strategien sind eher als Maschen zu sehen, um die Gesellschaft interessanter zu machen. Diese Tricks sind schon seit Jahrhunderten im Gebrauch gewesen. In jeder Methode werden unterschiedliche Aspekte der Strategien betont.

- Vergesellschaften im Sinn von Ausgehen bedeutet, daß man sich an Orte begibt, an denen es Menschen in großer Zahl gibt, und wo die Chance, jemanden zu treffen, mit dem man in eine Interaktivität tritt, mit dem man gemeinsame Interessen hat, groß ist. Manchmal trifft man zufällig jemanden und baut eine Bekanntschaft auf, und alles passiert von allein, und manchmal werden Leute von einem gemeinsamen Bekannten oder Freunden miteinander bekannt gemacht. Wenn man durch einen anderen jemandem vorgestellt wird, ist die Bereitschaft, sich mit jemandem zu unterhalten, höher, da sich ein gewisser Grad an Vertrauen auf der Basis der gemeinsamen Bekanntschaft aufbaut. Die neue Bekanntschaft identifizieren zu können hilft aus zwei Gründen: Als erstes weiß man, daß im Falle eines Fehlverhaltens der anderen Person die Identität des Missetäters bekannt ist; und zweitens kann man sich besser einen ersten Eindruck von der/dem anderen machen. Außerdem muß man aus Rücksicht auf den gemeinsamen Bekannten eine gewisse Höflichkeit und Freundlichkeit zeigen. Das fördert natürlich das Ziel des Dialogs zwischen den zwei Parteien.
- Eine andere Strategie besteht darin, daß ein Bekannter eine Person gut kennt und gut versteht, und deren Vorzüge und Geschmack gut beurteilen kann. Falls der Bekannte andere Leute kennt, die seiner Meinung nach dem Bild eines idealen bzw. realistischen Partners entspricht, dann kann der Bekannte die Rolle des Vermittlers oder "Kupplers" zwischen den zwei Parteien übernehmen. Der Bekannte kann versuchen, ein Treffen zwischen den beiden zu arrangieren, als auch sie einander vorzustellen.
- Manchmal werden Menschen zu Orten eingeladen, wo es sehr viele Leute gibt, von denen viele einander bereits kennen. Zumindest der Gastgeber kennt schon mehrere Personen. Der Gastgeber kann dann die Rolle des Vorstellungsagenten spielen und versuchen, zwei zueinander passende Menschen zusammen zu bringen.
- Manchmal versammeln sich Leute mit gewissen Interessen an einem bestimmten Ort. Hier wird es möglich, mit dem Anderen einen Dialog anzufangen und den Anderen kennenzulernen. Es ist aber nicht immer der Fall, daß an einem Ort eine so strenge und exklusive Politik betrieben wird, die garantieren könnte, daß ausschließlich Leute da sein werden, die in ein bestimmtes Muster passen. Man kann es also nicht selbstverständlich annehmen, daß nur eine bestimmte Kategorie von Leuten an dem Ort anwesend ist. Theoretisch ist ein solcher Ort natürlich denkbar.
- Weiterhin kann eine Person eine Kleinanzeige veröffentlichen, in der sie ihre Eigenschaften beschreibt, und, für einen bestimmten Zweck, nach einer Person sucht, die bestimmte Eigenschaften besitzt. Auf diese Weise kann man persönliche Informationen über sich selbst, seine Interessen, Erwartungen usw. veröffentlichen. Diese Informationen können über verschiedene Kanäle und Medien verbreitet werden. Diese persönlichen Informationen werden von diesem Zeitpunkt an genauso behandelt wie jede andere Art von Informationen. Andere Personen, die dies lesen, könnten sich angesprochen fühlen, und würden vielleicht mit der Person in Kontakt treten wollen.
- Manchmal werden alle diese Kleinanzeigen in einem Katalog zusammengefaßt, so daß die Suche für die Suchenden viel leichter wird. Die Kleinanzeigen wären immer noch im öffentlichen Bereich, würden jedoch nur Personen zukommen, die wirklich daran Interesse haben.
- Es gibt auch spezielle Agenturen, die auf kommerzieller Basis versuchen, für eine Person den richtigen Partner zu finden.
- Weiterhin ist ein hohes Maß an Kommunikation zwischen den zwei Parteien notwendig, um zu erkennen, ob die beiden Parteien wirklich für eine bestimmte Aktivität zu einander passen.
- Um dem Kommunikationsbedarf nachzugehen, gibt es mehrere sehr wichtige Komponenten, die in der Welt und für die menschliche Gesellschaft verfügbar sind. Einige Beispiele im Folgenden:
- 1. Luft für die Übertragung des Schalls
- 2. Stimmbänder in unserer Kehle
- 3. Handschrift
- 4. Sprache
- 5. Semiotik
- 6. Papier und andere Materialien
- 7. Post
- 8. Usw.

Anhand der vorherigen Diskussion kann man feststellen, daß die folgenden Strategien im allgemeinen die Entwicklung der Partnerschaftsfindung fördern:

1. Gemeinsame Umgebung
2. Kommunikationskanäle
3. Vorstellender Agent, der Vertrauen fördert
4. Fördernder Agent, der das Eis bricht
5. Informierender Agent, der Informationen über die andere Person liefert
6. Steuernder Agent, der gegenseitigen Respekt und Höflichkeit von den beiden Leuten fordert
7. Bekanntschaftsschaffender Agent, der beurteilen kann, ob die zwei Menschen über Eigenschaften verfügen, die zu einer Zusammenkunft von Interessen und Erwartungen führen könnten.
8. Werbung und Kleinanzeigenpublizierung von eigener Person, Interessen, Absichten und Erwartungen
9. Katalog von Leuten, die gefunden werden wollen
10. Gemeinsame Umgebung, die das Interesse an einer speziellen Kategorie von Interaktivitäten fördert
11. Speziell organisierte soziale Versammlungen zu bestimmten Zeiten

Herkömmliche Lösungen und ihre Nachteile

Viele von den oben genannten Strategien wurden schon technologisch umgesetzt. Es gibt neue Lösungen, die als Ergebnis von Informations-, Rechen-, Netzwerk-, Rundfunk- und Fernsehrevolutionen entstanden sind. Dies hat zu vielen Simulationen der oben genannten Strategien geführt, nur diesmal in den Cyber-, Druck-, Rundfunk- und Fernsehwelten. Einige solche Lösungen sind im folgenden:

1. Internet-Partnerschaftsvermittlungsprogramme
2. Internet-Kataloge
3. Internet-Chatrooms
4. Internet-Kleinanzeigen
5. Zeitungs- und Zeitschriftenkleinanzeigen
6. Ehekataloge
7. Fernsehkleinanzeigen
8. Fernsehpartnerschaftsvermittlungsshows
9. Rundfunk-Kataloge
10. Single-Parties
11. Konventionelle Öffentliche Freizeit- und Vergnügungstreffpunkte
12. Usw.

Die obigen Lösungen haben ihre Vorteile und ihre Nachteile. Was die Stärke der einer wäre, könnte die Schwäche der anderen sein. Meistens gab es Kritik in der Gesellschaft, daß viel zu viel im virtuellen Raum passiert und dabei manchmal die Motivation der Leute, in der realen Welt zu leben und zu interagieren, abnimmt. Das passiert manchmal, weil manche Leute sich viel sicherer fühlen, wenn sie mit anderen Leuten im virtuellen Raum durch einen Bildschirm interagieren. Diese Art der Sicherheit könnte psychische Probleme verursachen, da manche Leute sich daran gewöhnen könnten und immer diese Sicherheit der Gesichtslosigkeit brauchen, wodurch diese Leute sich von der realen Welt und ihren Herausforderungen entziehen.

Lösungsanforderungen

Wenn die Menschen wüßten, welche die richtigen Leute in einer Masse sind, und würden sie einander in einer angenehmeren Art vorgestellt werden, dann könnten sie einen Dialog führen, so wie es ihnen paßt. Außerdem würden sie sich nicht die ganze Zeit darüber Gedanken machen müssen, ob sie, falls sie auf den anderen zugehen, den anderen stören würden, oder ob sie sich dadurch lächerlich machen könnten. Überdies würde man über die behaupteten Absichten des anderen im klaren sein. Jeder könnte so wissen, ob es an diesem Ort jemanden gibt, der mit jemandem wie ihm/ihr zu kommunizieren bereit wäre. Diese Treffen würden im realen Leben, in Echtzeit stattfinden, und ohne vorher abgesprochene Termine und Verabredungen, oder nur im virtuellen Raum. Die Dynamik der realen Welt gibt diesem Dienst eine eindeutig andere Vorgehensweise als alles, was bis jetzt existiert. Außerdem wissen die Leute fast in Echtzeit, ob sie das Aussehen und das Auftreten des Anderen angenehm und akzeptabel genug finden, und ob sie diesen Bekanntschaftsprozeß fortführen wollen oder nicht.

Lösunpsvorteile

Es gibt zwei Aspekte des vorgeschlagenen Dienstes, die ihn von allen anderen unterscheiden.

Reales Leben: Es existieren viele verabredungsfördernde Dienste im Netz, mit deren Hilfe man interessante Parteien finden kann, über Katalogen, Kleinanzeigen oder Vermittlungsdienste. Für direkte persönliche Treffen andererseits müssen die betroffenen Parteien eine Verabredung treffen, was Schwierigkeiten bei der Einigung über Ort und Zeit mit sich bringt. Diese Dimension entfällt bei unserer Vorgehensweise. Der Verabredungsort ist üblicherweise gleich dort, wo die zwei Parteien sich gerade befinden. Da beide an dem gleichen Ort wären, wäre das gar kein Problem. Das Treffen ist einfach im realen Leben und nicht im Netz. Die Schwierigkeiten bei der Einigung auf einen bestimmten Treffpunkt und die Notwendigkeit, dorthin zu fahren, sind kein Thema mehr.

Echtzeit: Konventionellerweise wird das Treffen auch zu einem anderen Zeitpunkt arrangiert, was natürlich eine Wartezeit mit sich bringt, was wiederum sowohl unnötige Nervosität verursacht, als auch die beide Parteien in ihrer Spontaneität beraubt, da man sich bereits so viele Gedanken über die Gelegenheit und das richtigen Verhalten gemacht hat, daß dies aufgesetzt erscheint und alles um das Treffen herum einfach künstlich wirkt. Dieser Dienst fördert solche Treffen, aber mit einer ganz anderen Vorgehensweise. Da die betroffenen Parteien sich kurz nach dem anfänglichen Netz-Händeschütteln begegnen, ist das Treffen fast in Echtzeit. Man trifft sich, wie man gerade ist (mehr oder weniger). Die Enttäuschung, wenn eine Partei nicht zu dem Treffen erscheint, verliert seinen Biß. Zeit wird kaum verschwendet, während man auf den anderen wartet. Außerdem gibt es keinen Bedarf, sich irgendeine Ausrede auszudenken oder betroffen zu sein von der begleitenden Peinlichkeit, falls man spät ankommt oder gar nicht aufkreuzt. Es gibt keinen Bedarf, vorher Blumen zu kaufen. Man muß auch nicht in ständiger Hektik wegen der Pünktlichkeit sein. Es gibt keine Notwendigkeit nachzuschlagen, ob eine Verabredung in den Terminplan paßt. Alles passiert gleich da und dort.

Perspektive: Man könnte diesen Dienst aus einer bekannten Perspektiven betrachten. Man kann sagen, es funktioniert so ähnlich wie eine Gesellschaftsdame, die praktisch jeden in der Welt kennt, der sich bemüht zu ihr zu kommen und sich ihr zu erklären. Die Person würde ihr sein Herz offenbaren, und ihr über sich selbst, über die eigenen Bestrebungen, über die eigenen Ansichten, über die eigenen Hintergründe und den eigenen Kulturkreis usw. erzählen, und sie wissen lassen, daß er der Wunsch hat, den idealen Partner für eine Beziehung zu finden, welcher Natur die Beziehung auch sein mag. Die Gesellschaftsdame läßt die Person wissen, daß, falls er/sie zu einem bestimmten Ort gehen sollte, an dem sie sich auch befindet, sie die Person mit jemandem bekannt machen würde, der/die für ihn/sie genau die richtige Person zum Kennenlernen und zu einer weiteren Erforschung der gegenseitigen Eignung für eine Beziehung wäre. Da die beiden Leute die Gesellschaftsdame gut kennen, haben sie ein gewisses Vertrauen in ihre Urteilskraft und sind bereit, dieser Beziehungseignung nachzugehen. Weiterhin werden die beiden auch höflich und freundlich zueinander sein aus Rücksicht auf ihre gemeinsame Freundschaft mit der Gesellschaftsdame. Außerdem fühlen sie sich sicherer, da der andere Partner nicht ganz ein Fremder ist, da die Gesellschaftsdame ihn kennt und ihn vorgestellt hat. So könnte der andere auch keinen Schaden anrichten und dabei hoffen, ungeschadet davon zu kommen. Die Gesellschaftsdame würde auch nur solche Leute einander vorstellen, die ähnliche Erwartungen an ihre Beziehung haben, und bereit sind, auf den Anderen zuzugehen oder von dem Anderen angesprochen zu werden, und mit dem Anderen zu interagieren. Ein erstes Einvernehmen wird der Person auch dadurch gesichert, daß die Gesellschaftsdame ihm die andere Person beschreibt und womöglich auch das Foto der anderen Person zeigt, bevor das eigentliche Vorstellen stattfindet.

Lösungsarchitektur Hauptkomponenten

Auf der Basis sowohl von räumlicher Verteilung als auch von der Steuerungsinstanz, kann man das Verteilte System für Partnersuche, Partnerschaftseignungsprüfung und Vorstellung in Unterkomponenten unterteilen. Dies sind die folgenden:

1. Real Partner Match Making Server Unit (RPMMSU)
2. User's Personal Mobile Communications & Computing Device (PMCCD)
3. Candidate Partners Personal Mobile Communications & Computing Device (PMCCD)
4. Serviced Public Leisure and Entertainment Meeting Place (SPLEMP) Location Server Unit (LSU)
5. User Personal Information Entry Interface Unit (UPIEIU)

Real Partner Match Making Server Unit

Diese Einheit ist dazu da, um herauszufinden, welche zwei Leute sich in einer gemeinsamen Umgebung befinden, die ähnliche Interessen an einer interaktiven Tätigkeit aufweisen, und deren Erwartungen an den anderen, durch die behaupteten Eigenschaften des anderen, erfüllt werden. Um diese Aufgabe durchzuführen, muß diese Einheit auch die dafür benötigten Informationen verwalten. Dies umschließt das Benutzerprofil, die Interaktive- Tätigkeitsabsichten-Bestimmungen und die Partnerschaftskanditaten-Profil-Schablone. Diese Informationen müssen von dem Benutzer eingegeben werden. Diese Einheit wird auch mit der Verantwortung betraut, dem Benutzer die Eingabe solcher Informationen zu ermöglichen. Teile der vorher erwähnten Informationen werden dieser Einheit übertragen, kurz bevor die Aufgabe durchgeführt wird. Weiterhin teilt diese Einheit die Benutzer in Gruppen, je nachdem, in welchem SPLEMP der Benutzer sich befindet oder für welchen der Benutzer sich angemeldet hat. Nur Benutzer in den gleichen Gruppen werden für die Verkuppelung miteinander in Betracht gezogen. Da diese Einheit wissen muß, wie die Benutzer in Gruppen zu unterteilen sind, muß es auch die Informationen über die SPLEMPs besitzen. Ein Benutzer könnte viele Verkuppelungsmöglichkeiten brauchen, bevor er sich wirklich für den einen oder anderen entscheiden kann. Deswegen soll der Benutzer diesen Dienst nicht nur einmal am Abend vermittelt bekommen, sondern mehrere Verkuppelungsangebote sollen dem Benutzer bereitgestellt werden. Da ein Benutzer das Gelände des Ortes zwischendurch verlassen kann, muß die Einheit auch noch informiert werden, wann der Benutzer sich auf dem Gelände befindet und wann nicht. Dies ist wichtig, um einen Benutzer nicht mit einem Dienst zu beschäftigen, den er gar nicht mehr braucht, und auch um nicht anderen Benutzern einen Partnerschaftskandidaten anzubieten, der sich gar nicht mehr vor Ort befindet. Außerdem sollte ein Benutzer in der Lage sein, angeben zu können, wann er den Dienst benutzen möchte und wann nicht.

Die Einheit, obwohl bisher als eine einzige Komponente betrachtet, könnte selbst unterteilt werden. Einige Unterkomponenten könnten sich an einem anderen Ort befinden. Abhängig von der räumlichen Trennung klassifizieren wir die Unterkomponenten als systeminterne Unterkomponenten, naheliegende getrennte Unterkomponenten oder als weit entfernte getrennte Unterkomponenten.

User's Personal Mobile Communications & Computing Device

Dieses Gerät ist für die Benutzer gedacht. Es stellt die Laufzeitschnittstelle des Benutzers zu dem Dienst dar. Dieses Gerät benutzend wird der Benutzer sich an einem öffentlichen Freizeit- und Vergnügungs-Treffpunkt, der von unserem Dienst abgedeckt wird, anmelden; der Benutzer wird dadurch sowohl die genaue interaktive Tätigkeit oder Tätigkeiten, an denen er teilnehmen möchte, als auch die Rolle, die der Benutzer bei der Tätigkeit spielen möchte, und die Bedingungen für die Qualifikationen des Partnerschaftsanwärters spezifizieren. Der Benutzer wird mit diesem Gerät den Dienst aktivieren und deaktivieren. Mit diesem Gerät wird der Benutzer Einzelheiten über den vermittelten Partnerschaftskandidaten und dessen Vergleichsdaten abfragen können. Die Bestätigung der Absicht, sich mit dem vermittelten Partnerschaftskandidaten zu treffen, wird auch über dieses Gerät mitgeteilt. Die Kommunikation zwischen dem Benutzer und dem vermittelten Partnerschaftskandidaten wird auch über dieses Gerät stattfinden. Eventuell kann dieses Gerät auch von der Umgebung benutzt werden, um abzutasten, ob der Benutzer noch auf dem Gelände des SPLEMPs ist oder nicht. Das Personal Mobile Communications and Computing Device wird von jedem Benutzer getragen werden, das heißt, im Kontext der Vermittlung, beide, der Benutzer und sein vermittelter Partnerschaftskandidat werden dieses Gerät bei sich tragen.

Am wahrscheinlichsten wird dieses Gerät eine physikalisch zusammenhängende Einheit sein, aber es ist möglich, daß es mehrere unterscheidbare Geräte gibt, die zusammen alle Funktionalitäten und Verantwortungen, die von dem Gerät erwartet werden, realisieren. Im Falle von mehreren unterscheidbaren Geräten gäbe es die Notwendigkeit, daß alle Geräte miteinander kommunizieren können, und daß die RPMMSU jedes Gerät, das sie braucht, direkt oder indirekt über eines der anderen, einzeln ansprechen kann. Manchmal ist es besser, daß alle Funktionalitäten in einem einzigen physikalisch zusammenhängenden Gerät zu finden sind, und manchmal kann es vorteilhaft sein, mehrere Geräte mit verteilten Funktionalitäten zu haben, da es Multitaskingbetrieb und Flexibilität ermöglicht.

Candidate Partner's Personal Mobile Communications & Computing Device

Dieses Gerät ist identisch mit dem Personal Mobile Communications and Computing Device des Benutzers, und der einzige Unterschied ist, daß der Partnerschaftskandidat die Steuerinstanz darstellt. Der Partnerschaftskandidat ist selbst auch ein Benutzer. In dem Kontext einer Partnerschaftseignung wird der Begriff Partnerschaftskandidat benutzt, um ihn von dem Benutzer zu unterscheiden, aus dessen Blickwinkel die ganze Vermittlung betrachtet wird, und der Partnerschaftskandidat spielt die Rolle des dem Benutzer gegenüberstehenden.

Location Server Unit

Diese Einheit wird von dem Betreiber des öffentlichen Freizeit- und Vergnügungs- Treffpunktes gesteuert. Das Hauptziel dieser Einheit ist zu überprüfen, ob die Benutzer, die sich bei einem SPLEMP angemeldet haben, tatsächlich auf dem Gelände des SPLEMPs sich befinden. Diese Einheit wird die Anmeldungen von Benutzern verwalten und auch ihre Anwesenheit verfolgen. Das tut es, indem es ein Kurzstrecken-Signal in dem Personal Mobile Communications and Computing Device des Benutzers verfolgt und es abhört. Außerdem kümmert sich diese Einheit darum, daß wann immer sich jemand bei solch einem Ort anmeldet, derjenige das wirklich auf dem Gelände des Ortes tut und nicht aus einer Entfernung.

Da diese Einheit Unterkomponenten beinhaltet, die tatsächlich eine räumliche Verteilung nötig haben, kann man nicht sagen, daß diese Einheit vollkommen ein physikalisch zusammenhängendes Gerät sei. Es umfaßt viele kleine Geräte, die an verschiedenen Plätzen auf dem Gelände des SPLEMPs plaziert sind. Die Funktionalität dieser Geräte beinhaltet sowohl Anmeldung und Bestätigung von Einchecken und Auschecken als auch Abhören von anwesenheitsbestätigenden Signalen, die von dem PMCCD des Benutzers ausgehen. Alle diese Geräte werden körperlich getrennt sein von, zum Beispiel von dem Teil, der für die Verwaltung und das Weiterleiten von Informationen an die RPMMSU zuständig ist.

User Personal Information Entry Interface Unit

Diese Einheit wird vom Benutzer verwendet, um Angaben über sich selbst in die RPMMSU einzugeben. Normalerweise wird diese Einheit von dem RPMMSU ziemlich weit entfernt sein, so daß es nah am Benutzer sein kann, wo auch immer der Benutzer sein mag. Unter Benutzung dieser Einheit kann man eine Verbindung zu der RPMMSU eröffnen, was dieser Einheit genug Informationen von der RPMMSU herunterzuladen verhilft, so daß es eine interaktive Präsentations-Schnittstelle darstellen kann. Diese Informationsaustauschschnittstelle benutzend, muß es für den Benutzer möglich sein, Angaben über die eigene Identität, Kontaktierbarkeit, identitätsbestätigende Referenzen, Benutzer-Profil, allgemeine interaktive Tätigkeits-Interessen, das entsprechende allgemeine Partnerschaftskandidatenprofil usw. einzugeben. Alle diese Informationen kann man zusammenfassen als gestaltbares Benutzer-Konto.

In allgemeinen wird diese Einheit ein System sein, das über eine Netzwerk-Verbindung mit einem RPMMSU verbunden ist. Für eine bequeme Benutzer-Interaktions-Schnittstelle könnte ein großer Bildschirm nötig sein, so daß es eine entsprechend großzügige Auflösung möglich macht, eine große Farbpalette, usw. Nicht jedes Gerät wird alle diese Annehmlichkeiten anbieten können. Nichtsdestotrotz kann die Präsentation einfacher gehalten werden, so daß die Präsentationsanforderungen nicht zu hoch sind und Geräte mit verschiedenen Leistungsmerkmalen und Hardwarevoraussetzungen den Benutzer in seiner Interaktivität mit dem RPMMSU unterstützen könnte. Es ist durchaus möglich, daß der PMCCD des Benutzers die notwendigen Leistungsmerkmale aufweist, daß die gesamte Personal Information Entry Interface Unit des Benutzers darin integriert werden kann. Natürlich kann diese Einheit komplett unabhängig von dem PMCCD des Benutzers sein.

Zu Grunde liegende Architekturkonzepte

Diese räumlichen Komponenten können weiter physikalisch und räumlich in Unterkomponenten unterteilt werden, aber diese Unterkomponenten werden zusammenarbeiten, um eine einheitliche funktionale Verantwortung zu verwirklichen. Manchmal könnte die räumliche Unterteilung der Unterkomponenten erwünscht, erforderlich und praktisch sein.

Manche Unterkomponenten könnten von anderen Instanzen als der Haupt-Steuerungsinstanz der Komponente gesteuert oder beeinflußt werden. Dies kann nur passieren, wenn die Haupt- Steuerungsinstanz die Befugnis dafür erteilt. Die Befugnis kann an eine andere auf ein Anforderungszeichen hin für nur eine Aktion oder für eine ganze Sitzung erteilt werden. Es kann auch so gestaltet werden, daß die andere Instanz jederzeit die Steuerung haben kann, höchstwahrscheinlich in einem bestimmten Kontext, oder es hat die Steuerung als eine Vorbedingung, um einen Dienst verarbeitet zu bekommen oder in dem man an einem Dienst teilnimmt. Außerdem könnte Lese- und Schreibzugriff auf ein Informationsspeicherungs- Modul zwischen der Haupt-Steuerungsinstanz und einer anderen Instanz geteilt werden. In diesen Unterkomponenten könnten die zwei Instanzen unterschiedliche Verantwortungen tragen.

Nicht alle Unterkomponenten sind notwendig. Einige Unterkomponenten könnten notwendig sein für die folgenden Ziele:

1. Zusätzliche Sicherheit
2. Verbesserte Qualität des Dienstes
3. Wahlfreie funktionale Erweiterungen
4. Anspruchsbekräftigung und -zurückverfolgbarkeit
5. Zeitanalyse und statistische Datenerhebung
6. Leistung
7. Rechnungsschreibung
8. Multiple Informationseingabe- und -ausgabe-Mechanismen
9. Test und Diagnose

Die oben genannten abstrakten Aspekte können weiter konkreter spezifiziert werden. Darüber hinaus, um konkrete Aspekte zu realisieren, können verschiedene Unterarchitekturen vorgestellt werden.

Dies kann abhängen von entgegenwirkenden Dienstparametern, und dem wirklichen Ausgleich, was man dabei erreichen wollte.

Abstrakte Komponententypus-Architektur Komponenten

Die Abstrakte Komponententypen-Architektur beschreibt, wie man eine Architektur etwa senkrecht oder als Schichten betrachten kann. Diese Architektur wird sich fast in jeden räumlich sowie funktional unterscheidbaren Systemen wiederholen. So kann man die Architektur von, z. B. der Real Partner Match Making Server Unit, dem Personal Mobile Communications and Computing Device des Benutzers, oder auch der Location Server Unit des SPLEMPs betrachten. Alle werden Module haben, die grob in die folgenden Kategorien unterteilt werden können:

1. Plattform-Basis-Komponenten
2. Informations-Speicher-Komponenten
3. Dienst-Funktionalitäts-Komponenten

Plattform-Basis-Komponenten

Dies umschließt Module, die verantwortlich sind für Netzwerkbetrieb, Prozessor, Prozessorspeicher, Ausgabe-Formatierer, Bildschirm, Dauerhafter-Speicher- Verwaltungssystem-Modul, usw. Diese Komponenten kann man ansehen als solche, die in jeder Computer-Plattform vorhanden sind, die Funktionalitäten wie Eingabe, Ausgabe, Rechnen, Speichern, Kommunikation, usw., unterstützen. Alle anderen Komponenten bauen ihre Funktionalitäten auf diese Komponenten auf.

Informations-Speicher-Komponenten

Diese können weiter unterteilt werden nach verschiedene Kriterien. Informations-Speicher- Komponenten können dauerhafte oder vorübergehende Speicherung unterstützen. Dauerhafte Informations-Speicher-Komponenten bewahren ihren Informationsgehalt sogar, nachdem die Stromzufuhr ausgeschaltet wird. Die Vorübergehenden Informations-Speicher-Komponenten existieren nur, solange sie mit Strom beliefert werden. Dauerhafte Informations-Speicher- Komponenten werden benutzt, um Informationen über eine lange Zeitdauer zu bewahren, sogar wenn kein Modul Verwendung für den Informationsgehalt in den Komponenten hat. Vorübergehende Informations-Speicher-Komponenten werden von Modulen als Hauptspeicher benutzt, immer wenn diese Komponenten Lese- oder Schreibzugang auf deren Gehalt brauchen. Die Informationen, die darin beinhaltet sind, sind entscheidend für den Betrieb der Komponenten. Es gibt Informations-Speicher-Module, in denen nur einmal geschrieben werden kann. Hier bleibt die Information, die am Anfang eingesetzt wurde, für immer unverändert.

Dienst-Funktionalitäts-Komponenten

Diese stellen die Funktionalität, die kennzeichnend für das räumlich sowie funktional unterscheidbare System ist, bereit. Jedes System wird mehrere solcher Komponenten haben, und der Satz der Komponenten in jedem System wird zu Variationen neigen, sollte das System für unterschiedliche Funktionalität konzipiert sein. Diese Komponenten ermöglichen einem System, seine eigene individuelle Anwendbarkeit zu beanspruchen.

Signale Beschreibung

Ein anderer Aspekt der Architektur ist, wie die verschiedenen Komponenten miteinander kommunizieren. Dies geschieht mit der Hilfe der Signale. Diese Signale beinhalten folgende Art von Informationen:

1. Netzwerks- und Kommunikations-Protokoll-Informationen
2. Identität der Signalsender und andere Informationen zu Authentifizierungs-Zwecken
3. Identität der adressierten (angesprochenen) Komponente
4. Identität der adressierten Funktionalität der Komponente
5. Parameter zu der Funktionalität der Komponente
6. Inhaltliche Informationen

Außerdem werden die Signale selbst identifiziert und beschrieben, abhängig von der Art der Komponenten, unter welchen Signale ausgetauscht werden, und der Art des Mediums, über welches sie gesendet werden. Ein Signal wird üblicherweise durch eine Linie dargestellt, die von der sendenden Komponente zu der empfangenden Komponente gezeichnet wird, in einem Pfeil endet, und mit einem Namen oder einem Text, welcher die Funktionalität angibt, beschriftet wird.

Vernetzung

Zu Anfang genügt es zu sagen, daß Komponenten, die körperlich in direkter Verbindung miteinander stehen, mittels irgendeines Kommunikationsbus miteinander kommunizieren werden, z. B. innerhalb eines Rechners. Diejenigen, die in der Nähe des anderen, aber nicht körperlich mit ihm verbunden sind, könnten miteinander über Kabel oder über drahtlose Kurzstrecken-Verbindungsmittel kommunizieren. Diejenigen, welche voneinander weiter entfernt sind, werden mit den anderen über Kabel oder langstreckentaugliche drahtlose Mitteln benutzend kommunizieren, wobei Netzwerk- und Kommunikations-Protokoll- Architekturen verwendet werden. Basierend auf der Entfernung der Verbindung kann man die folgenden Vernetzungsarten unterscheiden:

1. Über sehr kurze Entfernungen mittels eines system-internen Kommunikations-Bus oder Hauptspeichers. Von Komponenten in einem physikalisch zusammenhängenden elektronischen System zu einer Komponente in dem gleichen System.
2. Über kurze Entfernungen mittels Kabel-Verbindungen oder drahtlosen Mitteln für kurze Entfernungen. Von Komponente an einem Punkt innerhalb eines Gebäude-Komplexes zu einer anderen Komponente an einem anderen Punkt in dem gleichen Gebäude-Komplex.
3. Über große Entfernungen mittels Kabel und drahtloser Funk-Übertragung. Von Komponenten an einem Punkt auf der Erde zu einem anderen Punkt auf der Erde oder sogar außerhalb.

Außerdem, abhängig von dem jeweiligen Mittel, kann man folgendes unterscheiden:

1. Über Kabel: Dies ist ein allgemeiner Begriff, der ausdrückt, daß es eine materielle Verbindung zwischen zwei Komponenten gibt, und dieses materielle Mittel für die Übertragung von Signalen verwendet wird.
2. Drahtlos. In diesem Fall wird das Signal ohne ein materielles Mittel dazwischen übertragen. Zum Beispiel werden elektromagnetische Wellen für die Übertragung benutzt.

Intra- und Inter-Verbindungs-Entfernung und Medium in der Architektur-Komponente

Abhängig vom Anwendungsgebiet der Einheit kann es sein, daß es mehr als eine im Hinblick auf die Entfernung unterscheidbare Kategorien verwendet, um die Unterkomponenten miteinander zu verbinden.

Real Partner Match Making Server Unit

Die Real Partner Match Making Server Unit wird alle drei Verbindungsmöglichkeiten einsetzen. Die Module in der Einheit werden höchstwahrscheinlich mit der LSU der SPLEMP über langstreckige Kabel-Verbindungen kommunizieren, und gegebenenfalls wäre das sogar mit langstreckigen drahtlosen Verbindungen möglich. Mit der PMCCD des Benutzers wird der RPMMSU über langstreckige drahtlose Verbindungen kommunizieren.

Personal Mobile Communications and Computing Device des Benutzers

Personal Mobile Communications and Computing Device des Benutzers werden höchstwahrscheinlich Verbindungen über sehr kurze Entfernungen haben, da alle Unterkomponenten in einem physikalisch zusammenhängenden Gerät eingeschlossen werden. Diese einschränkende Bedingung wird dadurch etwas aufgelockert, daß es möglich ist, daß das Gerät räumlich etwas verteilt sein könnte. Das eine oder der andere Modul könnte von den anderen getrennt sein, zum Beispiel die Audio-Eingabe-Komponente. Zwischen diesen könnte die Verbindung dann über kurze Kabel oder kurzstreckige drahtlose Mittel erfolgen. Extern kommuniziert das Gerät mit dem RPMMSU über langstreckige drahtlose Verbindungen und mit der LSU des SPLEMPs über kurzstreckige drahtlose Verbindungen.

Location Server Unit des Serviced Public Leisure and Entertainment Meeting Place

Die Location Server Unit des Serviced Public Leisure and Entertainment Meeting Place könnte zwei Arten von Verbindungen nutzen. Innerhalb der Hauptrechner-Plattform würde es Verbindungen über sehr kurze Entfernung besitzen. Mit den anderen abhörenden Modulen könnte es kurzstreckige Kabel-Verbindungen oder kurzstreckige drahtlose Verbindungen haben. Im Hinblick auf externe Verbindungen wird es mit der RPMMSU langstreckige Verbindungen haben, die höchstwahrscheinlich über Kabel verlaufen werden, aber auch drahtlose Mittel sind nicht ausgeschlossen. Zu dem PMCCD des Benutzers wird es nur kurzstreckige drahtlose Verbindungsarten geben.

Haupt-Dienstprozesse, Funktionalitäten und Lösungsstrategien Benutzer-Registrierung

Zuerst und vor allem muß sich ein Benutzer, bevor er den Vermittlungsdienst benutzen kann, bei diesem Dienst anmelden. Während der Anmeldung stellt der Benutzer die folgenden Informationen bereit:

1. Persönliche Identifikations-Angaben
2. Digitale Foto(s) von sich
3. Angaben zur Kontaktierbarkeit
4. Privat-Anschrift
5. Arbeitsplatz-Anschrift
6. Identitätsbürgende Instanz (z. B. in manchen Ländern die Post)
7. Autorisierende Angaben zur Identitätsbestätigung
8. Bankverbindung
9. Kontaktierbarkeitsadressen der Personal Mobile Communications and Computing Devices

Die private Anschrift ermöglicht es festzustellen, in welcher Region der Benutzer den Dienst beansprucht, und den Benutzer mit der jeweiligen geographischen Region zu assoziieren. Es wäre definitiv wünschenswert, die reale Identität des Benutzers festzustellen. Dazu kann man zwei Gründe nennen. Als erstes zur Authentifizierung, das heißt, um festzustellen, ob der Benutzer sich wirklich unter seiner Identität anmeldet, und zum zweiten, um zu bestätigen, ob das vorgegebene Foto wirklich von dem Benutzer ist und nicht von jemand anderem, ob real oder virtuell.

Angaben zur Bankverbindung könnten von Nutzen sein, um dem Benutzer Rechnungen zu schreiben, falls so eine Politik geführt wird, für eine bessere Dienstleistungsqualität, für einmalige Rechnungsschreiben, für Hilfsdienste wie Identifikations-Verarbeitung, usw., und natürlich für die Identifikation selbst.

Kontaktierbarkeits-Informationen könnten benötigt werden, um den Benutzer über mögliche den Dienst betreffende Informationen, Anforderungen, usw. zu informieren. Das Personal Mobile Communications and Computing Device wäre natürlich die wünschenswerteste Kontaktierbarkeitsmöglichkeit für Benachrichtigungen, die dringende Aufmerksamkeit oder Befolgung brauchen, aber es kann auch eine E-Mail Adresse oder eine Telefonnummer sein. Man braucht die Adresse des Personal Mobile Communications and Computing Device, um den Dienst zu verwirklichen. In der Theorie kann der Benutzer mehrere solchen Geräte haben, aber während der Benutzung muß er eine auswählen. Der Benutzer kann davon eine als vorgegebenen definieren. Das aktive Gerät kann natürlich auch gefunden werden, wenn der Benutzer sich einmal an dem SPLEMP anmeldet, und die LSU des SPLEMP die RPMMSU informiert, mit welchem Personal Mobile Communications and Computing Device der Benutzer sich angemeldet hat. Der Benutzer kann sich nur über ein Gerät anmelden, das auch hier aufgezählt wurde. Der Identifikations-Chip innerhalb des Personal Mobile Communications and Computing Device besagt, welche Identität es hat. Wenn man den Identifikations-Chip ändern würde, würde das Gerät einfach als ein anderes Gerät verstanden werden.

Benutzerprofil-Verwaltung

Dies ist ein sehr wichtiger Aspekt des Dienstes. Hier muß der Benutzer Angaben über sich selbst eingeben. Es gibt verschiedene Bereiche, worüber der Benutzer Informationen eingeben wird. Dies schließt die folgenden ein:

1. Körperliches Aussehen
2. Spirituelles Glaubenssystem
3. Politisches Glaubenssystem
4. Ethnische Abstammung
5. Kulturelle Identifizierung
6. Sozialer Status
7. Ausbildung
8. Berufliche Fachrichtung
9. Beruflicher Status
10. Wohlstand und Einkommen
11. Erfahrung
12. Wissen
13. Fähigkeiten
14. Gewohnheiten
15. Wohnumgebung
16. Interessen
17. Erwartungen
18. Ansichten
19. Bevorzugte Themen
20. Interaktive Tätigkeitsabsichts-Definitionen und Partnerschaftskandidaten-Profilschablone
21. Usw.

Es muß betont werden, daß der Benutzer die Angaben so ehrlich wie möglich eingeben sollte. Es wird nicht vorausgesetzt, daß der Benutzer alle oben genannten Informationen eingibt. Allerdings können alle oben genannten Elemente für die Überprüfung der Partnerschaftseignung benutzt werden. Dem Benutzer soll ermöglicht werden, daß er über diese und viele andere Themen mehr so viele Einzelheiten eingeben kann, wie er sich wünscht. Falls der Benutzer noch weitere Informationen bereitstellen möchte, sollte die Möglichkeit schon existieren. Natürlich kann der Benutzer die ganzen Informationen in freiem Text-Format bereitstellen, aber für den Algorithmus müßte es schon wohlstrukturiert werden. Freien Text in strukturierte Informationen umzuwandeln wäre schwierig, da dies technologisch hochentwickelte Sprachverarbeitungs-Module und sogar künstliche Intelligenz verlangen würde. Effektiver und einfacher wäre es, dem Benutzer sehr viele Fragen zu stellen und die durch die Antworten zurückgelieferten Informationen in geeigneten Datenstrukturen zu erfassen. Diese Vorstellungsgespräche könnten in textlicher oder mündlicher Form sein. Üblicherweise wird der Benutzer vor einem Computer mit Netzwerk-Zugang sitzen, und unter Verwendung gewisser Netzwerk-Protokolle eine Datenverbindung zu der RPMMSU erstellen. Durch Datenaustausch zwischen den zwei Einheiten könnte der Benutzer sein Benutzer-Profil editieren. Ein Beispiel ist, wenn der Benutzer eine Internet-Verbindung über einen Internet-Dienstanbieter herstellt. Über den Internet-Dienstanbieter kann der Benutzer eine Verbindung zu der Web-Präsenz der RPMMSU machen. Mit der Hilfe eines Web- Browsers kann der Benutzer Web-Seiten von dort herunterladen. Diese Web-Seiten bieten die Funktionalität zur Editierung des Benutzerprofils. Die Nutzung dieser Funktionalität eröffnet ein Interview, welches entweder textlicher, graphischer oder mündlicher Natur sein kann; indem man die Fragen des Interviews beantwortet, kann man sein Benutzer-Profil editieren. Diese Benutzerprofil-Editierungsfunktionalität kann der Benutzer wiederholt aufsuchen und das Benutzerprofil kann editiert, wiedereditiert und erweitert werden.

Bedienungs-Einleitung

Zuerst wendet sich ein neuer Benutzer des verteilten Systems für die Partnersuche, Partnerschaftseignungsprüfung und Bekanntmachung an einen dem System angeschlossenen öffentlichen Freizeit- und Vergnügungs-Ort (SPLEMP) und meldet sich für den dort verfügbaren Dienst an, als jemand, der sich an diesem SPLEMP aufhält. Dies geschieht über ein Personal Mobile Communications and Computing Device (PMCCD) mittels eines Befehlsformats. Dies kann entweder durch das Drücken einer Taste auf dem Gerät, welche in diesem Modus für diesen Zweck eingestellt wurde, oder durch Berührung eines bestimmten Punktes auf dem Sensorbildschirm, was die Anmeldung betätigen würde, oder durch einen mündlichen Befehl erfolgen. Dies ist der ersten Schritt. Nach diesem Schritt werden viele Teile dieses Moduls und andere sachdienliche Module geladen und dem Benutzer bereitgestellt, über welche die Parameter des Dienstes erfaßt werden können.

Ortsfeststellung

Ortsfestellung kann konzeptionell eigentlich in zwei Stufen unterteilt werden. Die erste ist die Orts-Anmeldung und die andere ist die Anmeldungsorts-Anwesenheits-Sicherstellung. Bei der Orts-Anmeldung reicht es, wenn ein Benutzer über sein PMCCD aussagt, daß er sich an so-und-so einem Ort befindet. Hier wird der Ort als ein SPLEMP verstanden. Unter Anmeldungsorts-Anwesenheits-Sicherstellung versteht man, Mechanismen zu haben, wodurch der Dienst sicherstellen kann, daß der Benutzer, der sich an einem Ort angemeldet hat, sich auch wirklich noch an diesem Ort befindet, und daß kein Betrug bzw. kein Mißverständnis vorliegt.

Bei der Anmeldungsorts-Anwesenheits-Sicherstellung findet ebenfalls eine Orts-Anmeldung statt, aber zusätzlich muß der Benutzer beweisen können, daß diese Behauptung wahr ist. Also wird hier bißchen anders vorgegangen. Dazu muß die Ortsposition festgestellt werden. Man kann diese als einen Parameter an die Dienstanforderung ansehen. Die Feststellung der Ortsposition kann auf mehrere unterschiedliche Weisen geschehen:

- Entweder die Koordinaten können von einem Positionierungsdienst abgelesen werden, zum Beispiel dem Global Positioning System, welches mit dem Personal Mobile Communications and Computing Device assoziiert wird, und dessen Daten zu dem RPMMSU übertragen werden.
- Falls die Umgebung von dem Personal Mobile Communications and Computing Device automatisch wahrnehmbar ist, und das Gerät die Fähigkeit besitzt, die Umgebung abzufragen, dann kann das Gerät auch die RPMMSU von der Ortsposition des Benutzers informieren. Eine Verbindung zu der Umgebung kann geschehen über verschiedene Technologien wie den auf Infrarot basierten IrDA, auf Rundfunkwellen basierten Bluetooth Technologie von BluetoothSIG, drahtlose JINI von Javasoft, oder ähnlichem, was die Aufgabe erledigen kann. Dann wird der Ortinformationsdienst aufgesucht, um herauszufinden, wie die Umgebung sich definiert, über Name und Domain-Name oder über geographische Koordinaten. Der Domain-Name kann aus unterschiedlichen Systemen entstehen wie zum Beispiel aus politisch-geographischer Zuordnung, Industriebranche, Gesellschaftsverband, Behördlicher Anmeldung, Zielgruppe, Topologie, usw. Wenn man den Namen des Ortes kennt, sollte man die geographischen Koordinaten feststellen können und zum Teil auch umgekehrt.
- Der Benutzer kann die Informationen über die Identität des Ortes auch selbst eingeben, durch Diktieren, Eintippen oder die Auswahl aus verschiedenen aufgelisteten Wahlmöglichkeiten.

Die Identitäts-Informationen den Ort betreffend können auf verschiedenen Wegen definiert werden:

- Name. Dies kann passieren, falls es einen eindeutigen Namen für den Ort gibt und die geopolitische Domain in dem Kontext klar ist.
- Adresse. Zu jeder Adresse entspricht ein bestimmter Ort.
- Geographische Koordinaten. Falls der Ort nicht in einem mehrstöckigen Gebäude untergebracht wurde, könnte man eine eins-zu-eins Beziehung zwischen den Koordinaten und dem Ort erwarten.
- Darüber hinaus mag es für manche Orte irgendeine behördliche oder handelskämmerliche Identifikation geben, welche für jeden Ort einzigartig ist.
- Eine solche ID könnte für eine ganze Kategorie von Diensten in Gebrauch sein, und würde dann eventuell von einem zentralen organisierenden Verband von Dienstanbietern vergeben werden.
- Es könnte sein, daß eine ID nur für diese eine Dienstleistung speziell konzipiert wurde.

Es ist möglich, von jeder dieser verschiedenen Arten, einen SPLEMP-Ort zu bezeichnen, von einer anderen oder Gruppen von anderen abzuleiten, je nach der Einzigartigkeit des Informationselementes und der Klarheit des Kontextes. In unterschiedlichen Kontexten würden einige Arten von Identitätsinformationen nicht vorhanden sein. Von den Informationselementen, die anwendbar sind, würde es ausreichen, eines oder einige zu spezifizieren, und die anderen über Abbildungen, Konvertierung oder ein anderes Nachschlageverfahren ableiten zu lassen. Außerdem, je nach den Anforderungen der Anwendung, wäre es gar nicht wünschenswert, manche bzw. alle abzuleiten. Diese Ableitung wird, wenn überhaupt, bei der RPMMSU stattfinden, welche diese Funktionalität selbst besäße, oder den Dienst von noch einer weiteren Einheit beanspruchen würde, welche solche Abbildungsverarbeitungsfähigkeiten und die notwendigen entsprechenden Informationen besitzt.

Interaktive-Tätigkeitsabsichten-Definition

Der Benutzer könnte den Wunsch haben, eine bestimmte Absicht an einer interaktiven Tätigkeit oder Tätigkeiten zu definieren, an der er gemeinsam mit einem Partnerschaftskandidaten teilnehmen möchte, und die er als die am besten geeignete und wünschenswerte für die bestimmte Situation, Ort, Laune, Bedürfnisanalyse und Beschäftigungsbetonung einstuft und die seinen Prioritäten entspricht. Mit anderen Worten, der Benutzer definiert, welche seine Interessen zu dem jeweiligen Zeitpunkt sind. Die Rollen in der Tätigkeit können symmetrisch oder unterschiedlich sein. Aus dem Benutzer-Profil oder von einer zusätzlichen Instanz sollte es schon klar hervor gehen, welche Rolle der Benutzer bei der Tätigkeit zu spielen beabsichtigt. Falls die Tätigkeit nur eine Rolle hat, oder eine vorgegebene Rolle implizit zu erkennen ist, ist es nicht notwendig, daß diese Information explizit von dem Benutzer eingegeben werden muß. Außerdem sollte der Benutzer in seinem Benutzer-Profil schon alles so beschrieben haben, daß es ihn qualifiziert, die Rolle zu besetzen.

Darüber hinaus könnte der Benutzer explizit zum Ausdruck gebracht haben, für welche Rolle ein Partnerschaftskandidat gesucht werden soll. In den meisten Fällen wird das klar aus dem Kontext hervor gehen. Die meisten interaktiven Tätigkeiten dürften nur zwei Rollen haben, und wenn der Benutzer die eine Rolle übernimmt, dann wird logischerweise der Partnerschaftskandidat für die übrig gebliebene Rolle gesucht. Falls die Rollen symmetrisch sind, ist die Rollenzuteilung auch klar. Gibt es hingegen mehrere Rollen für eine Tätigkeit, so finden wir Haupt- und Randrollen, und der Kontext kann auf die Hauptrollen beschränkt werden. Es gibt dann wohl auch Abhängigkeiten zwischen den Rollen, so daß eine bestimmte Rolle eine andere als Gegenstück erfordert, was es einfacher macht, welche Rolle der Partnerschaftskandidat spielen soll. Falls es Zweifel gibt, kann natürlich vom Benutzer immer gefordert werden, die genaue Rolle, die der Partnerschaftskandidat spielen soll, zu spezifizieren. Falls der Benutzer meint, daß die Rolle explizit spezifiziert werden soll, um die oben genannte Strategie, die Rolle des Partnerschaftskandidaten zu bestimmen, zu umgehen, kann der Benutzer dies natürlich selbst in die Hand nehmen.

Um die Anforderungen einer Rolle in einer Tätigkeit zu erfüllen, gibt es gewisse Qualifikationen, die der Partnerschaftskandidat aufweisen muß. Diese Anforderungen sind in sich abhängig von der Art der Tätigkeit und der Ansprüche der betroffenen Rolle, und können als solche davon abgeleitet werden. Außer diesen Anforderungen könnte der Benutzer weitere zusätzliche Bedingungen an den Partnerschaftskandidaten stellen wollen. Diese Bedingungen müßten explizit genannt werden. Der Algorithmus könnte allgemeine ästhetische Neigungen des Benutzers benutzen, die vorher in dem Benutzer Profil definiert wurden, um den Partnerschaftseignungsfund geschmackvoller zu machen. Diese Neigungen werden nicht unbedingt als notwendig eingestuft, um eine Partnerschaftseignung zu finden.

Es könnte interaktive Tätigkeiten geben, bei denen es wichtig wäre, eine breite Vielfalt von zusätzlichen Qualifikationen zu definieren. Wenn dies wiederholt gemacht wird oder gemacht werden muß, obwohl gerade keine Lust dazu vorhanden ist, seine Zeit so zu verbringen, so kann dies als belästigend und unangenehm empfunden werden. Deswegen sollte es möglich sein, alle diese verschiedenen Qualifikations-Mengen für verschiedene interaktive Tätigkeiten vorab zusammen mit dem Benutzerprofil zu definieren, oder sie zu einem späteren Zeitpunkt hinzufügen, aber nicht unbedingt zwingend dann, wenn man sich gerade in einer Partnersuchumgebung befindet. So werden mehrere bevorzugte interaktive Tätigkeiten definiert sein, und zu jeder könnten mehrere zusätzliche Profil-Schablonen für den Partnerschaftskandidaten definiert sein. Für diese Tätigkeiten wäre es bequem möglich, innerhalb einer Partnersuchumgebung einfach eine bestimmte Tätigkeit und die dazugehörende(n) Profil-Schablone(n) zu aktivieren. Wo dies möglich ist, kann eine Vereinigung der ausgewählten Profil-Schablonen für die Sitzung übernommen werden. Man kann auch die Attribute der spezifizierten Profil-Schablonen für den Partnerschaftskandidaten durch AND, OR, oder XOR Masken kombinieren.

Der Benutzer sollte auch seine Absichten etwas abstrakter definieren dürfen. Das heißt, der Benutzer wird die interaktive Tätigkeit abstrakter spezifizieren. Diese allgemeinere Kategorie wird all ihre spezifischeren Varianten einschließen. Welche Varianten dann als spezifiziert gelten werden, kann nur bestimmt werden, wenn die allgemeine interaktive Tätigkeit durch die Interessen des Benutzers, die im Benutzerprofil definiert wurden, filtriert wird und die Einschränkungen darauf eingesetzt werden.

Der Benutzer darf mehrere interaktive Tätigkeiten spezifizieren, an denen er zu dieser Zeit Interesse hat. Der Partnerschaftssuchalgorithmus wird dann alle beabsichtigten interaktiven Tätigkeiten getrennt bearbeiten.

Im oben erwähnten Fall kann es empfehlenswert sein, wenn die Prioritäten der interaktiven Tätigkeiten definiert sind. Diese Prioritäten geben an, wie wichtig die spezifizierten interaktiven Tätigkeiten für den Benutzer sind und in welcher Reihenfolge der Wichtigkeit das Eignungsüberprüfungsprogramm diese Tätigkeiten behandeln soll. Es gibt verschiedene interaktive Tätigkeiten, die den Benutzer in einer bestimmten Rolle haben, die als dienstbereitstellende Rolle beschrieben werden kann. Diese Arten von Tätigkeiten nehmen eine niedrigere Priorität an als Tätigkeiten, bei denen die Rolle des Benutzers mehr als eine symmetrische Rolle oder als Klienten-Rolle darzustellen wäre. Außerdem kann die Priorisierung auf der Basis des im Benutzer-Profil vordefinierten Interessen-Spiegels für bestimmte interaktive Tätigkeiten durchgeführt werden, oder auf der Basis von explizit angegebenen Priorisierungen der interaktiven Tätigkeiten selbst. Solch eine Priorisierung würde man als Vorgabe verwenden. Abhängig von zutreffendem Ort, Zeit, Situation, Laune und Wünschen könnte sich der Benutzer für eine unterschiedliche Priorisierung der interaktiven Tätigkeiten entscheiden, an welchen der Benutzer teilzunehmen beabsichtigt. Zusammenfassend dargestellt, definiert der Benutzer, für welches Ziel er den Partner sucht und welche Arten von Partner dafür in Frage kämen. Die meisten Charakteristiken des Partnerschaftskandidaten wären schon während der Phase der Definition der Schablone festgelegt worden. In dieser Phase wird man nur das Ziel aktivieren, entweder durch eine Auswahl aus üblichen Zielen, die man benutzt und die für den Benutzer schon vordefiniert sind, oder durch Eingabe eines Zieles, welches der Dienst anbietet. Fallsein vordefiniertes Ziel mehrere entsprechende Partnerschaftskandidaten-Profilschablonen besitzt, würde der Benutzer wohl gerne die Wahl haben, welche er sich am meisten wünscht oder, im Fall von mehreren, in welcher Reihenfolge. Falls der Benutzer mehrere Ziele aktiviert, könnte der Benutzer deren Prioritäten neu definieren wollen. Alles, was nicht vordefiniert aus dem Benutzer-Profil hervorgeht, kann eventuell über das Personal Mobile Communications and Computing Device vorgenommen werden.

Das oben Diskutierte umfaßt einen Dialog zwischen dem Benutzer und dem Dienst.

In manchen Fällen wäre es für den Benutzer möglich, alles über das Personal Mobile Communications and Computing Device zu benennen und die Dienst-Anforderung wird an die RPMMSU übertragen.

In anderen Fällen würde der Benutzer eine beliebige vordefinierte Möglichkeit von seinem Benutzer-Konto bei der RPMMSU auswählen wollen. In diesem Fall ist es denkbar, daß das Personal Mobile Communications and Computing Device alle vordefinierten Auswahlmöglichkeiten von der RPMMSU herunterladen wird. Die Verantwortung für diesen Dialog könnte von dem Personal Mobile Communications and Computing Device oder durch ein passendes Modul bei der RPMMSU übernommen werden, wobei im letzteren Fall das Personal Mobile Communications and Computing Device die Rolle eines passiven Mediums spielte.

Dienst-Aktivierung Benutzungs-Aktivierung

Sobald der Benutzer einen SPLEMP betreten hat, kann er den Dienst aktivieren. Der Dienst könnte automatisch nach der Ortsanmeldung aktiviert werden, oder der Benutzer könnte eine Aufforderung erhalten, um zu entscheiden, ob der Dienst aktiviert werden soll oder nicht, oder kann er kann die Aktivierung selbst auslösen. Dies würde dann die erste Dienst- Aktivierung für den bestimmten SPLEMP für eine Zeitdauer, z. B. einen Tag, darstellen. Von diesem Zeitpunkt an wird die RPMMSU den Benutzer bedienen.

Dienst-Deaktivierung

Der Benutzer kann im Laufe seines Aufenthaltes in diesem SPLEMP den Dienst deaktivieren wollen, um zu vermeiden, gestört zu werden oder in Situationen, zu denen er nicht verfügbar ist, was hin und wieder passieren kann, z. B. in den folgenden Fällen:

1. Der Benutzer geht zu dem Waschraum, um sich frisch zu machen.
2. Der Benutzer führt gerade ein Gespräch mit irgendeinem Bekannten, Freund, usw. und hat keine Lust, gestört zu werden.
3. Der Benutzer ist gerade beim Essen.
4. Der Benutzer könnte schon durch diesen Dienst einen Partnerschaftskandidaten gefunden haben und wäre gerade dabei, die ausgewählten Person kennenzulernen
5. Usw.

Dienst-Wiederaktivierung

Wenn der Benutzer fühlt, daß er wieder so weit ist, den Dienst weiter zu benutzen, kann er den Dienst wieder aktivieren.

Benutzer-Bedienungseinstellungen

Es kann mehrere Dienstparameter geben, welche der Benutzer beeinflussen können möchte. Einige Beispiele sind wie folgenden:

1. Qualitätsklasse der Bedienung
2. Preisklasse
3. Maximale Mitteilungshäufigkeit der Partnerschaftstreffer
4. Minimaler Übereinkunftsprozentsatz
5. Usw.

Je nach der Qualität des Dienstes, die der Benutzer anstrebt, kann der Benutzer eine der Qualitätsklassen auswählen. Diese Qualitätsklassen entsprechen vielleicht auch unterschiedlichen Preisklassen, aber nicht unbedingt. Vielleicht gibt es Zeitbeschränkungen, wie oft man eine bevorzugte Qualitätsklasse verwenden kann.

Ein Benutzer kann auch verschiedene Preisklassen benutzen. Die Preisklasse könnte etwa für einen bestimmten Benutzer fest sein, oder sie könnte frei wählbar sein.

Ein Benutzer könnte die höchst Anzahl von vermittelten Partnerschaftskandidaten, die innerhalb einer Zeitspanne angeboten werden, kontrollieren wollen. Zum Beispiel könnte ein Benutzer wollen, daß ihm nicht öfter als alle 20 Minuten ein Partnerschaftskandidat vermittelt werden soll.

Ein Benutzer kann spezifizieren, wie anspruchsvoll, er/sie sein möchte. Je anspruchsvoller ein Benutzer ist, desto schwieriger ist es, einen geeigneten Partnerschaftskandidaten für ihn/sie zu finden, es nimmt mehr Zeit in Anspruch, und vielleicht findet sich überhaupt gar kein Partner in dem entsprechenden SPLEMP, der so gut zu dem Benutzer passen würde.

Es könnte noch andere Parameter geben, die in den Umfang der bisher erwähnten Parameter fallen. Es könnten noch weitere existieren, die überhaupt nicht unter die oben genannten Kategorien fallen, aber trotzdem in diesen Verfahrensschritt oder in diese Funktionalität eingestuft werden könnten.

Überwachung der Aufenthaltsfortführung am Anmeldungsort

Es kann jedoch auch sein, daß die Überwachung des Aufenthaltsortes des Benutzers wichtig ist um herauszufinden, ob der Benutzer noch Bedienung benötigt, oder ob er noch bedient werden kann. Dieses Verfahren beginnt, nachdem sich der Benutzer bei dem SPLEMP angemeldet hat.

Dies kann ausgehend von zwei unterschiedliche Kriterien geschehen.

Benutzerbehauptung der Aufenthaltsfortführung am Anmeldungsort

Bei diesem geht es nur darum, daß der Benutzer der RPMMSU mitteilen kann, daß er noch da ist. Ob dies der Wahrheit entspricht, ist hier gar nicht wichtig. Dazu lassen sich verschiedene Strategien aufführen:

- Auf-Gelände-Überprüfung durch Umgebungs-Abhörung: Auf dem Gelände des SPLEMPs befinden sich mehrere Ausstrahler der SPLEMP-Kennzeichnung-Signale. Bei Empfang von solchen Signalen weiß das PMCCD, daß der Benutzer sich auf dem Gelände befindet. Wenn es diese Signale nicht mehr empfängt, heißt das, daß der Benutzer sich von dem SPLEMP entfernt hat. In diesem Fall, läßt das PMCCD des Benutzers die RPMMSU wissen, daß der Benutzer sich nicht mehr auf dem Gelände des SPLEMPs aufhält. Die RPMMSU ändert den Aufenthaltsstatus des Benutzers entsprechend, d. h. der Benutzer gilt als ausgecheckt. Das PMCCD folgt auch diesem Prozeß. Es besitzt auch die Kenntnis, daß der Benutzer ausgecheckt ist. Wenn das PMCCD die Signale des SPLEMPs wieder empfangen kann, meldet es sich wieder bei der RPMMSU als eingecheckt. Es ändert auch die eigene interne Aufenthaltszustandskenntnis.
- Geographische Feststellung der Aufenthaltsposition: Das PMCCD des Benutzers besitzt die Fähigkeit, die eigene geographische Position festzustellen. Das PMCCD kann auch eine geographische Karte des Geländes des SPLEMPs durch einen entsprechenden Informationsdienst zu sich herunterladen. Diesem Informationsdienst muß nur den Antrag erteilt werden und die notwendigen Informationen werden bereitgestellt. Dieses Herunterladen kann im Prinzip auch drahtlos erfolgen, entweder allein am Eingang, oder man hat überall auf dem Gelände Zugriff auf diesen Dienst. Durch diesen Informationsdienst wird eine Karte bereitgestellt, worauf der Umkreis des Geländes mit geographischen Koordinaten vermerkt ist. Es kann mehrere solcher Karten geben, je nachdem, welche Etage gemeint ist. Das PMCCD des Benutzers berechnet, ob die Aufenthaltskoordinaten innerhalb diesen Umkreis fallen oder nicht. Für welche Etage gerechnet werden soll, falls der SPLEMP überhaupt mehrere Etagen besitzt, kann durch Abhören von Etagen-Informationssignalen von dem Gelände des SPLEMPs festgestellt werden. Dies kann das PMCCD kontinuierlich machen oder nach einer bestimmten Zeitperiode. Jedesmal wenn die Antwort dieser Berechnung anders ausfällt als die vorherige Antwort, wird dies der RPMMSU mitgeteilt.
- Entgegennahme der Aufenthaltsänderungseingabe des Benutzers: Hierbei wird jede Änderung an dem Aufenthaltszustand des Benutzers bezogen auf den jeweiligen SPLEMP vom Benutzer selbst in das PMCCD eingegeben. Der Benutzer kann die RPMMSU wissen lassen, ob er sich auf dem Gelände des SPLEMPs befindet und dadurch als eingecheckt gelten soll oder daß er sich dort nicht befindet und dementsprechend als ausgecheckt gelten soll. Es ist dem Benutzer überlassen, sich darum zu kümmern, daß er diese Angaben in das PMCCD eingibt, so daß das PMCCD dies an die RPMMSU weiterleiten kann.

Sicherstellung der Aufenthaltsfortführung am Anmeldungsort

Hierbei geht es um mehr als nur um eine Benutzerbestätigung der Aufenthaltsfortführung am Anmeldungsort. Hier wird sichergestellt ob dies wirklich der Fall sei. Dazu wird auch noch ein Subsystem am SPLEMP in Anspruch genommen, was die Location Server Unit genannt wird. Das System kann sich nicht nur auf dem Benutzer verlassen. Es kann sein, daß der Benutzer nicht immer daran denkt den Dienst zu deaktivieren, sich auszuchecken oder sich abzumelden als er das tun sollte. Es ist aber auch denkbar, daß aus irgendwelchen Gründen, der Benutzer absichtlich dies nicht tun wolle. In dem Fall, besteht die Gefahr, daß einem anderen dieser Benutzer vermittelt wird, obwohl er sich nicht weiter auf dem Gelände des SPLEMPs befindet. Das könnte sehr irritierend auf anderen Benutzer wirken. Sogar der Benutzer selbst könnte sich davon irritiert fühlen.

Der Aufenthaltsort des Benutzers kann durch spezielle Aufenthaltsorts-Verfolgungs- Komponenten in dem Personal Mobile Communications and Computing Device des Benutzers oder einem anderen Gerät bei dem Benutzer überwacht werden. Das Gerät kann entweder an- oder ausgeschaltet sein. Es kann aber auch sein, daß die zuständige Komponente in dem Gerät selbst aktiviert oder deaktiviert werden kann, ohne das ganze Gerät an- oder auszuschalten.

Die Plattform-Module, welche die Komponente benötigt, könnten auch entscheidend sein, indem sie auch anwesend oder nicht vorhanden sein können. Da man nicht davon ausgehen kann, daß die Ortüberwachungskomponente in dem Gerät des Benutzers immer funktioniert, ist es wichtig, neue Strategien zu erdenken um festzustellen, ob der Benutzer, als bei einem SPLEMP Angemeldeter, in die Partnerschaftseignungsüberprüfung einbezogen werden soll. Einige der vielen hier möglichen Strategien sind die folgenden:

- Eingangsseinchecken und Ausgangsauschecken: An den Ein- und Ausgängen wird es Aufenthaltsveränderungen abhörende Module geben. Diese senden Signale aus, um die in dem Personal Mobile Communications and Computing Device des Benutzers vorhandenen, für die Aufenthaltsüberwachung zuständigen Module wissen zu lassen, daß der Benutzer das Gelände des SPLEMP gerade betritt bzw. verläßt. Auf den Empfang solcher Signale reagiert das Aufenthaltsortsverfolgungsmodul mit dem Senden von Ortsanmeldungskennzeichen oder einem anderen entsprechenden Kennzeichen, was den Ortsstatus des Benutzers entsprechend ändert. Falls das Modul auf ein Ausgangssignal reagiert, wird der Benutzer als ausgecheckt vermerkt, und falls das Modul auf ein Eingangssignal reagiert, wird der Benutzer als eingecheckt vermerkt. Dieser Status wird an die RPMMSU übermittelt.
- Auf-Gelände-Bestätigung: Die Gelände selbst sind mit aufenthaltsbestätigenden Abhörmodulen ausgestattet. Diese Module senden ununterbrochen Signale aus, welche besagen, daß sie von solch einer Art Modul gesendet wurden, und die das Kennzeichen des jeweiligen SPLEMPs übermitteln. Nach einer gewissen Zeit überprüft das Aufenthaltsorts-Verfolgungsmodul in dem Personal Mobile Communications and Computing Device des Benutzers, ob das Signal vorhanden ist, und falls dies der Fall ist, schickt es drahtlos ein Bestätigungssignal. Dieses Signal enthält ein Ortsanmeldungskennzeichen oder ein anderes entsprechendes Kennzeichen, und kann wahlweise Authentifizierungsinformationen enthalten. Beim Empfang solch einer Antwort verlängert das Benutzeraufenthaltsüberwachungsmodul der Ortsdiensteinheit des SPLEMPs den Aufenthaltsstatus des Benutzers. Falls das Benutzeraufenthaltsüberwachungsmodul innerhalb einer bestimmten Zeitdauer kein solches Signal empfängt, läßt es die RPMMSU wissen, daß der Benutzer sich nicht auf dem Gelände befindet. So hört die RPMMSU auf, den jeweiligen Benutzer zu bedienen. In der Ortsdiensteinheit des SPLEMPs wird der Benutzer als nicht verfügbar vermerkt. Sollte das Aufenthaltsortsverfolgungsmodul des PMCCD des Benutzers erneut dessen Anwesenheit auf dem Gelände signalisieren, so wird der Status des Benutzers wieder als verfügbar und bedienbar vermerkt. Die RPMMSU wird benachrichtigt, welche die Bedienung des Benutzers wieder aufnimmt.
- Zeitstrategien: Viele Strategien können angewendet werden, welche die Bedienbarkeit des Benutzers über das Kriterium Zeit festzustellen versuchen. Die Auf-Gelände-Bestätigung ist ebenfalls eine solche Strategie. Angenommen, daß ein Benutzer sich innerhalb einer gewissen Zeit, nach dem er ausgecheckt hat, sich nicht erneut eincheckt, dann könnte der Benutzer seine Anmeldung für den jeweiligen SPLEMP verlieren. Falls der Benutzer für eine längere Zeit nicht verfügbar bleibt, könnte er als ausgecheckt angesehen werden. Der SPLEMP könnte eine bestimmte Zeit als Geschäftschluß für einen bestimmten Tag, Ereignis oder Sitzung angegeben haben, und alle Benutzerortsanmeldungen für diesen SPLEMP werden zu dieser Zeit terminiert.
- Benutzereinstellungen: Der Benutzer kann explizit angeben, ob er vorübergehend diesen Dienst deaktivieren möchte, vorübergehend nicht verfügbar sein möchte, auschecken möchte, oder sich für diesen SPLEMP abmelden möchte. Der Benutzer kann auch den Dienst aktivieren oder einchecken. Dies geschieht auf Veranlassung des Benutzers selbst.
- Benutzeranfrage: Wann immer der Benutzer vor hat, sein PMCCD auszuschalten, kann der Benutzer angefordert werden, um zu bestätigen, ob er auch noch den Dienst deaktivieren möchte. Wenn der Benutzer auscheckt, kann er befragt werden, ob er sich auch noch von dem jeweiligen SPLEMP abmelden möchte.

Partnerschaftseignungsüberprüfung

Das Partnerschaftseignungsüberprüfungsmodul ist zuständig für die eigentliche Partnerschaftseignungsüberprüfung. Es hat in seinem Besitz Informationen über alle angemeldeten Benutzer in einem bestimmten SPLEMP. Die Benutzerinformationen eines Benutzers werden mit den Benutzerinformationen der anderen Benutzer verglichen, um festzustellen, ob es einen Partnerschaftseignungstreffer zwischen den Beiden gibt oder nicht, und wenn ja, wie hoch der Übereinkunftsgrad ist. Das Ziel ist, diejenigen Fälle herauszufinden, bei denen der Übereinkunftsgrad maximal ist. Es gäbe verschiedene Heuristiken, die benutzt werden können, um diese Partnerschaftseignungstreffer herauszufinden. Allgemein wird versucht, einen Ausgleich unter verschiedenen Kriterien wie Geschwindigkeit, Partnerschaftseignungstrefferqualität, gerechter Verteilung der Ressourcen, Nutzung von Ressourcen, gerechter Wahrscheinlichkeit einer Partnerschaftseignungsübereinkunft für alle, besserer Bedienung bei gutem Verhalten, Dienstverschlechterung als Bestrafung für Verhaltensverstöße usw., zu finden.

Vorgehensweise bei der Partnerschaftseignungsfeststellung

1. Der Anwärterteilnehmer soll sich auf dem gleichen Gelände befinden wie der Benutzer.
2. Der Anwärterteilnehmer soll seine Verfügbarkeit für eine solche Tätigkeit zu dieser Zeit eingegeben haben.
3. Der Anwärterteilnehmer soll diese Verfügbarkeit aktiviert haben.
4. Der Anwärterteilnehmer soll eine Erklärung abgegeben haben, keinen Einwand gegen eine solche Tätigkeit zu haben.
5. Der Anwärterteilnehmer soll eine Neigung für eine solche Tätigkeit geäußert haben.
6. Der Anwärterteilnehmer soll einen Wunsch für eine solche Tätigkeit betont haben.
7. Der Anwärterteilnehmer soll seine bevorzugte Rolle (Rollen) für eine solche Tätigkeit eingegeben haben.
8. Der Anwärterteilnehmer soll die notwendigen Qualifikationen für eine solche Rolle aufweisen können.
9. Der Anwärterteilnehmer soll die notwendigen zusätzlichen Qualifikationen, die der andere Benutzer von dem Anwärterteilnehmer verlangt, erfüllen.
10. Der Anwärterteilnehmer soll einwilligen, auf Anforderung einen Dialog mit dem anderen Benutzer zu initialisieren, nachdem ihm Informationen über den anderen Benutzer und den eine Begründung der Partnerschaftseignung bereitgestellt wurden.

Bekanntmachungssitzung

Dieser Prozeß beginnt, wenn ein Partnerschaftseignungstreffer für einen bestimmten Benutzer gefunden wird. Hierbei wird der Benutzer mit Informationen sowohl über den vermittelten Partnerschaftskandidaten als auch mit einer Begründung für den Partnerschaftseignungstreffer versorgt. Dem Benutzer werden folgenden Arten von Informationen gezeigt:

1. Günstige Attribute des vermittelten Partnerschaftskandidaten, die für den Benutzer von Interesse sind.
2. Ungünstige Attribute des vermittelten Partnerschaftskandidaten, die der Benutzer als störend empfinden könnte.
3. Attributen, nach denen der vermittelte Partnerschaftskandidat an einem Partnerschaftskandidaten gesucht hat.
4. Vertrauliche, bei Preisgabe Vorsicht verlangende Attribute, nach denen der vermittelte Partnerschaftskandidat an einem Partnerschaftskandidaten gesucht hat.
5. Eine Liste von empfehlenswerten und nicht empfehlenswerten Verhaltensmustern betreffend die gestellten Anforderungen, die zu respektierende Privatsphäre des Anderen, Verhaltensempfehlungen, Tätigkeitshemmungen, Tabus, Tätigkeitsvertiefungsbereitschaft, usw., wie von dem vermittelten Partnerschaftskandidaten bereitgestellt.
6. Ein Foto des vermittelten Partnerschaftskandidaten wird dem Benutzer ebenfalls bereitgestellt.

Kommunikationsverbindungsaufbau

Nachdem dem Benutzer die oben genannten Informationen gezeigt wurden, wird der Benutzer gefragt, ob eine Verbindung zu dem vermittelten Partnerschaftskandidaten hergestellt werden soll.

Die gleich Vorgehensweise wird bei dem vermittelten Partnerschaftskandidaten angewendet. Falls die beiden Teilnehmer dazu zustimmen, wird die Verbindung zwischen den beiden aufgebaut. Sobald dies geschehen ist, wird die Verbindung zum RPMMSU unterbrochen. Es gibt mehrere Punkte, über die man sich hier Gedanken machen sollte:

1. Die Partei, die den Verbindungsaufbau veranlaßt, ist für die Begleichung der Rechnung zuständig. Dies ist eine Frage der Rechnungsschreibung.
2. Die Partei, welche die Verbindung aufbaut, ist diejenige, die auch den Anruf zu einer anderen Verbindung transferieren kann. Dies ist eine Frage der Transfergenehmigungen.
3. Der Benutzer darf nicht die Kontaktierbarkeitsadresse des Anderen über diesen Dienst erfahren.

Dies kann auf verschiedene Weise geschehen:

1. Personal Mobile Communications and Computing Devices von beiden Benutzern sind zuständig für den Aufbau der Verbindungen zwischen ihnen auf der einer Seite und der Real Partner Match Making Server Unit auf der anderen Seite. Die RPMMSU verbindet dann die zwei Anrufe und entbindet sich selbst gleichzeitig von den Anrufen. Der Benutzer wird über eine Benachrichtigung aufgefordert, eine Verbindung zu der RPMMSU aufzubauen. Der Aufbau der Verbindung geschieht unabhängig und auf Befehl des Benutzers. Dies kann sich als etwas schwerfällig zu realisieren erweisen.
2. Die RPMMSU kann Anrufe zu den PMCCD der beiden Benutzer aufbauen, und sobald sie Verbindung zu beiden hat, die beiden Anrufe zusammenführen, so daß es eine direkte Verbindung zwischen den beiden gibt, und sich den von den Anrufen entbinden. Hier müßte vielleicht der Betreiber der RPMMSU die Rechnung übernehmen, was nicht wünschenswert wäre.
3. Die Benutzer könnten von einem Modul, welches auf dem PMCCD der Benutzer läuft und als ein Teil der Bekanntmachungssitzung anzusehen ist, eine Aufforderung erhalten. Wenn der Benutzer sein Einverständnis mitteilt, dann baut ein Modul zum Errichten eines synchronen Kommunikationskanals eine Verbindung zu der RPMMSU auf. Wenn beide Benutzer dies getan haben, verbindet die RPMMSU die beiden Anrufe und entbindet sich selbst. Dies könnte die praktischste Variante sein.

Dieser synchrone Kommunikationskanal kann verschiedenes bedeuten:

1. Einen Videokanal, durch den beide Benutzer einander sehen und einander hören können, wie z. B. Videofon.
2. Es könnte ein Audiokanal sein, wobei die Benutzer nur miteinander reden können, so wie eine ganz normale Telefonverbindung.
3. Es könnte ein Textaustausch sein, wobei jede Partei von der anderen Seite gesendeten Text empfängt. Beim Senden kann der Benutzer entweder den Text eintippen, oder er kann die Botschaft aussprechen und ein Modul in dem PMCCD übernimmt die Funktionalität der Spracherkennung und die Konvertierung von Sprache in Text, der anschließend gesendet wird. Es gibt jedoch noch weitere Möglichkeiten, um den Text einzugeben.

Dialog

Nachdem die beiden Parteien miteinander verbunden sind, müssen sie gewisse Maßnahmen treffen, um eine erfolgreiche Beendigung des Prozesses zu gewährleisten.

1. Nach der Verbindung sollte der Benutzer einen Dialog mit dem vermittelten Partnerschaftskandidaten einleiten.
2. Der Benutzer sollte einem Treffen mit dem vermittelten Partnerschaftskandidaten zustimmen, höchstwahrscheinlich an einem Ort auf dem Gelände des SPLEMPs, und zu einer Zeit sehr bald nach diesem Gespräch, womöglich sogar wenige Minuten danach, wobei beides, Ort und Zeit, gemeinsam vereinbart wird.
3. Der Benutzer sollte den vermittelten Partnerschaftskandidaten tatsächlich an dem vereinbarten Ort und zu der vereinbarten Zeit treffen. Die Abweichung von den Zeit- und Ortsparametern sollte möglichst gering gehalten werden.
4. Anschließend hält der Benutzer einen Dialog mit dem vermittelten Partnerschaftskandidaten, um festzustellen, ob dieser wirklich die Art von Person ist, wonach er gesucht hat, verschiedene erwünschte Attribute und deren tatsächlichen Ausprägungen betrachtend. Es soll auch festgestellt werden, ob die Chemie zwischen den beiden gut und die Gesellschaft des anderen angenehm ist. Am Ende wird eine Entscheidung getroffen, ob der vermittelte Partnerschaftskandidat wirklich der richtige ist, um die gewünschte Tätigkeit zu unternehmen. Eine Vereinbarung wird getroffen, um zu entscheiden, wann, wo und wie die beiden mit der Tätigkeit fortfahren sollen, oder daß sie einander erneut kontaktieren werden, um die organisatorischen Aspekte des Sachverhalts auszudiskutieren. Sie könnten auch entscheiden, daß sie einander besser kennenlernen müssen, um die Eignung des anderen für die gewünschte Tätigkeit festzustellen, und daß weitere Kommunikation erwünscht wird. In den meisten Fällen, abhängig von der Art der Tätigkeit, werden die beiden Kontaktierbarkeitsadressen austauschen.

Vermittelte-Partnerschaftskandidaten-Erinnerungsunterstützung

Wenn eine Partnerschaftseignungsbestätigung zwischen zwei Parteien erzielt wurde, die zwei Parteien eine Chance zum Besprechen gehabt haben und sich wieder voneinander verabschiedet haben, könnten die beiden Parteien wünschen, Informationen über die andere Partei und über das Treffen im allgemeinen zu speichern, so daß man eine Übersicht hat über die Leute, die man getroffen und kennengelernt hat. Es kann passieren, daß man nach einer gewissen Zeit früher vermittelte Partnerschaftskandidaten zu vergessen anfängt. Dies kann insbesondere geschehen, wenn man sehr viele solcher Fälle miterlebt hat, oder wenn das Gedächtnis des Benutzers nicht so optimal ist, oder wenn sehr viel Zeit seither vergangen ist, oder wenn an dem Treff oder an dem vermittelten Partnerschaftskandidaten nichts besonderes oder bemerkenswertes lag. Es ist wichtig, daß es eine Unterstützung gibt, um sich an die Leute zu erinnern, die man im Leben getroffen hat. Man kann das als ein auf die Partnerschaftseignungstreffer bezogenes Tage- und Kontaktbuch ansehen. Es gäbe verschiedene Arten von Informationen, die man in solch einem Tagebuch speichern würde:

1. Typ des Bekanntmachungsmittels: In diesem Fall, wäre das der Dienst, der durch dieses System ermöglicht wird.
2. Bekanntmachungsagent. Dies beinhaltet die Identität des Betreibers des Partnersuch-, Partnerschaftseignungsüberprüfungs- und Bekanntmachungsdienstes, der durch dieses System ermöglicht wird.
3. Bekanntschaftsschließungsereignis. Dies bezeichnet ein bestimmtes Ereignis, welches stattfand oder von einem SPLEMP organisiert wurde.
4. Bekanntschaftsschließungsort. Dies bezeichnet in diesem Fall die Identität des SPLEMPs.
5. Bekanntschaftsschließungszeit. Das bezeichnet ungefähr die Zeit, zu der man sich zum ersten mal mit dem vermittelten Partnerschaftskandidaten getroffen hat.
6. Alias des vermittelten Partnerschaftskandidaten. Dies ist der Name, der von dem vermittelten Partnerschaftskandidaten benutzt wurde, als er sich dem Benutzer vorgestellt hat. Es muß nicht unbedingt der echte Name des vermittelten Partnerschaftskandidaten sein.
7. Foto des vermittelten Partnerschaftskandidaten. Dessen Bereitstellung ist zum Teil von dem System abhängig, aber im Grunde genommen soll es nur mit der Zustimmung des vermittelten Partnerschaftskandidaten dem Benutzer bereitgestellt werden. Während der Bekanntmachungssitzung wurde eine Fotografie bereitgestellt. Dieses Foto könnte eigentlich auch hier benutzt werden. Die Frage ist, ob dieses Foto benutzt werden darf, da es hier möglich wäre, das Foto langfristig zu bewahren und dadurch die Anonymität des anderen verletzt werden könnte. Es ist inzwischen bekannt, daß, wenn man Zugang zu einer großen Datenbank mit persönlichen Daten hat, man die Identität des anderen dann unter Benutzung entsprechender Mustererkennungssysteme feststellen kann. Aufgrund dieser Überlegungen muß der Benutzer entscheiden, ob es klug ist, das Foto überhaupt für die Bekanntmachungssitzung preiszugeben, falls das langfristige Speichern des Fotos nicht verhindert werden kann. Das langfristige Speichern des Fotos kann von dem vermittelten Partnerschaftskandidaten abhängig gemacht werden, wenn es ein System gibt, welches das Speichern des Fotos von der Zustimmung des vermittelten Partnerschaftskandidaten abhängig macht. Ein mögliches System könnte veranlassen, daß das während der Bekanntmachungssitzung erhaltene Foto nur chiffriert gespeichert wird, obwohl es dechiffriert dargestellt wird, und nur mit Hilfe eines Schlüssels, den der vermittelte Partnerschaftskandidat übermittelt, auch in chiffrierter Form gespeichert werden kann. Die Darstellung des Fotos soll dadurch ermöglicht werden, daß das Foto mittels eines Schlüssels dechiffriert werden kann, der an einem Ort gespeichert wird, auf den der Benutzer keinen direkten Zugang hat. Darüber hinaus soll der Speicherort des Fotos nur dem System zugänglich sein, und nicht einmal der Besitzer des Systems soll es umgehen können. Darüber hinaus kann das chiffriertes Foto nach einer gewissen Zeit gelöscht werden, was abhängig sein kann von der Systemuhr und dem Betriebszustand des Gerätes (an- oder ausgeschaltet). Diese Unzugänglichkeit und explizite Genehmigung ist notwendig, nur falls der vermittelte Partnerschaftskandidat über die eigene Anonymität sehr besorgt ist, und kein Beweismaterial zurücklassen möchte, wodurch seine Identität durch den Benutzer festgestellt werden kann. Auch diese Maßnahmen der Anonymität sind vielleicht unnötig, da der andere diese sehr einfach umgehen kann, indem er einfach ein neues Foto von dem vermittelten Partnerschaftskandidaten macht, mit Hilfe einer digitalen oder sonstigen Kamera, was sogar in dem PMCCD integriert sein könnte. In diesem Fall wäre die ganze Mühe umsonst. Die beste Praxis ist, wenn dem Benutzer ein Zugang zu solch einer Datenbank über persönliche Daten der Menschen erschwert oder sogar verboten wird. Es kann auch hilfreich sein, für den Zweck der Erinnerung, daß ein aktuelles Foto des vermittelten Partnerschaftskandidaten gespeichert wird, so wie er zu diesem Zeitpunkt aussieht. Dafür kann die Verfügbarkeit eines digitalen Fotoapparates nützlich sein. Letztendlich kann es aber auch sein, das Angst vor Verlust der Anonymität dem Benutzer gar nichts ausmacht.
8. Beschreibung des vermittelten Partnerschaftskandidaten in eigenen Worten.
9. Umstände des Treffens in eigenen Worten.
10. Qualität des Erlebnisses in eigenen Worten.
11. Gegenseitige Entscheidung zum Ende des Treffens darüber, wie man vorgehen möchte bei der Erforschung der Möglichkeit, sich mit der zum Ziel gesetzten interaktiven Tätigkeit zu befassen.
12. Positive Attribute des vermittelten Partnerschaftskandidaten, welche zu einem Treffer verholfen haben und während der Bekanntmachungssitzung vorgestellt wurden.
13. Negative Attribute des vermittelten Partnerschaftskandidaten, die während der Bekanntmachungssitzung als Warnungen vorgelegt wurden.
14. Die Bestrebungen und Erwartungen des vermittelten Partnerschaftskandidaten an den anderen Partnerschaftskandidaten (in diesem Fall den Benutzer), wie sie in der Bekanntmachungssitzung vorgelegt wurden.
15. Eigene positive Attribute, die zu einem Treffer verholfen haben, und während der Bekanntmachungssitzung offenbart wurden.
16. Eigener Alias, der dem vermittelten Partnerschaftskandidaten vorgeführt wurde.
17. Kritik-Feedback, welche der RPMMSU bereitgestellt wurde.
18. Tagebucheinträge, die sich auf den gleichen vermittelten Partnerschaftskandidaten beziehen, und nach der Zeit des Eintrags angeordnet sind, wobei es sich um die Entwicklung der Beziehung und der Meinung über den anderen handelt.

Kritischer Feedback

Kritischer Feedback wird später vorgenommen. Falls das Treffen wirklich stattfindet, kann es trotzdem gemacht werden, um eine Meinung über den vermittelten Partnerschaftskandidaten zu übermitteln. Während der Bekanntmachungssitzung wurden viele Charakteristiken des vermittelten Partnerschaftskandidaten enthüllt.

Der Benutzer könnte Verdrehungen in dem Profil oder sogar volle Abweichungen oder Lügen beobachtet haben. Der Benutzer könnte darüber berichten wollen, um die eigene Unzufriedenheit und das Mißfallen an der Unehrlichkeit des vermittelten Partnerschaftskandidaten zu äußern.

Der Benutzer könnte auch über die Verhaltenabweichungen von den Regeln des Verhaltenskodex und von den Verhaltensanweisungen, wie von dem Betreiber des RPMMSU vorgeschrieben, berichten wollen. Dabei könnte es sich um verschiedenes handeln wie z. B. Benehmen, Pünktlichkeit, Erscheinen am Treffpunkt überhaupt, Halten an die Empfehlungen und Grenzen bezüglich des Eindringens in die Privatsphäre des Benutzers sowie Anfordern von Informationen oder Ressourcen von dem Benutzer, die dieser nicht bereitstellen wollte, entsprechend den Einstellungen im Benutzerprofil, die dem vermittelten Partnerschaftskandidaten während der Bekanntmachungssitzung bereitgestellt wurden. Dieses Feedback kann unterschiedlich in verschiedenen Formaten erhoben werden:

1. Freier Text und natürliche Sprache.
2. Freie Aussprache und natürliche Sprache.
3. Auswählen aus Listeneinträgen als Antwort auf Bemerkungen über verschiedene Aspekte, die selbst wiederum aus einem Menü ausgewählt werden.
4. Ein Dialog zwischen einem Kritischer-Feedback-Erhebungs-Subsystem und dem Benutzer, in diesem Fall liegt die Steuerung des Dialogs bei dem Subsystem. Der Benutzer wird aufgefordert, auf bestimmte Fragen Antworten einzugeben. Die Antwort kann aus einer Liste mit Einträgen ausgewählt werden, wobei die Liste auf dem Bildschirm sichtbar wird, oder die Einträge ausgesprochen werden. Die Antwort kann entweder frei eingegeben oder aus einer Liste von möglichen Antworten ausgewählt werden und aktiviert werden, indem man einen Bildschirmzeiger wie einen Touchscreenstift, Cursor oder Finger benutzt, oder durch Eingabe einer freien Textantwort durch einen Eingabemechanismus, oder sogar durch freie Sprache über eine Sprachschnittstelle.

Später wird dieses Feedback nach einer Bestätigung durch den Benutzer an die RPMMSU über das Kritischer-Feedback-Erhebungs-Subsystem gesendet.

Architekturentwurfsmodule

Hier werden alle drei wichtige Subsysteme in ihre jeweiligen Module aufgeteilt. Es werden verschiedene Module aufgeführt, die dazu beitragen, daß das System zu einem funktionstüchtigen System wird. Verschiedene folgende Aspekte der Module werden hier erklärt:

- die Funktionalität der Module,
- die Beziehung zu anderen Modulen,
- der Signalaustausch und die Kommunikation mit anderen Modulen sowohl innerhalb des gleichen als auch in andere Systeme,
- der Einsatzkontext innerhalb eines Prozesses,
- die Wahlfreiheit der Module,
- die Kategorisierung der Module
- usw.

Hier einige Anmerkungen zu dem System für die Benennungen. Die Namen der Module sind in englischer Sprache abgefaßt. Dies wird aus verschi 99999 00070 552 001000280000000200012000285919988800040 0002010040948 00004 99880edenen Gründen als günstig angesehen:

- Flexible Regeln für die Substantivierung
- Getrennte Namenteile und entsprechende bessere Sichtbarkeit der Semantik
- Leichteres Bilden von Akronymen aufgrund der geteilten Namensteile
- Bekannte Terminologie in der Ursprungssprache
- Leichte Übersetzungsfähigkeit

Anschließend wird aber der Name nochmals auf deutsch erklärt.

Real Partner Match Making Server Unit Informationsmanagementmodule

Managementmodule werden insbesondere gebraucht, um bestimmte Arten von Informationen in dem System zu managen. Über diese Managementmodule können Informationen erstellt, gelöscht, geändert, aktualisiert werden oder die Art der Informationen, die gemanagt werden, völlig geändert werden. Diese Managementmodule bieten eine einheitliche, ähnliche Schnittstelle, um in den gespeicherten Informationen einzusehen. Die meisten Managementmodule verwalten dauerhafte Informationen. Obwohl es durchaus denkbar ist, daß es Managementmodule geben kann, die auch die Laufzeit-Informationsstrukturen und ihren Informationsgehalt managen.

1. User Accounts Management Module: Dieses Modul ist zuständig für das Management von Benutzerkonten. Es koordiniert Erstellung, Aktualisierung, Löschung, Genehmigung, Laden, Speicherung, Sortierung, Versionierung, Übergabe, usw. von Benutzerkonten. Es managt Informationen, und ermöglicht auch den Zugang zu einer Menge anderer Managementmodule, die den Benutzer betreffen, wovon viele unten aufgelistet sind.
2. Serviced Public Leisure and Entertainment Meeting Place Accounts Management Module: Dieses Modul ist zuständig für das Management von Konten von SPLEMPs. Es koordiniert Erstellung, Aktualisierung, Löschen, Genehmigung, Laden, Speicherung, Sortierung, Versionierung, Übergabe, usw. von SPLEMP-Konten.
3. User Match History Management Module: Dieses Modul verfolgt die Geschichte der Partnerschaftseignungstreffer, die ein Benutzer gehabt hat. Es unterscheidet die Partnerschaftseignungstreffer zwischen dem Benutzer und dem vermittelten Partnerschaftskandidaten anhand dessen, ob das Trefferangebot von dem Benutzer, von dem vermittelten Partnerschaftskandidaten, oder von beiden abgelehnt wurde oder von beiden akzeptiert wurde. Weiterhin ist jeder Ablehnungseintrag mit der Begründung des Ablehnens vermerkt. Akzeptanz oder Ablehnung wird während der Bekanntmachungssitzung entschieden. Falls der Benutzer ein Partnerschaftseignungstrefferangebot ablehnt, und zwar nicht auf der Basis von während der Bekanntmachungssitzung vorgelegten Informationen, dann kann der Partnerschaftseignungstreffer dem Benutzer nochmals angeboten werden. Das Ziel des Moduls ist es, Managementdienste dem Match Processing Module anzubieten, so daß das Modul entscheiden kann, ob ein Partnerschaftskandidat für die Partnerschaftseignung mit dem Benutzer überprüft werden soll oder nicht. Falls ein vorheriger Partnerschaftseignungstreffer zwischen den beiden schon abgelehnt wurde, dann sollen die beide Leute nicht nochmals einander vermittelt werden, falls ein Alternative vorhanden ist. Auf der anderen Seite, falls zwischen den beiden schon ein Partnerschaftseignungstreffer erzielt wurde, was von den beiden auch noch akzeptiert wurde, dann könnte es hilfreich sein, beide darüber zu informieren. In diesem Fall sind die beiden mit ausreichenden Informationen zu versorgen, um an den jeweils anderen zu erinnern, und zu fragen, ob ein weiteres Treffen mit dem anderen noch erwünscht ist.
4. SPLEMP Sessions History Management Module: Dieses Modul verfolgt alle Sitzungen, die bei einem SPLEMP stattfanden. Dies kann für Zwecke der Rechnungsschreibung gebraucht werden, und in selteneren Fällen kann es für die Zurückverfolgung wichtig sein, falls irgendeine Sicherheits- oder Anweisungsverletzung geschehen ist.
5. User Servicing Sessions History Management Module: Dieses Modul verfolgt alle Sitzungen, die für einen Benutzer stattfanden. Dies kann für Zwecke der Rechnungsschreibung gebraucht werden, und in selteneren Fällen kann es für die Zurückverfolgung wichtig sein, falls irgendeine Sicherheits- oder Anweisungsverletzung geschehen ist. Es wird auch gebraucht, um zu berechnen, wieviel Bedienung der Benutzer letztlich bekommen hat. Darüber hinaus kann man die Benutzungsmuster des Benutzers bestimmen, um ihn mit einem verbesserten Dienst zu versorgen. Die verfügbaren Statistiken können auch verwendet werden, um die Priorität der Bedienung zu bestimmen, die der Benutzer beim nächsten mal bekommen soll, wenn er sich bei einem SPLEMP anmeldet.
6. User Home and Stay Locality Management Module: Dieses Modul hält sich darüber auf dem laufenden, wo der Benutzer gerade wohnt und für welchen globalen Ort der Benutzer gerade angemeldet ist. Üblicherweise werden diese Benutzerinformationen einer entsprechenden Systemkomponente zur Verwaltung Globaler Orte, welche SPLEMPs beherbergen, übergeben. Darüber hinaus werden weitere Benutzerinformationen gesammelt, die in das Benutzerprofil eingehen und dessen Mobilität und Weltperspektive vermerken. Weiterhin kann sich ein Benutzer an einem Ort als Besucher klassifizieren, und die Partnersuche kann dieses Kriterium auch mit einbeziehen.
7. Matched Candidate Partner Catalogue Management Module: Dies hilft dem Benutzer, sich die Liste der vermittelten Partnerschaftskandidaten anzusehen. Dies schließt alle Partnerschaftseignungstreffer ein. Der Benutzer hat keine Genehmigung, irgendwelche Einträge hier zu löschen.
8. Matched Candidate Partner Remembrance Information Management Module: Dieses Modul hilft dem Benutzer, sich seine bisherigen Partnerschaftseignungstreffer anzusehen. Dies dient zur Erinnerung und wirkt wie ein Tagebuch. Der Benutzer ist frei, hier Informationen hinzuzufügen, zu löschen, zu ändern, usw. Der Benutzer kann die Beziehung, die entstanden ist, oder die Kommunikation, welche mit dem vermittelten Partnerschaftskandidaten stattgefunden hat, beschreiben. Meistens wird über die Einträge hier von dem Benutzer entschieden.
9. Specific Comobility and Coactivity Intention Definition and Tracking Information Management Module: Dieses Modul managt Informationen über die. Benutzerbewegung, die Begleitung, die Absichten, die Vorschläge, die Angebote, usw. Diese Informationen werden von dem Benutzer zu dessen eigener Sicherheit bereitgestellt. Im Fall von Schaden oder Festnahme usw. könnten die Behörden den Benutzer ausfindig machen. Diese Information wird von dem Benutzer auch bereitgestellt, um die begleitende Person, die nicht vertrauenswürdig oder fremd ist, wissen zu lassen, daß sie nicht ungeschoren davonkäme, sollte sie dem Benutzer irgendwelchen Schaden zufügen. Die Information hier wird nicht weiter benötigt, sollte der Benutzer den Dienst nochmals zu benutzen angefangen haben. Die Informationen sollen nur für eine maximale Dauer von wenigen Wochen behalten werden, oder bis der Benutzer sich nochmals bei dem Dienst gemeldet hat und einige Wochen vergangen sind.
10. User Home Locality History Management Module: Dieses Modul managt Informationen über die vorherigen Orte, an denen der Benutzer gewohnt hat.
11. User Stay Locality History Management Module: Dieses Modul manage Informationen über alle Orte, an denen der Benutzer gewesen ist und den Dienst benutzt hat. Damit kann man dessen Aufenthaltsort ausfindig machen und eventuelle Missetaten zurückverfolgen.
12. Geographical Places and Positions Interrelationships Graphs based Information Management Module: Dieses Modul managt Informationen, wie man sie in einem Atlas findet. Dies hilft, die Benutzermobilität sowie auch die Beziehungen zwischen verschiedenen Mengen von globalen Orten und den globalen Orten selbst zu managen.
13. Locality related Demographic Information Capture and Management Module: Dieses Modul managt Informationen, welche die Demografik in verschiedenen Regionen betreffen. Weiterhin erfaßt es Informationen über Haßverbrechen in verschiedene Regionen, was dabei zu wissen hilft, welche Kategorien von Benutzern in welchen Regionen angreifbar sind und daher mehr Sicherheit und Vorsicht bei der Dienstbenutzung brauchen.
14. System Behaviour Complaints Information Management Module: Dieses Modul verwaltet alle Beschwerden, die von Benutzern oder SPLEMPs eingereicht wurden. Basierend auf diesen Informationen kann man versuchen, den Dienst zu verbessern, die Probleme oder Engpässe beim Dienstangebot herauszufinden, usw.
15. User Behaviour Complaint Information Management Module: Dieses Modul verwaltet Informationen, die von den SPLEMPs selbst über die Benutzer des Dienstes bereitgestellt wurden. Normalerweise sind diese in Form von Beschwerden. Anhand dieses Feedbacks kann man eine geeignete Strategie erdenken, wie der Benutzer in der Zukunft bedient werden soll. Normalerweise geht es hier um rohe Informationen.
16. User directed Critical Feedback History Management Module: Dieses Modul behandelt den gesamten Feedback, den ein Benutzer eingereicht hat, dazu gehören Kritik oder Lob an anderen Benutzern, den vermittelten Partnerschaftskandidaten. Dieses Feedback ist wichtig, um herausfinden zu können, ob die Benutzer den Dienst in einer verantwortungsbewußten Art und Weise, gemäß den Benutzeranweisungen, dem Verhaltenskodex folgend, benutzen, und in ihren Benutzerprofilen glaubwürdige Informationen geliefert haben. Hier wird die Information in ihrem rohen Zustand bewahrt.
17. User Security File Management Module: Diese Information wird normalerweise von Sicherheitsagenturen oder -behörden, die privat oder öffentlich sein können, erhoben. Das könnte das Strafregister eines Benutzers, oder sogar Angaben über sein öffentliches Verhalten einschließen. Dies wird benötigt, um Benutzer auszufiltern, denen man kriminelle Neigungen zutraut.
18. User Profile Attribute Credibility Tracking History Management Module: Dieses Modul managt Informationen über die vergangene Glaubwürdigkeits-Akte des Benutzers. Dies ist hilfreich, um herauszufinden, ob es in der Glaubwürdigkeit des Benutzers Änderungen gab.
19. User Behaviour towards Service Usage Tracking History Management Module: Dieses Modul verwaltet Informationen über die Dienstbenutzung. Dies beinhaltet Informationen darüber, ob der Benutzer sich nach einem Check-Out von einem SPLEMP eigenhändig abmeldet, wenn er nicht zurückzukehren vorhat, oder wie oft der Benutzer ein Partnerschaftseignungstrefferangebot, aus welchen Gründen auch immer, ablehnt, usw.
20. User Behaviour towards Matched Candidate Partner Tracking History Management Module: Dieses Modul ist mit dem Benutzerkonto assoziiert. Hier werden Informationen nach einer gebührenden Analyse des kritischen Feedbacks von Benutzern und von SPLEMPs, bewahrt.
21. System to User Messages Information Management Module: Dies beinhaltet ein Protokoll der Benachrichtigungen, die dem Benutzer vom System geschickt wurden.
22. User Profile History Management Module: Der Benutzer ändert sein Benutzerprofil von Zeit zu Zeit, durch Zufügen, Löschen, Ändern, oder Aufführen von weiteren Einzelheiten. Das Benutzerprofil ändert sich infolgedessen ständig. Um den Zweck der Zurückführung von Aspekten wie warum ein bestimmter Partnerschaftseignungstreffer gefunden wurde und wie der Benutzer sich im Laufe der Zeit verändert hat, und auch um die Glaubwürdigkeit des Benutzerprofils herauszufinden, ist es notwendig, Versionen von vergangenen Benutzerprofilen, oder die Unterschiede und Änderungen, und auch Informationen über die Gültigkeitsdauer von bestimmten Attributen und ihre Änderungen usw. zu speichern und zu managen. Dies wird von diesem Modul bewerkstelligt.
23. User Profile Change and Development Information Management Module: Dieses Modul managt im Grunde Informationen, die durch ein entsprechendes Informationsanalysenmodul, User Profile Change and Development Analysis Module genannt, generiert werden. Dies ist notwendig, weil das User Profile History Management Module Informationen managt, die zeitlich beschränkt sind. Es ist nicht sinnvoll, detaillierte Informationen länger zu bewahren, als deren Relevanz dies rechtfertigt. Einerseits sind diese Informationen eine Zusammenfassung der oben beschriebenen Benutzerprofilgeschichte. Weiterhin können vergangene Informationen noch Relevanz haben, wenn sie als analysierte Informationen gespeichert werden. Es ist kompakter und nützlicher.
24. User Profile Management Module: Dieses Modul managt die wichtigsten der Informationsblöcke. Über dieses Modul erhalten die meisten anderen Module ihre Informationen über den Benutzer. Es ist das am meisten benutzte Modul, und verwaltet Benutzerprofil, Interaktive-Tätigkeitsabsichten, gezielte Partnerschaftsanwärter- Profilschablonen, usw., was der Benutzer mit Hilfe des User Account and Personal Information Configuration Support Module konfiguriert hat. Es beinhaltet viele Metainformationen über das Profil, wie Aktualisierungszeiten, Geheimhaltungspolitik bei Attributen, Verweise zu Glaubwürdigkeitseinträgen in dem User Profile Attribute Credibility Tracking History Management Module, Attributsbezogene Informationen, usw.
25. Psychological and Social Systems based Profile History Management Module: Dieses Modul managt die psychologischen Profile, erstellt durch ein entsprechendes Modul, welches Psychological and Social Systems based Profile Evaluation Module genannt wird.
26. User Behaviour towards People in General Tracking History Management Module: Dieses Modul managt Informationen, erstellt durch mehrere Module, zum Beispiel das User Behaviour Complaint Submissions Processing Module, oder das Matched Candidate Partner Critical Feedback Processing Module. In beiden Modulen leitet eine andere Instanz, wie der Betreiber des SPLEMPs oder der vermittelten Partnerschaftskandidat, seine Meinungen an das System weiter, und das System bewahrt die Informationen, in das erforderliche Format überführt. Weiterhin werden auch die Informationen abstrahiert, die im User Behaviour towards Marched Candidate Partner Tracking History Management Module verfügbar sind. Hierbei handelt sich um das Verhalten des Benutzers im allgemeinen, was das Verhalten gegenüber einem bestimmten Partnerschaftskandidaten einschließt.
27. User Behaviour towards SPLEMPs Tracking History Management Module: Dieses Modul managt Informationen, welche durch das User Behaviour Complaint Submissions Processing Module erstellt wurden. Bei den durch dieses Modul verwalteten Informationen handelt es sich um das Verhalten des Benutzers in einem beliebigen SPLEMP. Es gibt zwei Arten, wie diese Information unterteilt werden kann, abhängig davon, ob sie ein bestimmtes SPLEMP angeht, oder ob sie auf SPLEMPs im allgemeinen verweist. Soweit es ein bestimmtes SPLEMP angeht, können diese Informationen sehr nützlich und sogar erforderlich sein. Manche SPLEMPs hätten schon mit Kunden Problemen gehabt, entweder aufgrund dessen Inanspruchnahme des Partnersuchdienstes oder unabhängig davon, und der SPLEMP Betreiber könnte wünschen, einem solchen unruhestiftenden Kunden die Benutzung des Dienstes bei diesem SPLEMP zu untersagen. Falls die Kundschaft bei einem SPLEMP sehr groß ist, ist es schwer, einen Überblick darüber zu behalten, wer kommt und wer geht, und falls der SPLEMP ein Verbot für einen Kunden durchsetzen möchte, dann sollte dies ohne viel Komplikationen und Mühe durchführbar sein. Im Falle, daß ein SPLEMP Betreiber das Ortsanmelde-Kennzeichen des Benutzers in Erfahrung bringen kann, wäre möglich, eine Beschwerde über das Benutzerverhalten bei der RPMMSU einzureichen, wobei um eine Untersagung des Dienstes für die jeweilige Sitzung gebeten wird. Der SPLEMP Betreiber kann auch verlangen, daß dem Benutzer überhaupt die Benutzung des Dienstes bei diesem SPLEMP untersagt werden soll. Auf diese Weise würde jeder daraufhin erfolgende Versuch von der Seite des Benutzers, an diesem SPLEMP den Dienst in Anspruch zu nehmen, Einschränkungen unterliegen, wobei dem Benutzer einige Funktionalitäten des Dienstes nicht mehr angeboten würden, die Qualität des Dienstes gesenkt oder der Benutzer sogar ganz verbannt würde. Mit Hilfe dieser Informationen können die Einschränkungen des Benutzers ausgeweitet werden, nicht nur bei dem jeweiligen SPLEMP, sondern bei beliebig vielen SPLEMPs, je nachdem, welch eine Art von Beschwerde es war. Dieses Modul managt Informationen, die durch alle Beschwerden entstanden sind. Die Einschränkungen selbst können wieder aufgehoben werden, wenn eine bestimmte Zeit vergangen ist, oder wenn andere wieder etwas Positives über den Benutzer zu melden hatten.
28. System Operations Quality Control and Maintenance Information Management Module: Hier werden Betriebsstörungen, Systemzusammenbrüche, Betriebsanomalien, Qualitätssenkung, usw. gemanagt werden können. Viele der Informationen würden von dem System selbst generiert werden, und viele als Beschwerden von den Benutzern und den SPLEMP-Betreibern eingereicht werden. Dieses Modul bekommt viele seiner Informationen von dem System Behaviour Complaint Submissions Processing Module. Das Managementsystem wird ein geeignetes System zur Verarbeitung von Beschwerden und Störungen beinhalten. Es stellt die richtige Schnittstelle, um Störungen zu behandeln, bereit. Weiterhin ist es dafür zuständig, die Problemauftritte und Problembehebungen zu verfolgen, die notwendigen Schritte einzuleiten, um mit einem Problem fertigzuwerden, zu entscheiden, ob eine Beschwerde gerechtfertigt und ernst genug, um ihr nachzugehen, ist oder nicht, ob es nur ein kurzfristiger Qualitätsrückfall wegen zu hohem Druck bei der Nutzung der Ressourcen ist, oder ob es ein ernsthafter Systemfehler sei, ob weitere Ressourcen in ähnlichen Situationen gebraucht werden oder nicht, usw. Dieses Modul kann auch benutzt werden, um dem Beschwerdeführer die Gründe für das Problem mitzuteilen. Dies kann vorgenommen werden, um den Benutzern gegenüber Verständnis und Empfänglichkeit für ihre Probleme zu zeigen. Es ist auch nützlich, um Statistiken über Häufigkeit und Gründe zu führen, um eine besser durchdachte Lösung für das Problem einzuführen und das weitere Potential des Wiederauftretens des Problems in Griff zu halten.
29. System Security Information Management Module: Dieses Modul bewahrt und managt alle Schlüssel und Zertifikate, die benötigt werden, um Sicherheitsdienste in dem System zu unterstützen. Dies schließt Privatschlüssel, öffentliche Schlüssel, Zertifikate, eigene Schlüssel, Fremdschlüssel, usw. ein.

Benutzerdialogmodule

In solchen Modulen wird ein Dialog zwischen zwei Parteien aufgebaut. Hier sind beide Seiten der Antwort der anderen Partei gegenüber sehr aufgeschlossen. Im Gegensatz zu den Konfigurationsmodulen sind die Fragen hier, die von einer Partei gestellt werden oder die Informationen, die hier angefragt werden, abhängig davon, was die andere Partei zuletzt geantwortet hat oder was während des gesamten Dialoges bis zu dieser Zeit alles besprochen wurde. Informationsanfragemodule haben den Zweck, die Anforderungen des Systems an Informationen zu erfüllen. In Dialogmodulen können beide Parteien einander Fragen stellen. Diese Module unterscheiden sich auch von Benachrichtigungsmodulen, dadurch daß mit der Hilfe dieser Module der Benutzer auch noch Anfragen stellt über Informationen, an welchen er ein gewisses Interesse hat, Bestätigungen mitteilt, und Anfragen von Benutzern bearbeitet werden, bevor geantwortet werden kann, und die Offenbarungsregelungen überprüft werden.

1. Introductory Session Management Support Module: Dieses Modul kümmert sich um den Dialog zwischen dem Benutzer und der RPMMSU. Es übernimmt die Aufgabe, dem Benutzer Informationen über den gerade erzielten Partnerschaftseignungstreffer zukommen zu lassen, über die Interessen des vermittelten Partnerschaftskandidaten, über die Gründe, warum der Partnerschaftseignungstreffer erzielt wurde, usw. Hier kann der Benutzer über die verschiedenen Aspekte, die vorher erwähnt wurden, nachfragen. Dieses Modul kommuniziert mit einem anderen Modul, das sich auf dem PMCCD des Benutzers befindet, dem lntroductory Session Support Module. Zusammen verwirklichen diese Module den Dialog. Der Betrieb besteht aus einem Austausch von Signalen. Die Signale werden über das Long Distance Wireless Signalling Connection to User's Personal Mobile Communications and Computing Device Management Module übertragen. Je nachdem, ob diese Anfragen von dem Benutzer akzeptiert oder den Benutzer nur benachrichtigt, könnte dieses Modul auch bei den Benutzerbenachrichtigungsmodulen eingestuft werden, falls es nur benachrichtigt.

Informationsanalyse-Module

Diese Module übernimmt vorher erhobene system-interne Informationen und wandelt diese in andere Informationen um, die für das System nützlich sind. Es geht durch eine große Menge an Informationen und liefert nur das Wesentliche davon zurück, und verwirft den Rest.

1. User Profile Change and Development Analysis Module: Das Benutzerprofil ändert sich im Laufe der Zeit. Manchmal kann es sich als wichtig erweisen, aufzuspüren, warum ein Partnerschaftseignungstreffer erzielt wurde, wie oft der Benutzer sein Profil ändert, ob der Benutzer etwas ändert, was nicht als flüchtige Information betrachtet wird, ob der Benutzer bei der Änderung bestimmter Attributen das Motiv verfolgt, bei einer bestimmten Gruppe von Leuten eine Partnerschaftseignung zu erzielen, ob die Änderungen realistisch sind, etc. Die nachfolgenden Informationen werden an das User Profile Change and Development Information Management Module zur Speicherung und Verwaltung übergeben. Dieses Modul erhält die zu bearbeitenden Informationen von dem User Profile History Management Module.
2. Matched Candidate Partner Critical Feedback Processing Module: Dieses Modul behandelt den kritischen Feedback, welcher von den Benutzern ankommt und der bestimmte akzeptierte vermittelte Partnerschaftskandidaten angeht. Die Speicherung von rohen Informationen wie oben erwähnt wird von dem User directed Critical Feedback History Management Module gemanagt. Es verarbeitet die Inhalte so, daß die nachfolgenden Informationen dem User Behaviour towards Matched Candidate Partner Tracking History Management Module des jeweils kritisierten Benutzers, übergeben werden können. Es gibt zusätzliche Informationen, die ein Benutzer in der Kritik bereitstellt, die auf Abweichungen der Realität, wie der Benutzer sie sieht, von den Benutzerprofilattributen des vermittelten Partnerschaftskandidaten, welche das System dem Benutzer zu Glauben gegeben hat, verweist. Dies formt die Grundlagen der Informationen, die dem User Profile Attribute Credibility Tracking History Management Module übergeben werden. Die Glaubwürdigkeit ist auch von anderen Informationsquellen abhängig. Informationen verfügbar durch das User Profile Change and Development Information Management Module werden auch benutzt, um die Glaubwürdigkeit des Benutzers zu bewerten.
3. Psychological and Social Systems based Profile Evaluation Module: Dieses Modul analysiert mehrere Informationsquellen wie das User Profile Management Module, User Profile Change and Development Information Management Module, User Profile Attribute Credibility Tracking History Management Module, Locality related Demographic Information Capture and Management Module, User Stay Locality History Management Module, User Home Locality History Management Module und das Psychological and Social Systems based Profile History Management Module auf früher erstellte, auf psychologischen und sozialen Systemen basierte Profile. Es erzeugt eine alles umfassende Übersicht über die psychologischen und sozialen Eigenschaften des Benutzers. Das Produkt dieser Bewertung wird an das Psychological and Social Systems based Profile History Management Module zum Management übergeben.
4. User Behaviour Complaint Submissions Processing Module: Dieser arbeitet mit Informationen, die von dem User Behaviour Complaint Submissions Reception Module bereitgestellt werden. Dies beschäftigt sich mit Beschwerden, die bei dem SPLEMP entsteht und zu dem System eingereicht werden. Es kann sich dabei um Fehlverhalten von der Seite des Benutzers auf der Gelände eines SPLEMPs handeln. Dieses Fehlverhalten kann gegen Personal oder Eigentum eines SPLEMPs oder gegen einen SPLEMP-Besucher gerichtet sein, oder es kann unzivilisiertes Benehmen im allgemeinen sein. Die Verarbeitung erfordert üblicherweise, daß man Beschwerdenvorlagen entgegennimmt, die Informationen umwandelt, mit dem jeweiligen Benutzer assoziiert und in die jeweiligen Informationsstrukturen integriert, die von der Bedienung des Benutzers an einem SPLEMP bzw. an alle SPLEMPs handeln, und welche die Vermittlung des Benutzers an einen Partnerschaftskandidaten beeinflussen.
5. System Behaviour Complaint Submissions Processing Module: Dieses Modul verarbeitet alle Beschwerdenvorlagen, die mit dem System, das heißt mit der RPMMSU, zu tun haben. Diese Beschwerden könnten entweder von einem Benutzer oder von einem SPLEMP stammen. Die Beschwerde kann gegen verschiedene Aspekte des Dienstes gerichtet sein. Es kann sich um eine Verschlechterung der Qualität des Dienstes, oder die Nichtverfügbarkeit des Dienstes handeln. Es wird sehr viel Parameter geben, von welchen der Benutzer oder der SPLEMP-Betreiber auswählen würde, um das Problem zu beschreiben. Das Modul bereitet Verwaltungsberichte für die zuständigen passenden Arbeitsgruppe vor. Die Ergebnisse der Verarbeitung werden an das System Operations Quality Control and Maintenance Information Management Module übergeben.
6. Astrological Systems based Astrological Profile Evaluation Module: Es existieren verschiedene Systeme der Astrologie je nach Ursprung, Evolution, usw. Diese Systeme der Astrologie benutzen bestimmte Regeln und Algorithmen, welche auf bestimmten Informationselementen des Benutzerprofils arbeiten und ein astrologisches Profil des Benutzers erstellen. Diese Astrologieprofile bieten eine Vorhersage über das Leben des Menschen, dessen Möglichkeiten und dessen Charakter, über bestimmte Zeitperioden, je nach der Konstellation der Sterne und Planeten. Sie behaupten auch zu wissen, welcher Lebensstil, Aktionen, Tätigkeiten, Bekanntschaftsarten oder Gegenstände für eine Person empfehlenswert wären. Dem Benutzer wird solch ein Astrologieprofil zugewiesen, welches dann benutzt werden kann, um das augenblickliche Horoskop zu berechnen.
7. Palmistry Systems based Palmistrical Profile Evaluation Module: Dies ist sehr ähnlich zu dem oben genannten Fall, außer daß die Berechnung des Chiromantieprofils des Benutzers auf Gestalt, Form, Festigkeit, und vor allem auf den Linien der Handfläche und der Fingerabdrücke, oder allgemeiner gesagt, auf der Hand des Benutzers basiert. Dafür wird der Benutzer eine Abtastung der Hand, Fingerabdrücke, eine Beschreibung der Festigkeit, usw. vorlegen. Der Benutzer kann auch zu einem professionellen Handleser gehen, der die Hand beschreibt und diese Beschreibung in einem bestimmten Dateiformat der RPMMSU übergibt. Der Zweck dieses Moduls besteht darin, die Informationen, die durch Beschreibungen und Abtastungen gesammelt werden, in ein benutzbares Format umzuwandeln. Informationen über die Dimensionen der Hand können auch ein Teil der Informationen sein, die dem Modul bereitgestellt werden.
8. User's Current Service Usage Privilege Defining Points Computing Module: Dieses Modul ist zuständig für das Berechnen von Bedienungsprivilegien, die ein Benutzer in Anbetracht seines Benutzerkonto haben sollte. Verschiedenen quantitativen Informationselementen werden Punkte zugewiesen. Die Punkte können benutzt werden, um die Bedienungsprivilegien zu berechnen. Ein gewichteter Durchschnitt kann schon als Anfangspunktanzahl im Voraus gefunden werden, oder der gewichtete Durchschnitt könnte erst dann berechnet werden, wenn einige andere Faktoren aus anderen Quellen, darunter Betriebszeit- oder Laufzeitfaktoren, die mit einbezogen werden müssen, verfügbar sind. Dieses Modul erhält seine Eingabe von verschiedenen Managementmodulen wie User Behaviour towards People in General Tracking History Management Module, User Behaviour towards SPLEMPs Tracking History Management Module, User Behaviour towards Service Usage Tracking History Management Module, User Profile Attribute Credibility Tracking History Management Module, User Servicing Sessions History Management Module, User Match History Management Module und User Accounts Management Module. Aus dem zuletzt erwähnten Modul läßt sich die Bedienungsqualitätsklasse, für die sich der Benutzer entschieden hat, erfahren. Dieses Modul wird dabei behilflich sein, die Punkteanzahl von verschiedenen Quantitätsinformationselementen zu berechnen. Dieses Modul wird von dem User Servicing Module aufgerufen werden.
9. User Security Check File Processing Module: Dieses Modul nutzt Informationen aus dem entsprechenden User Security File Management Module, ebenso wie aus dem User Behaviour towards People in General Tracking History Management Module und dem User Behaviour towards SPLEMPs Tracking History Management Module. Es bewertet die Informationen in diesen Modulen und schreibt die analysierten Informationen in das User Security File Management Module zurück.
10. SPLEMP related User Profile Attributes Sensitivity Determination Module: Es gibt verschiedene SPLEMPs in der Nachbarschaft oder Stadt. Jeder SPLEMP hat eine andere Kundschaft. Die Kundschaft eines bestimmten SPLEMPs könnte einer bestimmte Kategorie von Benutzern aus Gründen der Ethnizität, Religion, politischen Meinungen, Geschlecht, sexuellen Orientierung, Verbandsmitgliedschaft, usw. nicht so wohlgesinnt sein. Sollte ein Benutzer solche Eigenschaften haben, was aus ihm einen unwillkommenen Besucher bei diesem SPLEMP macht, wäre es nicht so klug, jedem an diesem Ort beliebigen Zugang zu diesen Eigenschaften des Besuchers zu ermöglichen. Diese Attribute sind als sensitiv für den bestimmten SPLEMP zu verstehen. Im Regelfall sollten diese Attribute in diesem SPLEMP nicht für Partnerschaftseignungsüberprüfungen benutzt werden. Der Benutzer soll über diese kontextuelle Empfindlichkeit benachrichtigt werden und gefragt werden, ob er vor hat, diese Einstellung aufzuheben. Dieses Modul hilft dabei festzustellen, welche Attribute in einem Benutzerprofil bei einem SPLEMP als empfindlich erklärt werden sollen. Ein SPLEMP wird in dem SPLEMPs Account Managemenr Module als eine Vorsichtsregelung benötigend beschrieben. Die Eingabe für dieses Modul stammt vom Feedback von verschiedenen Benutzern, die meinten, daß eine solche Regelung nötig wäre. Ein SPLEMP könnte selbst den Wunsch haben, irgendwelche unglücklichen Vorfälle zu vermeiden und solch eine Vorsichtsregelung angewendet zu bekommen.
11. Locality related User Profile Attributes Sensitivity Determination Module: Dieses Modul ist dem oben genannten Modul sehr ähnlich. Der Unterschied liegt darin, daß statt auf einen bestimmten SPLEMP, die Vorsichtsregelung auf den gesamten Ortsbereich erweitert wird. Die Dateneingabe kommt aus verschiedenen demographischen Studien, Benutzerfeedback, Vorfallsberichten, usw. Die Empfindlichkeitsattributsinformation aus diesen Auswertungen wird normalerweise an das Locality related Demographic Information Capture and Management Module zu Managementzwecken übergeben.
12. Resource Allocation Evaluation Module: Dieses Modul ist zuständig für die Bewertung der Frage, wie viele Ressourcen gebraucht werden, um den Dienst einem SPLEMP, oder einer Gruppe von SPLEMPs, oder einer ganzen Örtlichkeit hinsichtlich der Rechnerkapazität, Netzwerkbandbreite, Arbeitskräfte, Strom, dauerhaften Speicher, Hauptspeicher, usw. für eine Bedienungssitzung, einen ganzen Tag, oder eine andere Zeitperiode, bereitzustellen. Die Informationseingabe wird normalerweise von Statistiken aus dem SPLEMP Sessions History Management Module und dem SPLEMP Accounts Management Module abgeleitet. Das SPLEMP Accounts Management Module beinhaltet einen Sitzungskalender für den SPLEMP. Dieser Sitzungskalender beinhaltet auch Angaben darüber, wie viele Leute zu kommen erwartet werden.

Systeminformationserfassungsmodule

Diese Module sind konzipiert, um dem System zu ermöglichen, Informationen über bestimmte Ressourcen zu erfassen und zu sammeln, wobei die Quelle nicht eine der Hauptparteien in der verteilten Architektur ist, sondern eine systemexterne Instanz sei, entweder eine dritte Partei oder Person, oder ein automatisch wahrnehmungsfähiges System, oder vorher gesammelte Informationen, wenn auch in nicht direkten benutzbarem Format.

1. User Location Tracking Module: Dieses Modul läßt die RPMMSU wissen, wann es einen Benutzer bedienen soll und wann nicht. Dieses Modul ist im Kontakt mit einem entsprechenden Modul bei der SPLEMP LSU, welches User Location Registration Module heißt und Informationen darüber sendet, ob der Benutzer angemeldet, aktiviert, deaktiviert, verfügbar, nicht verfügbar, eingecheckt, ausgecheckt oder abgemeldet ist. Diese Information wird zu dem User Location Status and Serviceability Tracking Module weitergeleitet.
2. Locality related Demographic Information Capture and Management Module: Diese Informationen sind notwendig, falls man die Vorsichtsregelung anwenden möchte. Es gibt noch einen anderen Grund, aus dem man demographische Informationen über eine geographische Region besitzen sollte. Manchmal kann man besonders intensiv versuchen, an Informationen über Leute in einem bestimmten Gebiet heranzukommen. Falls man mit den Leuten aus einem bestimmten Gebiet schon vertraut ist, kann man durch Benutzung einer Partnerschaftskandidat-Profilschablone mit einer gewissen Spezifikation von Attributen, die private Informationen von bestimmten Leuten, die in einer Nachbarschaft wohnen, herausfinden. Man probiert eine Kombination von Attributen aus, und läßt sich vom Dienst bedienen. Wenn der Dienst sich mit einem bestimmten Partnerschaftseignungstreffer zurückmeldet, dann bekommt man bestätigt, daß die jeweilige Person die angegebenen Eigenschaften besitzt. In diesem Fall würde es nützlich sein zu wissen, ob es sehr viele Leute gibt, die auf ein bestimmtes Attributsmuster ansprechen oder nicht. Falls es sehr viele Leute gibt, dann schadet es nicht allzu viel, falls jemand das herausfindet. Auf der anderen Seite, falls es nur eine einzelne Person gibt, und die Attributsmuster ein etwas empfindliches Muster war, dann könnte dies rein theoretisch das Leben für ihn sehr schwer machen. Weiterhin braucht man Informationen über den Toleranzspiegel des Ortes. Falls man herausfindet, daß wegen einer solchen Partnerschaftsvermittlung jemand zu Schaden gekommen ist, dann sollte man dieser Region für dieses Attributsmuster eine starke Vorsichtsregelung einrichten.
3. User Registration requiring Third-Party Authentication Coordination Module: Dieses ist das Modul, das Informationen von einer Authentifizierungsbehörde einen bestimmten Benutzer betreffend, zum Zwecken der Authentifizierung erfaßt. Dieses Modul darf sich direkt an das Authentication Server Module, was vor Ort bei der Authentifizierungsbehörde befindet, anschließen. Dieses Modul bildet außerdem den Rückhalt eines anderen Moduls des Authentication Authority Agencies User Authentication Confirmation Feed Human-Machine Interface Support Module.
4. SPLEMP Registration requiring Third-Party Authentication Coordination Module: Dies ist sehr ähnlich zu dem oberen Modul, wobei der Unterschied vielleicht darin liegt, daß dieses Modul dazu dient, den Zweck der SPLEMPs zu authentifizieren.
5. Geographical Places and Positions Interrelationships Graphs based Information Format Conversion Modules: Es besteht ein Bedarf, Beziehungen zwischen verschiedenen geographischen Gebieten, wie Beinhaltung, Beinhaltungsausmaß, Beinhaltungstyp, Beinhaltungshierarchie, Nähe, Näheausmaß, politische Grenzen, natürliche Hindernisse, usw. zu berechnen. Solche Informationen sind meistens in verschiedenen vorhandenen geographischen Informationssystemen und digitalen kartographischen Systemen bereits verfügbar. Die Strukturen, die zur Darstellung dieser geographischen Objekte und ihrer Beziehungen benutzt werden, könnten von den schon Vorhandenen abweichen, und deswegen ist Konvertierung von vorhandenen in Systemstrukturen notwendig. Dieses Modul kümmert sich darum. Die Konvertierungen werden von mehreren unterschiedlichen schon vorhandenen Formaten gemacht werden müssen. Dieses Modul ist dafür zuständig, das System durch Zugriff auf vorhandene Informationsquellen mit den erforderlichen Informationen zu versorgen.
6. User Security Check required Security Authority Check-Up Request Module: An dieses Modul richtet das User Security Check File Managemenr Module eine Anfrage nach Informationen über einen bestimmten Benutzer. Dieses Modul stellt einerseits im Auftrag des Managementmoduls eine Verbindung zu der Servereinheit auf dem Gelände einer entsprechenden Sicherheitsagentur her, von der es unter Benutzung passender Zugangsrechte sicherheitsbezogene Informationen zu dem erwünschten Benutzer abrufen kann.

Benutzeranfragemodule

Diese Module ermöglichen es dem System, etwas bestimmtes zu dem bestimmten Zeitpunkt, an dem es für das System wichtig wird, diese Information zu besitzen, abzufragen. Die Fragen werden den anderen Parteien gestellt und sie werden zu deren Beantwortung aufgefordert. Diese Module sind auch dafür zuständig, die Antworten, die von der anderen Partei bereitgestellt wurde, entgegenzunehmen.

1. Matched Candidate Partner Contact Willingness Confirmation Support Module: Dieses Anfragemodul kooperiert mit einem anderen, ihm gegenüberstehenden Modul, das in dem PMCCD des Benutzers vorhanden ist, dem Matched Candidate Partner Offer Response Module. Gemeinsam unterbreiten sie dem Benutzer eine Anfrage bezüglich der Kontaktbereitschaft gegenüber einem vermittelten Partnerschaftskandidaten. Dieses Modul übergibt die Antwortinformationen an das Match Processing Module, in dessen Auftrag das Modul arbeitet.
2. Location Deregistration Intent Confirmation Support Module: Wann auch immer ein Benutzer das Gelände eines SPLEMPs verläßt, kann es sehr nützlich sein zu wissen, ob der Benutzer zu diesem Zeitpunkt die Örtlichkeit endgültig verläßt, oder ob der Benutzer vorhat, sofort wieder zurückzukehren. Falls der Benutzer den SPLEMP endgültig verläßt, dann könnte das System den Benutzer abmelden. Diese Information könnte dabei helfen, den Verbrauch von Ressourcen zu minimieren. Dieses Modul funktioniert mit einem gegenüberliegenden Modul zusammen, welches sich in dem PMCCD befindet, dem Location Deregistration Confirmation Module. Zusammen holen sie von dem Benutzer eine Bestätigung ein bezüglich dessen Absicht, das Gelände des SPLEMPs endgültig für die laufende Sitzung zu verlassen. Dieses Modul übergibt die Antwortinformationen an das User Location Status and Serviceability Tracking Module, in dessen Auftrag das Modul funktioniert.

Benutzerbenachrichtigungsmodule

Diese Module ermöglichen es dem System, Botschaften oder Benachrichtigungen an andere Parteien zu schicken, um sie über etwas zu informieren.

1. System to SPLEMP Messaging Support Module: Das System könnte dieses Modul benutzen, um an den SPLEMP-Betreiber eine Nachricht bezüglich irgendeines Besorgnis oder Interesse erweckendes Thema zu schicken. Es kann eine Mahnung, eine Warnung, ein neues Angebot, eine Einladung, eine wissenswerte Information, eine Bestätigung, eine Aufklärung, eine Begründung, eine Rechtfertigung, eine Entschuldigung oder etwas anderes sein.
2. System to User Messaging Support Module: Das System könnte dieses Modul benutzen, um an den Benutzer eine Nachricht bezüglich irgendeines Besorgnis oder Interesse erweckendes Thema zu schicken. Es kann eine Mahnung, eine Warnung, ein neues Angebot, eine Einladung, eine wissenswerte Information, eine Bestätigung, eine Aufklärung, eine Begründung, eine Rechtfertigung, eine Entschuldigung, oder etwas anderes sein.

Konfigurationsmodule

Diese Module bilden die Strukturen, in denen ein Benutzer seine Bedürfnisse auszudrücken versuchen würde. Diese Anforderungen werden in diesen Strukturen gesammelt und zur Speicherung und Verarbeitung geschickt. Diesem Ausdruck des Bedarfs folgt eine gewisse Reihenfolge oder Menge, welche akzeptiert werden kann.

1. User Account and Personal Information Configuration Support Module: Der Benutzer wird dieses Modul benutzen, um sein Benutzerprofil, Interaktive-Tätigkeitsabsichten, Geheimhaltungseinstellungen, Bedienungspreisklasse, Identitätsinformation, Kontaktinformation, Information zu Heimat- und Aufenthaltsort, usw. zu konfigurieren. Anschließend werden diese Informationen weiter dem User Account Management Module übergeben. Dieses Modul bildet den Rückhalt des User Registration and Persistent Configuration Human-Machine Interface Support Module.
2. User Home and Stay Information Configuration Support Module: Das ist ein zusätzliches Modul, um den Benutzer bei der Eingabe zu unterstützen, in welcher Örtlichkeit er sich zur Zeit aufhält oder wo er in der nahen Zukunft sich aufzuhalten vorhat. Dieser Aufenthaltsort unterscheidet sich von der Örtlichkeit, die er als Heimat ansieht. Auch dieser Heimatort kann auch über dieses Modul spezifiziert werden. Dies ist allerdings etwas, das nicht so oft geschehen soll oder wird. Auf dieses Modul kann eventuell auch von dem PMCCD des Benutzers zugegriffen werden. Die Informationen, die hier erhoben werden, werden dem User Home and Stay Locality Management Module übergeben.
3. Location Registration Configuration Support Module: Dieses Modul benutzend kann der Benutzer angeben, für welchen SPLEMP er sich anzumelden beabsichtigt. Der Benutzer kann auf dieses Modul über das gegenüberstehende Location Registrarion Module auf dem PMCCD des Benutzers, zugreifen. Die Informationen, die so erfaßt werden, werden an das User Servicing Module übergeben.
4. Service Activation Configuration Support Module: Dieses Modul benutzend kann der Benutzer den Partnerschaftseignungssuchdienst aktivieren. Der Benutzer kann auf dieses Modul über das gegenüberstehende Service Activation Module auf dem PMCCD des Benutzers zugreifen. Die Informationen, die so erfaßt werden, werden an das User Servicing Module übergeben.
5. User Servicing Settings Configuration Support Module: Dieses Modul benutzend kann der Benutzer die Bedienungseinstellungen, die der Benutzer für Bedienungssitzungen braucht, konfigurieren. Der Benutzer kann auf dieses Modul über das gegenüberstehende User Servicing Settings Module auf dem PMCCD des Benutzers zugreifen. Die Informationen, die so erfaßt werden, werden an das User Servicing Settings Processing Module übergeben.
6. Interactive Activity Intentions Configuration Support Module: Dieses Modul benutzend kann der Benutzer die Interaktive-Tätigkeitsabsichten, die der Benutzer für Bedienungssitzungen benötigt, definieren. Der Benutzer kann auf dieses Modul über das gegenüberstehende Interactive Activity Intentions Definition Module auf dem PMCCD des Benutzers zugreifen. Die Informationen, die so erfaßt werden, werden an das Interactive Activity Intentions Definition Processing Module übergeben.
7. Matched Candidate Partner Remembrance Information Configuration Module: Dieses Modul muß sich hier nicht notwendigerweise befinden. Die Informationen, die damit erfaßt werden, werden von dem User Servicing Module nicht gebraucht. Diese können aber später geliefert werden. In diesem Fall wäre das Matched Candidate Partner Remembrance Information Management Module dasjenige, an das die Informationen übergeben werden. Falls das PMCCD des Benutzers eine eingeschränkte Kapazität hat, kann dieses Modul für die Konfiguration benutzt werden. Dieses Modul kann auch als dasjenige verstanden werden, welches für den Empfang von Informationen zur Erinnerung an die vermittelten Partnerschaftskandidaten zuständig ist, die an das Matched Candidate Partner Remembrance Information Management Module weitergeleitet werden.
8. SPLEMP Account Information Configuration Support Module: Dieses Modul benutzend wird der SPLEMP Betreiber sein Konto konfigurieren. Das schließt ein, daß der Benutzer Informationen wie Identitätsangaben, Kontaktierbarkeitsadressen, Bankkonteninformationen, Bedienungsinformationen, allgemeine bedienungszeitbezogene Regeln, usw. eingibt. Dieses Modul bildet den Rückhalt des SPLEMP Registration and Persistent Configuration Human-Machine Interface Support Module. Die Informationen, die so erhalten werden, werden an das Serviced Public Leisure and Entertainment Meeting Place Accounts Management Module übergeben.
9. SPLEMP Sessions and Events Information Configuration Support Module: Dieses Modul Benutzend gibt der SPLEMP-Betreiber Informationen zu bestimmten Sitzungen und Begebnissen, die bei dem SPLEMP stattfinden werden, ein. Zugriff auf dieses Modul wird auch über das SPLEMP Registration and Persistent Configuration Human-Machine Interface Support Module in der LSU des SPLEMPs erreicht. Die Informationen werden an das Serviced Public Leisure and Entertainment Meeting Place Accounts Management Module übergeben.
10. SPLEMP Servicing Settings Configuration Support Module: Durch dieses Modul kann der SPLEMP-Betreiber angeben, welche Bedienungseinstellungen vorzunehmen sind. Die Einstellungen können sich darauf beziehen, wie viele Partnerschaftseignungstreffer jedem Benutzer maximal zustehen, welche Bedienungspreisklassen die dienstbenutzenden Kunden in Anspruch nehmen dürfen, wie viele Benutzer höchstens bedient werden dürfen, wie lange ein Benutzer längstens bedient werden darf, usw. Dadurch kann die LSU Betreuungsangestellten auch noch die Öffnungszeiten angeben. Dieses Modul arbeitet mit dem Service Quality Settings Module bei der LSU zusammen. Dieses Modul benutzend, kann der Benutzer die Bedienungseinstellungen, die er für Bedienungssitzungen braucht, konfigurieren. Der Benutzer kann auf dieses Modul über das gegenüberstehende User Servicing Settings Module auf dem PMCCD des Benutzers zugreifen. Die Informationen, die so erfaßt werden, werden an das User Servicing Settings Processing Module übergeben.

Informationseingabemodule

Unter Benutzung dieser Module kann eine Partei eine ihrer Meinungen einer anderen Partei zukommen lassen. Da die Meinungsäußerung selbst nicht verbindlich ist, sind diese Module auch nicht kritisch, im Sinne von notwendig. Normalerweise fungieren diese Module als das erster Speicherplatz, an dem die Informationen, nachdem sie die Zielpartei erreicht haben, gesammelt werden. Obwohl man sich vorstellen würde, daß diese Module freien und natürlichen Text zur Transmission gestatten würden, ist es jedoch möglich, nur bestimmte Informationsarten zu den Empfängerparteien zu senden. Das macht die Verarbeitung von Informationen sehr viel leichter. Diese Module unterscheiden sich dadurch von den Konfigurationsmodulen, daß die Informationen nur das System bestimmt sind, und nicht mit einer personifizierten Bedienung des Benutzers zu tun haben. Auch wenn eine beliebige Bedienung dadurch beeinflußt wird, wird das System diese nicht direkt beeinflussen, sondern es würde eine andere Partei damit beauftragen, oder den eigenen allgemeinen Betrieb entsprechend ändern, wodurch nicht nur der eine Benutzer, sondern alle relevanten Benutzer, einen geänderten Dienst bereitgestellt bekommen werden.

1. Matched Candidate Partner Critical Feedback Reception Module: Immer wenn der Benutzer dem Matched Candidate Partner Critical Feedback Module auf Seinem PMCCD benutzt, um kritischen Feedback über irgendeinen vermittelten Partnerschaftskandidaten einzugeben, kommen die Informationen auf den Weg zum System als erster Haltestelle hier an, bevor sie weiter an das Matched Candidate Partner Critical Feedback Processing Module und an das User directed Critical Feedback History Management Module weitergegeben werden.
2. System Behaviour Complaint Submissions Reception Module: Immer wenn der Benutzer oder der SPLEMP-Betreiber sein PMCCD bzw. LSU benutzt, um eine Beschwerde über das Funktionieren des Systems einzureichen, kommen die eingegebene Informationen auf dem Weg zu dem System zuerst als erster Haltestelle hier an, bevor sie weiter an das System Behaviour Complaint Submissions Processing Module und an das System Behaviour Complaints Information Management Module weitergegeben werden.
3. User Behaviour Complaint Submissions Reception Module: Immer wenn der SPLEMP-Betreiber das User Behaviour Complaint Submission Module der LSU benutzt, um eine Beschwerde über das Verhalten des Benutzers einzureichen, kommen die eingegebenen Informationen auf dem Weg zu dem System zuerst als der erster Haltestelle hier an, bevor sie später weiter an das User Behaviour Complaint Submissions Processing Module und an das User Behaviour Complaint Information Management Module weitergegeben werden.
4. Specific Comobility and Coactivity Intention Definition and Tracking Security information Reception Module: Der Benutzer könnte in seltenen Fällen diesen Aspekt des Dienstes benutzen wollen. Der Benutzer startet einfach diese Verfolgungssitzung, und gibt kontinuierlich Angaben zu seiner Begleitung, Absichten, augenblicklichem Verbleib, usw. ein. Die ganzen Informationen kommen zuerst hier in diesem Modul an, bevor sie verarbeitet und in dem Specific Comobility and Coactivity Intention Definition and Tracking Information Management Module gespeichert werden.
5. Emergency Call Reception Module: Immer wenn der Benutzer einen Notruf verschickt, was sowohl asynchron oder synchron sein kann, kommt dieser hier an und wird weiter an das Emergency Call Security Processing Module übergeben. Der Notruf wird mit der Hilfe des Emergency Call Security Module auf dem PMCCD des Benutzers gesendet.

Dienstbearbeitende Module

Diese Module sind zuständig für die Bearbeitung oder Verwirklichung einer Funktionalität. Sie sind im Grunde genommen Laufzeitmodule. Sie existieren nur solange der Dienst bereitgestellt wird. Nachdem das Ziel der Bedienung die Benutzung des Dienstes terminiert hat, hören diese Module zu existieren auf. Viele dieser Module sind der Schlüssel zu der Verwirklichung des Dienstes. Ohne manche von ihnen könnte der Dienst gar nicht existieren.

1. Match Making Processor Module: Das ist ein Kernmodul der Dienstverwirklichung. Dieses Modul benutzt die zwei aktiven Benutzerprofile des Benutzers und des Partnerschaftskandidaten und vergleicht sie, um herauszufinden, ob eine Partnerschaftseignung möglich ist oder nicht, und falls ja, wie hoch der Partnerschaftsübereinstimmungsgrad in Prozentpunkten ist. Die aktiven Benutzerprofile werden von dem User Servicing Module gemanagt. Dieses Modul wird zum Ausführen durch das Match Processing Module aufgerufen, welches wiederum im Kontext des User Servicing Module läuft.
2. User Servicing Module: Dieses Modul ist dasjenige, welches eine Übersicht über alle benutzerbezogenen Laufzeitmodule hat, und, je nachdem wann und wie diese zur Ausführung fällig sind, für die Ausführung dieser Module zuständig ist. Dieses Modul wird erstellt, wenn der Benutzer sich ganz zu Beginn bei einem SPLEMP anmeldet und die Anmeldung gelingt. Es wird von dem SPLEMP Location Registration Processing Module aufgerufen, welches selbst im Kontext des SPLEMP Servicing Module läuft. Es wird erst dann vernichtet, wenn die Benutzersitzung für beendet erklärt wird. Die Sitzung endet, wenn die einzige Anmeldung bei einem SPLEMP abläuft oder der Benutzer sich von einem SPLEMP oder Dienst abmeldet. Die Zuständigkeit der Terminierung liegt bei dem User Location Status and Serviceability Tracking Module, welches ein Teil des Moduls ist. Bei der Terminierung, übermittelt dieses Modul, viele der verwalteten Informationen an das User Servicing Sessions History Management Module weiter. Nachdem dieses Modul erstellt wurde, erstellt es auch das Active User Profile Generation Module. Das User Servicing Module unterstützt den Aufruf des User Servicing Settings Processing Module. Es managt auch das Interactive Activity Intentions Definition Processing Module. Dieses läuft auch im Kontext dieses Moduls. Weiterhin verfolgt es alle überprüften Partnerschaftskandidaten, ebenso wie alle akzeptierten, abgelehnten oder blockierten Partnerschaftseignungstreffer einer bestimmten Sitzung.
3. SPLEMP Servicing Module: Bevor die Benutzer sich überhaupt bei einem SPLEMP anzumelden beginnen können, sollte dieses Modul schon für den jeweiligen SPLEMP in Betrieb sein. Es wird von dem SPLEMP Betreiber selbst gestartet, oder es kann auch durch einen Alarmmechanismus in dem Serviced Public Leisure and Entertainment Meeting Place Accounts Management Module gebootet werden. Das SPLEMP Location Registration Processing Module läuft als ein Teil dieses höheren Moduls und wird auch von diesem Modul gesteuert. Es terminiert dann, wenn der SPLEMP-Betreiber es absichtlich terminiert oder wenn eine voreingestellte Laufdauer abläuft und ein Alarm ausgelöst wird. Dieses Modul stellt ein SPLEMP dar, wenn dort eine Sitzung stattfindet, oder mit anderen Worten, wenn es im Betrieb ist. Darüber hinaus hat dieses Modul eine Übersicht über alle angemeldeten Benutzer bei diesem SPLEMP, und somit Verweise zu den entsprechenden User Servicing Modules. Es ist zuständig für die Laufreihenfolgefestlegung der User Servicing Modules. Konkreter gesagt, wird die Laufreihenfolgefestlegung sowohl durch die Laufzeitprioritätsbenotungsangaben, welche über die User Servicing Modules verfügbar gemacht werden, als auch durch die Statistiken über die Bedienung während der aktuellen Sitzung getroffen. Eigentlich können viele User Servicing Modules parallel zueinander laufen. 4. Match Processing Module: Dieses Modul managt den gesamten Prozeß der Partnerschaftseignungssuche. Es übernimmt die Kontrolle über das March Making Processor Module. Es wird benutzt, um sicherzustellen, daß alle Phasen der Partnerschaftseignungssuche so ablaufen, wie sie konzipiert wurden. Dieses Modul wird von dem User Servicing Module aufgerufen. Es ist auch zuständig für das Aufrufen des Partner Introductory Information Generation and Provision Support Module. Danach ruft es das Matched Candidate Partner Contact Willingness Confirmation Support Module auf. Anschließend benutzt es falls notwendig das Communication Connection Establishment Module.
4. Interactive Activity Intentions Definition Processing Module: Falls es Informationen gibt, die eine gewisse Verarbeitung der Interaktive-Tätigkeitsabsichten-Definition benötigen, dann kümmert sich dieses Modul darum. Es arbeitet mit Informationen, die von dem Interactive Activity Intentions Configuration Support Module bereitgestellt wird. Es wird von dem User Servicing Module aufgerufen.
5. Authentication Module: Dieses Modul prüft nach, ob das Informationsübertragungssignal, welches empfangen wurde, in der Tat von der Partei stammt, die von dem Signal angegeben wird, und daß die Unversehrtheit der Information nicht kompromittiert wurde. Weiterhin muß, wenn man auf eine Ressource zugreifen muß, die anfordernde Partei identifiziert und authentifiziert werden, bevor die Erlaubnis erteilt wird. Dieses Modul benutzt Unterschriftsschlüssel und Zertifikate von dem System Security Information Management Module. Nur dann wird die Information von der anderen Partei akzeptiert und an die andere Partei geliefert.
6. User Servicing settings Processing Module: Dieses Modul übernimmt Informationen von dem User Servicing Settings Configuration Support Module und tätigt die notwendige Verarbeitung dieser Informationen. Das könnte Vorgänge einschließen wie das Feststellen, ob es überhaupt möglich ist, eine bestimmte Klasse von Bedienung zu benutzen oder nicht, oder ob eine gewisse Qualität des Dienstes bei einem bestimmten SPLEMP überhaupt bereitgestellt werden kann oder nicht, usw.
7. Partner Introductory Information Generation and Provision Support Module: Dieses Modul ist zuständig für das genaue Feststellen der Bekanntmachungsinformation, die dem vermittelten Partnerschaftskandidaten geliefert werden kann und soll, was abhängig ist von einem dem gesunden Menschenverstand entsprechenden bzw. vom Benutzer vorgeschriebenen Vertraulichkeitspegel. Das Benutzerprofil des Benutzers kann auch darüber Auskunft geben, ob Informationen preisgegeben werden dürfen oder nicht. Weiterhin sollte die Profilschablone des vermittelten Partnerschaftskandidaten auch wie ein Maßstab funktionieren, um die Attribute von Interesse festzustellen. Eigenartige Attribute des Benutzers wären auch in manchen Fällen mitteilenswert. Die Sensitivität mancher Attributen an bestimmten Örtlichkeiten oder SPLEMPs muß auch in Betracht gezogen werden. Dieses Modul wird von dem March Processing Module aufgerufen.
8. Communication Connection Establishment Module: Dieses Modul wird ebenfalls von dem Match Processing Module aufgerufen. Nachdem das Matched Candidate Partner Contact Willingness Confirmation Support Module seine Billigung gegeben hat, wird dieses Modul die Aufgabe, eine synchrone Kommunikationsverbindung zu dem vermittelten Partnerschaftskandidaten aufzubauen, übernehmen. Dieses Modul benutzt die Funktionalität, welche von dem Long Distance Wireless Synchronous Communication Connection to User's Personal Mobile Communications and Computing Device Management Module bereitgestellt wird. Am Ende existiert eine aufgebaute synchrone Kommunikationsverbindung zwischen den beiden Benutzern.
9. Active User Profile Generation Module: Dieses Modul arbeitet mit den Informationen, welche durch das User Profile Management Module verfügbar gemacht werden. Es wird von dem User Servicing Module aufgerufen. Für die Generierung des aktiven Benutzerprofils müssen Vertraulichkeitseinstellungen im Betracht gezogen werden, und das SPLEMP related User Profile Attributes Sensitivity Determination Module sowie das Locality related User Profile Attributes Sensitivity Determination Module müssen einbezogen werden. Weiterhin werden darin Informationen von des User Profile Attribute Credibility Tracking History Management Module darin integriert.
10. Automatic User Position Determining Module: Dieses Modul könnte benutzt werden, falls der Benutzer nicht über das User Location Tracking Module geortet werden möchte, sondern es bevorzugt, daß seine geographische Koordinaten durch Zugriff auf das User Position Tracking Security Module in dem PMCCD des Benutzers festgestellt werden. Diese Koordinaten werden mit der Hilfe von Geographical Places and Positions Interrelationships Graphs based Information Format Conversion Modules in SPLEMP Identitätsinformation konvertiert. In dem Fall wird eine assoziierte LSU bei dem SPLEMP nicht mehr notwendigerweise benötigt.
11. Specific Comobility and Coactivity Intention Definition and Tracking Security Processing Module: Es kann ein Bedarf existieren, die Informationen, welche von dem Specific Comobility and Coactivity Intention Definition and Tracking Security information Reception Module geliefert werden, weiter zu verarbeiten, bevor die Informationen in dem Specific Comobility and Coactivity Intention Definition and Tracking Information Management Module gespeichert werden können. Es könnte Verwandlung von Eingabe in ein anderes Format einschließen.
12. Emergency Call Security Processing Module: Nachdem ein Notruf von dem Emergency Call Reception Module empfangen wird, wird der Notruf verarbeitet werden müssen. Dies wird wahrscheinlich dadurch geschehen, daß es zu den entsprechenden Sicherheitsdiensten mit den notwendigen zusätzlichen Informationen weitergeleitet wird. Diese notwendigen zusätzlichen Informationen werden wahrscheinlich von dem Specific Comobility and Coactivity Intention Definition and Tracking Information Management Module abgeleitet. Darüber hinaus könnten weiteren Informationen über das Aussehen von dem Benutzer, sein Foto, Erklärung der Umstände, usw. den Sicherheitsdiensten bereitgestellt werden.
13. User Location Status and Serviceability Tracking Module: Dieses Modul ist zuständig für die Feststellung der Bedienbarkeit des Benutzers anhand seines Örtlichkeitszustandes bei dem SPLEMP, wo er sich angemeldet hat. Es bleibt während der gesamten Dauer des User Servicing Module aktiv. Es arbeitet auf Informationen, welche von dem User Location Tracking Module gesammelt wurden. So ist dieses Modul dafür zuständig, das User Servicing Module mit den erforderlichen Informationen versorgt zu halten, die gebraucht werden, um zu entscheiden, ob der Benutzer bedient werden soll oder nicht. Dieses Modul kann auch seine Eingabe von dem Automatic User Position Determining Module beziehen.
14. SPLEMP Location Registration Processing Module: Dieses Modul arbeitet in enger Kooperation mit dem Location Registrations Management Module der LSU des SPLEMP- Betreibers. Immer dann, wenn eine neue Anmeldung bemerkt wird, wird es zu dem steuernden SPLEMP Servicing Module weitergeleitet. Außerdem besteht hier die Anforderung, daß das Location Registrations Management Module als eine Bestätigung des Benutzerstandortes fungiert. Das Modul arbeitet hier innerhalb des Kontextes des SPLEMP Servicing Module.
15. Testing and Diagnosis Module: Dieses Modul wird gebraucht um die gesamte RPMMSU zu testen. Es ist nützlich für die Diagnose bei unzufriedenstellendem Betrieb. Es kann entweder benutzt werden, bevor die RPMMSU in Betrieb genommen wird, oder wenn der Betrieb kurz eingestellt wird, oder um herauszufinden, warum etwas nicht ordnungsmäßig funktioniert, sogar während des Betriebes. Im letzten Fall wird es sehr eng mit dem System Operations Quality Control and Maintenance Information Management Module zusammenarbeiten.
16. SPLEMP Servicing Settings Processing Module: Dieses Modul arbeitet mit den Informationen, welche durch das SPLEMP Servicing Settings Configuration Support Module bereitgestellt werden. Was die Bedienung des einzelnen Benutzers angeht, wird es versuchen, die Einstellungen mit denen des Benutzers zu integrieren. Bei allen anderen Einstellungen werden die notwendigen Schritte vorgenommen, um diese auch zu verwirklichen. Dieses Modul arbeitet eng mit dem SPLEMP Servicing Module zusammen.

Kommunikationsverbindungsmanagement-Module

Diese Module sind dazu da, eine Kommunikationsverbindung zwischen zwei entfernt gelegenen Parteien so aufzubauen, daß Signale über diese Verbindungen übermittelt werden können. Das heißt, die Informationen, die am Anfang auf einer Seite der Verbindung vorhanden ist, können nach einem Prozeß, welcher Übermittlung bzw. Senden heißt, auf der anderen Seite dupliziert werden, so daß am Ende die gleichen Informationen auf beide Seiten vorhanden sind. Über synchrone Verbindungen ist es auch möglich, ein Gespräch in menschliche Sprache zu führen.

1. Long Distance Signalling Connection to Serviced Public Leisure and Entertainment Meeting Place's Location Server Unit Management Module: Dieses Modul wird benutzt, um Informationssignale über große Entfernungen zu verschiedenes SPLEMPs an verschiedenen Örtlichkeiten zu schicken. Diese können entweder über Draht oder drahtlos gesendet werden. Dieses Modul hilft dabei, eine Verbindung aufzubauen, eine Verbindung abzubrechen, zu garantieren, daß die Information auf der anderen Seite in der richtigen Reihenfolge ankommt, usw. Das Modul wird von verschiedenen anderen Modulen benutzt, die abhängig von der Kommunikation zwischen der RPMMSU und der LSU sind. Dies betrifft das SPLEMP Location Registration Processing Module, das User Location Tracking Module, das System Behaviour Complaint Submissions Reception Module, das User Behaviour Complaint Submissions Reception Module und das SPLEMP Registration and Persistent Configuration Human-Machine Interface Support Module auf der Seite der RPMMSU bzw. das Location Registrations Management Module, das User Location Registration Module, das System Behaviour Complaint Submission Module und das User Behaviour Complaint Submission Module auf der Seite der LSU bei dem SPLEMP. Dieses Modul selbst benutzt die Long Distance Networking and Communications Unit, um die eigene Funktionalität zu verwirklichen. Dieses Modul kann zusätzlich für die Kommunikation zu anderen Parteien, wie Sicherheitsbehörden, Authentifizierungsagenturen, usw. benutzt werden.
2. Long Distance Wireless Signalling Connection to User's Personal Mobile Communications and Computing Device Management Module: Dieses Modul wird benutzt, um Informationssignale über große Entfernungen an verschiedene Benutzer in verschiedenen Örtlichkeiten zu senden. Diese Signale werden immer drahtlos über Luft gesendet und werden und von den PMCCDs der Benutzer aufgefangen. Dieses Modul benutzt eigentlich ein anderes Grundplattformmodul, welches als Long Distance Wireless Networking and Communications Unit bezeichnet wird. Verschiedene Signale werden zwischen der RPMMSU und dem PMCCD des Benutzers ausgetauscht. Viele dieser Signale dienen dem Zwecke des Verbindungsaufbaus und der Sicherheitsgewährleistung, und andere dazu da, Informationen auszutauschen, die direkt relevant für das System selbst sind.
3. Long Distance Wireless Synchronous Duplex Communication Connection to User's Personal Mobile Communications and Computing Device Management Module: Dieses Modul wird benutzt, um eine drahtlose synchrone Duplex-Kommunikationsverbindung zwischen der RPMMSU und dem PMCCD des Benutzers zu verwirklichen. Im Grunde genommen benutzt man dieses Modul aber, um zwei Verbindungen aufzubauen, zunächst einmal zwischen der RPMMSU und dem PMCCD des Benutzers auf der einen Seite, und zwischen der RPMMSU und dem PMCCD des vermittelten Partnerschaftskandidaten auf der anderen Seite. Danach werden die zwei Verbindungen zusammengefügt und die RPMMSU entbindet sich von den Verbindungen, so daß am Ende eine direkte Verbindung existiert zwischen den beiden Benutzern. Dies tut das Modul nicht direkt, statt dessen wird es von dem Communication Connection Establishment Module, Welches dieses Modul auch steuert, beauftragt, dies zu tun.

Präsentations-Module

Präsentations-Module ermöglichen es einer Präsentation, aus einer Entfernung verfügbar gemacht zu werden. Die Person auf der anderen Seite kann sowohl Informationen bekommen als auch so interagieren, daß es möglich wird, Informationen zurück an das Präsentations- Modul zu übermitteln. In dieser Art und Weise spielen die Präsentationsmodule die Rolle, nicht nur die sinnlich wahrnehmbaren Informationen einer entfernten Person darzustellen, sondern auch Informationen zu erheben. Oftmals werden die Informationen so organisiert, daß der Benutzer sie visuell mit Leichtigkeit verstehen, oder akustisch anhören, oder taktil abtasten und sogar anriechen kann. Das heißt, die Informationen werden mittels Multimedia dargestellt. Darüber hinaus muß eine Einbindung der Präsentationen in die darunterliegenden Netzwerk-, Kommunikations- und Präsentationsplattform gesichert werden.

1. Operator and Service Description Information Provision Support Module: Dadurch kann der RPMMSU-Betreiber Informationen über sich selbst und über den Partnerschaftssuchdienst dem Benutzer zukommen lassen. In der heutigen Techniksprache ausgedrückt, ähnelt dies dem Browsing einer Website, für den RPMMSU-Betreiber erstellt.
2. Operator System Management Human-Machine Interface Support Module: Mit dieser Schnittstelle kann der RPMMSU-Betreiber das gesamte RPMMSU-System managen. Dazu gehört, das System hochzufahren, das System herunterzufahren, einen neuen SPLEMP in der Bedienbarkeit aufzunehmen, eine neue Örtlichkeit in den Betrieb zu integrieren, Betriebsstörungen zu suchen und zu beheben, SPLEMP-Örtlichkeits- Beziehungen neu zu konfigurieren, das System um neue Funktionalitäten zu erweitern, usw.
3. Operator Statistical & Other Reports Generator Support Module: Dieses Modul erstellt Statistiken und Analysen über den Betrieb der RPMMSU, die Bedienung der SPLEMPs, die Bedienung der Benutzer, den Betrieb bezüglich einer Örtlichkeit, Beschwerdemenge, die Attribute der Benutzer selbst, die Eigenschaften der SPLEMPs selbst, usw., und präsentiert diese dem RPMMSU-Betriebsmanagement mit Hilfe von Diagrammen, Graphiken, Tabellen, Text, usw. Diese Berichte können regelmäßig erstellt werden und automatisch der Betriebsmanagementmannschaft zugeschickt werden, oder sie können abgerufen werden. Das hilft der Betriebsmanagementmannschaft, eine Übersicht über den gesamten Systembetrieb zu behalten.
4. User Registration and Persistent Configuration Human-Machine Interface Support Module: Mit der Unterstützung dieses Moduls, kann der Benutzer sein Benutzerprofil, Interaktive- Tätigkeitsabsichten, Geheimhaltungseinstellungen, Bedienungspreisklasse, Identitätsinformationen, Kontaktierbarkeitsinformationen, Informationen zu Heimat- und Aufenthaltsort, Genehmigungen, usw. in das System eingeben. Dieses Modul dient eigentlich nur als Schnittstelle, welche es dem Benutzer ermöglicht, diese Informationen einzugeben, obwohl der Benutzer entfernt an einem anderen Rechnersystem sitzt. Die Darstellung der Fragen, die Erfassung der Eingaben, die Navigation von Frage zu Frage oder sogar zu anderen Teilen des Systems, das Anbieten der Wahlmöglichkeit, um den erwünschten Teil zum Konfigurieren oder Durchschauen auszuwählen, die multimediale Darstellung der konfigurierbaren Teile, die Ernennung des aktuellen konfigurierbaren Teils, den der Benutzer gerade durchschaut. Darüber hinaus muß eine Einbindung der Präsentationen mit der darunterliegenden Netzwerk- und Kommunikations- und Präsentationsplattform gesichert werden.
5. SPLEMP Registration and Persistent Configuration Human-Machine Interface Support Module: Dieses Modul ähnelt etwas dem oben genannten Modul, der Unterschied ist, daß dieses Modul von den SPLEMP-Betreibern benutzt wird. Dieses Modul ermöglicht, daß den SPLEMP-Betreibern eine Mensch-Maschine-Schnittstelle zur Verfügung steht. Dieses Modul benutzend kann der SPLEMP-Betreiber der RPMMSU seine Identitätsangaben, LSU-Zugriffsschlüssel, LSU-Kontaktierbarkeitsinformationen, SPLEMP- Örtlichkeitsinformation, Bankkontennummern und Auszugsermächtigungen, Öffnungszeiten und Öffnungsregeln, usw. mitteilen. Über dieses Modul soll der SPLEMP-Betreiber auch in der Lage sein, mit dem RPMMSU-Betreiber Verträge zu schließen. Darüber hinaus kann der SPLEMP-Betreiber die RPMMSU auch über bevorstehende Öffnungssitzungen und geplante Veranstaltungen im Voraus informieren.
6. Authentication Authority Agencies User Authentication Confirmation Feed Human-Machine Interface Support Module: Über dieses Modul können Authentifizierungsagenturen die Identitätsangaben des Benutzers bestätigen. Wenn der Benutzer mit dem RPMMSU- Betreiber einen Bedienungsvertrag abschließt, dann könnte der Benutzer eventuell eine digitale Unterschrift dazu fügen. Es muß festgestellt werden, ob diese Unterschrift wirklich zu den von dem Benutzer behaupteten Identitätsangaben paßt. Dies nehmen die Authentifizierungsagenturen vor. Dieses Präsentationsmodul ermöglicht einem Angestellten einer Authentifizierungsagentur, die Authentifizierungsbestätigung für einen bestimmten Benutzer einzugeben, oder der RPMMSU weitere Benutzerangaben mitzuteilen, wie die PMCCD-Kontaktierbarkeitsadresse, die Sozialversicherungsnummer, das Bankkonto, usw.
7. Security Authority User Security Check and User Personal and Activity Information Feed Support Human-Machine Interface Support Module: Dieses Modul Benutzend kann ein Sicherheitsbehördenbeamter Informationen zu einem bestimmten Benutzer eingeben, was seine Strafakte, oder seine Geschichte, oder seine Bekanntschaften, oder sein öffentliches Verhalten, oder seine Gewohnheiten, usw. angeht. Nicht alles davon ist erforderlich und nicht bei jedem Benutzer erforderlich. Aber falls es zu Beschwerden über einen Benutzer kommt, dann kann manchmal eine Überprüfung eines Benutzers erforderlich werden. Dies kann nur geschehen, wenn man eine Genehmigung von dem Benutzer dafür hat. Dieses Modul bildet die Eingabeschnittstelle für den Sicherheitsbehördenbeamten.

Grundplattform-Module

Diese Module sind diejenigen, die das Fundament für die anderen bilden. Alle anderen Module benutzen dieses für ihre Verwirklichung. Die Funktionalität einiger davon könnte redundant sein. Die Redundanz dient nur der Benutzungsflexibilität und der Benutzungsfreiheit.

1. Long Distance Wired Networking and Communications Unit: Diese Einheit bildet die Grundlage für Vernetzung und Kommunikation über große Entfernungen. Üblicherweise werden in diesem Fall Informationen und Sprache über Kabel übertragen.
2. Long Distance Wireless Networking and Communications Unit: Diese Einheit benutzend können die Informationen von einem Sender an einem Empfänger, der nicht mit dem Sender über Kabel verbunden ist, gesendet werden, d. h. drahtlos gesendet werden.
3. External Serial and Parallel Interfaces Bus and Control Units: über diese Schnittstelleneinheiten können Peripheriegeräte mit der RPMMSU verbunden werden, entweder direkt oder über ein Netzwerk, wobei diese Einheit der RPMMSU behilflich ist, sich an das Netzwerk, z. B. ein Intranet, anzubinden.
4. Main Memory unit: Die Ausführungsmodule werden diese Einheit neben der Central Processing Unit benutzen, um überhaupt ausgeführt werden zu können. Die meisten Informationen, die ein Modul intern während seiner Ausführung braucht, werden hier gespeichert.
5. Central Processing Unit: Die gesamte Ausführung der Ausführungsmodule in der RPMMSU wird mit Hilfe dieser Einheit erledigt.
6. Keys Input Mechanism Unit: Mit Hilfe einer Tastatur oder einer Anzahl von Tasten, kann der Betreuungsangestellte der RPMMSU seine Eingaben durchführen.
7. Persistent Memory Unit: Mit Hilfe dieser Einheit können alle die dauerhaften Speicher betreffenden Module verwirklicht werden.
8. Power Supply Unit: Dies versorgt die gesamte RPMMSU mit dem benötigten Strom.
9. Display Output Mechanism Unit: Dadurch kann der Betreuungsangestellte der RPMMSU Feedback über das System bekommen und es so manipulieren.

Möglichkeiten der Partnerschaftseignungssuchprozessor-Module

1. User Profile and Wishes based Match-Making Processor Module
2. User Social and Psychological System Profile based Match-Making Processor Module
3. User Astrological System Horoscope based Match-Making Processor Module
4. User Palmistry System Profile based Match-Making Processor Module

User's Personal Mobile Communications and Computing Device

1. Service Main Module: Dies ist das erste Modul, das auszuführen beginnt und zuständig ist für den direkten oder indirekten Aufruf aller anderen Module. Dieses Modul dient als Auslöser für das Funktionieren des Systems. Unter Benutzung dieses Moduls bekommt der Benutzer Zugang zu allen anderen Modulen. Die meisten Bedienungsmodule arbeiten im Kontext dieses Moduls.
2. Location Registration Module: Dieses Modul arbeitet in zwei verschiedenen Modi. Bei dem ersten Modus, wird dieses Modul nur für die Orts-Anmeldung benutzt. Dabei wird nicht überprüft, ob der Benutzer sich wirklich an dem angegebenen SPLEMP aufhält. In diesem Fall kommuniziert dieses Modul direkt mit dem User Location Tracking Module bei der RPMMSU über die Long Distance Wireless Networking and Communications Unit. Hierbei wird das Kennzeichen des jeweiligen SPLEMPs, das eigene Benutzerkennzeichen des Benutzers und eventuell auch noch das Kennzeichen des PMCCDs des Benutzers mitgeteilt. Es gibt keine Notwendigkeit, diese Informationen an die LSU oder über die LSU zu übertragen, wobei die LSU womöglich gar nicht vorhanden ist. Bei dem zweiten Modus ist die LSU sehr wahrscheinlich vorhanden. Der Benutzer kann angeben, daß er sich bei einem bestimmten SPLEMP anzumelden wünscht. Dieses Modul würde mit beiden Module, sowohl mit dem User Location Tracking Module in der RPMMSU als auch mit dem User Location Registration Module bei der LSU des SPLEMPs, kooperieren. Mit dem User Location Tracking Module bei der RPMMSU kommuniziert es mit der Unterstützung der Long Distance Wireless Networking and Communications Unit und mit dem User Location Registration Module bei der LSU an dem SPLEMP tut es das mit der Hilfe der Short Distance Wireless Networking and Communications Unit. Es teilt beiden Einheiten mit, daß es wünscht, sich bei ihnen anzumelden. An die RPMMSU sendet es zusätzlich die eigene Kontaktierbarkeitsadresse oder das Benutzerkennzeichen oder wahlweise beide, diejenige benutzend, welche die RPMMSU wissen lassen würde, welchen Benutzer es zu bedienen gilt. Es schickt auch noch das Ortsanmeldungskennzeichen, welches dieses Modul mit dem LSU verhandelt und akzeptiert. So wann immer die LSU die RPMMSU bezüglich eines Benutzers kontaktiert, tut sie das immer, indem sie das Ortsanmeldungskennzeichen benutzt, besonders zu Zwecken der Bestätigung des Aufenthaltes. Es könnte der LSU nicht erlaubt sein, die Identität des Benutzers oder die Identität seines PMCCD zu erfahren. Bei der RPMMSU kann die Konvertierung zwischen dem PMCCD-Kennzeichen und dem Ortsanmeldungskennzeichen in beiden Richtungen vorgenommen werden.
3. Location Stay Monitoring Module: Dieses Modul ist erstens optional und zweitens funktioniert es auch in zwei Modi. Bei dem ersten Modus kommuniziert dieses Modul direkt mit dem User Location Tracking Module der RPMMSU, und läßt diese wissen, ob das PMCCD und infolgedessen der Benutzer sich auf dem Gelände des SPLEMPs aufhalten. Hier braucht das Modul der RPMMSU nicht zu beweisen, daß dies wirklich der Tatsache entspricht. In dem zweiten Modus ist dieses Modul zuständig für die Interaktion zwischen den Modulen bei dem SPLEMP, die verantwortlich für die Überprüfung sind, ob der Benutzer noch auf dem Gelände des SPLEMPs ist oder nicht. Das schließt die On-Premises Stay Check Listener Units, die Check-In Confirmation Listener Units and Check-Out Confirmation Listener Units ein. Dieses Modul kümmert sich darum, regelmäßig zu überprüfen, ob sich der Benutzer auf dem Gelände des SPLEMPs aufhält, ob sich der Benutzer gerade einem Ausgang oder Eingang nähert, und schickt dementsprechend ein Auscheck- Bestätigungssignal bzw. ein Eincheck-Bestätigungssignal. Mit allen Signalen, die es ausstrahlt, sendet es auch noch ein Ortsanmeldungskennzeichen. Dieses Modul arbeitet im Kontext des Location Registrarion Module. Alle Änderungen an dem Aufenthaltsstatus des Benutzers werden an das Location Registration Module weitergeleitet. Diese Information, nur falls sie nicht über die User Location Registration Module des SPLEMPs zu dem RPMMSU mitgeteilt wird, kann dann über das Location Registration Module an das User Location Tracking Module des RPMMSU übermittelt werden.
4. Location Deregistration Confirmation Module: Unter Benutzung dieses Moduls kann der Benutzer beim Auschecken angefragt werden, ob der sich abmelden möchte, oder ob er meint, daß er zu dem SPLEMP zurückkehren wird und mit der Dienstbenutzung weitermachen wird. Dieses Modul kann der Benutzer auch dafür verwenden, um explizit mitzuteilen, daß er sich abmelden möchte.
5. Matched Candidate Partner Offer Response Module: Dieses Modul benutzend kann der Benutzer angefragt werden, ob er bereit und willig ist, den Kontakt mit dem vermittelten Partnerschaftskandidaten aufzubauen. Die Antwort des Benutzers wird entgegengenommen und zu dem Introductory Session Support Module übergeben, in dessen Kontext dieses Modul läuft.
6. Matched Candidate Partner Personal Object Transfer and Access Grant Module: Dieses Modul wird von dem vermittelten Partnerschaftskandidaten benutzt, um eine Informationseinheit auf das PMCCD des Benutzers zu übermitteln. Diese Informationseinheit könnte alles mögliche sein, z. B. digitale Fotos, digitale Visitenkarte, Dechiffrierschlüssel, usw. Dies könnte wichtig sein, um Information über den anderen aus Gründen der Erinnerung und Kontaktierbarkeit auszutauschen. Mittels dieses Moduls kann der Benutzer auch ähnliche Informationseinheiten auf das PMCCD des anderen Benutzers übermitteln. Als Übermittlungsweg benutzt dieses Modul die Short Distance Wireless Networking and Communications Unit.
7. Interactive Activity Intentions Definition Module: Immer wenn der Benutzer bedient werden möchte, ist es nötig, daß er die Parameter der Bedienung spezifiziert. Natürlich können diese Parameter vordefiniert sein und als vorgegeben angewendet werden. Wenn der Benutzer jedoch aus vielen Parametersätzen eine Auswahl treffen muß, dann benutzt er dieses Modul. Der Benutzer kann auch neue Parameter eingeben, falls dies erforderlich ist. Unter Benutzung dieses Moduls gibt der Benutzer ein, an welchen Arten von interaktiven Tätigkeiten er teilnehmen möchte, welche Rolle er dabei am liebsten spielen möchte, welche Rolle die andere Partei spielen soll, und ob es bestimmte Eigenschaften gäbe, die der Benutzer sich bei der anderen Partei d. h. bei dem Partnerschaftskandidaten, erhofft.
8. Service Activation Module: Dieses Modul benutzend kann der Benutzer die Bedienung aktivieren. Dies bildet natürlich einen wesentlichen Bestandteil des Ortsanmeldungsprozesses. Der Benutzer benutzt dieses Modul, um den Dienst zu deaktivieren, was der Benutzer sich wünschen könnte, z. B., wenn er auf die Toilette gehen muß, oder sich schon in einem Gespräch befindet, oder mit einer anderen Aufgabe beschäftigt ist, usw. Nach der Deaktivierung kann der Benutzer seine Bedienung durch dieses Modul erneut aktivieren. Dieses Modul teilt dem Location Registration Module die Aktivierungen und Deaktivierungen mit, welches die Information an die RPMMSU weiterleitet.
9. Introductory Session Support Module: Dieses Modul dient nur dem Zweck, den Dialog zwischen dem Benutzer und der RPMMSU zu unterstützen, im Hinblick auf die Neugier des Benutzers bezüglich des vermittelten Partnerschaftskandidaten vor dem Akzeptieren des Angebots, mit jenem in Kontakt zu treten. Dieser Modus hat ein gegenüberstehendes Modul bei der RPMMSU, das Introductory Session Management Support Module.
10. System to User Messaging Support Module: Immer wenn das System dem Benutzer etwas mitteilen möchte, wird die Benachrichtigung von diesem Modul empfangen. Die Benachrichtigung könnte verschiedenes bedeuten, wie z. B. eine Mahnung, eine Warnung, ein neues Angebot, eine Einladung, Informationen von Interesse, eine Bestätigung, eine Aufklärung, eine Begründung, eine Rechtfertigung, eine Entschuldigung oder anderes. Der gegenüberstehende Modul bei der RPMMSU heißt ebenfalls System to User Messaging Support Module.
11. System Behaviour Complaint Submission Module: Dieses Modul hilft dem Benutzer, eine Beschwerde bei der RPMMSU einzureichen über die Bedienung durch die RPMMSU. Dieses Modul sendet die Beschwerde an das System Behaviour Complaint Submissions Reception Module bei der RPMMSU.
12. Communication Connection Establishment Module: Dieses Modul wird immer dann benutzt, wenn eine Verbindung zwischen dem Benutzer und dem vermittelten Partnerschaftskandidaten aufgebaut werden muß. Zuerst könnte eine Verbindung zwischen dem Benutzer und dem Communication Connection Establishment Module der RPMMSU aufgebaut werden. Das kann passieren auf Veranlassung des Benutzers, oder es kann von einem anderen Modul in dem PMCCD angeordnet werden, oder es kann von einem anderen Modul in der RPMMSU befohlen werden. Das gleiche geschieht bei dem vermittelten Partnerschaftskandidaten. Danach verbindet die RPMMSU die zwei Anrufe, so daß eine Verbindung zwischen den zwei Benutzern besteht.
13. Synchronous Communication Support Module: Nachdem eine Verbindung zwischen den zwei Benutzern aufgebaut wurde, wird dieses Modul von den Benutzern dafür verwendet, um miteinander ein Gespräch zu führen, wahrscheinlich um sich mit den anderen über einen Treffpunkt zu einigen. Man kann es eine Mobiltelefonverbindung nennen.
14. Matched Candidate Partner Remembrance Information Configuration Module: Dieses Modul hilft dem Benutzer, Informationen über den vermittelten Partnerschaftskandidaten zu konfigurieren, so daß auch nachdem viel Zeit vergangen ist, sich der Benutzer an den vermittelten Partnerschaftskandidaten mit Hilfe der konfigurierten Informationen zu erinnern vermögen würde. Dieses Modul hilft auch, diese Informationen auf einen bestimmten Informationsspeicherplatz zu laden, welcher mit dem Management der persönlichen Informationen des Benutzers beauftragt ist. Dieses Modul hilft dem Benutzer auch beim Herunterladen der vorher konfigurierten Informationen über beliebige vermittelten Partnerschaftskandidaten von der RPMMSU oder von einem anderen Ort. Um die Kooperation zwischen dem PMCCD des Benutzers und der RPMMSU zu bewältigen, gibt es ein entsprechendes Modul, das Matched Candidate Partner Remembrance Information Configuration Module. Der Matched Candidate Partner Remembrance Information Management Module kann ebenfalls diese Funktion übernehmen.
15. Matched Candidate Partner Critical Feedback Module: Dieses Modul kann der Benutzer dafür verwenden, seine Verärgerung oder Enttäuschung zum Ausdruck zu bringen. Es ist möglich, daß ein anderer Benutzer falsche Informationen in sein Profil eingegeben hat, um das March Making Processor Module in die Irre zu führen. Es kann verschiedene dafür Gründe geben, warum ein Benutzer über den vermittelten Partnerschaftskandidaten verärgert ist. Es kann sein, daß der vermittelte Partnerschaftskandidat sehr spät zu dem vereinbarten Ort kommt, daß er gar nicht zu dem vereinbarten Ort kommt, daß er die Regeln des Verhaltenskodex nicht folgt, daß er sich dem Benutzer gegenüber schlecht oder unzivilisiert benimmt, daß er offensichtlich falsche Angaben in seinem Profil gemacht hat, daß er dem Benutzer etwas böses tun will, daß er Tabuthemen des Benutzers anspricht, daß er den Benutzer irgendwie betrügt, und so weiter und so fort. Dieses Modul kann in dem Kontext des Service Main Module arbeiten, es kann aber auch seinen eigenen Kontext haben. Es kommuniziert mit dem Matched Candidate Partner Critical Feedback Reception Module auf der RPMMSU über die Long Distance Wireless Networking and Communications Unit.
16. User Servicing Settings Module: Manchmal muß der Benutzer, wenn er bedient werden möchte, explizit einige Parameter, welche die Bedienung selbst betreffen, richtig spezifizieren. Er könnte die Häufigkeit der Partnerschaftssuchtreffermeldungen erhöhen bzw. vermindern wollen, oder eine bestimmte Qualitätskategorie oder Preiskategorie zur Zeit der Bedienung selbst festlegen wollen, oder den minimalen prozentuellen Partnerschaftseignungsgrad variieren wollen, usw. Das alles kann der Benutzer über dieses Modul erledigen. Die so eingegebenen Informationen werden an das gegenüberstehenden Modul bei der RPMMSU, das User Servicing Settings Configuration Support Module, mit Hilfe des Long Distance Wireless Networking and Communications Unit übermittelt. Dieses Modul läuft im Kontext des Service Main Module.
17. Authentication Module: Dieses Modul ist prüft nach, ob das Informationsübertragungssignal, das empfangen wurde, in der Tat von der Partei stammt, wie durch das Signal behauptet wird, und daß die Unversehrtheit der Information nicht kompromittiert wurde. Weiterhin muß, wenn man auf eine Ressource zugreifen muß, bevor die Erlaubnis erteilt wird, die anfordernde Partei identifiziert und authentifiziert werden. Nur dann wird die Information von der angefragten Partei akzeptiert und an die authentifizierte Partei geliefert. Dieses Modul benutzt Unterschriftsschlüssel und Zertifikate, welche es entweder selbst verwaltet oder welche durch ein zentrales Informationslager verwaltet werden, das sich in den PMCCD, auf das aber auch andere im PMCCD laufende Systeme Zugriff haben. Wenn die RPMMSU eine Verbindung zu dem PMCCD aufbauen möchte oder Informationen senden möchte, oder Steuerungszugang zu einem PMCCD-internen Modul sucht, dann muß dieses Modul feststellen, daß auf der anderen Seite in der Tat das RPMMSU ist und für diese Aktion auch berechtigt ist, bevor die Erlaubnis erteilt werden kann. In der Verbindungsaufbauphase muß dieses Modul eventuell mit dem Authentication Module der RPMMSU, durch Austausch von Informationen in beiderlei Richtungen, zusammenarbeiten. Auch wenn das PMCCD mit der LSU des SPLEMP-Betreibers kommuniziert, spielt dieses Modul die Rolle des Beglaubigers und Pförtners. Es muß letztendlich festgestellt werden, daß das PMCCD wirklich mit der LSU Informationsaustausch führt und nicht mit den eventuell vielen anderen Umgebungssystemen oder LSU-Betrügersystemen. Dafür muß es mit dem Authentication Module auf der LSU zusammenarbeiten. Dieses Modul kann im Kontext des Service Main Module, aber auch eigenständig laufen.
18. Matched Candidate Partner Catalogue Access Module: Dieses Modul ermöglicht es dem Benutzer, eine Liste von vermittelten Partnerschaftskandidaten durchzusehen. Dieses Modul kann selbst über Informationen über vermittelte Partnerschaftskandidaten verfügen. Die Informationen, die von diesem Modul selbst verwaltet werden, sind meistens nur auf die aktuelle Sitzung bezogen. Es verschafft auch Zugang zu den von dem Matched Candidate Partner Catalogue Management Module gemanagten Informationen. Diese Informationen beziehen sich auf alte Partnerschaftseignungstreffer. Der Benutzer könnte auch diese alten Partnerschaftseignungstreffer durchsehen. Der Benutzer könnte auch die gezeigten Partnerschaftseignungstreffer durch irgend welche Parameter einschränken, z. B. Datum, Zeitperiode, Aussehen, usw. Der Benutzer hat keine Genehmigung, Einträge hier zu löschen.
19. User Position Tracking Security Module: Dieses Modul ist im Stande, die geographischen Koordinaten des PMCCDs zu erraten. Da das PMCCD normalerweise bei dem Benutzer ist, kann man davon ausgehen, daß es die Position des Benutzers kennt. Der Benutzer könnte unter Umständen bereit sein, diese Angaben einer anderen Instanz mitzuteilen. Das kann passieren, wenn man z. B um einen Dienst in Anspruch zu nehmen beweisen muß, sich auf einem bestimmten Ort zu befinden. In diesem Fall muß das System den Angaben des PMCCDs vertrauen können, daß die Ortsangaben nicht verfälscht wurden. Es kann auch sein, daß der Benutzer einen Dienst im Anspruch nehmen möchte, dessen Inhalt sich auf den Aufenthaltsort des Benutzers bezieht, und der Benutzer nicht die Umständlichkeit ertragen will, seinen Aufenthaltsort ständig einzugeben. Manchmal wäre es viel effektiver, wenn das System über die genauen geographischen Ortsangaben verfügte, und diese könnte der Benutzer, um sie dem System mitzuteilen, schlecht selbst erraten, selbst wenn er dies wollte. Drittens könnte es einen Dienst geben, bei es nur darum ginge, die Aufenthaltsposition des Benutzers zu protokollieren, und zwar bei dem Dienst selbst. In diesen Fällen lohnt es sich, dieses Modul zu benutzen.
20. Emergency Call Security Module: Dieses Modul hilft den Benutzer dabei, einen Notruf auszusenden. Falls der Benutzer das User Position Tracking Security Module aktiviert hat, braucht er bei diesem Notruf noch nicht einmal seine Position nochmals explizit einzugeben. Falls der Benutzer das Specific Comobility and Coactivity Intention Definition and Tracking Security Module aktiviert hat, braucht er oftmals auch nicht die Umstände zu erklären. Bei dem Notruf kann der Benutzer nochmals bestimmte Optionen auswählen, um das Problem etwas zu schildern. Dieses Modul ermöglicht es erstmals, an den richtigen anzusprechenden Ort einen Notruf zu senden und auch die notwendigen Informationen zu liefern über den Standort oder die Art des Problems, usw. In solchen Fällen kann die RPMMSU diesen Notruf automatisch bearbeiten, indem sie den Notruf zu der zuständigen Sicherheitsbehörde weiterleitet, mit den notwendigen Angaben zum Benutzer, seinem Standort, den Umständen und der Art des Problems. Dieses Modul kooperiert mit dem Emergency Call Reception Module bei der RPMMSU.
21. Specific Comobility and Coactivity Intention Definition and Tracking Security Module: Dieses Modul wird eventuell von dem Benutzer bei einem Ausflug nach einer Sitzung benutzt, um Angaben zu machen über seine Begleitung, Absichten, augenblicklichem Verbleib, usw. Das dient dem Zweck, daß im Falle, dem Benutzer stößt etwas zu, es dann für die Ermittlungsleute einfach herauszufinden wäre, was mit dem Benutzer passiert ist, und im Falles einer Vermutung, die auf ein Verbrechen verweist, auch wer die Verdächtigten wären. Allein die Kenntnis, daß man nicht unbestraft davonkommen kann, wäre Grund genug, daß die begleitende Person dem Benutzer keinen Schaden zufügen würde. Dieses Modul kooperiert mit dem Specific Comobility and Coactivity Intention Definition and Tracking Security Information Reception Module, um Informationen der RPMMSU zukommen zu lassen. 22. Geographical Position Determiner Unit: Diese Einheit kann die geographische Koordinaten des PMCCDs ermitteln. Diese Koordinaten können mit denen des SPLEMPs verglichen werden, um herauszufinden, ob diese Koordinaten von den des SPLEMPs umgefaßt werden oder nicht. Dadurch läßt sich ermitteln, ob der Benutzer sich auf dem Gelände eines SPLEMPs befindet. Man kann diese geographischen Koordinaten in eine Position auf einer Landkarte, z. B. einem Stadtplan, konvertieren. Die Art, in der die geographischen Koordinaten ermittelt werden, ist genau wie oder ähnlich zu dem "Global Positioning System" des US-Militärs.
22. Long Distance Wireless Networking and Communications Unit: Diese Elnhelt ermöglicht es dem PMCCD, drahtlos eine Verbindung zu einem anderen System aufbauen und mit Hilfe von Netzwerkprotokollen, wie z. B. dem Wireless Application Protocol des WAP-Forums, mit dem anderen System zu kommunizieren. Es kann natürlich auch ein anderes Protokoll sein, was eine Kommunikation ermöglicht. Die ganze Kommunikation zwischen den Modulen des PMCCDs und des RPMMSUs läuft über dieses Modul.
23. Short Distance Wireless Networking and Communications Unit: Diese Einheit wird von vielen anderen Modulen benutzt, wie dem Location Registration Module, dem Location Stay Monitoring Module, und dem Matched Candidate Partner Personal Object Transfer and Access Grant Module. Diese Einheit ist sehr kritisch für das Funktionieren des gesamten Systems. Diese Einheit sendet elektromagnetische Signale aus, die nur so stark sind, daß sie nur eine Entfernung von höchstens wenigen Metern erreichen. Diese Einheit ermöglicht es dem PMCCD, mit anderen Geräten in seiner unmittelbaren Umgebung drahtlos zu kommunizieren. Ein Beispiel einer Technologie, die dies ermöglicht, ist "Bluetooth Technology" von Bluetooth SIG. Natürlich können auch andere Technologien oder Implementierungen von Standards, die dies ermöglichen, eingesetzt werden.
24. External Serial and Parallel Interfaces Bus and Control Unit: über diese Schnittstelleneinheiten können Peripheriegeräte an das PMCCD verbunden werden, meistens direkt oder eventuell auch über ein Netzwerk, wobei diese Einheit dem PMCCD dazu verhilft, sich an das Gerät, z. B. ein Headset, ein Modem, usw., anzubinden.
25. Touch Screen Input Mechanism Unit: Diese Einheit ermöglicht es dem Benutzer des PMCCD, Eingaben in dem System vorzunehmen, allein durch berühren des Bildschirms durch ein Körperteil, vermutlich den Fingern, oder einem Stift, auf einem bestimmten Platz auf dem Bildschirm. Je nachdem, wo man angefaßt hat, wird eine andere Funktionalität getätigt. 27. Keys Input Mechanism Unit: Mit Hilfe einer Tastatur oder einer Menge von Tasten, kann der PMCCD-Benutzer auch seine Eingaben durchführen.
26. Speech Recognition Input Mechanism Unit: Auf diese Weise kann der PMCCD-Benutzer mit Sprachbefehlen Funktionen betätigen. Er kann auch irgendwelchen Text eingeben, und zwar dadurch, daß er ihn diktiert.
27. Main Memory Unit: Die lauffähigen Module benutzen diese Einheit, um von ihnen benötigte Informationen kurzfristig zu lagern. Diese Einheit wird auch von Modulen selbst benutzt, um sich lauffähig zu machen.
28. Central Processing Unit: Diese Einheit benötigen die Module, um überhaupt lauffähig zu sein. Die Lauffähigkeit der Module wird dadurch sichergestellt. Es kann aber auch sein, daß manche Module ihren eigenen Prozessor haben und diese Einheit nicht brauchen.
29. Speech Synthesis Output Mechanism Unit: Dadurch können dem PMCCD-Benutzer wichtige Informationen sprachlich mitgeteilt werden.
30. Persistent Memory Unit: Mit Hilfe dieser Einheit können auf dauerhafte Speicher bezogene Module verwirklicht werden.
31. Power Supply Unit: Das versorgt das ganze PMCCD mit dem benötigte Strom.
32. Display Output Mechanism Unit: Dadurch kann der PMCCD-Benutzer über das System Feedback bekommen und es so manipulieren.

Serviced Public Leisure and Entertainment Meeting Place's Location Server Unit

1. Server Boot Module: Dieses Modul ist das erste Modul, das von dem LSU- Betreuungsangestellten der SPLEMP-Betriebsmannschaft hinaufgefahren wird. Nach dem Hinauffahren ermöglicht es den LSU-Betreuungsangestellten, auf verschiedenen Funktionalitäten und Module der LSU zuzugreifen bzw. sie zu starten. Alle Laufzeitmodule werden im Kontext dieses Moduls ausgeführt. Es bietet dem LSU- Betreuungsangestellten auch eine Mensch-Machine-Schnittstelle an, wodurch er den Betrieb der LSU managen und steuern kann.
2. User Servicing Activation Module: Durch dieses Modul kann der LSU-Betreuungsangestellte dem System mitteilen, daß es sich vorbereiten soll, die Kundschaft zu bedienen. Dieses Modul übernimmt die Verantwortung, die Verbindung mit der RPMMSU aufzubauen und die anderen notwendigen Vorbereitungen bei sich einzuleiten. Dieses Modul ist auch dafür zuständig, die Bedienung einzustellen und die geladenen Module wieder zu terminieren. Dieses Modul arbeitet im Kont 78845 00070 552 001000280000000200012000285917873400040 0002010040948 00004 78726ext des Server Boot Module.
3. Service Quality Settings Module: Durch dieses Modul kann der LSU-Betreuungsangestellte angeben, welche Bedienungseinstellungen vorzunehmen sind. Die Einstellungen können sich darauf beziehen, wie viele Partnerschaftseignungstreffer jedem Benutzer maximal zustehen, welche Bedienungspreisklasse die dienstbenutzenden Kunden in Anspruch nehmen dürfen, wie viele Benutzer höchstens bedient werden dürfen, wie lange ein Benutzer längstens bedient werden darf, usw. Außerdem kann der LSU- Betreuungsangestellte dadurch auch noch die Öffnungszeiten angeben. Dieses Modul arbeitet mit dem SPLEMP Servicing Settings Configuration Support Module der RPMMSU zusammen.
4. System Behaviour Complaint Submission Module: Dieses Modul wird benutzt, um der RPMMSU Beschwerden über das Funktionieren des Systems mitzuteilen. Man kann aus verschiedenen Listen von Systemproblemen die zutreffenden Einträge auswählen. Dieses Modul benutzt den Long Distance Networking and Communications Unit, um die Informationen an die RPMMSU zu senden. Dieses Modul kommuniziert mit dem System Behaviour Complaint Submissions Reception Module der RPMMSU.
5. User Behaviour Complaint Submission Module: Es passiert manchmal, daß es dem SPLEMP- Betriebsmanagement zur Kenntnis gelangt, daß sich ein Kunde schlechtbenimmt. Das unverantwortliche Verhalten eines Kunden hat natürlich auch noch verschiedene Gradierungen. In so einem Fall kann der SPLEMP-Betreiber auch, wenn er vermutet, daß der Kunde ein Benutzer dieses Dienstes ist, versuchen, das Ortsanmeldungskennzeichen festzustellen, und unter dessen Benutzung bei der RPMMSU eine Beschwerde über den Benutzer einreichen. Allerdings kann es schwerfallen, das Ortsanmeldungskennzeichen festzustellen, da bei diesem Dienst versucht wird, die Identität eines Benutzers dem SPLEMP-Betriebsmanagement nicht preiszugeben. Dadurch hat das SPLEMP- Betriebsmanagement keinen Weg, etwas über den Benutzer zu erfahren. Es wird auch schwer herauszufinden sein, welchem Benutzer welches Ortsanmeldungskennzeichen zugeordnet ist. Eine Methode wäre, wenn das PMCCD des Benutzers ein Signal ausstrahlen würde, und es durch dieses Signal möglich wäre, das entsprechende Ortsanmeldungskennzeichen des Benutzers zu bestimmen. Das Signal würde das über Short Distance Wireless Networking and Communications Unit des PMCCD gesendet werden. Es wäre auch notwendig, ein gesendetes Signal einem Benutzer direkt zuzuordnen, da es möglicherweise sehr viele Benutzer in einem SPLEMP gibt und es ganz denkbar ist, daß ein bestimmtes Signal von jedem Benutzer hätte abstammen können. Deswegen muß das Signal nur in nächster Nähe des Benutzers spürbar sein. Solange das PMCCD des Benutzers eingeschaltet ist, könnte es ein Signal aussenden. Dieses Signal erfolgt auf einer niedrigen Amplitude. Der SPLEMP-Betriebsangestellte nähert sich dem Benutzer mit einem speziellen Gerät, und wenn er dem Benutzer ganz nah ist, kann er das Signal auffangen. Das Ortsanmeldungskennzeichen wird zusammen mit dem Verstoß an die RPMMSU übermittelt. Im Ausnahmenfall kann der SPLEMP-Betriebsangestellte einfach den Benutzer nach seiner Identifikation verlangen. In diesem Fall wird die persönliche Identifikation des Benutzers an die RPMMSU übermittelt. Das User Behaviour Complaint Submissions Reception Module der RPMMSU nimmt es entgegen.
6. User Location Registration Module: Mit Hilfe dieses Moduls wird die SPLEMP LSU einen Benutzer bei sich anmelden lassen können. Es ist zuständig für die Vergabe von Ortsanmeldungskennzeichen und weiteren entsprechenden Kennzeichen an den Benutzer. So lange der Benutzer bei diesem SPLEMP als angemeldet gilt, ist dieses Modul im Betrieb. Es ist auch das Modul, das die ganze Zeit über die Anmeldung eines Benutzers bei diesem SPLEMP betreut. Selbst läuft es im Kontext des Location Registrations Management Module.
7. Location Registrations Management Module: Dieses Modul managt die gesamte Benutzeranmeldung bei dem jeweiligen SPLEMP. Es kann aussagen darüber machen, wie viele Benutzer angemeldet sind und, soweit es anmeldungsbezogene Angaben angeht, welche Benutzer angemeldet sind. Es managt alle User Location Registration Modules, die in seinem Kontext laufen. Es ist auch zuständig für die Erstellung von User Location Registration Modules.
8. Premises Listeners Management Module: Dieses Modul managt sämtliche Abhöreinheiten auf dem Gelände. Das schließt alle Check-In Confirmation Short Distance Wireless Listener and Signalling Units, Check-Out Confirmation Short Distance Wireless Listener and Signalling Units, und On- Premises Stay Check Short Distance Wireless Listener and Signalling Units ein. Mit Hilfe dieses Moduls kann der LSU-Betreuungsangestellte die Abhöreinheiten ein- und ausschalten, ihre Ausstrahlreichweite variieren, steuern, welche Signale sie auszusenden haben (z. B. Örtlichkeitskennzeichen), sie in das Abhörnetz aufnehmen oder ausstoßen, usw. Es ist auch zuständig für die Weitergabe einer Laufzeitbestätigung eines Benutzers an das User Stay Monitoring Module, nachdem es die Informationen in das richtige Format konvertiert hat. 9. System to SPLEMP Messaging Support Module: Dieses Modul unterstützt den Empfang von Mitteilungen an das SPLEMP-Betriebsmanagement bzw. LSU-Betreuungsangestellte bzw. LSU selbst. Es verwirklicht diese Benachrichtigungsfunktion in Kooperation mit dem System to SPLEMP Messaging Support Module der RPMMSU. Es leitet die Nachrichten weiter an die jeweiligen Module oder an Nachrichtsysteme des SPLEMPs.
9. User Stay Monitoring Module: Dieses Modul läuft im Kontext des User Location Registration Module. Es ist zuständig für die Aufenthaltsüberwachung des Benutzers. Der Aufenthaltsstatus des Benutzers wird mit Hilfe dieses Moduls festgestellt. Es sammelt Informationen darüber, ob der Benutzer verfügbar, nicht verfügbar, aktiv, inaktiv, eingecheckt, ausgecheckt, usw. ist. Es verarbeitet Informationen, welche es vom Premises Listeners Management Module bekommt und integriert sie mit Zeitinformationen.
10. Premises User Stay Information Forwarding Module: Dieses Modul wird von dem User Stay Monitoring Module benutzt. Es leitet den Aufenthaltszustand des Benutzers weiter an die RPMMSU. Es teilt der RPMMSU mit, ob der Benutzer anhand seines Aufenthaltsstatus bedient werden soll oder nicht. Dafür kooperiert es mit dem User Location Tracking Module der RPMMSU. Es arbeitet im Kontext des User Location Registration Module.
11. Server Testing Module: Dieser Modul dient nur zu Testzwecken. Wenn die LSU bei einem SPLEMP installiert wird, dann hilft dieses Modul sicherzustellen, daß das ganze LSU- System einwandfrei arbeitet. Das schließt sowohl alle internen Systeme als auch die Kommunikation und die Kooperation mit externen Systemen, wie einem Test-PMCCD und dem zuständigen LSU Testing Module bei der RPMMSU. Es wird auch während der Wartungsphase des LSU benutzt. Wenn Störungen anzumelden sind, hilft dieses Modul zunächst, sie zu erfassen und eventuell auch sie zu beheben. Es läßt sich von der LSU selbst steuern, aber auch von der RPMMSU bzw. einem anderen Wartungsbetreuer fernsteuern. Es kann auch diagnostische Berichte erstellen.
12. Authentication Module: Dieses Modul ist für die externe Sicherheit der LSU zuständig. Immer wenn die LSU eine Verbindung zu der RPMMSU aufbauen will, schaltet sich dieses Modul ein, um den SPLEMP bzw. auch noch die LSU zu beglaubigen. Es stellt auch sicher, daß am anderen Ende wirklich die bestimmte RPMMSU ist und nicht eine andere Instanz. Es stellt die Integrität der Kommunikation mit der RPMMSU sicher. Auch während dem Testen der LSU kümmert es sich darum, die Identität der RPMMSU festzustellen, da in dieser Phase eventuell Zugang zu inneren Modulen der LSU verschafft wird.
13. Location Registration Information Exchange Short Distance Wireless Listener and Signalling Units: Diese Einheiten ermöglichen es der LSU, mit dem Benutzer Ortsanmeldungsinformationen physikalisch auszutauschen. Ein Exemplar dieser Einheiten kann als eine Subeinheit des Geräts am Eingang des SPLEMPs zu finden sein, oder die SPLEMP-Kundenbetreuung könnte so etwas mit sich tragen, oder es könnte sogar sonstwo auf dem Gelände des SPLEMPs plaziert sein. Mit der Hilfe dieser Einheit könnten Ortsanmeldungskennzeichen und andere relevante Informationen an den Benutzer übermittelt werden. Es wird meistens von dem User Location Registration Module beansprucht. Es sendet ein elektromagnetisches Signal aus, das sich nur über eine Reichweite von wenigen Zentimetern ausweiten kann. Über eine Signalverbindung zu dem PMCCD des Benutzers wird zunächst ein Netzwerkprotokoll aufgesetzt, was wiederum den Austausch von Informationen in einer Art ermöglicht, die beide Systeme, diese Einheit und das PMCCD, verstehen können.
14. Check-In Confirmation Short Distance Wireless Listener and Signalling Units: Diese Einheiten befinden sich an den Eingängen. Sie senden ständig Check-In-Scope-Signale. Damit teilen sie den Zuhörern mit, daß sie sich in einem Bereich stattfinden, wo sie kurz davor sind, das Gelände des SPLEMPs zu betreten. Eventuell sieht man es als notwendig an, die Bewegung des Benutzers zu verfolgen. Nur wenn der Benutzer sich in die Richtung des Geländes bewegt, würde man die Bewegung auch als einen Eingang interpretieren. Um diese Bewegung zu verfolgen und zu merken, könnte man mehrerer solcher Einheiten in jedem Eingangsflur installieren, wobei die Untereinheiten dieses Einheitensatzes sich gut miteinander koordinieren. Wenn der Benutzer mit seinem PMCCD das Gelände verlässt, baut sein PMCCD eine Verbindung zu diesen Untereinheiten bzw. Einheiten auf und teilt sein Ortsanmeldungskennzeichen mit. Damit weiß die LSU, welcher Benutzer das Gelände verläßt. Die Angaben werden an das User Stay Monitoring Module weitergeleitet. Auch dem PMCCD des Benutzers wird mitgeteilt, daß der Benutzer ab jetzt als eingecheckt gilt. Die Signale werden zwischen diesem Modul und dem PMCCD drahtlos ausgetauscht. Der Austausch wird über drahtlose Netzwerkprotokolle abgewickelt. Die Reichweite des Signals wird auf wenige Meter beschränkt. Alle diese Einheiten werden vom Premises Listeners Management Module gemanagt. Eine mögliche Lösung wäre realisierbar durch die Benutzung der Bluetooth Technologie, oder etwas ähnlichem.
15. Check-Out Confirmation Short Distance Wireless Listener and Signalling Units: Diese Einheiten sind ähnlich zu den oben genannten Einheiten, wobei die Unterschied darin liegt, daß hier überprüft wird, ob der Benutzer das Gelände verläßt. Diese Einheiten werden zu Einheitensätzen zusammengefaßt. Jeder Satz befindet sich an einem Ausgang. Die Untereinheiten jedes Satzes kooperieren unter sich und verfolgen die Bewegung des Benutzers über sein PMCCD. Diese Untereinheiten senden ein Signal, das Check-Out Scope Signal heißt. Wenn das PMCCD des Benutzers dieses Signal hört, sendet es auch ein Signal. Dieses Signal wird aufgefangen von den Untereinheiten und bewertet, ob über das Signal, z. B. seine Stärke oder die Reihenfolge der Änderung der Stärke des Signals, wie von verschiedenen Untereinheiten aufgefangen, offenbart wird, ob das PMCCD des Benutzers sich von dem Gelände hinaus bewegt. Am Ende wird noch ein Signal an das PMCCD des Benutzers gesendet, wodurch dem PMCCD mitgeteilt wird, daß die LSU sein Auschecken jetzt vornimmt. Die Angaben werden weiter an das User Stay Monitoring Module weitergeleitet. Die Signale werden zwischen diesen Modulen und dem PMCCD drahtlos getauscht. Der Austausch wird über drahtlose Netzwerkprotokolle abgewickelt. Die Reichweite des Signals wird auf wenige Meter beschränkt. Alle diese Einheiten werden vom Premises Listeners Management Module gemanagt. Eine mögliche Lösung wäre realisierbar durch die Benutzung der Bluetooth Technologie, oder etwas ähnlichem.
16. On-Premises Stay Check Short Distance Wireless Listener and Signalling Units: Diese Einheiten befinden sich verstreut über dem gesamten Gelände des SPLEMPs. Sie senden einfach On-Premises-Scope-Signale aus. Nach einer bestimmten Zeit soll das PMCCD des Benutzers sich mit einem Aufenthaltsbestätigungssignal melden, das so viel sagt wie, "ich, Benutzer. . . ., bin da". Dies muß das PMCCD des Benutzers innerhalb regelmäßiger Intervalle tun, ansonsten wird der Benutzer als nicht verfügbar erklärt, und der Partnerschaftssuchdienst wird aufhören, den Benutzer zu bedienen. Dazu soll das PMCCD immer betriebsfähig und in Betrieb sein. Natürlich kann sich das PMCCD auch später wieder zurückmelden, und dann wird der Benutzer wieder als verfügbar eingestuft, und die Bedienung des Benutzers wird wieder aufgenommen. Diese ganze Verwaltung bleibt die Aufgabe des User Stay Monitoring Module. Diese Einheiten hat nur als Aufgabe, die Aufenthaltsbestätigungssignale des Benutzers zu empfangen und an das User Stay Monitoring Module weiterzuleiten. Diese Einheiten werden so zerstreut sein, daß überall auf dem Gelände des Benutzers, mit wenigen Ausnahmen wie den Toiletten, das Signal von dem Benutzer empfangen werden kann. Allerdings muß auch darauf geachtet werden, daß von außerhalb des Geländes des SPLEMPs keiner sein Signal erfolgreich diesen Einheiten zukommen lassen kann. Das kann zum Teil dadurch gesichert werden, indem eine entsprechende Information in dem On-Premises Scope Signals enthalten ist. Nur jemand, der die On-Premises-Scope-Signals auch empfangen kann, kann auch darauf erfolgreich antworten. Alle diese Einheiten werden vom Premises Lisreners Management Module gemanagt. Eine mögliche Lösung wäre realisierbar durch die Benutzung der Bluetooth Technologie, oder etwas ähnlichem.
17. Long Distance Networking and Communications Unit: Diese Einheit ist zuständig für Aufbau und Erhalt von Verbindungen über große Entfernungen. Für solche Verbindungen werden Netzwerkprotokolle eingesetzt. Die gesamte Kommunikation zu dem RPMMSU wird durch diese Einheit ermöglicht. Höchst wahrscheinlich werden die Kommunikationsverbindungen über ein Kabelnetzwerk gemacht. Es kann aber auch drahtlos verwirklicht werden.
18. Touch Screen Input Mechanism Unit: Diese Einheit ermöglicht es den LSU- Betreuungsangestellten, Eingaben in dem System vorzunehmen, allein durch Anfassen des Bildschirms durch ein Körperteil, vermutlich den Fingern, oder einem Stift, auf einem bestimmten Platz auf dem Bildschirm. Je nachdem, wo man angefaßt hat, wird eine andere Funktionalität betätigt.
19. Keys Input Mechanism Unit: Mit Hilfe von einer Tastatur oder einer Menge von Tasten kann der LSU Betreuungsangestellte ebenfalls seine Eingaben durchführen.
20. Speech Recognition Input Mechanism Unit: Damit kann der LSU Betreuungsangestellte mittels Sprachbefehlen die Funktionen betätigen. Er kann auch irgendwelche Text eingeben, und zwar dadurch, daß er sie diktiert.
21. Main Memory Unit: Die lauffähigen Module benutzen diese Einheit, um von ihnen benötigte Informationen kurzfristig zu speichern. Diese Einheit wird auch von Modulen selbst benutzt, um sich lauffähig zu machen.
22. Central Processing Unit: Diese Einheit benötigen die Module, um überhaupt lauffähig zu sein. Die Lauffähigkeit der Module wird dadurch sichergestellt. Es kann sein, daß manche Module ihren eigenen Prozessor haben und diese Einheit nicht brauchen.
23. Speech Synthesis Output Mechanism Unit: Damit können dem LSU-Betreuungsangestellten wichtige Informationen sprachlich mitgeteilt werden.
24. External Serial and Parallel Interfaces Bus and Control Unit: Über diese Schnittstelleneinheiten können Peripheriegeräte mit der LSU verbunden werden, entweder direkt oder über ein Netzwerk, wobei diese Einheit der LSU dazu verhilft, sich an das Netzwerk, z. B. ein Intranet, oder einen Drucker, usw., anzubinden.
25. Persistent Memory Unit: Mit Hilfe von dieser Einheit können alle dauerhafte Speicher betreffende Module verwirklicht werden.
26. Power Supply Unit: Dies versorgt das ganze PMCCD mit dem benötigten Strom.
27. Display Output Mechanism Unit: Dadurch kann der PMCCD-Benutzer über das System Feedback bekommen und es so manipulieren.

System-Dienst Zweiteilung

Oft wird hier von Dienst und System gesprochen. Es ist notwendig die beide Begriffe auseinanderzuhalten.

1. Dieses System ermöglicht den Partnerschaftseignungssuch-, -überprüfungs- und -vermittlungs-Dienst. In diesem Fall wird über die Architektur des Abstrakten Systems gesprochen, welches, sobald es implementiert ist, den Dienst ermöglichen wird. Viele Aspekte dieses Systems sind Kernaspekte, einige sind Optimierungsaspekte, und noch andere sind Erweiterungsaspekte. Dadurch wird klar, welche möglichen Kombinationen von Aspekten denkbar sind, und jede Kombination entspricht eine oder mehrere konzipierbare Varianten des Dienstes. Auf diese ideellen Ebene darf das System alle Aspekte umfassen oder es kann einfach als eine Aspektkombination verstanden werden. 2. Ein angebotener Dienst verwendet ein implementiertes System. Hier wird nur auf ein System verwiesen. Es ist eine bestimmte Art von System, aus einer Reihe von Systemen, die sich durch die verschiedenen Funktionalitäten und Optionen, welche tatsächlich in ihnen vorhanden sind, unterscheiden. Jedes implementierte System läßt sich zurückführen zu einer Kombination, welche oben als konzipierbar erklärt wurde. Wenn von einem Dienst gesprochen wird, wird gleichzeitig auch das dazugehörige System impliziert, was wiederum auf oben erwähntes System verweist.
2. Einem laufenden Dienst liegt ein laufendes System zugrunde. Dieses System ist die laufende Version von dem System, was oben als implementiertes System erwähnt wurde. So ein System hat einen internen Zustand, was sich von Zeit zu Zeit unterscheidet.
3. Die oben erwähnten drei Punkte weisen auf ein künstliches System. Für die Verwirklichung des Dienstes werden viele Menschen auch eine Rolle spielen. Diese Rollen sind mit Verantwortungen, Aufgaben, Rechten, Beziehungen, Besitztümern, usw. verbunden. Werden diesen Rollen einbezogen, erfaßt das Ganze nicht nur das künstliche System, sondern auch den menschlichen Anteil. Hier wird also das System als ganzes, aber noch abstrakt verstanden. Es nimmt auch einen organisatorische Bedeutung an.
4. Wenn die oben erwähnten Rollen besetzt sind, dann wird das System wieder im gleichen Sinn wie in Punkt 2 verstanden, aber mit dem menschlichen Teil eingeschlossen.
5. Wenn die besetzten Rollen gerade mit dem laufenden System auch noch interagieren, dann wird das System im Sinne wie in Punkt 3 verstanden, nur mit einem zusätzlichen organisatorisch-menschlichen Anteil eingeschlossen.

An verschiedenen Orten in dieser Aufführung wird System anders gemeint, und muß je nach Kontext verstanden werden.

Dienstanforderungskategorien

Ausgehend vom Dienst existieren verschiedene Aspekte, die überlegt werden müssen. Beschränkend auf den künstlichen Teil des Systems, werden die Kernanforderungen des Dienstes durch die Kernaspekte des Systems, die optimierenden Aspekte des Dienstes durch optimierende Aspekte des Systems und die erweiterbaren bzw. optionalen Aspekte des Dienstes durch erweiterbare Aspekte des Systems realisiert.

Kernanforderungen

Die Kernanforderung des Dienstes sind einfach, daß wenn zwei Leute sich in einem SPLEMP befinden, beide diesen Dienst in Anspruch nehmen, und die Beiden zueinander passen, dann sollte das System ihnen Bescheid sagen, daß die beiden zu einander passen, und sie einander vorstellen.

Optimierende Anforderungen

Diese Anforderungen sind dafür gedacht, das die häufigen Ausnahmefälle schon einbezogen sind, und daß sie einen minimalen Störungsfaktor für den Dienst darstellen. Das System soll nicht zwei Leute vermitteln, von denen einer oder sogar beide sich gar nicht in dem SPLEMP befanden, oder daß keine Vermittlung vorgenommen wird, wenn einer von ihnen oder sogar beide den SPLEMP verlassen. Der Dienst soll auch nicht Leute vermitteln, die bereits vermittelt wurden und die bezüglich ihrer gegenseitigen Eignung einer anderen Meinung waren. Der Dienst soll darauf aufpassen, daß der Benutzer seine Angaben richtig eingegeben hat, weil nur so die richtigen Leute vermittelt werden können.

Erweiterte Anforderungen

Diese Anforderungen sind im Grunde genommen eine Erweiterung der optimierenden Anforderungen. Hier geht man aber über die Grenzen der Kernanforderungen hinaus. Diese Anforderungen dienen also nicht dazu, die Kernanforderungen zu optimieren, sondern um den gesamten Dienst zu verbessern. Ohne diese Anforderungen würde das System auch noch funktionieren. Hier geht es um Punkte wie etwa, daß der Benutzer oder SPLEMP-Betreiber selbst wählen kann, in welcher Form ihnen der Dienst am besten gefallen würde, daß der Benutzer daran erinnert werden kann, welche anderen Leute ihm in der Vergangenheit vermittelt wurden, daß nur Leute vermittelt werden, die in der Vergangenheit ein gutes Benehmen vorgezeigt hatten, daß der Benutzer den Dienst, falls ihm etwas zustößt, wissen lassen kann, wo er hinzugehen beabsichtigte, damit der Dienst irgendwie Hilfe leisten kann, daß auf die Anonymität der Nutzer geachtet wird, daß der Dienst den Benutzer nicht in Gefahr bringt durch Vermittlung eines womöglich gefährlichen Partners, daß es für den Benutzer einen Ansporn gibt, nicht zu lügen und sich richtig zu benehmen, usw.

Systemumfangsumrisse

Manche Systemkomponenten sind wichtiger als andere. Manche sind relevant für das System, anderen wiederum nicht. Genauso wie bei Dienstanforderungskategorien, unterteilt man diese Kategorien auch ähnlich.

Kernfunktionalitäten

Diese Komponenten sind für die Verwirklichung des Systems äußerst wichtig. Sie sind auch zuständig für die Kernanforderungen des Dienstes. Sie sind für die folgenden Funktionalitäten zuständig:

1. Benutzer-Registrierung
2. Benutzerprofil-Verwaltung
3. Diensteinleitung
4. Ortsanmeldung
5. Interaktive-Tätigkeitsabsichten-Definition
6. Dienstaktivierung
7. Partnerschaftseignungsüberprüfung
8. Bekanntmachungssitzung
9. Dialog

Aufbauende Funktionalitäten

Diese Funktionalitäten bauen das System eher vertikal auf. Eine der Kernbedingungen dafür, daß das System funktioniert, ist, daß die beiden Benutzer, die eventuell aneinander vermittelt werden, sich an dem gleichen Ort aufhalten. Die Erfüllung dieser Bedingung wird mit Hilfe verschiedener Funktionalitäten sichergestellt. Die Ortsanmeldungs-Funktionalität ist schon oben erwähnt worden. Die anderen Funktionalitäten, die hier erwähnt werden, sind weitere Entwicklungen davon.

Anmeldungsorts-Anwesenheits-Sicherstellung

Das verbessert das Funktionieren des Systems, da man so weiß, daß der Benutzer sich wirklich an diesem Ort aufhält. Nur so könnte ein Partnerschaftsvermittlungssystem mit Sicherheit einen Benutzer dem Anderen vermitteln. Im anderen Fall würden dem Benutzer Partnerschaftskandidaten vermittelt, die gar nicht da sind. Die Ortsanmeldung wird in dieser Funktionalität eingeschlossen. Diese Funktionalität wurde oben in "Lösungsarchitektur"/ "Haupt-Dienstprozesse, Funktionalitäten und Lösungsstrategien"/"Ortsfeststellung" erläutert.

Benutzerbehauptung der eigenen Aufenthaltsfortführung am Anmeldungsort

Diese Funktionalität verbessert das System, so daß ein Benutzer nur dann bedient werden muß, wenn er auch da ist, und zweitens läßt er sich auch nicht fälschlicherweise an andere vermitteln, da er dabei auch noch an das Wohl Anderer denkt. Diese Funktionalität wurde oben in "Lösungsarchitektur"/"Haupt-Dienstprozesse, Funktionalitäten und Lösungsstrategien"/"Überwachung der Aufenthaltsfortführung am Anmeldungsort"/ "Benutzerbehauptung der Aufenthaltsfortführung am Anmeldungsort" erläutert.

Sicherstellung der Aufenthaltsfortführung des Benutzers am Anmeldungsort

Bei dieser Funktionalität, wird nicht von dem optimalsten Verhalten des Benutzers ausgegangen, sondern das System nimmt selbst alles in die Hand und stellt sicher, daß der Benutzer sich wirklich noch an diesen Ort aufhält. Die Benutzerbehauptung wird in dieser Funktionalität eingeschlossen. Diese Funktionalität wurde oben in "Lösungsarchitektur"/ "Haupt-Dienstprozesse, Funktionalitäten und Lösungsstrategien"/"Überwachung der Aufenthaltsfortführung am Anmeldungsort"/"Sicherstellung der Aufenthaltsfortführung am Anmeldungsort" erläutert.

Optimierende Funktionalitäten

Diese Funktionalitäten beschränken die Wahrscheinlichkeit, daß die Voraussetzungen bei den Kernfunktionalitäten in Wirklichkeit nicht erfüllt werden. Sie dienen als Unterstützung für die Realisierung der Kernfunktionalitäten. Dadurch wird das System wohlgeformter.

Benutzer-Feedback

Dadurch wird ein Aspekt des Systems zum Teil behandelt, der das System ohne diese Funktionalität zu einem anfälligen System machen würde. Es fehlt Vertrauen in die Angaben des Benutzers bezüglich seines Profils. Mehr zu dieser Funktionalität wird oben in "Lösungsarchitektur"/"Haupt-Dienstprozesse, Funktionalitäten und Lösungsstrategien"/ "Kritischer Feedback" erklärt.

Erweiternde Funktionalitäten

Diese Funktionalitäten sind nicht für die Realisierung des Dienstes kritisch. Die folgenden Funktionalitäten gehören dazu:

1. Benutzer-Bedienungseinstellungen
2. Benutzer-Gedächtnisunterstützung
3. Benutzer-Sicherheit

Benutzer-Bedienungseinstellungen

Es kann mehrere Dienstparameter geben, welche der Benutzer beeinflussen können möchte. Einige Beispiele sind die folgenden:

Ein Benutzer kann spezifizieren, wie anspruchsvoll er/sie sein möchte. Je anspruchsvoller ein Benutzer ist, desto schwieriger ist es, einen geeigneten Partnerschaftskandidaten für ihn/sie zu finden, es nimmt mehr Zeit in Anspruch, und vielleicht findet sich überhaupt gar kein Partner in dem entsprechenden SPLEMP, der so gut zu dem Benutzer passen würde.

Es könnte noch andere Parameter geben, die in den Umfang der bisher erwähnten Parameter fallen. Es könnten noch weitere existieren, die überhaupt nicht unter die oben genannten Kategorien fallen, aber trotzdem in diesen Verfahrenschritt oder Funktionalität eingestuft werden könnten.

Benutzer-Gedächtnisunterstützung

1. Typ des Bekanntmachungsmittels
2. Bekanntmachungsagent
3. Bekanntschaftsschließungsereignis.
4. Bekanntschaftsschließungsort.
5. Bekanntschaftsschließungszeit.
6. Alias des vermittelten Partnerschaftskandidaten.
7. Foto des vermittelten Partnerschaftskandidaten.
8. Beschreibung des vermittelten Partnerschaftskandidaten in eigenen Worten.
9. Umstände des Treffens in eigenen Worten.
10. Qualität des Erlebnisses in eigenen Worten.
11. Gegenseitige Entscheidung zum Ende des Treffens darüber, wie man vorgehen möchte bei der Erforschung der Möglichkeit, sich mit der zum Ziel gesetzten interaktiven Tätigkeit zu befassen.
12. Positive Attribute des vermittelten Partnerschaftskandidaten, welche zu einem Treffer verholfen haben und während der Bekanntmachungssitzung vorgestellt wurden.
13. Negative Attribute des vermittelten Partnerschaftskandidaten, die während der Bekanntmachungssitzung als Warnungen vorgelegt wurden.
14. Die Bestrebungen und Erwartungen des vermittelten Partnerschaftskandidaten an den anderen Partnerschaftskandidaten (in diesem Fall den Benutzer), wie sie in der Bekanntmachungssitzung vorgelegt wurden.
15. Eigene positive Attribute, die zu einem Treffer verholfen haben, und während der Bekanntmachungssitzung offenbart wurden.
16. Eigener Alias, der dem vermittelten Partnerschaftskandidaten vorgeführt wurde.
17. Kritik-Feedback, welche der RPMMSU bereitgestellt wurde.
18. Tagebucheinträge, die sich auf den gleichen vermittelten Partnerschaftskandidaten beziehen, und nach der Zeit des Eintrags angeordnet sind, wobei es sich um die Entwicklung der Beziehung und der Meinung über den anderen handelt.

Benutzer-Sicherheit

Zur Benutzersicherheit können sehr viele Mechanismen ausgedacht werden. Die meisten von ihnen haben eine gesellschaftliche Komponente und sind stark von den herrschenden Gesellschaftsnormen und -strukturen abhängig. Die künstlichen Mechanismen, die bereitgestellt werden, sind auch nur einsatzfähig, wenn einige gesellschaftliche Voraussetzungen erfüllt sind, oder wenn bestimmte Vorgehensweisen akzeptiert sind, und auch nur in einer unterstützenden Rolle. Die folgenden Maßnahmen sind vorstellbar:

1. Verhaltenskodex-Vertrag: Wenn der Benutzer sich für diesen Dienst registriert, muß er einen Verhaltenskodex-Vertrag lesen und unterschreiben, bzw. einfach akzeptieren. Mit diesem Verhaltenskodex versichert er, daß er die Regelungen befolgen wird, nichts tun wird, was verboten ist, die Verhaltensweisen, die als nicht empfohlen erklärt sind, zu vermeiden versuchen wird, usw. Hier wird der Benutzer sich auch für einverstanden erklären, daß, wenn die Polizei eine Ermittlung gegen ihn vornimmt, seine Angaben den Behörden - mit großer Zurückhaltung - überreicht werden dürfen. Er wird dem Dienst auch die Genehmigung erteilen, seine Identität und Personalien von seiner Identitätsbürgungsinstanz abzufragen.
2. Verhaltens- und Benutzungsanweisungen: Dies betrifft eher den Umgang mit System und Dienst. Anders als oben, wo eher Verbote aufgeführt sind, werden hier Empfehlungen und Tips erklärt. Der Benutzer dürfte durch die Haltung an diese Empfehlungen den Dienst und das System am optimalsten benutzen können.
3. Kritischer Feedback: Falls der Benutzer merkt, daß der vermittelte Partnerschaftskandidat nicht auf den Verhaltenskodex oder die Verhaltens- und Benutzungsanweisungen achtet, oder auch sonst ein schlechtes Benehmen vorweist, dann kann der Benutzer ein kritisches Schreiben an den Dienst schicken. Auch wenn der Benutzer der Meinung ist, daß der vermittelte Partnerschaftskandidat mit seinen Angaben geschummelt hat, um seine Chancen, einen Partnerschaftseignungstreffer zu erzielen, zu verbessern, kann der Benutzer dem Dienst dies mitteilen. Das hilft deshalb, daß im Falle, daß die Beschwerden gegen einen Benutzer an Glaubwürdigkeit gewinnen, der Benutzer irgendwie bestraft werden kann.
4. Sicherheitsüberprüfung: In dem Dienstnutzungsvertrag wird der Benutzer auch die Genehmigung erteilen, nach seiner Strafakte und anderen Personalien bei den Behörden oder anderen Instanzen nachschlagen oder abfragen zu dürfen. Wenn der Verdacht bestünde, daß der Benutzer eine Gefahr für andere Benutzer darstellen könnte, dann würde bei den Behörden auch nachgeforscht. Es kann sogar eine gewisse Automatisierung dabei geben. Wenn sich aus der Sicherheitsüberprüfung ergibt, daß der Benutzer ein Risiko ist, dann könnten verschiedene Maßnahmen getroffen werden, je nachdem, welche Gesetz- und Gesellschaftsnormenverstöße er aufzuweisen hat. Dies kann alles, zwischen Bedienungsverweigerung, komplettem Ausscheiden, bis zur Behördenmitteilung nach sich ziehen.
5. Identitätsbestätigungsüberprüfung: Der Benutzer wird in seinem Benutzungsantrag dem Dienst auch die Genehmigung erteilen, seine Identität und Personalien von seiner Identitätsbürgungsinstanz bestätigen zu lassen. Dafür gibt er an welche Identitätsbürgungsinstanz dies machen würde, seine Personalien, und eine eventuell digital unterschriebene Genehmigung.
6. Anonymität: Anonymität ist eine der wichtigsten Leistungen des Dienstes. Die Leute wollen selbst die Kontrolle haben zu entscheiden, wem sie von sich erzählen wollen und wem nicht. Es ist auch so, daß kein vermittelter Partnerschaftskandidat aus irgendeinem Grund anfangen soll, den Benutzer zu verfolgen oder zu belästigen. Deswegen werden während des gesamten Prozesses keine identitätsbezogenen Angaben oder sonstige Angaben vermittelt, wodurch der vermittelte Partnerschaftskandidat an den Benutzer nachträglich herankommen könnte.
7. Rechenschaftspflichtigkeit: Sollte ein vermittelter Partnerschaftskandidat den Benutzer irgendwie schlecht behandeln oder ihm Schaden zufügen, dann kann durch Benutzer- Feedback-Beschwerden, polizeiliche Anzeigen, oder Aufzeichnungen über gemeinsam unternommene Tätigkeiten zunächst ermittelt werden, wer die Person war, die als vermittelter Partnerschaftskandidat an den Benutzer vermittelt wurde, und außerdem kann festgestellt werden, für was sich diese Person schuldverdächtig gemacht hat. Dann kann entschieden werden, welche Maßnahmen getroffen werden können, entweder auf den Dienst bezogen oder zur Unterstützung bei polizeilichen Ermittlungen.
8. Steuerbare Kontaktierbarkeit: Wenn zwei vermittelte Benutzer nach ihren Gesprächen entscheiden, daß sie doch weiter in Kontakt bleiben wollen, aber noch nicht so weit sind, daß sie einander vertrauen, oder die Regeln der Anonymität einhalten wollen, oder die Natur ihrer Vorhaben Anonymität empfehlenswert macht, dann können sie sich auch für Kontaktiermöglichkeiten entscheiden, bei denen sie nicht ihre persönlichen Kontaktadressen herausgeben müssen, sondern sie können einfach die Kennzeichnung eines vorvermittelten Partners aufrufen, und die RPMMSU damit beauftragen, eine asynchrone bzw. synchrone Verbindung zwischen den beiden herzustellen.
9. Interaktive-Koaktivitäts-und-Komobilitäts-Überwachungs-Funktionalität: Dies ähnelt dem Fall, daß man ausgeht und die Eltern wissen läßt, mit wem man unterwegs sein würde und wo genau man hingeht, so daß einerseits die Eltern sich keine Sorgen machen müssen und man zweitens, sollte einem etwas zustoßen, es leichter festgestellt werden könnte, wo das Kind sich befindet, usw. Natürlich möchte man aus Gründen der Privatsphäre dem Bekannten nicht unbedingt Bescheid sagen, was man tut und mit wem man es tut. Diese Sicherheit basiert auf den Informationen, die der Benutzer einfach der RPMMSU zukommen läßt bezüglich der Benutzerbewegung, dem Verbleib, der Begleitung, den Absichten, den Vorschlägen und Angeboten des Begleiters bzw. den eigenen, usw. Im Falle von Schaden oder Festnahme, usw. des Benutzers, könnten die Behörden den Verlauf zurückverfolgen und den Benutzer ausfindig machen. Diese Information wird auch von dem Benutzer bereitgestellt, um die begleitende Person, die nicht vertrauenswürdig oder fremd ist, wissen zu lassen, daß er nicht unbestraft davonkommen könnte, sollte er dem Benutzer irgendwelchen Schaden zufügen. Diese Information hier wird nicht weiter benötigt, sobald sich der Benutzer erneut bei dem Dienst gemeldet hat und einige Wochen vergangen sind, da man in diesem Fall davon ausgehen kann, daß das Treffen ohne Zwischenfälle verlaufen ist. Die Informationen sollen insgesamt nur für eine maximale Dauer von wenige Wochen behalten werden.
10. Notruf-Weiterleitung: Dies kann hilfreich sein, da im Falle daß der Benutzer einen Notruf aussendet und um Hilfe wegen irgendwelcher ernsthaften Probleme bittet, dann sehr viele zusätzliche Informationen über den Benutzer, über seinen Verbleib, über die eventuelle bedrohliche Begleitung des Benutzers, und sogar die Art des Problems erfaßt werden können und an die Behörden weitergeleitet werden können. Da der Dienst einfach mehr Informationen über den Benutzer hat und eventuell über das, was er gerade macht, ist es ihm möglich, nützliche Hilfe anbieten zu können. Darüber hinaus könnten weitere Informationen über das Aussehen des Benutzers, sein Foto, Erklärung der Umstände, usw. den Sicherheitsdiensten zur Verfügung gestellt werden.
11. Kooperation mit der Polizei: Sollte die Polizei gerade eine Ermittlung machen gegen einen Benutzer, dann kann der Dienst eventuell durch Bereitstellung von Informationen behilflich sein. Hier muß darauf geachtet werden, welche Informationen bereitgestellt werden dürfen und welche die Privatsphäre des Benutzers verletzen könnten. Im Falle von bloßem Verdacht oder Befragung wird die Hilfe nur angeboten, wenn die Behörden zusagen, daß sie sehr feinfühlig damit umgehen würden. Die angebotene Hilfe ist auch abhängig davon, ob die Beschwerde an die Polizei von einem anderen Benutzer eingereicht wurde oder nicht.
12. Privatsphäre: Der Benutzer kann all seinen Angaben eine Stufe der Privatsphäre zuordnen und auch angeben, für welche Zielgruppen welche Stufe gilt. Empfindliche Angaben werden dann dieser Zielgruppe nicht preisgegeben. Auch bei Ermittlungen wird Diskretion gewahrt.
13. Beratung: Der Benutzer kann sich eventuell von jemandem von dem Dienst beraten lassen, was Gesprächsverhalten angeht oder wie man mit einem sehr ungezogenen Verhalten eines vermittelten Partnerschaftskandidaten umgeht, oder wie man sich beschweren soll, und über viele anderen Themen bezüglich Gesellschaftsumgang, Sicherheit, Beschweren, Dienstnutzung, usw. 14. Vertrauenswürdiger Partnerschaftseignungsüberprüfungs-Algorithmus: Das ist wichtig, weil es möglich ist, daß Informationen in anderen zur Partnerschaftseignungsüberprüfungs und Partnervermittlung benutzten Algorithmen auf verschieden Weisen benutzt werden können. An diese Algorithmen werden sehr persönliche Informationen bereitgestellt und wenn man nicht genau weiß, was diese Algorithmen damit machen, dann könnte ein Sicherheitsrisiko entstehen. In dem Fall der RPMMSU ist das fast ausgeschlossen. Dieser Algorithmus ist in der Obhut des RPMMSU-Betreibers und damit gibt es nur eine Instanz, die für die Sicherheit und die richtige Benutzung zuständig ist.
14. Vertraulichkeit erfordernde Benutzer-Angaben bei bestimmten SPLEMP-Typen: Es gibt verschiedene SPLEMPs in einer Nachbarschaft oder Stadt. Jeder SPLEMP hat eine andere Kundschaft. Die Kundschaft eines bestimmten SPLEMPs könnte einer bestimmten Kategorie von Benutzern aus Gründen der Ethnizität, Religion, politischen Meinungen, Geschlecht, sexueller Orientierung, Verbandsmitgliedschaft, usw. nicht so wohlgesonnen sein. Sollte ein Benutzer solche Eigenschaften haben, was aus ihm einen unwillkommenen Besucher bei diesem SPLEMP machen würde, wäre es nicht so klug, jedem Beliebigen Zugang zu den Eigenschaften des Besuchers zu ermöglichen. Diese Attribute sind als Vertraulichkeit erfordernd für den bestimmten SPLEMP zu verstehen. Als eine vorgegebene Regel sollten diese Attribute in diesem SPLEMP nicht für Partnerschaftseignungsüberprüfungen benutzt werden. Der Benutzer soll über diese kontextuelle Vertraulichkeitsanforderung benachrichtigt werden und gefragt werden, ob er vor hat, diese Einstellung aufzuheben. Dieser Aspekt des Dienstes hilft, um festzustellen, welche Attribute in einem Benutzerprofil bei einem SPLEMP als Vertraulichkeit erfordernd erklärt werden sollen. Die Informationen dies bezüglich stammen vom Feedback von verschiedenen Benutzern, die meinten, daß so eine Regelung nötig wäre. Ein SPLEMP könnte selbst den Wunsch haben, irgendwelche unglückliche Vorfälle zu vermeiden und so eine Vorsichtsregelung angewendet zu bekommen.
15. Vertraulichkeit erfordernde Benutzer-Angaben bei bestimmten Örtlichkeiten: In bestimmten Örtlichkeiten gibt es bestimmte Arten von Menschen, die eine Gefahr für Andere eines bestimmten Typus darstellen können. Alle SPLEMPs, die in diesem Gebiet sich befinden, sind auch für diesen Typus von Benutzern eine Gefahr, außer wenn der SPLEMP extra für diesen Typus bedacht ist. Andernfalls ist es wichtig, daß höchste Vorsicht bei der Vermittlung von Benutzern dieses Typus in diese SPLEMPs angewendet werden soll. Die Informationen, um so etwas zu bewerten kommen aus verschiedenen Quellen wie demographischen Studien, Benutzerfeedback, Vorfallsberichten, usw.
16. Vorsicht bei der Nutzung von Vertraulichkeit bedürftigen Benutzer-Angaben bei Partnerschaftseignungsüberprüfungen bei bestimmten Partnerschaftskandidaten: Der Dienst erhält Informationen über einen Benutzer entweder über seine eigenen Angaben, oder über sein Verhalten, das direkt durch die Dienstbenutzung klar wurde, oder über Berichte von anderen Benutzern, oder durch das, was von seiner Strafakte hergeleitet werden konnte. Alle diese Quellen ermöglichen es, daß entschieden werden kann, ob ein Benutzer bei einem anderen gut aufgehoben sein könnte oder ob man Vorsicht walten lassen soll. Dieser Entschluß ist auch von dem Charakter des Benutzers selbst abhängig.
17. Analyse der Dauerhaftigkeit der Benutzerprofilattribute und ihre Anwendung: Das Benutzerprofil ändert sich im Verlauf der Zeit. Manchmal kann es sich als wichtig erweisen, aufzuspüren, warum ein Partnerschaftseignungstreffer erzielt wurde, wie oft der Benutzer sein Profil ändert, ob der Benutzer etwas ändert, was nicht als flüchtige Information betrachtet wird, ob der Benutzer bei der Änderung von Attributen Motive verfolgt, die es ihm ermöglichen würden, bei einer bestimmten Gruppe von Leuten eine Partnerschaftseignung zu erzielen, ob die Änderungen realistisch sind, usw. Das kann sich als wichtig erweisen, z. B. wenn der Benutzer seine Profilattribute einfach so verändert, z. B. seine religiöse Zugehörigkeit, um Leuten nicht aus Gründen der Partnerschaft vermittelt zu werden, sondern um eine Gruppe von Menschen aufzuspüren, denen gegenüber er ein negatives Ziel verfolgt, oder um bei der Partnerschaftseignungsüberprüfung selbst zu tricksen. Solche unehrlich veranlagten Menschen wären bereit, öfters ihre Attribute zu verändern.
18. Verfolgung der Glaubwürdigkeit bei den Benutzerprofilattributen: Je nachdem, was der Benutzer in sein Benutzerprofil eingibt und was widersprüchliches von dem vermittelten Partnerschaftskandidaten durch Feedback ermittelt wurde, wird bewertet, wie hoch die Glaubwürdigkeit bei verschiedenen Angaben eines Benutzers ist. Auch die früheren Glaubwürdigkeitsbewertungen spielen dabei eine Rolle. Diese Glaubwürdigkeit spielt eine große Rolle dabei, ob ein Benutzer einem anderen vermittelt wird oder nicht.

Betriebsbezogene Funktionalitäten

Hierbei geht es um Funktionalitäten, die den Betrieb einer Implementierung des Systems betreffen. Das sind folgende Funktionalitäten:

1. Installieren
2. Überwachen
3. Protokollieren
4. Analysieren
5. Steuern
6. Konfigurieren
7. Diagnostizieren
8. Korrigieren
9. Erweitern
10. Unterbrechen
11. Anschalten
12. Ausschalten
13. Kommunikation sichern
14. Kooperation sichern
15. Verteilungs-Management
16. Usw.

Darüber hinaus betrifft es die Modularisierung, Verteilung, und Organisation der Implementierung des Systems, besonders was die RPMMSU angeht. Verschiedene SPLEMPs befinden sich in verschiedenen Gebieten der Welt. Um ihre Verwaltung zu vereinfachen, werden die SPLEMPs zusammengefaßt zu Gruppen, die hier SPLEMP-Cluster genannt werden.

Ein SPLEMP-Cluster kann geographisch oder nach Typus der SPLEMPs festgelegt werden. Die kleinste Örtlichkeit wäre vielleicht ein Stadtteil oder eine ganze Kleinstadt. Geographisch könnte eine Örtlichkeit topographisch, politisch, kulturell, demographisch, rein geographisch oder aus Gründen der gleichmäßigen Verteilung bestimmt werden. Hier geht man von der Örtlichkeit des SPLEMPs aus. Auch wenn die SPLEMPs nach Typus zusammengefaßt werden, werden sie trotzdem höchst wahrscheinlich noch eine geographische Komponente haben. Unter Typus versteht man, ob der SPLEMP einer bestimmte Art von Kundschaft pflegt, in welcher Größenordnung man es einstufen kann, welches Bedienungs-Paket der Dienstanbieter in Anspruch nimmt, usw. Hier geht man von dem SPLEMP aus.

Die SPLEMP-Cluster können wiederum nach zwei Arten unterschieden werden: Betriebs-SPLEMP-Cluster und virtuelle SPLEMP-Cluster. Die SPLEMPs in einem Betriebs- SPLEMP-Cluster benutzen die gleiche Ressourcen und ihre Verarbeitung läuft auf die gleichen Ressourcen, z. B. Prozessor und/oder Speicher. Sie teilen eine Plattform. Mehrere Betriebs-SPLEMP-Cluster können zu einem Oberen-Betriebs-SPLEMP-Cluster zusammengefaßt werden, wobei dieser sich auch wie ein Betriebs-SPLEMP-Cluster verhält. Ein virtueller SPLEMP-Cluster umfaßt mehrere SPLEMPs eventuell aus verschiedenen Betriebs-SPLEMP-Clusters nach irgendwelchen Kriterien, nur um irgendwelche Operationen auf ihnen gemeinsam durchführen zu können, oder auch einfach um auf sie direkt auf einmal zuzugreifen. Zu diesen Arten von Funktionalitäten gehört auch das Management von Betriebs-SPLEMP-Clusters und virtuellen SPLEMP-Clusters.

Technologien

Technologien wie die auf Infrarot basierte IrDA, auf Rundfunkwellen basierte Bluetooth Technologie von BluetoothSIG, drahtlose JINI von Javasoft, oder ähnliche, können die Aufgabe der kurzstreckigen drahtlosen Kommunikation bewältigen.

Mobilfunknetze benutzen standardisierte Technologien wie GSM, IS-136, PDC, UMTS, usw. für die langstreckige drahtlose Kommunikation zwischen zwei Geräte.

Für die langstreckige Kabel-Verbindungen, gibt es auch eine Reihe von Standards wie ISDN, Internet, usw. Auch viele anderen Technologien wie Java RMI, DCE, CORBA, XML Familie, CGI, Java Spezifikationen, usw. können benutzt werden.

Glossar Allgemeines

Match Partnerschaftseignung, je nach Kontext auch: Partnerschaftseignungstreffer, Partnerschaftseignungsbestätigung, Partnerschaftseignungsfund, Partnerschaftsübereinstimmung, Partnerschaftssuchtreffer, Partnerschaftsfund, Übereinstimmungsmöglichkeitsbestätigung
Match Making: Partnerschaftssuche, Partnerschaftsüberprüfung, Partnervermittlung, Übereinstimmungsprüfung
Match Making Scheme Partnerschaftssuchprogramm, Partnervermittlungsdienst,
Public Leisure and Entertainment Meeting Place (PLEMP): Öffentlicher Freizeit- und Vergnügungstreffpunkt
Serviced Public Leisure and Entertainment Meeting Place (SPLEMP): Bedienter öffentlicher Freizeit- und Vergnügungstreffpunkt

Hauptkomponenten

Real Partner Match Making Server Unit (RPMMSU): Partner-im-realen-Leben- Übereinstimmungsprüfungs-Dienstleistungs-Einheit
Serviced Public Leisure and Entertainment Meeting Place's (SPLEMP) Location Server Unit (LSU): Örtlichkeitsdienstleistungseinheit eines bedienten öffentlichen Freizeit- und Vergnügungstreffpunktes
User's Personal Mobile Communications and Computing Device (PMCCD): Persönliches Mobilkommunikations- und Rechengerät des Benutzers

Parteien

Authentification Agency: Authentifizierungsagentur
Security Authority: Sicherheitsinstanz
SPLEMP Operator: SPLEMP-Betreiber
RPMMSU Operator: RPMMSU-Betreiber
User: Benutzer

Rollen

Accepted Matched Candidate Partner: Akzeptierter vermittelter Partnerschaftskandidat
Candidate Partner: Partnerschaftskandidat
Matched Candidate Partner: Vermittelter Partnerschaftskandidat
Probationing Accepted Matched Candidate Partner: Akzeptierter vermittelter Partnerschaftskandidat in der Probezeit
Successfully Probationed Accepted Matched Candidate Partner: Erfolgreich erprobter vermittelter und akzeptierter Partnerschaftskandidat
User: Benutzer

Kategorien der Module

Basic Platform Modules: Grundplattform-Module
Communications Connection Management Modules: Kommunikationsverbindungsmanagement-Module
Configuration Modules: Konfigurationsmodule
Information Analysis Modules: Informationsanalyse-Module
Information Feed Modules: Informationseingabemodule
Information Management Modules: Informationsmanagementmodule
Presentation Modules: Präsentations-Module
Service Processing Modules: Dienstbearbeitende Module
System Information Capture Modules: Systeminformationserfassungsmodule
User Dialogue Modules: Benutzerdialogmodule
User Notification Modules: Benutzerbenachrichtigungsmodule
User Query Modules: Benutzeranfragemodule

Real Partner Match Making Server Unit

Active User Profile Generation Module: Modul zur Erstellung aktiver Benutzerprofile
Astrological Systems based Astrological Profile Evaluation Module: Modul zur Bewertung auf astrologischen Systemen basierter astrologischer Profile
Authentication Authority Agencies User Authentication Confirmation Feed Human- Machine Interface Support Module: Modul zur Unterstützung der Mensch-Maschine- Schnittstelle für die Authentifizierungsinstanzen zur Bestätigungseingabe bezüglich der Authentifizierung des Benutzers
Authentication Module: Authentifizierungsmodul
Automatic User Position Determining Module: Modul zur automatischen Bestimmung der Benutzerposition
Central Processing Unit: Zentralprozessoreinheit
Communication Connection Establishment Module: Modul zum Aufbau einer Kommunikationsverbindung
Display Output Mechanism Unit: Bildschirmausgabemechanismuseinheit
Emergency Call Reception Module: Notrufempfangsmodul
Emergency Call Security Processing Module: Sicherheitsmodul zur Verarbeitung von Notrufen
External Serial and Parallel Interfaces Bus and Control Unit: Bus- und Steuerungseinheit externer serieller und paralleler Schnittstellen
Geographical Places and Positions Interrelationships Graphs based Information Format Conversion Modules: Modul zur Konvertierung des Formates der Informationen der Wechselbeziehungen zwischen geographischen Orten und Positionen
Geographical Places and Positions Interrelationships Graphs based Information Management Module: Modul zur Verwaltung der auf Wechselbeziehungsgraphen über geographische Orte und Positionen basierten Informationen
Interactive Activity Intentions Cofiguration Support Module: Modul zur Unterstützung der Konfiguration der Interaktive-Tätigkeits-Absichten
Interactive Activity Intentions Definition Processing Module: Modul zur Verarbeitung der Bestimmung der Interaktive-Tätigkeiten-Absichten
Introductory Session Management Support Module: Vorstellungssitzungs- Verwaltungs- und Unterstützungsmodul
Keys Input Mechanism Unit: Tasteneingabenmechanismuseinheit
Locality related Demographic Information Capture and Management Module: Modul zur Erfassung und Verwaltung örtlichkeitsbezogener demographischer Informationen
Locality related User Profile Attributes Sensitivity Determination Module: Modul zur Feststellung der Sensibilität der örtlichkeitsbezogenen Benutzerprofilsattribute
Location Deregistration Intent Confirmation Support Module: Modul zur Bestätigungsunterstützung der Absicht zur Örtlichkeitsabmeldung
Location Registration Configuration Support Module: Modul zur Unterstützung der Konfiguration der Örtlichkeitsanmeldung
Long Distance Signalling Connection to Serviced Public Leisure and Entertainment Meeting Place's Location Server Unit Management Module: Modul zur Verwaltung von Langstrecken-Datenübermittlungsverbindungen zur LSU eines SPLEMPs
Long Distance Wired Networking and Communications Unit: Langstrecken-Kabel- Vernetzungs- und Kommunikationseinheit
Long Distance Wireless Networking and Communications Unit: Langstreckige drahtlose Vernetzungs- und Kommunikationseinheit
Long Distance Wireless Signalling Connection to User's Personal Mobile Communications and Computing Device Management Module: Modul zur Verwaltung von drahtlosen Langstrecken-Datenübermittlungsverbindungen zum PMCCD eines Benutzers.
Long Distance Wireless Synchronous Duplex Communication Connection to User's Personal Mobile Communications and Computing Device Management Module: Modul zur Verwaltung von drahtlosen synchronen Duplex Langstrecken- Kommunikationsverbindungen zum PMCCD eines Benutzers.
Main Memory Unit: Hauptspeichereinheit
Match Making Processor Module: Modul zur Verarbeitung der Partnerschaftseignungssuche
Match Processing Module: Modul zur Verarbeitung der Partnerschaftseignungstreffer
Matched Candidate Partner Catalogue Management Module: Verwaltungsmodul des Kataloges von vermittelten Partnerschaftskandidaten
Matched Candidate Partner Contact Willingness Confirmation Support Module: Modul zur Bestätigungsunterstützung der Kontaktbereitschaft zu dem vermittelten Partnerschaftskandidaten
Matched Candidate Partner Critical Feedback Reception Module: Modul zum Empfang von kritischem Feedback zu einem vermittelten Partnerschaftskandidaten
Matched Candidate Partner Critical Feedback Processing Module: Modul zur Verarbeitung des kritischen Feedbacks gegenüber vermittelten Partnerschaftskandidaten
Matched Candidate Partner Rememberance Information Configuration Support Module: Modul zur Unterstützung der Konfiguration der Informationen zur Erinnerung an vermittelte Partnerschaftskandidaten
Matched Candidate Partner Rememberance Information Management Module: Modul zur Verwaltung von Informationen zur Erinnerung an vermittelte Partnerschaftskandidaten
Operator and Service Description Information Provision Support Module: Modul zur Unterstützung von Bereitstellung von Informationen, die Betreiber und Dienst beschreiben
Operator Statistical & Other Reports Generator Support Module: Modul zur Unterstützung der Erstellung von Statistiken und anderen Berichten für den Betreiber
Operator System Management Human-Machine Interface Support Module: Modul zur Unterstützung der Mensch-Maschine-Schnittstelle für den Betreiber bei der Systemverwaltung
Palmistry Systems based Palmistrical Profile Evaluation Module: Modul zur Bewertung auf handleserischen Systemen basierter handleserischer Profile
Partner Introductory Information Generation and Provision Support Module: Modul zur Unterstützung von Erstellung und Bereitstellung von Informationen zur Vorstellung von einem Partner
Persistent Memory Unit: Dauerhafte Speichereinheit
Power Supply Unit: Stromversorgungseinheit
Psychological and Social Systems based Profile Evaluation Module: Modul zur Bewertung des auf dem psychologischen und sozialen System basierenden Profils
Psychological and Social Systems based Profile History Management Module: Verwaltungsmodul der auf psychologischen und sozialen Systeme basierten Profilchronik
Resource Allocation Evaluation Module: Modul zur Bewertung der Ressourcenzuteilung
Security Authority User Security Check and User Personal and Activity Information Feed Support Human-Machine Interface Support Module: Modul zur Unterstützung der Mensch-Maschine-Schnittstelle für die Sicherheitsbehörden zur Unterstützung der Eingabe von Angaben aus der Sicherheitsakte des Benutzers, persönlichen Angaben des Benutzers und Informationen über Tätigkeiten des Benutzers
Service Activation Configuration Support Module: Modul zur Unterstützung der Konfiguration der Dienstaktivierung
Serviced Public Leisure and Entertainment Meeting Place Accounts Management Module: Verwaltungsmodul des Kontos eines bedienten öffentlichen Freizeit- und Vergnügungstreffpunktes
Specific Comobility and Coactivity Intention Definition and Tracking Information Management Module: Modul zur Verwaltung von Absichtsdefinitionen und Nachverfolgungsinformationen bezüglich der Zusammenbewegung und Zusammenagierung
Specific Comobility and Coactivity Intention Definition and Tracking Security Information Reception Module: Modul zum Empfang von Informationen über Absichtsdefinitionen und Nachverfolgungsinformationen bezüglich der Zusammenbewegung und Zusammenagierung
Specific Comobility and Coactivity Intention Definition and Tracking Security Processing Module: Modul zur Verarbeitung von Informationen über Absichtsdefinitionen und Nachverfolgungsinformationen bezüglich der Zusammenbewegung und Zusammenagierung
SPLEMP Account Information Configuration Support Module: Modul zur Unterstützung der Konfiguration der Informationen über SPLEMP-Konten
SPLEMP Location Registration Processing Module: Modul zur Verarbeitung der Ortsanmeldungen bei einer SPLEMP
SPLEMP Registration and Persistent Configuration Human-Machine Interface Support Module: Modul zur Unterstützung der Mensch-Maschine-Schnittstelle zur SPLEMP-Anmeldung und dauerhaften Konfiguration
SPLEMP Registration requiring Third-Party Authentication Coordination Module: Modul zur Koordination der für die SPLEMP-Anmeldung erfordlichen Dritt-Partei- Authentifizierungs
SPLEMP related User Profile Attributes Sensitivity Determination Module: Modul zur Feststellung der Sensibilität der SPLEMP-bezogenen Benutzerprofilsattribute
SPLEMP Servicing Module: SPLEMP-Bedienungsmodul
SPLEMP Servicing Settings Configuration Support Module: Modul zur Unterstützung der Konfiguration der SPLEMP-Bedienungseinstellungen
SPLEMP Servicing Settings Processing Module: Modul zur Verarbeitung der SPLEMP-Bedienungseinstellungen
SPLEMP Sessions and Events Information Configuration Support Module: Modul zur Unterstützung der Konfiguration der Informationen über SPLEMP-Sitzungen und - Veranstaltungen
SPLEMP Sessions History Management Module: Verwaltungsmodul für die Chronik der Sitzungen eines SPLEMPs
System Behaviour Complaint Submissions Processing Module: Modul zur Verarbeitung von Beschwerdevorlagen über das Systemverhalten
System Behaviour Complaint Submissions Reception Module: Modul zum Empfang von Beschwerdevorlagen über das Systemverhalten
System Behaviour Complaints Information Management Module: Modul zur Verwaltung von Beschwerden über das Systemverhalten
System Operations Quality Control and Maintenance Information Management Module: Informationsverwaltungssystem zur Kontrolle der System-Betriebsqualität und zur Wartung
System Security Information Management Module: Systemsicherheit- Informationsverwaltungsmodul
System to SPLEMP Messaging Support Module: Modul zur Unterstützung von Benachrichtigungen vom System an den SPLEMP
System to User Messages Information Management Module: Modul zur Verwaltung von Informationen über Benachrichtigungen von dem System an den Benutzer
System to User Messaging Support Module: Modul zur Unterstützung von Benachrichtigungen vom System an den Benutzer
User Account and Personal Information Configuration Support Module: Modul zur Unterstützung der Konfiguration von Benutzerkonto und von persönlichen Angaben des Benutzers
User Accounts Management Module: Benutzerkonto-Verwaltungsmodul
User Behaviour Complaint Information Management Module: Modul zur Verwaltung von Beschwerden über das Benutzerverhalten
User Behaviour Complaint Submissions Reception Module: Modul zum Empfang von Beschwerdevorlagen über das Benutzerverhalten
User Behaviour Complaint Submissions Processing Module: Modul zur Verarbeitung von Beschwerdevorlagen über das Benutzerverhalten
User Behaviour towards Matched Candidate Partner Tracking History Management Module: Verwaltungsmodul für die Nachverfolgungs-Chronik des Verhaltens des Benutzers gegenüber vermittelten Partnerschaftskandidaten
User Behaviour towards People in General Tracking History Management Module: Verwaltungsmodul für die Nachverfolgungs-Chronik des Verhaltens des Benutzers gegenüber Leuten im Allgemeinen
User Behaviour towards Service Usage Tracking History Management Module: Verwaltungsmodul für die Nachverfolgungs-Chronik des Benutzerverhaltens im Hinblick auf dessen Dienstnutzung
User Behaviour towards SPLEMPs Tracking History Management Module: Verwaltungsmodul für die Nachverfolgungs-Chronik des Verhaltens des Benutzers gegenüber SPLEMPs
User directed Critical Feedback History Management Module: Verwaltungsmodul für die Chronik benutzer-gerichteten kritischen Feedbacks
User Home and Stay Information Configuration Support Module: Modul zur Unterstützung der Konfiguration der Heimats- und Aufenthaltsortsinformationen des Benutzers
User Home and Stay Locality Management Module: Verwaltungsmodul der Heimat- und Aufenthaltsortes des Benutzers
User Home Locality History Management Module: Verwaltungsmodul für die Chronik der Heimatorte des Benutzers
User Location Status and Serviceability Tracking Module: Modul zur Nachverfolgung von Status und Bedienbarkeit des Benutzers an einer Örtlichkeit
User Location Tracking Module: Modul zur Verfolgung der Benutzer-Örtlichkeit
User Match History Management Module: Verwaltungsmodul für die Chronik der Partnerschaftseignungstreffer eines Benutzers
User Profile Attribute Credibility Tracking History Management Module: Verwaltungsmodul für die Nachverfolgungs-Chronik der Glaubwürdigkeit der Attribute eines Benutzerprofils
User Profile Change and Development Analysis Module: Modul zur Analyse von Veränderung und Entwicklung des Benutzerprofils
User Profile Change and Development Information Management Module: Informationsverwaltungsmodul der Benutzerprofilveränderungen und -entwicklung
User Profile History Management Module: Verwaltungsmodul für die Chronik der Benutzerprofile
User Profile Management Module: Benutzerprofil-Verwaltungsmodul
User Registration and Persistent Configuration Human-Machine Interface Support Module: Modul zur Unterstützung der Mensch-Maschine-Schnittstelle zur Benutzeranmeldung und dauerhaften Konfiguration
User Registration requiring Third-Party Authentication Coordination Module: Modul zur Koordination der für die Benutzeranmeldung erfordlichen Dritt-Partei- Authentifizierungs
User Security Check File Processing Module: Modul zur Verarbeitung der Benutzer- Sicherheitsüberprüfungsakte
User Security Check required Security Authority Check-Up Request Module: Modul zur Stellung einer sicherheitsüberprüfungsbezogene Anfrage an eine Sicherheitsinstanz zum Zwecke der Benutzersicherheitsüberprüfung
User Security File Management Module: Verwaltungsmodul der Benutzer- Sicherheitsakte
User Servicing Module: Benutzerbedienungsmodul
User Servicing Sessions History Management Module: Verwaltungsmodul für die Chronik der Bedienungssitzungen eines Benutzers
User Servicing Settings Cofiguration Support Module: Modul zur Unterstützung der Konfiguration der Bedienungseinstellungen des Benutzers
User Servicing Settings Processing Module: Modul zur Verarbeitung der Bedienungseinstellungen des Benutzers
User Stay Locality History Management Module: Verwaltungsmodul für die Chronik der Aufenthaltsorte des Benutzers
User's Current Service Usage Privilege Defining Points Computing Module: Modul zur Berechnung der aktuellen Dienstbenutzungsprivilegien-Punktzahl des Benutzers
Testing and Diagnosis Module: Test- und Diagnosemodul

User's Personal Mobile Communications and Computing Device

Authentication Module: Authentifizierungsmodul
Central Processing Unit: Zentralprozessoreinheit
Communication Connection Establishment Module: Modul zum Aufbau der Kommunikationsverbindungen
Display Output Mechanism Unit: Bildschirmausgabemechanismuseinheit
Emergency Call Security Module: Sicherheitsmodul bei Notrufen
External Serial and Parallel Interfaces Bus and Control Unit: Bus- und Steuerungseinheit externer serieller und paralleler Schnittstellen
Geographical Position Determiner Unit: Einheit zur Bestimmung der geographischen Position
Interactive Activity Intentions Definition Module: Modul zur Definition von Interaktive-Tätigkeits-Absichten
Introductory Session Support Module: Modul zur Unterstützung der Bekanntmachungssitzung
Keys Input Mechanism Unit: Tasteneingabenmechanismuseinheit
Location Deregistration Confirmation Module: Örtlichkeitsabmeldungsbestätigungsmodul
Location Registration Module: Örtlichkeitsanmeldemodul
Location Stay Monitoring Module: Örtlichkeitsanwesenheitsüberwachungsmodul
Long Distance Wireless Networking and Communications Unit: Langstreckige drahtlose Vernetzungs- und Kommunikationseinheit
Main Memory Unit: Hauptspeichereinheit
Matched Candidate Partner Catalogue Access Module: Modul für den Zugriff auf den Katalog des vermittelten Partnerschaftskandidaten
Matched Candidate Partner Critical Feedback Module: Modul für den kritischen Feedback zu einem vermittelten Partnerschaftskandidaten
Matched Candidate Partner Offer Response Module: Modul zur Beantwortung von Angeboten von vermittelten Partnerschaftskandidaten
Matched Candidate Partner Personal Object Transfer and Access Grant Module: Modul für Transfer von persönlichen Informationsobjekten und Gewährung von Zugriff an und von dem vermittelten Partnerschaftskandidaten
Matched Candidate Partner Rememberance Information Configuration Module: Modul zur Konfiguration der Informationen zur Erinnerung an vermittelte Partnerschaftskandidaten
Persistent Memory Unit: Dauerhafte Speichereinheit
Power Supply Unit: Stromversorgungseinheit
Service Activation Module: Modul zur Dienstaktivierung
Service Main Module: Hauptbedienungsmodul
Short Distance Wireless Networking and Communications Unit: Kurzstreckige drahtlose Vernetzungs- und Kommunikationseinheit
Specifice Comobility and Coactivity Intention Definition and Tracking Security Module: Sicherheitsmodul für die Absichtsdefinitionen und Nachverfolgungsinformationen bezüglich der Zusammenbewegung und Zusammenagierung
Speech Recognition Input Mechanism Unit: Spracherkennungseingabemechanismuseinheit
Speech Synthesis Output Mechanism Unit: Ausgabemechanismuseinheit durch Sprachsynthese
Synchronous Communication Support Module: Modul zur Unterstützung der synchronen Kommunikation
System to User Messaging Support Module: Modul zur Unterstützung der Benachrichtigungen vom System an den Benutzer
System Behaviour Complaint Submission Module: Modul zur Vorlage von Beschwerden über das Systemverhalten
Touch Screen Input Mechanism Unit: Eingabemechanismuseinheit mit berührungsempfindlichem Bildschirm
User Position Tracking Security Module: Sicherheitsmodul zur Nachverfolgung der Benutzerposition
User Servicing Settings Module: Modul für die Bedienungseinstellungen des Benutzers

Serviced Public Leisure and Entertainment Meeting Place's Location Server Unit

Authentication Module: Authentifizierungsmodul
Central Processing Unit: Zentralprozessoreinheit
Check-In Confirmation Short Distance Wireless Listener and Signalling Units: kurzstreckige drahtlose Abhör- und Signalisierungseinheiten zur Check-In-Bestätigung
Check-Out Confirmation Short Distance Wireless Listener and Signalling Units: kurzstreckige drahtlose Abhör- und Signalisierungseinheiten zur Check-Out-Bestätigung
Display Output Mechanism Unit: Bildschirmausgabemechanismuseinheit
External Serial and Parallel Interfaces Bus and Control Unit: Bus- und Steuerungseinheit externer serieller und paralleler Schnittstellen
Keys Input Mechanism Unit: Tasteneingabenmechanismuseinheit
Location Registration Information Exchange Short Distance Wireless Listener Signalling Units: kurzstreckige drahtlose Abhör- und Signalisierungseinheiten zum Austausch von Örtlichkeitsanmeldeinformationen
Location Registrations Management Module: Modul zur Verwaltung der Örtlichkeitsanmeldungen
Long Distance Networking and Communications Unit: Langstreckige Vernetzungs- und Kommunikationseinheit
Main Memory Unit: Hauptspeichereinheit
On Premises Stay Check Short Distance Wireless Listener and Signalling Units: kurzstreckige drahtlose Abhör- und Signalisierungseinheiten zur Überprüfung des Aufenthaltes auf dem Gelände
Persistent Memory Unit: Dauerhafte Speichereinheit
Power Supply Unit: Stromversorgungseinheit
Premises Listeners Management Module: Modul zur Verwaltung der Umgebungsabhöreinheiten
Premises User Stay Information Forwarding Module: Modul zur Weiterleitung der Informationen über den Aufenthalt des Benutzers auf dem Gelände
Server Boot Module: Modul zum Hochfahren des Servers
Server Testing Module: Servertestmodul
Service Quality Settings Module: Modul für die Einstellungen zur Dienstqualität
Speech Recognition Input Mechanism Unit: Spracherkennungseingabemechanismuseinheit
Speech Synthesis Output Mechanism Unit: Ausgabemechanismuseinheit durch Sprachsynthese
System Behaviour Complaint Submission Module: Modul zur Vorlage von Beschwerden über das Systemverhalten
System to SPLEMP Messaging Support Module: Modul zur Unterstützung der Benachrichtigungen vom Sytem an den SPLEMP
Touch Screen Input Mechanism Unit: Eingabemechanismuseinheit mit berührungsempfindlichem Bildschirm
User Behaviour Complaint Submission Module: Modul zur Vorlage von Beschwerden über das Benutzerverhalten
User Location Registration Module: Modul zur Anmeldung des Benutzers bei einer Örtlichkeit
User Servicing Activation Module: Modul zur Aktivierung der Benutzerbedienung
User Stay Monitoring Module: Modul zur Überwachung des Benutzeraufenthalts

Signale

Check-In Area Approach Notification Signal: Signal, das die Annäherung an eine Örtlichkeit beim Check-In bekannt gibt
Check-In Confirmation Signal: Eincheck-Bestätigungssignal
Check-Out Area Approach Notification Signal: Signal, das die Annäherung an eine Örtlichkeit beim Check-Out bekannt gibt
Check-Out Confirmation Signal: Auscheck-Bestätigungssignal
Location Registration Request Processing Signal: Signal, das die Anfrage nach einer Anmeldung bei einer Örtlichkeit bekannt gibt
On-Premises Signal: Signal, das den Umfang eines Geländes markiert
On-Premises Stay Confirmation Signal: Signal, das den Aufenthalt auf einem Gelände bestätigt
SPLEMP Identification Signal: Signal, das ein SPLEMP eindeutig identifiziert
SPLEMP Area Identification Signal: Signal, daß die Region eines SPLEMPs bekannt gibt
SPLEMP Floor Identification Signal: Signal, daß das entsprechende Stockwerk eines mehrgeschoßigen SPLEMPs bekannt gibt
SPLEMP Registrability Signal: Signal, das die Anmeldbarkeit bei einem SPLEMP bestätigt
User Registration Identifier Broadcast Signal: Signal, das ein dem Benutzer bei der Anmeldung zugeordnetes Kennzeichen besagt

Hauptakronyme

LSU: Location Server Unit
PLEMP: Public Leisure and Entertainment Meeting Place
PMCCD: Personal Mobile Communications and Computing Device
RPMMSU: Real Partner Match Making Server Unit
SPLEMP: Serviced Public Leisure and Entertainment Meeting Place

Andere Akronyme

CGI: Common Gateway Interface
CORBA: Common Object Request Broker Architechture
DCE: Distributed Communication Environment
GSM: Global System for Mobile Communications
IrDA: Infrared Data Association
IS-136: TDMA Cellular/PCS - Radio Interface - Mobile Station - Base Station Compatibility Standard
ISDN: Integrated Services Digital Network
Java RMI: Java Remote Method Invocation
PDC: Personal Digital Cellular
UMTS: Universal Mobile Telecommunications Services
XML: Extensible Markup Language

Abbildungsverzeichnis

1. Abb. 1: Diese Abbildung stellt einen einfachen Partnerschaftsvermittlungsprozeß dar.

2. Abb. 2: Das System, wenn es um eine Location Server Unit erweitert wird.

3. Abb. 3: Hauptspeicher-Module der Partnerschaftsvermittlungs- Dienstleistungseinheit.

4. Abb. 4: Dauerhafte-Speicher-Module zu auf bediente öffentliche Freizeit- und Vergnügungstreffpunkte bezogene Informationen

5. Abb. 5: Dauerhafte-Speicher-Module zu Informationen bezogen auf vom Partnerschaftsvermittlungs-Dienstleistungssystem verwaltete Benutzer, nämlich Informationen, die der Benutzer selbst konfiguriert, wie Benutzerprofil, Tätigkeitsinteressen, Heimatort, Aufenthaltsort, usw.

6. Abb. 6: Dauerhafte-Speicher-Module zu Informationen bezogen auf vom Partnerschaftsvermittlungs-Dienstleistungssystem verwaltete Benutzer, nämlich Chroniken des Benutzerprofils, der Heimatsorte, der Aufenthaltsorte, usw.

7. Abb. 7: Dauerhafte-Speicher-Module zu Informationen bezogen auf vom Partnerschaftsvermittlungs-Dienstleistungssystem verwaltete Benutzer, nämlich die Partnerschaftseignungstrefferchronik des Benutzers.

8. Abb. 8: Dauerhafte-Speicher-Module zu Informationen bezogen auf vom Partnerschaftsvermittlungs-Dienstleistungssystem verwaltete Benutzer, nämlich die Chronik der Bedienungssitzungen des Benutzers

9. Abb. 9: Dauerhafte-Speicher-Module zu Informationen bezogen auf vom Partnerschaftsvermittlungs-Dienstleistungssystem verwaltete Benutzer, nämlich die Krititische-Feedback-Chronik des Benutzers und seine Sicherheitsakte

10. Abb. 10: Dauerhafte-Speicher-Module zu Informationen bezogen auf vom Partnerschaftsvermittlungs-Dienstleistungssystem verwaltete Benutzer, nämlich die aktuelle Dienstbenutzungsprivilegien-Punktzahl des Benutzers und andere darauf basierende Informationen.

11. Abb. 11: Modulstruktur des Personal Mobile Communications and Computing Device des Benutzers

12. Abb. 12: Modulstruktur der Location Server Unit (LSU) des Serviced Public Leisure and Entertainment Meeting Place (SPLEMPs)

13. Abb. 13: Modulstruktur der Real Partner Match Making Server Unit beschränkt auf die Informationsmanagementmodule

14. Abb. 14: Modulstruktur der Real Partner Match Making Server Unit beschränkt auf die Benutzerdialogmodule

15. Abb. 15: Modulstruktur der Real Partner Match Making Server Unit beschränkt auf die Benutzeranfragemodule

16. Abb. 16: Modulstruktur der Real Partner Match Making Server Unit beschränkt auf die Informationsanalyse-Module

17. Abb. 17: Modulstruktur der Real Partner Match Making Server Unit beschränkt auf die Systeminformationserfassungsmodule

18. Abb. 18: Modulstruktur der Real Partner Match Making Server Unit beschränkt auf die Benutzerbenachrichtigungsmodule

19. Abb. 19: Modulstruktur der Real Partner Match Making Server Unit beschränkt auf die Konfigurationsmodule

20. Abb. 20: Modulstruktur der Real Partner Match Making Server Unit beschränkt auf die Informationseingabemodule

21. Abb. 21: Modulstruktur der Real Partner Match Making Server Unit beschränkt auf die dienstbearbeitenden Module

22. Abb. 22: Modulstruktur der Real Partner Match Making Server Unit beschränkt auf die Kommunikationsverbindungsmanagement-Module

23. Abb. 23: Modulstruktur der Real Partner Match Making Server Unit beschränkt auf die Präsentations-Module

24. Abb. 24: Modulstruktur der Real Partner Match Making Server Unit beschränkt auf die Grundplattform-Module

25. Abb. 25: Modularten des Partnerschaftseignungssuchprozessor-Moduls der Real Partner Match Making Server Unit

26. Abb. 26: Abstrakte Komponententypus-Architektur

Interpretierungsanleitung

Die Texte, die in den

Abb.

3-10 benutzt werden, dienen primär nicht dem Ziel der Erläuterung, sondern stellen die Art der Informationen dar, die in den entsprechenden Speicher-Elementen enthalten sind, und geben dadurch die Speicher-Elemente selbst wieder. Die Abbildungen repräsentieren die Verschachtelung der Speicher-Elemente.
Die Texte, die in den

Abb.

11-25 vorkommen, sind ebenfalls keine Erläuterungen, sondern repräsentieren nur die Namen der jeweiligen Module.

Claims

1. Zwei Benutzer eines Dienstes werden einander durch Partnersuche, Partnerschaftseignungsüberprüfung und Bekanntmachung vermittelt, wobei die Beiden sich irgendwo in einer gemeinsamen, mit dem Dienst kooperierenden, Umgebung befinden. Die Überprüfung findet auf einem anderen eventuell entfernten Rechensystem (RPMMSU) statt. Die beiden Benutzer werden über den "Treffer" über ihr Personal Mobile Communication and Computing Device (PMCCD) informiert, wobei jeder Benutzer ein solches PMCCD mit sich trägt. Dieser Treffer ermöglicht es, daß die zwei Benutzer direkt oder indirekt miteinander kommunizieren können. Die drei Subsysteme - PMCCD des Benutzers, PMCCD des Partnerschaftskandidaten, RPMMSU - kommunizieren miteinander drahtlos. Zusammen bildet dies ein verteiltes System. Die Beziehung Dienst-System ist wie in den Punkten "Lösungsarchitektur"/"System-Dienst Zweiteilung" zu verstehen.

2. Patentanspruch (1) dadurch gekennzeichnet, daß das System einige oder alle der oben in "Lösungsarchitektur"/"Systemumfangsumrisse"/"Kernfunktionalitäten" aufgelisteten Funktionalitäten besitzt.

3. Patentansprüche (1) und (2) dadurch gekennzeichnet, daß das System die in Patentanspruch (2) erwähnten Funktionalitäten mittels der in "Lösungsarchitektur"/ "Haupt-Dienstprozesse, Funktionalitäten und Lösungsstrategien" ausgeführten Strategien, so weit es nur diese Funktionalitäten betrifft, die verschiedenen Aspekten und Bedingungen betrachtend realisiert.

4. Patentansprüche (1) und (2) dadurch gekennzeichnet, daß das System die in Patentanspruch (2) erwähnten Funktionalitäten mittels der in "Lösungsarchitektur"/ "Architekturentwurfsmodule" empfohlene Lösung, so weit es nur diese Funktionalitäten betrifft, realisiert.

5. Patentansprüche (1) und (2) dadurch gekennzeichnet, daß das System gar keine, eine, einige oder alle der oben in "Lösungsarchitektur"/"Systemumfangsumrisse"/ "Aufdauende Funktionalitäten" aufgelisteten Funktionalitäten besitzt.

6. Patentansprüche (1), (2), (3) und (5) dadurch gekennzeichnet, daß das System die oben in Patentanspruch (4) erwähnte Funktionalitäten mittels der in "Lösungsarchitektur"/ "Haupt-Dienstprozesse, Funktionalitäten und Lösungsstrategien" ausgeführten Strategien, so weit es nur diese Funktionalitäten betrifft, die verschiedenen Aspekten und Bedingungen betrachtend realisiert.

7. Patentansprüche (1), (2), (4) und (5) dadurch gekennzeichnet, daß das System die oben in Patentanspruch (4) erwähnte Funktionalitäten mittels der in "Lösungsarchitektur"/ "Architekturentwurfsmodule" empfohlene Lösung, soweit es nur diese Funktionalitäten betrifft, realisiert.

8. Patentansprüche (1), (2) und (5) dadurch gekennzeichnet, daß das System gar keine, eine, einige oder alle der oben in "Lösungsarchitektur"/"Systemumfangsumrisse"/ "Optimierende Funktionalitäten" aufgelisteten Funktionalitäten besitzt.

9. Patentansprüche (1), (2), (3), (5), (6) und (8) dadurch gekennzeichnet, daß das System die oben in Patentanspruch (8) erwähnte Funktionalitäten mittels der in "Lösungsarchitektur"/ "Haupt-Dienstprozesse, Funktionalitäten und Lösungsstrategien" ausgeführten Strategien, so weit es nur diese Funktionalitäten betrifft, die verschiedenen Aspekten und Bedingungen betrachtend realisiert.

10. Patentansprüche (1), (2), (4), (5), (7) und (8) dadurch gekennzeichnet, daß das System die oben in Patentanspruch (6) erwähnte Funktionalitäten mittels der in "Lösungsarchitektur"/ "Architekturentwurfsmodule" empfohlene Lösung, soweit es nur diese Funktionalitäten betrifft, realisiert.

11. Patentansprüche (1), (2), (5) und (8) dadurch gekennzeichnet, daß das System gar keine, eine, einige oder alle der oben in "Lösungsarchitektur"/"Systemumfangsumrisse"/ "Erweiterte Funktionalitäten" aufgelisteten Funktionalitäten besitzt.

12. Patentansprüche (1), (2), (3), (5), (6), (8), (9) und (11) dadurch gekennzeichnet, daß das System die oben in Patentanspruch (11) erwähnten Funktionalitäten mittels der in "Lösungsarchitektur"/"Haupt-Dienstprozesse, Funktionalitäten und Lösungsstrategien" ausgeführten Strategien, so weit es nur diese Funktionalitäten betrifft, die verschiedenen Aspekten und Bedingungen betrachtend realisiert.

13. Patentansprüche (1), (2), (4), (5), (7), (8), (10) und (11) dadurch gekennzeichnet, daß das System die oben in Patentanspruch (11) erwähnten Funktionalitäten mittels der in "Lösungsarchitektur"/"Architekturentwurfsmodule" empfohlene Lösung, soweit es nur diese Funktionalitäten betrifft, realisiert.

14. Patentansprüche (1) und (2) dadurch gekennzeichnet, daß das System gar keine, eine, einige oder alle der oben in "Lösungsarchitektur"/"Systemumfangsumrisse"/ "Betriebsbezogene Funktionalitäten" aufgelisteten Funktionalitäten besitzt.

15. Patentansprüche (1), (2), (3) und (14) dadurch gekennzeichnet, daß das System die in Patentanspruch (14) erwähnten Funktionalitäten mittels der in "Lösungsarchitektur"/ "Haupt-Dienstprozesse, Funktionalitäten und Lösungsstrategien" ausgeführten Strategien, so weit es nur diese Funktionalitäten betrifft, die verschiedenen Aspekten und Bedingungen betrachtend realisiert.

16. Patentansprüche (1), (2), (4) und (14) dadurch gekennzeichnet, daß das System die in Patentanspruch (14) erwähnten Funktionalitäten mittels der in "Lösungsarchitektur"/ "Architekturentwurfsmodule" empfohlene Lösung, so weit es nur diese Funktionalitäten betrifft, realisiert.

17. Patentansprüche (1), (2), (5) und (14).

18. Patentansprüche (1), (2), (3), (5), (6), (14), (15) und (17) dadurch gekennzeichnet, daß das System die in Patentanspruch (17) erwähnten Funktionalitäten mittels der in "Lösungsarchitektur"/"Haupt-Dienstprozesse, Funktionalitäten und Lösungsstrategien" ausgeführten Strategien, so weit es nur diese Funktionalitäten betrifft, die verschiedenen Aspekten und Bedingungen betrachtend realisiert.

19. Patentansprüche (1), (2), (4), (5), (7), (14), (16) und (17) dadurch gekennzeichnet, daß das System die in Patentanspruch (17) erwähnten Funktionalitäten mittels der in "Lösungsarchitektur"/"Architekturentwurfsmodule" empfohlene Lösung, soweit es nur diese Funktionalitäten betrifft, realisiert.

20. Patentansprüche (1), (2), (5), (8), (14) und (17).

21. Patentansprüche (1), (2), (3), (5), (6), (8), (9), (14), (15), (17), (18) und (20) dadurch gekennzeichnet, daß das System die in Patentanspruch (20) erwähnten Funktionalitäten mittels der in "Lösungsarchitektur"/"Haupt-Dienstprozesse, Funktionalitäten und Lösungsstrategien" ausgeführten Strategien, so weit es nur diese Funktionalitäten betrifft, die verschiedenen Aspekten und Bedingungen betrachtend realisiert.

22. Patentansprüche (1), (2), (4), (5), (7), (8), (10), (14), (16), (17), (19) und (20) dadurch gekennzeichnet, daß das System die in Patentanspruch (20) erwähnten Funktionalitäten mittels der in "Lösungsarchitektur"/"Architekturentwurfsmodule" empfohlene Lösung, soweit es nur diese Funktionalitäten betrifft, realisiert.

23. Patentansprüche (1), (2), (5), (8), (11), (14), (17), und (20).

24. Patentansprüche (1), (2), (3), (5), (6), (8), (9), (11), (12), (14), (15), (17), (18), (20), (21) und (23) dadurch gekennzeichnet, daß das System die in Patentanspruch (23) erwähnten Funktionalitäten mittels der in "Lösungsarchitektur"/"Haupt-Dienstprozesse, Funktionalitäten und Lösungsstrategien" ausgeführten Strategien, so weit es nur diese Funktionalitäten betrifft, die verschiedenen Aspekten und Bedingungen betrachtend realisiert.

25. Patentansprüche (1), (2), (4), (5), (7), (8), (10), (11), (13), (14), (16), (17), (19), (20), (22) und (23) dadurch gekennzeichnet, daß das System die in Patentanspruch (23) erwähnten Funktionalitäten mittels der in "Lösungsarchitektur"/"Architekturentwurfsmodule" empfohlene Lösung, soweit es nur diese Funktionalitäten betrifft, realisiert.

26. Patentansprüche (1)-(25) dadurch gekennzeichnet, daß die durch die Patentansprüche (1)- (25) ermöglichte Systeme die Technologien, die in "Lösungsarchitektur"/ "Systemumfangsumrisse"/"Technologien" erwähnt sind, benutzen, besonders für die kurzstreckige drahtlose Kommunikation.
Interpretierungsanleitung
In Patentansprüchen, die davon handeln, über welche Funktionalitäten das System verfügt, wird an manchen Stellen die "gar-keine"-Variante bei der Einfügung von Funktionalitätsgruppen verwendet. Diese Variante wird in nachfolgenden ähnlichen Patentansprüchen benötigt, um darauf zu deuten, daß die Einbeziehung des ersten Patentanspruches in den Zweiten nicht notwendigerweise diejenigen Funktionalitäten, die erst in dem ersten Patentanspruch eingeführt wurden, besitzen muß, sondern sich dadurch nur auf die Patentansprüche beziehen kann, auf die der erste Patentspruch sich selbst bezieht. Eine andere Verwendung für diese Variante ist nicht vorgesehen.
In Patentansprüchen, die davon handeln, über welche Funktionalitäten das System verfügt, können, wo hingewiesen, unterschiedliche Funktionalitäten und auch unterschiedliche Anzahl von Funktionalitäten einbezogen werden. Ein einziger Patentanspruch kann also mehrere Systeme beanspruchen, wo jedes der beanspruchten Systeme eine andere Kombination der Funktionalitäten verkörpert. Manche Funktionalitäten implizieren schon bestimmte andere Funktionalitäten. Dadurch könnten bei Einbeziehung von Funktionalitäten auch andere automatisch einbezogen werden.
In Patentansprüchen, die von der Realisierung des Systems mittels bestimmter Strategien handeln, wird impliziert, daß dessen Realisierung eine optimale Kombination der Strategien, so wie es in den entsprechenden Diskussionspunkten erklärt wird, mit sich zieht.
In Patentansprüchen, die von der Realisierung des Systems mittels bestimmter Lösungsmöglichkeiten handeln, wird impliziert, daß die Lösungsteile, die in den einbezogenen ähnlichen Patentansprüchen verwendet werden, von neuen Lösungen erübrigt werden könnten, da diese neuen Lösungen für das jeweilige beanspruchte System wegen der herrschenden Konstellation der Funktionalitäten eine bessere Lösung darstellen.
Diese Form der Schreibung für Patentansprüche wurde eingeführt, um den Umfang des Patentanspruches besser zu verdeutlichen. Es wird hier eine große Zahl von Funktionalitäten, Strategien, Lösungen, Systemkomponenten, usw. ausgeführt. Ein bestimmter Aspekt kann vorkommen oder auch nicht. Das System kann in sehr vielen verschiedenen Weisen erweitert werden. Die Art und Weise, wie sie alle miteinander kombiniert werden können, ist unüberschaubar.
In den Patentansprüchen wurden viele Verweise auf andere Stellen benutzt, weil es ansonsten zu viel Stoff gäbe, welcher an den Stellen hätte aufgeführt werden müssen. So sind die Patentansprüche kurz und deutlich geblieben.