WO2002003648A1 - Kommunikationssystem - Google Patents

Kommunikationssystem Download PDF

Info

Publication number
WO2002003648A1
WO2002003648A1 PCT/EP2000/006272 EP0006272W WO0203648A1 WO 2002003648 A1 WO2002003648 A1 WO 2002003648A1 EP 0006272 W EP0006272 W EP 0006272W WO 0203648 A1 WO0203648 A1 WO 0203648A1
Authority
WO
WIPO (PCT)
Prior art keywords
communication system
components
layer
application
user
Prior art date
Application number
PCT/EP2000/006272
Other languages
English (en)
French (fr)
Inventor
Carsten Hecht
Christian Seiler
Original Assignee
Cassiopeia Ag
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Cassiopeia Ag filed Critical Cassiopeia Ag
Priority to PCT/EP2000/006272 priority Critical patent/WO2002003648A1/de
Priority to AU2000264312A priority patent/AU2000264312A1/en
Publication of WO2002003648A1 publication Critical patent/WO2002003648A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • the invention relates to a communication system.
  • the invention relates to a communication system in the form of a community.
  • the communication system in the form of a community is based on a special application server.
  • Application servers are generally understood to be software systems that provide basic services for a large number of clients / users by means of appropriate components on the central / server side and can be expanded by any components (“modules”).
  • the components can use the services and basic functionalities of the application server. In particular, this includes (i) distributability of the individual components of the application server in order to distribute load and increase availability; (ii) session management; and (iii) user management.
  • communities are understood to be communities in, internet, extra or intranet which are tailored to the individual needs of a community of interest. Users can communicate with each other within the community, for example via a web browser and other end devices, coordinate joint projects and thus make their collaboration more efficient. This includes Team rooms, discussion forums, chat rooms, audio / video conferences, email, document filing or appointment management are available.
  • the community has an integrated notification system that keeps individual participants constantly informed of events and actions by other users.
  • the object of the invention is to provide an improved communication system, in particular an improved community. This object is achieved with the features of the claims.
  • the communication system according to the invention in particular a community according to the invention, has a modular structure and, according to a first aspect of the invention, has an application layer (2), a presentation layer (3) and a data storage layer (4).
  • the application layer (2) has a core device (21), a plurality of core components (22) and a plurality of application components (23).
  • a communication system with an application layer (2), a presentation layer (3) and a data storage layer (4) is provided, the communication system having a plurality of virtual work areas (5).
  • the communication system according to the invention permits simultaneous communication with all customers who access the communication system, for example via the Internet, and the recording of customer profiles. Customers can contact one another by means of the communication system according to the invention.
  • the communication system according to the invention supports the exchange of data and information within a company.
  • the advantage of the communication system according to the invention lies in its construction in the modular system and in its modular 3-layer architecture. By providing virtual workspaces, individual communication environments are provided for different user groups. The invention is explained in more detail below with reference to the drawings. Show it:
  • FIG. 1 shows an example of the hierarchical structure according to the invention of the virtual work areas of the communication system according to the invention
  • Fig. 3 shows the dynamic page generation in the communication system according to the invention.
  • the communication system according to the invention or the community according to the invention is based on an architecture which allows anyone to add any components with knowledge of the interfaces. These components can take advantage of a number of basic functionalities provided by core components (22).
  • the architecture of the community according to the invention is explained in more detail below.
  • the community according to the invention supports any end devices. These include e.g. Web browser and WAP-enabled mobile phones.
  • All devices that support HTTP or HTTPS as a communication protocol can be operated with the communication system according to the invention / the community according to it. Since the standard technologies XML (Extended Markup Language) and XSL (Extended Stylesheet Language) are based on the invention, no programming effort is required to support different or diverse clients. If terminal devices that use other protocols are to be operated, a community layer (presentation layer, see below) can be implemented in another way according to the invention. user management
  • the community according to the invention can also serve anonymous users, many functions are preferably reserved for registered users. Users can register themselves in the community (it is also possible to implicitly register users automatically). Your attributes or profiles can be managed in any user administration.
  • the community according to the invention maintains its own user administration. It represents an implementation of a programming interface that can also be used for any other implementation. This enables a community to organize different users in several administrations at the same time. Many operators can thus also use their existing user management in the community according to the invention. Data transformations and / or synchronizations are therefore not necessary.
  • each user attribute of a user administration whether it can be read and changed (written) by the user himself or not.
  • attributes can also exist for users (e.g. a customer status) whose values are managed "in the background" and invisibly for the user.
  • a system is made available with which any number of virtual work areas (so-called workspaces) can be set up.
  • Workspaces are virtual spaces that bring users and information / functionalities into context. Information is preferably available in the workspaces in the form of individual discussion forums, conference rooms, group calendars, document filing or workflows.
  • Workspaces can map departments, team rooms or individual subject areas of a topic community. They can be created for groups such as project teams or other interest groups.
  • Workspaces of the communication system according to the invention differ from conventional concepts / systems in the following properties:
  • workspaces do not exist separately from one another, but form a hierarchy. From a workspace that forms the root, further workspaces can be created, which in turn can be further subdivided. Any tree structures as shown in FIG. 1 can thus be formed.
  • the uppermost workspace 51 - the root - is accessible to the public.
  • a sub-workspace 52 represents the intranet - an area only for employees.
  • the other branch 53 "clients" is intended for customers.
  • This workspace is in turn assigned to two workspaces "Sales" 54 and "Support" 55.
  • functionalities of individual modules or application components can be used - e.g. chat rooms, discussion forums and document filing.
  • Users belong to one or more workspaces. If they belong to a subordinate workspace, they can also automatically belong to all superordinate workspaces (example with three workspace levels: an employee of a project team also belongs to a department and thus also to the entire company).
  • Descending in the hierarchy user groups and blocked words are inherited.
  • a registered user can belong to one or more workspaces. He does not have to register multiple times, but can become a member of a workspace based on his registration using the following alternative mechanisms: • Implicitly through certain properties:
  • a workspace can be configured so that users with certain attributes automatically connect to this workspace. belong.
  • a user can submit an application to belong to a workspace.
  • the application will be positively or negatively certified by a designated user who already belongs to this workspace.
  • a designated user can invite a user by generating an access authorization in the form of a password.
  • the recipient of the password must enter this within the community in order to become a member of the workspace.
  • a user can, if he belongs to a certain user group, declare himself to belong to a workspace.
  • a feature of the workspaces according to the invention is that they do not have to be administered centrally. Rather, individual users have rights that allow them to make various configurations. Configurations are e.g. the granting of access rights to the workspace (e.g. "only employees"), inviting certain users to the workspace, creating module instances such as discussion forums, chat rooms and document filing, the assignment of read and write rights for module instances located in the workspace (e.g. "Customers can read, employees from the marketing team can read and write”), or the creation of subordinate workspaces (eg for sales teams that look after different industries or regions).
  • Configurations are e.g. the granting of access rights to the workspace (e.g. "only employees"), inviting certain users to the workspace, creating module instances such as discussion forums, chat rooms and document filing, the assignment of read and write rights for module instances located in the workspace (e.g. "Customers can read, employees from the marketing team can read and write”), or the creation of subordinate workspaces (eg for sales teams that look after different industries or regions).
  • cross-workspace or workspace-independent modules that relate to the individual users. They can be used by users in all workspaces. Examples are personal calendars, guest books, mailboxes and task lists. It can be configured in the workspaces whether the users can use the cross-workspace modules or not.
  • user groups are preferably defined via the profiles of individual users which are stored in the user administrations. This can e.g. "Women over 30", “Men from Kunststoff” or "Head of department in a certain branch”. These user groups are used to assign write / read rights for individual information. For example, only customers have write rights in a special discussion forum or conference room; Non-customers are only allowed to read. As another example, women are shown different content in the same position than men.
  • the user groups are defined by authorized users in the workspaces. User group definitions are inherited in the workspace hierarchy. Subordinate workspaces therefore adopt definitions of user groups from the higher-level workspaces and can define additional user groups, which they in turn pass on.
  • the community according to the invention has an integrated reward system that encourages users to actively use the community.
  • Individual modules award points to users if they are active, ie actively contribute to the community. These are, for example, contributions to discussion forums, guest books or documents submitted.
  • Each user has a points account per workspace. The score reflects his activ reflected in the respective workspace.
  • a ranking list can be created for the associated users in each workspace.
  • the points account is considered an attribute of the user, so that write and read rights can be made dependent on the activity of the user.
  • External systems can access the points account via interfaces, so that shop systems, for example, can offer active users special, cheaper offers than less active users.
  • Authorized users determine how many points are awarded for which activity in the workspaces.
  • Authorized users can configure according to the invention in the workspaces which words users are not allowed to use when posting. If a user tries to contribute a post that contains a blocked word, the post is rejected.
  • the locked words are inherited in descending order in the workspace hierarchy (like user group definitions). Subordinate workspaces take over the filter filters of superordinate workspaces and can add their own words.
  • the community manages sessions ("sessions") of users across all modules and functions of the community.
  • a session begins with an explicit login of a user or with an automatic / implicit login and ends with the user's explicit logout or after a timeout if the User has not sent a request to the community for a long time.
  • a user can use all components and functions without having to log in multiple times.
  • the special feature of the session management of the community according to the invention is that a programming interface is available via which Any session management can be implemented, making it possible, for example, to manage sessions using cookies.
  • All contents of the community according to the invention can be personalized, that is to say individually tailored to individual users.
  • the User groups are used so that different user groups can be provided with different content.
  • a notification system is integrated into the community according to the invention, which continuously informs users about activities and events that affect them. Depending on the degree of importance, the notifications appear within the user interface (volatile notification) or are saved in the user's personal mailbox (persistent notification), but can also be actively sent via SMS, email or other push mechanisms. Notifications are sent by individual components, i.e. The components determine which notifications are generated.
  • Volatile notifications are, for example, “a user from the buddylist enters / leaves the community” or “receipt of a new mail”.
  • Persistent notifications are, for example, “receipt of a meeting request” or "receipt of a new task”.
  • a user can be shown at any time how many and which users are currently online. This information can refer to the entire community or preferably to individual workspaces. This strengthens the so-called awareness, i.e. Users find out in the community that other users are also using it at the same time. You can easily get in touch with them.
  • All information managed in the community according to the invention for example entries in discussion forums, chat rooms, documents, websites etc. - are provided with uniform attributes (author, title, time of creation and change, occurring keywords, read / write rights, associated workspace, number of requests , User rating). These attributes can add other attributes be supplemented. This enables uniform access to all information regardless of its type.
  • the information provided with attributes is referred to as information units.
  • the information units form the basis for the following functionalities that the community according to the invention offers:
  • search users can search for the occurrence of terms.
  • the search is carried out in all information units or in those that are assigned to a specific workspace. Read rights are taken into account, so that only search results are provided as search results for which the user also has read rights.
  • the information units are additionally indexed in parallel by a system that does not work with keywords, but recognizes patterns in information regardless of the language and type of information. This means that information can also be found in which the searched terms do not appear themselves, but rather related terms.
  • Example: A search with the term "car” also finds information that contains "car” and "four wheels” instead of "car”.
  • a search mechanism does not necessarily have to be triggered explicitly by a user. It is also possible, depending on the context, to inform the user of relevant or thematically related information that is inside or outside the community.
  • the context is determined by the information that the user is currently accessing or has accessed in the past.
  • references to existing information can be offered that are considered to be related to the information that was just retrieved (example: a user accesses a website that deals with tennis sports.
  • the community can automatically offer references to discussion forums and other websites who also deal with tennis, tournaments or players).
  • he can be actively notified as soon as new in- formations that are related to information that the user has accessed in the past.
  • Corresponding notices can be displayed within the community, but can also be sent to the user via SMS, email or other notification systems.
  • Users can rate each unit of information (example: a forum post that users rate as particularly good has a higher rating than a forum post whose content is rated as less good). Each user can submit a rating at most once per information unit. The ratings flow into search results, i.e. better rated information ranks higher in a list of results than poorly rated information.
  • Information units can preferably be provided with prices.
  • the price of an information unit is deducted from a user's account when the user retrieves the information. It can be configured that the repeated retrieval of an information unit within a session / session is only calculated once.
  • the account itself is not specified, but can be implemented via an interface. It is possible to use a user's points account as an account.
  • the community logs which user accessed which information unit at which time. This creates more precise user profiles that can be transferred to other systems via interfaces.
  • the collected data are preferably anonymized, ie they are not assigned to individual users, but rather to user groups to which the users belong. Matchmaking
  • Matchmaking describes the functionality that allows users to find other users with certain profiles who are also registered users of the community. There are two methods available: (i) explicit: A user can explicitly specify which attributes (e.g. qualification, position, gender, age) a user should have that he wants to find; (ii) implicit: A user is suggested other users who have a similar profile (attributes or interests) to himself. Every user can decide whether he can be found by other users.
  • attributes e.g. qualification, position, gender, age
  • the communication system 1 according to the invention or the community according to the invention is based on a three-tier architecture (three-tier architecture), so that individual layers or their components can be exchanged without having to change other layers.
  • FIG. 2 illustrates this 3-layer architecture with Application Layer 2, Presentation Layer 3 and Data Access Layer 4.
  • the Application Layer has the application logic that is independent of the final representation and the one used End devices (web browser, WAP-compatible mobile phones etc.). To access permanently stored data, it uses the functions of the data access layer.
  • the presentation layer is connected to an input device and a display device, via which a user inputs or exchanges data / information with the communication system. In particular, requests from clients are answered via the presentation layer. In most cases, responses (eg websites) have to be prepared dynamically depending on the individual user.
  • the Presentation Layer provides this information with a layout that is tailored to the respective requesting client (eg HTML (HyperText Markup Language) for web browsers and WML for WAP-capable mobile phones).
  • the application layer takes on central administrative tasks of the communication system according to the invention and answers inquiries from the presentation layer. While conventional application servers consist of a basic system and components based on it, the community according to the invention has the following components:
  • Core Components Core components of the system (see below) 22
  • Application Compo components with which the community can be expanded with special functionalities can be developed by anyone with knowledge of the corresponding programming interfaces. You access the functionalities of the core components by using their programming interfaces.
  • the core components are of central importance. They offer basic and comprehensive functionalities that can be used by all application components. They are unique in their form and combination. Due to the abundance of core functionalities, the development of application components is simplified. This advantage is further enhanced by the fact that, according to the invention, application components are independent of the end devices and the underlying persistent data storage can be developed since they are part of the application layer.
  • Application components are integrated into the community according to the invention via clearly defined interfaces. Their number is not limited.
  • the community according to the invention preferably has a number of application components - for example discussion forums, chat, group appointment calendar, task and project management etc.
  • the UserManager is a device 211 which is responsible for the administration of the registered users. When registering, users enter their profile, which is saved by UserManager. Registration in UserManager should not be confused with membership in individual workspaces. Registration is not required to use the system.
  • the SessionManager (see below) also supports sessions by guests. Application components have to decide whether to enable their services to unregistered users.
  • the UserManager is responsible for creating the users and their IDs in the system. It supports the simultaneous connection of several user administrations (domains). By default, users are saved in the "nativedomain" domain. Other / additional domains can be docked via an interface.
  • Each domain defines its own attributes and registers them in the UserManager.
  • the SessionManager is a device 212 that is responsible for logging in and out the user. Every time you log in, the SessionManager creates a session object for the user. Using the SessionManager you can preferred embodiment also sessions of other users and a list of all registered users can be requested. In principle there are four different types of sessions: (i) registered user: a user registered in UserManager has logged on; (ii) Guest: a user who is not registered in the UserManager has logged in, providing a (temporary) name; (iii) Anonymous guest: a user who is not registered in the UserManager has logged on and has not given a name; (iv) Lurker: Users without a session ("lurkers") who have not logged in. Applications Components can also temporarily store any objects in the user's session object. This can be a shopping cart or a mailbox, for example.
  • the WorkspaceManager is a device 220 for managing the workspaces. This includes workspace elements (instances of individual modules such as discussion forums), members of a workspace and the workspaces themselves. Members of a workspace can only be registered users in UserManager. Individual users logged on locally in the workspace preferably have special rights in the workspace, the so-called "WorkspacePermissions". In contrast, the access rights of the workspace elements are linked to user groups. Each application component can define its own access rights and have these managed by the WorkspaceManager Read and write rights: User groups are required to define the access rights to Workspaceltems, which are also managed by WorkspaceManager. The Workspaces pass on their user groups to their children.
  • a preferred component 221 of the application layer is the event mechanism.
  • events that exchange the components with each other. For example, requests from the presentation layer are also forwarded in special events.
  • PersistentNotificationE- multi Asynchronous sending of a persistent notification
  • VolatileNotificationEvent multi Asynchronous sending of a volatile notification
  • PeriodicalEvent multi Asynchronous Triggering of periodic events. Is used to call routine tasks in the component without creating its own thread
  • the DataAccessManager is a device 214 which represents the connection to the Data Access Layer. It represents an interface that allows components in the application layer to access persistent data regardless of the storage medium.
  • the device / component Request Dispatcher 213 forms the interface to the presentation layer. It accepts the request and generates events that are sent to the EventDispatcher are passed. After the request has been processed by the addressed component, the RequestDispatcher forwards the result to the presentation layer.
  • the ContainerManager is a device 225 for managing containers for application components.
  • Containers provide a context for different implementations of a module or application component (e.g. it is possible to operate two different implementations of the application component discussion).
  • ApplicationContext core components including ContainerManager
  • ContainerManager Container for application components
  • the AdministrationManager is a device 222 for managing access authorizations for the technical server administration (the non-technical administration takes place by users in the workspaces of the community).
  • the technical administration is carried out via an interface.
  • the InformationUnitManager is a device 223 for managing the information units of the individual components.
  • File Access Manager is a device 223 for managing the information units of the individual components.
  • the FileAccessManager is a device 224 for storing binary files that cannot be stored in the ordinary data storage (via the data access layer).
  • Application components are devices 23 which represent the modules by which the community according to the invention can be expanded by anyone. These can be integrated into the community via clearly defined programming interfaces. According to the invention, the community offers the following application components (names separated by ":” indicate that they extend a component):
  • the presentation layer 3 preferably has the following features.
  • HTTP HyperText Transfer Protocol
  • Java servlet The scope of delivery of the community includes an HTTP web server, which can optionally be replaced by another servlet-capable web server (e.g. Apache).
  • the templates 31 (“templates for websites”) are organized in the file system like in conventional web servers that deliver static content: any directory structures and file / directory names can be selected. Purely static websites can be transferred to the community according to the invention, so that an existing website can continue to be operated and successively expanded with community features (HTML templates must comply with the rules of the XML standard). In order to achieve optimum performance, the templates are preferably cached on the server side. During the reading process, a template is preferably used by one XML parser read in and stored internally in an optimized structure.
  • the output on a display device using the presentation layer is generated in the form of XML documents or HTML pages at runtime from templates which contain defined placeholders or tags. These placeholders - hereinafter called triggers - are dynamically replaced at runtime and specify what should be used in their place.
  • the presentation layer isolates the triggers and passes them on to the application layer, in which the responsible component (e.g. the calendar module) processes the request.
  • the responsible component e.g. the calendar module
  • the information generated is returned in the form of an XML fragment. This is converted into any output language (e.g. HTML) using an XSL stylesheet before it is used in the template instead of the trigger.
  • the requested page is sent to the client (see Fig. 3).
  • Each component of the application layer can define triggers and assign functionalities to them.
  • XSL style sheet for each trigger, which can be adapted as required. This allows dynamically generated elements (e.g. a list of discussion forums or a calendar sheet) to be individually designed down to the last detail. Multiple occurrences of a trigger can optionally be linked to different stylesheets so that the same information can be presented differently. For example, a page can be displayed differently for different end devices (e.g. web browser and WAP-compatible mobile phones) or user groups. Like the XML parser, the supplied XSL processor can also be replaced by other processors.
  • a user does not call up a template (or a page) in order to log in indirectly, but instead explicitly calls up a service with which the output of a specific page is implicitly connected. Since there can be different answers or answer pages when calling up such services Another method is available (eg "Registration successful" and "Registration unsuccessful"): To call up services, the user calls up a so-called virtual document. The call is answered by returning one of several alternative virtual documents. This answer document is virtual, ie the user does not get to see it. Instead, the virtual document is mapped according to a central configuration to an actually existing document or template, which is finally displayed to the user.
  • the community according to the invention has an interface via which any data storage systems can be docked and used for data storage.
  • SQL-compatible databases 41 are supported as standard.
  • Access is via JDBC (Java Database Connectivity).
  • the application layer does not know which system is used for data storage. It accesses relations that are mapped to the existing data storage system. This enables application components to be developed independently of the underlying system.
  • the community according to the invention has a number of advantages: 100% Java-based three-tier architecture, modular structure
  • Cross-component session management optional Organization of a community in several hierarchically structured sub-communities or workspaces with individual access rights Simple structure of the web space as with conventional web servers dynamic page generation extensive personalization options Integrated notification system that informs users about current events and actions of other users.
  • Cross-component search mechanism
  • An SQL-compatible database with a JDBC driver is preferably used to operate the community according to the invention.
  • the community accesses the database via JDBC.
  • a Java virtual machine is used in which the community runs.
  • the community according to the invention is platform-independent.
  • the following operating systems are preferred: Sun Solaris:
  • the community according to the invention covers a wide range of applications, including:

Abstract

Die Erfindung betrifft ein Kommunikationssystem, insbesondere eine Community, mit einer Applikationsschicht (2), einer Präsentationsschicht (3) und einer Datenhaltungsschicht (4), wobei die Applikationsschicht (2) eine Kerneinrichtung (21), mehrere Kernkomponenten (22) und mehrere Applikationskomponenten (23) aufweist. Ferner betrifft die Erfindung ein Kommunikationssystem mit einer Applikationsschicht (2), einer Präsentationsschicht (3) und einer Datenhaltungsschicht (4) wobei das Kommunikationssystem mehrere virtuelle Arbeitsbereiche (5) aufweist.

Description

Kommunikationssystem
Die Erfindung betrifft ein Kommunikationssystem. Insbesondere betrifft die Erfindung ein Kommunikationssystem in Form einer Community.
Das Kommunikationssystem in Form einer Community basiert auf einem speziellen Application Server. Unter Application Servern versteht man gemeinhin Softwaresysteme, die zentral/serverseitig für eine große Zahl von Clients/Benutzern mittels entsprechender Komponenten grundlegende Dienste erbringen und um beliebige Komponenten („Module") erweiterbar sind. Die Komponenten können auf Dienste und Grundfunktionalitäten des Application Servers zurückgreifen. Dazu gehören insbesondere (i) Verteibarkeit der einzelnen Komponenten des Application Servers, um Last zu verteilen und die Verfügbarkeit zu erhöhen; (ii) Sessionverwaltung; und (iii) Benutzerverwaltung.
Unter Communities werden erfindungsgemäß Gemeinschaften in, Inter-, Extra- oder Intranet verstanden, die auf die individuellen Bedürfnisse einer Interessensgemeinde zugeschnitten sind. Die Benutzer können innerhalb der Community beispielsweise per Webbrowser und anderer Endgeräte miteinander kommunizieren, gemeinsame Vorhaben koordinieren und so ihre Zusammenarbeit effizienter gestalten. Dafür stehen u.a. Teamräume, Diskussionsforen, Chaträume, Audio/Videokonferenzen, E-Mail, Dokumentenablagen oder Terminverwaltungen zur Verfügung. Die Gemeinschaft weist ein integriertes Benachrichtungssystem auf, das die einzelnen Teilnehmer ständig über Ereignisse und Aktionen anderer Benutzer informiert.
Mit dem Aufkommen des Begriffs e-Commerce ging man davon aus, dass allein der Betrieb eines Online-Shops Umsatz beschert. Inzwischen haben viele Betreiber von Online-Shops erkannt, dass Aspekte wie z.B. Versand und Inkasso dabei oftmals vernachlässigt worden sind und vernachlässigt werden. Ein wesentlicher Aspekt von Online-Shops ist, Kunden langfristig an sich zu binden. Es ist bekannt, dass es wesentlich teurer ist, einen neuen Kunden zu gewinnen als einen vorhandenen zu behalten. Studien haben ergeben, dass ein Internet-Shop an einem Kunden erst nach vier Einkäufen oder 18 Monaten Treue verdient. Je länger ein Kunde gehalten wird, desto stärker steigen darüberhinaus dessen Ausgaben. Wie die McKinsey-Manager Hagel und Armstrong in ihrem Buch „Net Gain - Profit im Netz" (Net Gain: Expanding Markets Through Virtual Communities; Hagel, Armstrong; 1997) beschrieben haben, eignen sich virtuelle Communities hevorragend, um loyale Kunden zu gewinnen und zu binden, direktes Feedback zu bekommen sowie Kundenprofile und Umsätze zu generieren. Wie die in Net Gain vorgestellte Theorie auch in der Praxis funktioniert, zeigen herkömmliche Communities. Die Grundlage für die Treue der Benutzer bilden die Funktionalitäten der herkömmlichen Communities, mit der jeder einzelne durch und für die Gemeinschaft Mehrwerte erzielen kann.
Herkömmlicherweise schliessen sich Menschen in Communities meist zu kleineren Gruppen zusammen, um dort spezielle Interessen zu verfolgen und bestimmte Teilziele zu erreichen. Dasselbe Verhaltensmuster ist in Unternehmen zu beobachten: Organisationen sind immer seltener von starren Strukturen und Hierarchien geprägt, sondern immer stärker durch weitgehend eigenständige Teams und Einheiten, die häufig auch nur vorübergehend existieren. Parallel dazu gibt es einen Trend zu mehr räumlich und zeitlich verteilter Zusammenarbeit. Genau betrachtet sind Unternehmen damit nichts anderes als Communities: Sie sind eine Gemeinschaft von Menschen mit gleichgerichteten Interessen, die auf viele Teilziele und ein gemeinsames Hauptziel hinarbeiten.
Ferner verändern sich heutzutage Märkte rasend schnell, werden transparenter und lassen über Nacht aus verteilten Organisationen neue Allianzen entstehen. Um dem Wettbewerb immer einen Schritt voraus zu sein, müssen Geschäftsprozesse beschleunigt und Geschäftspartner in diese integriert werden.
Weiterhin geht mit der Veränderung von Unternehmensstrukturen die Delegierung von Verantwortlichkeiten einher. Ein System, das unternehmensweit sowie mit Kunden und Partnern die Kommunikation unterstützen und fördern will, muss dem Rechnung tragen. Viele herkömmliche Systeme kranken daran, dass ein zentraler Administrator benötigt wird, der Benutzer einrichten und Rechte vergeben muss. Bei grösse- ren Benutzerzahlen stösst ein solches System schnell an seine Grenzen. Eine Zu- sammenführung von Internet-Website und Unternehmensprozessen ist praktisch nicht möglich.
Somit besteht Bedarf an einem Kommunikationssystem in Form einer Community, das diesen Anforderungen gerecht wird.
Der Erfindung liegt die Aufgabe zugrunde, ein verbessertes Kommunikationssystem, insbesondere eine verbesserte Community bereitzustellen. Diese Aufgabe wird mit den Merkmalen der Ansprüche gelöst.
Das erfindungsgemäße Kommunikationssystem, insbesondere eine erfindungsgemäße Community, ist modular aufgebaut und weist gemäß einem ersten Aspekt der er- findung eine Applikationsschicht (2), eine Präsentationsschicht (3) und eine Datenhaltungsschicht (4) auf. Die Applikationsschicht (2) weist eine Kerneinrichtung (21 ), mehrere Kernkomponenten (22) und mehrere Applikationskomponenten (23) auf. Gemäß einem weiteren Aspekt der Erfindung wird ein Kommunikationssystem mit einer Applikationsschicht (2), einer Präsentationsschicht (3) und einer Datenhaltungsschicht (4) bereitgestellt, wobei das Kommunikationssystem mehrere virtuelle Arbeitsbereiche (5) aufweist.
Das erfindungsgemäße Kommunikationssystem erlaubt die gleichzeitige Kommunikation mit allen Kunden, die beispielsweise über das Internet auf das Komunikationssy- stem zugreifen, und die Erfassung von Kundenprofiien. Kunden können mittels des erfindungsgemäßen Komunikationssystems miteinander in Kontakt treten. Außerdem unterstützt das erfindungsgemäße Komunikationssystem den Daten- und Informationsaustausch innerhalb eines Unternehmens. Der Vorteil des erfindungsgemäßen Komunikationssystems liegt dabei in dessen Aufbau im Baukastensystem sowie in dessen modularer 3-Schichten Architektur. Durch die Bereitstellung von virtuellen Arbeitsräumen werden für unterschiedliche Benutzergruppen individuelle Kommunikationsumgebungen bereitgestellt. Die Erfindung wird im folgenden mit Bezug auf die Zeichnungen näher erläutert. Es zeigen:
Fig. 1 ein Beispiel für die erfindungsgemäße hierarchische Struktur der virtuellen Arbeitsbereiche des erfindungsgemäßen Kommunikationssystems;
Fig. 2 die detaillierte Architektur des erfindungsgemäßen Kommunikationssystems; und
Fig. 3 die dynamische Seitengenerierung in dem erfindungsgemäßen Kommunikationssystem.
Zunächst werden bevorzugte Elemente des erfindungsgemäßen Kommunikationssystems bzw. der erfindungsgemäßen Community beschrieben.
Architekturkonzept
Das erfindungsgemäße Kommunikationssystem bzw. die erfindungsgemäße Community basiert auf einer Architektur, die es jedermann erlaubt, unter Kenntnis der Schnittstellen beliebige Komponenten hinzuzufügen. Diese Komponenten können eine Reihe grundlegender Funktionalitäten, die durch Kernkomponenten (22) erbracht werden, in Anspruch nehmen. Die Architektur der erfindungsgemäßen Community ist unten näher erläutert.
Unterstützung beliebiger Endqeräte
Die erfindungsgemäße Community unterstützt beliebige Endgeräte. Dazu zählen z.B. Webbrowser und WAP-fähige Mobiltelefone.
Alle Endgeräte, die HTTP bzw. HTTPS als Kommunikationsprotokoll unterstützen, können mit dem erfindungsgemäßen Kommunikationssystem/der er indungsgemäßen Community bedient werden. Da erfindungsgemäß die Standardtechnologien XML (Extended Markup Language) und XSL (Extended Stylesheet Language) zugrunde liegen, ist für die Unterstützung unterschiedlicher bzw. diverser Clients kein Programmieraufwand nötig. Sollen Endgeräte bedient werden, die andere Protokolle verwenden, kann erfindungsgemäß eine Schicht der Community (Presentation Layer, siehe unten) anderweitig implementiert werden. Benutzerverwaltung
Wenngleich die erfindungsgemäße Community auch anonyme Benutzer bedienen kann, sind vorzugsweise viele Funktionen registrierten Benutzern vorbehalten. Benutzer können sich selbst in der Community registrieren (ebenso ist es möglich, Benutzer automatisch implizit zu registrieren). Ihre Attribute bzw. Profile können in beliebigen Benutzerverwaltungen verwaltet werden. Die erfindungsgemäße Community unterhält eine eigene Benutzerverwaltung. Sie stellt eine Implementierung einer Programmierschnittstelle dar, die für beliebige andere Implementierungen ebenso genutzt werden kann. Damit kann eine Community verschiedene Benutzer gleichzeitig in mehreren Verwaltungen organisieren. Viele Betreiber können somit ihre bisher vorhandene Benutzerverwaltung auch in der erfindungsgemäßen Community nutzen. Datentransformationen und/oder -synchronisierungen sind somit nicht notwendig.
Ferner wird erfindungsgemäß für jedes Benutzerattribut einer Benutzerverwaltung festgelegt, ob es vom Benutzer selbst gelesen und verändert (geschrieben) werden kann oder nicht. Somit können für Benutzer auch solche Attribute existieren (z.B. ein Kundenstatus), deren Werte „im Hintergrund" und für den Benutzer unsichtbar verwaltet werden.
Workspaces
Herkömmliche Systeme unterscheiden meist nur zwischen registrierten und nicht- registrierten Benutzern. Einige Systeme ermöglichen es zusätzlich, für Gruppen von einzelnen, registrierten Benutzern virtuelle Arbeitsbereiche einzurichten, zu denen nur diese Zugang haben.
Erfindungsgemäß wird ein System zur Verfügung gestellt, mit dem beliebig viele virtuelle Arbeitsbereiche (sogenannte Workspaces) eingerichtet werden können. Workspaces sind virtuelle Räume, die Benutzer und Informationen/Funktionalitäten in einen Kontext bringen. Informationen stehen in den Workspaces vorzugsweise in Form einzelner Diskussionsforen, Konferenzräumen, Gruppenkalendern, Dokumentenablagen oder Workflows zur Verfügung. Workspaces können Abteilungen, Teamräume oder einzelne Themenbereiche einer Themencommunity abbilden. Sie können für Gruppen wie Projektteams, oder anderen Interessengruppen gebildet werden. Workspaces des erfindungsgemäßen Kommunikationssystems unterscheiden sich von herkömmlichen Konzepten/Systemen durch folgende Eigenschaften:
1. Hierarchie:
Workspaces existieren erfindungsgemäß nicht voneinander losgelöst, sondern bilden eine Hierarchie. Von einem Workspace aus, der die Wurzel bildet, können weitere Workspaces angelegt werden, die wiederum weiter untergliedert werden können. Damit können beliebige Baumstrukturen wie in Fig. 1 gezeigt gebildet werden. In dem in Fig. 1 gezeigten Beispiel ist der oberste Workspace 51 - die Wurzel - für die Öffentlichkeit zugänglich. Ein Unter- Workspace 52 stellt das Intranet - einen Bereich nur für Mitarbeiter - dar. Der andere Zweig 53 „clients" ist für Kunden vorgesehen. Diesem Workspace sind wiederum zwei Workspaces „Sales" 54 und „Support" 55 zugeordnet. In den einzelnen Workspaces können Funktionalitäten einzelner Module bzw. Applikationskomponenten benutzt werden - z.B. Chaträume, Diskussionsforen und Dokumentenablagen.
Benutzer gehören einem oder mehreren Workspaces an. Sofern sie einem untergeordneten Workspace angehören, können sie automatisch auch allen übergeordneten Workspaces angehören (Beispiel mit drei Workspaceebenen: Ein Mitarbeiter eines Projektteams gehört auch einer Abteilung und damit auch dem gesamten Unternehmen an).
In der Hierarchie absteigend werden Benutzergruppen und gesperrte Wörter vererbt.
2. Zugehörigkeit zu Workspaces:
Ein registrierter Benutzer kann erfindungsgemäß einem oder mehreren Workspaces angehören. Er muß sich dazu nicht mehrfach registrieren, sondern kann auf Basis seiner Registrierung über folgende alternative Mechanismen Angehöriger eines Workspaces werden: • implizit durch bestimmte Eigenschaften:
Jeder Benutzer verfügt über Attribute. Ein Workspace kann so konfiguriert werden, dass Benutzer mit bestimmten Attributen automatisch diesem Workspace an- gehören.
• explizit durch Aufnahmeantrag:
Ein Benutzer kann einen Antrag stellen, um einen Workspace anzugehören. Der Antrag wird von einem ausgewiesene Benutzer, der diesem Workspace bereits angehört, positiv oder negativ bescheinigt werden.
• explizit durch Einladung:
Ein ausgewiesener Benutzer kann einen Benutzer einladen, indem er für diesen eine Zugangsberechtigung in Form eines Passwortes generiert. Der Empfänger des Passwortes muß dieses innerhalb der Community eingeben, um die Zugehörigkeit zum Workspace zu erlangen.
• Explizit durch Erklärung:
Ein Benutzer kann, sofern er einer bestimmten Benutzergruppe angehört, sich als zu einem Workspace zugehörig erklären.
3. Dezentrale Verwaltung durch Rechtekonzept:
Ein Merkmal der erfindungsgemäßen Workspaces ist, dass diese nicht zentral administriert werden müssen. Vielmehr verfügen einzelne Benutzer über Rechte, die es ihnen erlauben, diverse Konfigurationen vorzunehmen. Konfigurationen sind z.B. die Vergabe von Zugangsberechtigungen zum Workspace (z.B. „nur Mitarbeiter"), Einladung von bestimmten Benutzern in den Workspace, Anlegen von Modulinstanzen wie z.B. Diskussionsforen, Chaträume und Dokumentenablagen, die Vergabe von Lese- und Schreibrechten für Modulinstanzen, die sich im Workspace befinden (z.B. „Kunden dürfen lesen, Mitarbeiter aus dem Marketing-Team dürfen lesen und schreiben"), oder das Anlegen von untergeordneten Workspaces (z.B. für Sales-Teams, die unterschiedliche Branchen oder Regionen betreuen).
4. Schreib-/Leserechte
In den Workspaces existieren Instanzen diverser Module: Diskussionsforen, Chaträume, Dokumentablagen etc. Erfindungsgemäß können für jede dieser Instanzen Schreib-/Leserechte vergeben werden. Diese Rechte werden nicht explizit an einzelne Benutzer vergeben, sondern implizit an Benutzer mit bestimmten Attributen. Die Vergabe der Rechte erfolgt durch ausgewiesene/berechtigte Benutzer. Workspaceübergreifende Module
Neben Modulinstanzen bzw. Applikationskomponenten/Kommunikationskomponenten, die in den Workspaces angesiedelt sind (z.B. Diskussionsforen und Chaträume) existieren erfindungsgemäß workspaceübergreifende (oder workspaceunabhängige) Module, die sich auf die einzelnen Benutzer beziehen. Sie können von den Benutzern in allen Workspaces verwendet werden. Beispiele sind persönliche Kalender, Gästebücher, Mailboxes und Aufgaben listen. In den Workspaces kann jeweils konfiguriert werden, ob die Benutzer darin die workspace- übergreifenden Module nutzen können oder nicht.
Benutzergruppen
Über den Profilen einzelner Benutzer, die in den Benutzerverwaltungen gespeichert sind, werden erfindungsgemäß vorzugsweise Benutzergruppen definiert. Dies können z.B. „Frauen über 30", „Männer aus München" oder „Abteilungsleiter in einer bestimmten Niederlassung" sein. Diese Benutzergruppen dienen dazu, für einzelne Informationen gezielt Schrei b-/Leserechte zu vergeben. Beispielsweise haben nur Kunden Schreibrechte in einem speziellen Diskussionsforum oder Konferenzraum; NichtKunden dürfen nur lesen. Als weiteres Beispiel werden Frauen an ein und derselben Position andere Inhalte angezeigt als Männern.
Definiert werden die Benutzergruppen durch berechtigte Benutzer in den Workspaces. In der Workspacehierarchie werden Benutzergruppendefinitionen vererbt. Untergeordnete Workspaces übernehmen also Definitionen von Benutzergruppen von den übergeordneten Workspaces und können zusätzliche Benutzergruppen definieren, die sie wiederum weitervererben.
Belohnungssvstem/Punkte
Die erfindungsgemäße Community weist in einer bevorzugten Ausführungsform ein integriertes Belohnungssystem auf, das Benutzer dazu animiert, die Community aktiv zu nutzen. Einzelne Module vergeben den Benutzern Punkte, sofern diese aktiv sind, d.h. aktiv Beiträge und Inhalte in die Community einbringen. Dies sind z.B. Beiträge zu Diskussionsforen, Gästebüchern oder eingebrachte Dokumente. Jeder Benutzer verfügt pro Workspace über ein Punktekonto. Der Punktestand spiegelt seine Aktivi- tat im jeweiligen Workspace wider. In jedem Workspace kann für die zugehörigen Benutzer eine Rangliste erzeugt werden. Das Punktekonto wird als Attribut der Benutzer betrachtet, so dass Schreib- und Leserechte von der Aktivität der Benutzer abhängig gemacht werden können. Auf das Punktekonto können externe Systeme über Schnittstellen zugreifen, so dass z.B. Shopsysteme aktiven Benutzern spezielle, günstigere Angebote machen können als weniger aktiven Benutzern. Wieviele Punkte für welche Aktivität vergeben werden, legen berechtigte Benutzer in den Workspaces fest.
Filth Filter (..Schmutzfilter")
In den Workspaces können berechtigte Benutzer erfindungsgemäß konfigurieren, welche Wörter Benutzer beim Einstellen von Beiträgen nicht verwenden dürfen. Versucht ein Benutzer, einen Beitrag einzubringen, der ein gesperrtes Wort enthält, wird der Beitrag abgelehnt. Die gesperrten Wörter werden in der Workspacehierarchie absteigend vererbt (wie Benutzergruppendefinitionen). Untergeordnete Workspaces übernehmen die Filth Filter übergeordneter Workspaces und können eigene Wörter hinzufügen.
Sessionverwaltung
Die erfindungsgemäße Community verwaltet Sessions („Sitzungen") von Benutzern über alle Module und Funktionen der Community hinweg. Eine Session beginnt mit einem expliziten Login eines Benutzers oder mit einem automatischen/impliziten Login und endet mit dessen expliziten Logout oder nach einem Timeout, wenn der Benutzer längere Zeit keine Anfrage mehr an die Community gesendet hat. Im Rahmen einer Session kann ein Benutzer alle Komponenten und Funktionen nutzen, ohne sich mehrfach einloggen zu müssen. Die Besonderheit der Sessionverwaltung der erfindungsgemäßen Community ist, dass eine Programmierschnittstelle zur Verfügung steht, über die beliebige Sessionverwaltungen implementiert werden können. Damit ist es z.B. möglich, Sessions auch per Cookies zu verwalten.
Personalisierung
Alle Inhalte der erfindungsgemäßen Community können personalisiert, also auf einzelne Benutzer individuell zugeschnitten werden. Insbesondere kann dabei auf die Benutzergruppen zurückgegriffen werden, so dass unterschiedliche Benutzergruppen mit unterschiedlichen Inhalten versorgt werden können.
Awareness durch Benachrichtigungssvstem
In die erfindungsgemäße Community integriert ist ein Benachrichtigungssystem, das Benutzer ständig über Aktivitäten und Ereignisse, die sie betreffen, informiert. Die Benachrichtigungen erscheinen je nach Bedeutungsgrad innerhalb der Benutzeroberfläche (volatile Benachrichtigung) oder werden in der persönlichen Mailbox des Benutzers gespeichert (persistente Benachrichtigung), können aber auch per SMS, E-Mail oder andere Push-Mechanismen aktiv zugestellt werden. Benachrichtigungen werden durch einzelne Komponenten versendet, d.h. welche Benachrichtigungen erzeugt werden wird durch die Komponenten bestimmt.
Benutzer können in einer persönlichen Buddy-List andere Benutzer verwalten und diese in verschiedene Kategorien einordnen, z.B. Freunde, Verwandte oder Kollegen. Über das Benachrichtigungssystem werden die Benutzer insbesondere über Aktionen dieser „Buddies" informiert. Volatile Benachrichtigungen sind beispielsweise „ein Benutzer aus der Buddylist betritt/verläßt die Community" oder „Eingang einer neuen Mail". Persistente Benachrichtigungen sind beispielsweise „Eingang eines Meeting- Requests" oder „Eingang einer neuen Aufgabe".
Einem Benutzer kann jederzeit angezeigt werden, wie viele und welche Benutzer gerade online sind. Diese Angabe kann sich auf die gesamte Community oder vorzugsweise auf einzelne Workspaces beziehen. Damit wird die sog. Awareness gestärkt, d.h. Benutzer erfahren in der Community, dass diese zeitgleich auch von anderen Benutzern genutzt wird. Sie können einfach mit diesen in Kontakt treten.
Informationseinheiten
Alle in der erfindungsgemäßen Community verwalteten Informationen - z.B. Einträge in Diskussionsforen, Chaträume, Dokumente, Webseiten etc. - werden mit einheitlichen Attributen (Autor, Titel, Zeitpunkt der Erstellung und Änderung, auftretende Schlüsselwörter, Schreib-/Leserechte, zugehöriger Workspace, Anzahl der Abrufe, Bewertung durch Benutzer) versehen. Diese Attribute können um weitere Attribute ergänzt werden. Damit ist ein einheitlicher Zugriff auf alle Informationen unabhängig von deren Typ möglich. Die mit Attributen versehenen Informationen werden als Informationseinheiten bezeichnet.
Die Informationseinheiten bilden die Grundlage für folgende Funktionalitäten, die die erfindungsgemäße Community bietet:
1. Suchmechanismus
Über einen Suchmechanimus können Benutzer nach dem Vorkommen von Begriffen suchen. Gesucht wird in allen Informationseinheiten oder in denen, die einem bestimmten Workspace zugeordnet sind. Es werden Leserechte berücksichtigt, so dass als Suchergebnisse nur solche Informationen geliefert werden, für die der Benutzer auch Leserechte hat. Die Informationseinheiten werden zusätzlich parallel von einem System indiziert, das nicht mit Schlüsselwörtern arbeitet, sondern in Informationen Muster unabhängig von Sprache und Typ der Information erkennt. Damit können auch solche Informationen gefunden werden, in denen die gesuchten Begriffe nicht selbst, sondern verwandte Begriffe vorkommen. Beispiel: Bei einer Suche mit dem Begriff „Auto" werden auch solche Informationen gefunden, in denen nicht „Auto", sondern „Kfz" und „vier Räder" vorkommen.
2. Automatische Empfehlungen
Ein Suchmechanismus muss nicht unbedingt explizit durch einen Benutzer angestoßen werden. Es ist ebenso möglich, den Benutzer abhängig vom Kontext auf relevante bzw. thematisch verwandte Informationen hinzuweisen, die sich innerhalb oder außerhalb der Community befinden. Der Kontext wird durch die Informationen bestimmt, die der Benutzer aktuell abruft oder in der Vergangenheit abgerufen hat. Im ersten Fall können ihm Verweise auf vorhandene Informationen angeboten werden, die zu der gerade abgerufenen Information als verwandt erachtet werden (Beispiel: Ein Benutzer ruft eine Webseite auf, die sich mit Tennissport auseinandersetzt. Die Community kann ihm automatisch Referenzen auf Diskussionsforen und andere Webseiten anbieten, die sich mit ebenfalls mit Tennissport, -tumieren oder -Spielern beschäftigen). Im zweiten Fall kann er aktiv benachrichtigt werden, sobald neue In- formationen indiziert werden, die verwandt sind mit Informationen, die der Benutzer in der Vergangenheit abgerufen hat. Entsprechende Hinweise können innerhalb der Community angezeigt werden, aber auch per SMS, E-Mail oder anderer Benachrichtigungssysteme an den Benutzer gesendet werden.
3. Rating/Bewertung
Benutzer können jede Informationseinheit bewerten (Beispiel: Ein Forenbeitrag, der von Benutzern als besonders gut eingestuft wird, hat eine höhere Bewertung als ein Forenbeitrag, dessen Inhalt als weniger gut eingestuft wird). Jeder Benutzer kann pro Informationseinheit maximal einmal eine Bewertung abgeben. Die Bewertungen fließen in Suchergebnisse ein, d.h. besser bewertete Informationen rangieren in einer Ergebnisliste weiter oben als schlechter bewertete Informationen.
4. Abrechnung
Informationseinheiten können vorzugsweise mit Preisen versehen werden. Der Preis einer Informationseinheit wird von einem Konto des Benutzers abgezogen, wenn er die Information abruft. Es kann konfiguriert werden, dass der mehrmalige Abruf einer Informationseinheit innerhalb einer Session/Sitzung nur einmal berechnet wird. Das Konto selbst ist nicht vorgegeben, sondern kann über eine Schnittstelle beliebig implementiert werden. Es besteht die Möglichkeit, als Konto das Punktekonto eines Benutzers zu verwenden.
5. Tracking (Protokollierung)
Die erfindungsgemäße Community protokolliert in einer bevorzugten Ausführungsform, welcher Benutzer zu welchem Zeitpunkt welche Informationseinheit abgerufen hat. Damit werden genauere Benutzerprofile erzeugt, die über Schnittstellen in andere Systeme überführt werden können. Vozugsweise werden die gesammelten Daten anonymisiert, d.h. sie werden nicht einzelnen Benutzern, sondern Benutzergruppen zugeordnet, denen die Benutzer angehören. Matchmaking
Mit Matchmaking wird die Funktionalität beschrieben, die es Benutzern erlaubt, andere Benutzer mit bestimmten Profilen zu finden, die ebenfalls registrierte Benutzer der Community sind. Es stehen zwei Verfahren zur Verfügung: (i) explizit: Ein Benutzer kann explizit angeben, welche Attribute (z.B. Qualifikation, Position, Geschlecht, Alter) ein Benutzer haben soll, den er auffinden möchte; (ii) implizit: Einem Benutzer werden andere Benutzer vorgeschlagen, die ein ähnliches Profil (Attribute oder Interessensschwerpunkte) wie er selbst haben. Jeder Benutzer kann entscheiden, ob er für andere Benutzer auffindbar ist.
Im folgenden wird die Architektur des erfindungsgemäßen Kommunikationssystems näher erläutert.
Das erfindungsgemäße Kommunikationssystem 1 bzw. die erfindungsgemäße Community basiert auf einer 3-Schichten-Architektur (Three-Tier-Ärchitecture), so dass einzelne Schichten oder deren Bestandteile ausgetauscht werden können, ohne dass andere Schichten dabei verändert werden müssen. Fig. 2 veranschaulicht diese 3- Schichten-Architektur mit Application Layer (Applikationsschicht) 2, Presentation Layer (Präsentationsschicht) 3 und Data Access Layer (Datenhaltungsschicht) 4. Die Application Layer weist die Applikationslogik auf, die unabhängig von der endgültigen Darstellung und den verwendeten Endgeräten (Webbrowser, WAP-fähige Mobiltelefone etc.) ist. Für den Zugriff auf dauerhaft gespeicherte Daten greift sie auf Funktionalitäten der Data Access Layer zurück. Die Presentation Layer ist mit einer Eingabeeinrichtung und einer Anzeigeeinrichtung verbunden, über die ein Benutzer mit dem Kommunikationssystem Daten/Informationen eingibt bzw. austauscht. Insbesondere werden über die Präsentationsschicht Anfragen der Clients beantwortet. In den meisten Fällen müssen Antworten (z.B. Webseiten) dynamisch in Abhängigkeit des einzelnen Benutzers aufbereitet werden. Zu diesem Zweck werden Funktionen der Application Layer aufgerufen. Die Presentation Layer versieht diese Informationen mit Layout, das auf den jeweils anfragenden Client zugeschnitten ist (z.B. HTML (Hyper- Text Markup Language) für Webbrowser und WML für WAP-fähige Mobiltelefone). Die Data Access Layer ist für die Verwaltung dauerhaft gespeicherter Daten zustän- dig. Sie bietet der Application Layer eine Schnittstelle an, die unabhängig vom verwendeten Speichermedium (z.B. SQL-Datenbankmanagement-System (SQL = Structured Query Language) ist. Erfindungsgemäß dient diese Trennung von Programmlogik und Darstellung (Präsentation) dazu, dass auf der Applikationsebene nur Informationen verarbeitet werden, die ausschliesslich auf der Präsentationsebene mit Layout versehen werden.
Die einzelnen Schichten werden im folgenden näher erläutert.
Application Laver (Applikationsschicht)
Die Applikationsschicht übernimmt zentrale Verwaltungsaufgaben des erfindungsgemäßen Kommunikationssystems und beantwortet Anfragen der Präsentationsschicht. Während herkömmliche Application Server aus einem Basissystem und darauf aufbauenden Komponenten bestehen, verfügt die erfindungsgemäße Community über folgende Bestandteile:
Basissystem 21 Kern des Systems
(„Gore")
Core Components Kernkomponenten des Systems (s.u.) 22
Application CompoKomponenten, mit denen die Community um spezielle Funktionents 23 nalitäten erweitert werden können. Application Components (Applikationskomponenten) können von jedermann mit Kenntnis der entsprechenden Programmierschnittstellen entwickelt werden. Sie greifen auf Funktionalitäten der Core Components zu, indem sie deren Programmierschnittstellen nutzen.
Eine zentrale Bedeutung kommt den Core Components zu. Sie bieten grundlegende und umfassende Funktionalitäten an, die von allen Application Components genutzt werden können. Sie sind in ihrer Ausprägung und Kombination einzigartig. Aufgrund der Fülle von Kernfunktionalitäten ist die Entwicklung von Application Components vereinfacht. Dieser Vorteil wird zusätzlich dadurch verstärkt, dass erfindungsgemäß Application Components unabhängig von den Endgeräten und der zugrundeliegen- den persistenten Datenhaltung entwickelt werden können, da sie Bestandteil der Application Layer sind. Application Components werden über klar definierte Schnittstellen in die erfindungsgemäße Community eingebunden. Ihre Zahl ist nicht begrenzt. Die erfindungsgemäße Community weist vorzugsweise eine Reihe von Application Components auf - z.B. Diskussionsforen, Chat, Gruppenterminkalender, Aufgaben- und Projektverwaltung etc.
1. Core Components (Kernkomponenten)
Die verschiedenen erfindungsgemäßen Kernkomponenten werden im folgenden erläutert:
UserManager
Der UserManager ist eine Einrichtung 211 , die für die Verwaltung der registrierten Benutzer verantwortlich ist. Bei der Registrierung geben Benutzer ihr Profil an, welches vom UserManager gespeichert wird. Die Registrierung im UserManager ist nicht zu verwechseln mit der Mitgliedschaft in einzelnen Workspaces. Die Registrierung ist keine Pflicht, um das System nutzen zu können. Der SessionManager (s.u.) unterstützt auch Sessions von Gästen. Application Components müssen jeweils entscheiden, ob sie unregistrierten Benutzern ihre Dienste freischalten. Der UserManager ist für die Erzeugung der Benutzer und deren Kennungen im System verantwortlich. Er unterstützt die gleichzeitige Anbindung von mehreren Benutzerverwaltungen (Domains). Standardmäßig werden die Benutzer in der Domain „nativedomain" gespeichert. Über eine Schnittstelle können andere/zusätzliche Domains angedockt werden.
Wichtiger Bestandteil des UserManagers ist die Speicherung der einzelnen Profilfelder, der sog. Attribute. Jede Domain definiert ihre eigenen Attribute und meldet diese im UserManager an.
SessionManager
Der SessionManager ist eine Einrichtung 212, die für das Ein- und Ausloggen der Benutzer verantwortlich ist. Bei jedem Einlogvorgang legt der SessionManager ein Session-Objekt für den Benutzer an. Über den SessionManager können in einer be- vorzugten Ausführungsform auch Sessions anderer Benutzer sowie eine Liste aller angemeldeten Benutzer angefordert werden. Prinzipiell gibt es vier verschiedene Arten von Sessions: (i) registrierter Benutzer: ein im UserManager registrierter Benutzer hat sich angemeldet; (ii) Gast: ein im UserManager nicht registrierter Benutzer hat sich angemeldet, wobei er einen (temporären) Namen angegeben hat; (iii) Anonymer Gast: ein im UserManager nicht registrierter Benutzer hat sich angemeldet, wobei er keinen Namen angegeben hat; (iv) Lurker: Benutzer ohne Session ("lurkers"), die sich nicht eingeloggt haben. Applications Components können zudem beliebige Objekte im Session-Objekt des Benutzers temporär speichern. Dies kann beispielsweise ein Warenkorb oder eine Mailbox sein.
WorkspaceManager
Der WorkspaceManager ist eine Einrichtung 220 zum Verwalten der Workspaces. Dazu gehören Workspaceltems (Instanzen einzelner Module wie z.B. Diskussionsforen), die Angehörigen eines Workspaces sowie die Workspaces selbst. Angehörige eines Workspace können nur im UserManager registrierte Benutzer werden. Einzelne im Workspace lokal angemeldete Benutzer verfügen vorzugsweise über spezielle Rechte im Workspace, die sog. „WorkspacePermissions". Im Gegensatz hierzu sind die Zugriffsrechte der Workspaceltems an Benutzergruppen gekoppelt. Jede Applikationskomponente kann ihre eigenen Zugriffsrechte definieren und diese vom WorkspaceManager verwalten lassen. Standardmässig gibt es Lese- und Schreibrechte. Zur Definition der Zugriffsrechte auf Workspaceltems sind Benutzergruppen notwendig. Diese werden ebenfalls vom WorkspaceManager verwaltet. Die Workspaces vererben ihre Benutzergruppen an ihre Kinder weiter.
EventDispatcher
Ein bevorzugter Bestandteil 221 der Applikationsschicht ist der Event-Mechanismus. Es existiert eine Vielzahl von Events (Ereignisse), die die Komponenten untereinander austauschen. Beispielsweise werden auch die Anfragen aus der Presentation- Layer in speziellen Events weitergeleitet. Es gibt zwei unterschiedliche Arten von Events: (i) Broadcast-Events: Diese Events werden an alle Komponenten weitergeleitet, die den entsprechenden Event-Typ abonniert haben; (ii) Singlecast-Events: Der Event ist an eine spezielle Komponente adressiert. Darüberhinaus können Events synchron oder asynchron ausgeliefert werden. Nur bei synchronen Events besteht die Möglichkeit, Ergebnisse an die aufrufende Komponente zu übermitteln. Asynchrone Events hingegen blockieren die Antwort nicht und ermöglichen eine schnellere Abarbeitung.
Die folgende Tabelle gibt einen Überblick über bevorzugte Event-Typen:
PersistentNotificationE- multi Asynchron Versendung einer persistenten Notivent fikation
VolatileNotificationEvent multi Asynchron Versendung einer volatilen Notifikation
UserRegistrationEvent multi Synchron Benutzer (de-)regist ert sich im UserManager
SessionStateEvent multi Asynchron Benutzer meldet sich an oder ab
CallEvent Single Synchron Event zur Kommunikation zwischen (Applikations-) Komponenten
PeriodicalEvent multi Asynchron Auslösen von periodischen Events. Dient zum Aufruf von Routineaufgaben in der Komponente ohne Erzeugung eines eigenen Threads
DataAccessManager
Der DataAccessManager ist eine Einrichtung 214, die die Verbindung zur Data Access Layer darstellt. Er stellt eine Schnittstelle dar, die es Komponenten in der Applikationsschicht erlaubt, auf persistente Daten unabhängig vom Speichermedium zuzugreifen.
Request Dispatcher
Die Einrichtung/Komponente Request Dispatcher 213 bildet die Schnittstelle zur Presentation Layer. Sie nimmt die Anfrage entgegen und erzeugt Events, die an den EventDispatcher übergeben werden. Nachdem die Anfrage von der adressierten Komponente abgearbeitet wurde, leitet der RequestDispatcher das Ergebnis weiter an die Presentation-Layer.
ContainerManager
Der ContainerManager ist eine Einrichtung 225 zum Verwalten von Containern für Applikationskomponenten. Container bieten eine Kontext für verschiedene Implementierungen eines Moduls bzw. Application Components (Es ist z.B. möglich, zwei verschiedene Implementierungen der Application Component Discussion zu betreiben).
Nicht nur Applikationskomponenten befinden sich in einem Container, sondern prinzipiell alle Komponenten. Es ergibt sich folgende Hierarchie:
ApplicationContext Core-Komponenten (u.a. ContainerManager)
ContainerManager Container für Applikationskomponenten
Container für ApplikationskompoApplikationskomponenten nenten
AdministrationManager
Der AdministrationManager ist eine Einrichtung 222 zum Verwalten von Zugangsberechtigungen für die technische Server-Administration (die nichttechnische Administration findet durch Benutzer in den Workspaces der Community statt). Die technische Administration wird über eine Oberfläche durchgeführt.
InformationUnitManager
Der InformationUnitManager ist eine Einrichtung 223 zum Verwalten der Informationseinheiten der einzelnen Komponenten. FileAccessManager
Der FileAccessManager ist eine Einrichtung 224 zum Speichern von binären Dateien, die nicht in der gewöhnlichen Datenhaltung (über die Data Access Layer) abgelegt werden können.
2. Application Components (Applikationskomponenten)
Application Components sind Einrichtungen 23, die die Module darstellen, um die die erfindungsgemäße Community durch jedermann erweitert werden kann. Über klar definierte Programmierschnittstellen können diese in die Community integriert werden. Erfindungsgemäß bietet die Community folgende Application Components an (durch „:" getrennte Namen geben an, dass sie eine Komponente erweitern):
Figure imgf000020_0001
Figure imgf000021_0001
Die Vorteile dieser Struktur der Applikationsschicht liegen in der einfachen Erweiter- barkeit und Integration durch Hinzufügen von Application Components, der geringen Komplexität der Module durch Nutzung zentraler Funktionalitäten der Core Components, der Integrität der Komponenten und der Unabhängigkeit von Endgeräten durch Trennung von Applikationslogik und Darstellung
Presentation Layer (Präsentationsschicht)
Die Präsentationsschicht 3 weist vorzugsweise die folgenden Merkmale auf.
1. Kommunikation zwischen Client und Server
Mit der Präsentationsschicht 3 werden Anfragen von Benutzern entgegengenommen und als Antwort dynamisch generierte XML-Dokumente oder - im speziellen Fall - HTML-Seiten zurück geliefert. Das Protokoll, über das der Client mit der Präsentationsschicht kommuniziert, ist standardmässig HTTP. HTTP-Anfragen werden von einem Java-Servlet entgegengenommen. Im Lieferumfang der Community ist ein HTTP- Webserver enthalten, der optional durch einen anderen Servlet-fähigen Webserver (z.B. Apache) ersetzt werden kann.
2. Templates
Die Templates 31 („Vorlagen für Webseiten") sind wie bei herkömmlichen Webservern, die statischen Content liefern, im Dateisystem organisiert: es können beliebige Verzeichnisstrukturen und Datei-/Verzeichnisnamen gewählt werden. Rein statische Websites können auf die erfindungsgemäße Community übertragen werden, so dass eine vorhandene Website weiterbetrieben und sukzessiv durch Community-Features erweitert werden kann (HTML-Templates müssen den Regeln des XML-Standards entsprechen). Um eine optimale Performance zu erreichen, werden die Templates vorzugsweise serverseitig gecached. Während des Lesevorgangs wird ein Template vorzugsweise von einem XML-Parser eingelesen und intern in einer optimierten Struktur vorgehalten.
Workspaces werden auf die Verzeichnisstruktur der Templates gemapped, d.h. be- stimmte Verzeichnisbäume enthalten die Templates eines bestimmten Workspaces.
3. Trigger und Stylesheets
Die Ausgabe an einer Anzeigeeinrichtung mittels der Präsentationsschicht wird in Form von XML-Dokumenten bzw. HTML-Seiten zur Laufzeit aus Templates generiert, die definierte Platzhalter bzw. Tags enthalten. Diese Platzhalter - im folgenden Trigger genannt - werden zur Laufzeit dynamisch ersetzt und geben an, was an ihrer Stelle eingesetzt werden soll. Die Präsentationsschicht isoliert die Trigger und übergibt diese an die Applikationsschicht, in der die zuständige Komponente (z.B. das Calendar-Modul) die Anforderung verarbeitet. Als Antwort wird die erzeugte Information in Form eines XML-Fragments zurückgegeben. Dieses wird durch Anwendung eines XSL-Stylesheets in eine beliebige Ausgabesprache (z.B. HTML) umgewandelt, bevor es anstelle des Triggers in das Template eingesetzt wird. Sobald alle Trigger im Template ersetzt sind, wird die angeforderte Seite an den Client geschickt (vgl. Fig. 3).
Jede Komponente der Application Layer kann Trigger definieren und diesen Funktionalitäten zuweisen.
Für jeden Trigger existiert jeweils ein vordefiniertes XSL-Stylesheet, das beliebig an- gepasst werden kann. Damit können dynamisch generierte Elemente (z.B. eine Liste von Diskussionsforen oder ein Kalenderblatt) bis ins Detail individuell gestaltet werden. Mehrere Vorkommen eines Triggers können optional mit verschiedenen Stylesheets verknüpft werden, so dass dieselbe Information unterschiedlich präsentiert werden kann. Beispielsweise kann eine Seite für verschiedene Endgeräte (z.B. Webbrowser und WAP-fähige Mobiltelefone) oder Benutzergruppen unterschiedlich dargestellt werden. So wie der XML-Parser kann auch der mitgelieferte XSL-Prozessor durch andere Prozessoren ersetzt werden.
4. Virtual Documents (Virtuelle Dokumente)
In einigen Fällen (z.B. beim Registrieren) ruft ein Benutzer nicht ein Template (bzw. eine Seite) auf, um sich dadurch indirekt einzuloggen, sondern er ruft explizit einen Dienst auf, mit dem implizit die Ausgabe einer bestimmten Seite verbunden ist. Da es beim Aufruf solcher Dienste verschiedene Antworten bzw. Antwortseiten geben kann (z.B. „Registrierung erfolgreich" und „Registrierung nicht erfolgreich"), steht ein weiteres Verfahren zur Verfügung: Zum Aufruf von Diensten ruft der Benutzer ein sogenanntes Virtual Document auf. Der Aufruf wird durch Rückgabe eines mehrerer alternativer Virtual Documents beantwortet. Dieses Antwort-Dokument ist virtuell, d.h. der Benutzer bekommt es nicht zu sehen. Stattdessen wird das Virtual Document gemäß einer zentralen Konfiguration auf ein tatsächlich existierendes Dokument bzw. Template gemapped, das dem Benutzer schließlich angezeigt wird.
Die beschriebene Struktur der Präsentationschicht weist folgende Vorteile auf:
• Unterstützung von Standardtechnologien wie HTTP, HTML, XML, XSL und Java
• einfache Dokumentenstruktur wie bei herkömmlichen Webservern
• klare Trennung von Applikationslogik und Darstellung
• verschiedene Endgeräte wie Browser und WAP-Mobiltelefone können ohne Programmieraufwand bedient werden
• andere Protokolle als HTTP(S) können implementiert werden
• Ortsunabhängigkeit der Benutzer
• nahezu beliebige Gestaltungsmöglichkeiten bei der Benutzeroberfläche
Data Access Layer (Datenhaltungsschicht)
In der Datenhaltungsschicht werden Informationen dauerhaft gespeichert. Die erfindungsgemäße Community verfügt über eine Schnittstelle, über die beliebige Datenhaltungssysteme angedockt und für die Datenspeicherung verwendet werden können. Standardmässig werden SQL-fähige Datenbanken 41 unterstützt. Der Zugriff erfolgt per JDBC (Java Database Connectivity).
Der Applikationsschicht ist nicht bekannt, welches System für die Datenspeicherung verwendet wird. Sie greift auf Relationen zu, die auf das jeweils vorhandene Datenhaltungssystem gemapped werden. Damit können Application Components unabhängig vom jeweils zugrundeliegenden System entwickelt werden.
Die Vorteile einer solchen Datenhaltungsschicht sind (i) Unabhängigkeit der Applikation vom Datenhaltungssystem; (ii) Möglichkeit des Einsatzes nahezu beliebiger Datenhaltungssysteme; und (iii) Standardmäßige Unterstützung von SQL-Datenbanken via JDBC.
Die erfindungsgemäße Community bringt eine Vielzahl von Vorteilen mit sich: 100% Java-basiert Three-Tier-Architektur modularer Aufbau
Unterstützung diverser internationaler Industriestandards wie XML/XSL, HTML, JDBC und HTTP(S) umfangreiche Programmierschnittstellen zur Integration und Erweiterung klare Trennung von Applikationslogik und Darstellung durch Verwendung von XML/XSL
Unterstützung beliebiger Endgeräte (Webbrowser, WAP-Handies etc.) Unterstützung mehrerer und/oder beliebiger Benutzerverwaltungen komponentenübergreifende Sessionverwaltung optional Organisation einer Community in mehrere hierarchisch strukturierte Sub- communities bzw. Workspaces mit individuellen Zugriffsrechten einfache Struktur des Webspace wie bei herkömmlichen Webservern dynamische Seitengenerierung umfangreiche Personalisierungsmöglichkeiten integriertes Benachrichtigungssystem, das Benutzer über aktuelle Ereignisse und Aktionen anderer Benutzer informiert komponentenübergreifender Suchmechanismus
Im folgenden werden die Systemvoraussetzungen des erfindungssgemäßen Kommunikationssystems erläutert. Für den Betrieb der erfindungsgemäßen Community wird vorzugsweise eine SQL-fähige Datenbank mit JDBC-Treiber verwendet. Die Community greift per JDBC auf die Datenbank zu. Des weiteren wird eine Java Virtual Machine verwendet, in der die Community läuft. Die erfindungsgemäße Community ist plattformunabhängig. Bevorzugt ist der Einsatz folgender Betriebssysteme: Sun Solaris:
• Solaris 2.6 oder höher
• 128 MB Hauptspeicher
• 100 MB freier Festplattenplatz
Linux:
• Linux Redhat 6.1 oder höher
• 128 MB Hauptspeicher
• 100 MB freier Festplattenplatz
Microsoft Windows:
• Microsoft Windows NT 4.0/2000
• Service Pack 4 oder höher
• 128 MB Hauptspeicher
• 100 MB freier Festplattenplatz
Die erfindungsgemäße Community deckt eine grσsse Bandbreite von Anwendungen ab, u.a.:
• Persönlicher Kalender, über den Meetings mit anderen Benutzern bequem vereinbart und Teamevents eingetragen werden können
• Konferenzen per Audio und Video (über MS Netmeeting) oder Chat
• Integration von Datenbeständen, die in relationalen Datenbanken gehalten werden
• unmoderierte und moderierte Diskussionsforen
• gemeinsame Dokumentenverwaltung in Workspaces
• Mailsystem, über das externe Mailserver integriert werden können
• workflowbasierte Aufgabenverwaltung
• Projektunterstützung, die Workflows in Zusammenhang bringt und visualisiert
• Suche über in der Community vorgehaltenen Informationen (z.B. in Dokumenten und Diskussionsforen)

Claims

Patentansprüche
1. Kommunikationssystem (1 ) mit einer Applikationsschicht (2), einer Präsentationsschicht (3) und einer Datenhaltungsschicht (4), dadurch gekennzeichnet, dass die Applikationsschicht (2) eine Kerneinrichtung (21 ), mehrere Kernkomponenten (22) und mehrere Applikationskomponenten (23) aufweist.
2. Kommunikationssystem nach Anspruch 1, wobei die Kernkomponenten (22) Funktionalitäten aufweisen, die von allen Applikationskomponenten (23) verwendet werden können.
3. Kommunikationssystem nach Anspruch 1 oder 2, wobei eine der mehreren Kernkomponenten eine Einrichtung (211) zum Verwalten der regstrierten Benutzer des Kommunikationssystems (1 ) ist.
4. Kommunikationssystem nach Anspruch 1 , 2 oder 3, wobei eine der mehreren Kernkomponenten eine Einrichtung (212) für das Einloggen und Ausloggen der Benutzer ist.
5. Kommunikationssystem nach einem der Ansprüche 1 bis 4, wobei eine der mehreren Kernkomponenten eine Einrichtung (220) zum Verwalten von virtuellen Arbeitsbereichen ist.
6. Kommunikationssystem nach einem der Ansprüche 1 bis 5, wobei eine der mehreren Kernkomponenten eine Einrichtung (221 ) zum Verarbeiten von Ereignissen ist.
7. Kommunikationssystem nach einem der Ansprüche 1 bis 6, wobei eine der mehreren Kernkomponenten eine Einrichtung (214) zur Kommunikation der Applikationsschicht (2) mit der Datenhaltungsschicht (4) ist.
8. Kommunikationssystem nach einem der Ansprüche 1 bis 7, wobei eine der mehreren Kernkomponenten eine Einrichtung (213) zur Kommunikation der Applikationsschicht (2) mit der Präsentationschicht (3) ist.
9. Kommunikationssystem nach einem der Ansprüche 1 bis 8, wobei eine der mehreren Kernkomponenten eine Einrichtung (225) zum Verwalten von Container für die Applikationskomponenten ist.
10. Kommunikationssystem nach einem der Ansprüche 1 bis 9, wobei eine der mehreren Kernkomponenten eine Einrichtung (222) zum Verwalten von Zugangsbe- rechtigungen ist.
11. Kommunikationssystem nach einem der Ansprüche 1 bis 10, wobei eine der mehreren Kernkomponenten eine Einrichtung (223) zum Verwalten der Informationseinheiten der einzelnen Komponenten ist.
12. Kommunikationssystem nach einem der Ansprüche 1 bis 11 , wobei eine der mehreren Kernkomponenten eine Speichereinrichtung ist.
13. Kommunikationssystem nach einem der Ansprüche 1 bis 12, wobei die mehreren Applikationskomponenten (23) auf Funktionalitäten der mehreren Kernkomponenten (22) zugreifen können.
14. Kommunikationssystem nach einem der Ansprüche 1 bis 13, wobei die Applika- tionskomponeneten (23) ausgewählt sind aus der Gruppe Gästebuch, Kalender, e-mail, gemeinsame Dokumentenablage, persönliche Benutzerverwaltungsliste, Kommunikationsdienste, Karteikästen, Diskussionsforen, Mehrbenutzerspiele, Suchfunktion, Benutzerprofilerstellung, Protokollierung von Benutzerwegen.
15. Kommunikationssystem nach einem der Ansprüche 1 bis 14, wobei die Präsentationsschicht (3) Eingaben von Benutzem entgegennimmt und dynamisch generierte XML-Dokumente, insbesondere HTML-Seiten, zurückliefert.
16. Kommunikationssystem nach einem der Ansprüche 1 bis 15, wobei dynamisch generierte Ausgabedokumente aus Vorlagen/Templates generiert werden, die Platzhalter enthalten, die durch die Komponenten auf Applikationsebene (2) definiert werden.
17. Kommunikationssystem nach einem der Ansprüche 1 bis 16, wobei die Datenhaltungsschicht (4) Speichereinrichtungen zum Speichern von Daten und/oder Informationen für mehrere Benutzer aufweist.
18. Kommunikationssystem nach einem der Ansprüche 1 bis 17, wobei die Datenhaltungsschicht (4) mindestens eine SQL-Datenbank aufweist.
19. Kommunikationsystem nach einem der Ansprüche 1 bis 18, ferner mit einer ' Schnittstelle für verschiedene Datenhaltungsschichten.
20. Kommunikationssystem, insbesondere nach einem der Ansprüche 1 bis 19, mit einer Applikationsschicht (2), einer Präsentationsschicht (3) und einer Datenhaltungsschicht (4), dadurch gekennzeichnet, dass das Kommunikationssystem mehrere virtuelle Arbeitsbereiche (5) aufweist.
21. Kommunikationssystem nach Anspruch 20, wobei mehrere virtuelle Arbeitsbe- reiche (5) eingerichtet werden können und eine Hierarchie bilden.
22. Kommunikationssystem nach Anspruch 21 , wobei die Hierarchie eine Baumstruktur aufweist.
23. Kommunikationssystem nach Anspruch 21 oder 22, wobei Benutzer eines untergeordneten Arbeitsbereichs auch den übergeordneten Arbeitsbereichen angehören.
24. Kommunikationssystem nach einem der Ansprüche 20 bis 23, wobei die mehreren virtuellen Arbeitsbereiche dezentral verwaltet werden.
25. Kommunikationssystem nach einem der Ansprüche 20 bis 24, wobei ein virtueller Arbeitsbereich eine oder mehrere individuelle Instanzen von Funktionalitäten der Applikationskomponenten aufweist.
26. Kommunikationssystem nach einem der Ansprüche 20 bis 25, ferner mit arbeitsbereichübergreifenden Applikationskomponenten, die von Benutzern aller Arbeitsbereiche verwendet werden können.
27. Kommunikationssystem nach Anspruch 25 oder 26, wobei die individuellen Applikationskomponenten ausgewählt sind aus der Gruppe Diskussionsforum, Chatraum, Dokumentenablage.
28. Kommunikationssystem nach Anspruch 25, 26 oder 27, wobei die arbeitsbereichübergreifenden Applikationskomponenten ausgewählt sind aus der Gruppe Kalender, Gästebuch, Mailbox. Aufgabenliste.
29. Kommunikationssystem nach einem der Ansprüche 20 bis 28, wobei ein Benutzer mehreren virtuellen Arbeitsbereichen angehört.
30. Kommunikationssystem nach Anspruch 29 wobei ein Benutzer auf der Basis seiner Registrierung im Kommunikationssystem mehreren virtuellen Arbeitsbereichen angehört.
31. Kommunikationssystem nach einem der vorhergehenden Ansprüche, wobei das Kommunikationssystem (1) eine Community ist.
32. Kommunikationssystem nach einem der Ansprüche 1 bis 31 , ferner mit einer Eingabeeinrichtung zum Zuführen von Daten zur Präsentationsschicht (33).
33. Kommunikationssystem nach einem der Ansprüche 1 bis 32, femer mit einem mit der Präsentationsschicht verbundenen Anzeigeeinrichtung zum Ausgeben von von der Präsentationsschicht (3) bereitgestellten Daten .
34. Serversystem mit einem Kommunikationssystem (1 ) nach einem der vorherge- henden Ansprüche.
35. Serversystem mit einer Applikationsschicht (2), einer Präsentationsschicht (3) und einer Datenhaltungsschicht (4), dadurch gekennzeichnet, dass die Applikationsschicht (2) eine Kerneinrichtung (21 ), mehrere Kernkomponenten (22) und mehrere Applikationskomponenten (23) aufweist.
36. Serversystem , mit einer Applikationsschicht (2), einer Präsentationsschicht (3) und einer Datenhaltungsschicht (4), dadurch gekennzeichnet, dass das Server System mehrere virtuelle Arbeitsbereiche (5) aufweist.
PCT/EP2000/006272 2000-07-04 2000-07-04 Kommunikationssystem WO2002003648A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/EP2000/006272 WO2002003648A1 (de) 2000-07-04 2000-07-04 Kommunikationssystem
AU2000264312A AU2000264312A1 (en) 2000-07-04 2000-07-04 Communication system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2000/006272 WO2002003648A1 (de) 2000-07-04 2000-07-04 Kommunikationssystem

Publications (1)

Publication Number Publication Date
WO2002003648A1 true WO2002003648A1 (de) 2002-01-10

Family

ID=8164014

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2000/006272 WO2002003648A1 (de) 2000-07-04 2000-07-04 Kommunikationssystem

Country Status (2)

Country Link
AU (1) AU2000264312A1 (de)
WO (1) WO2002003648A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2845174A1 (fr) * 2002-09-27 2004-04-02 Thales Sa Procede permettant de rendre l'interaction utilisateur-systeme independante de l'application et des medias d'interaction

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0810799A2 (de) * 1996-05-31 1997-12-03 Lucent Technologies Inc. Vorrichtung zum Erleichtern der Integration von Anrufmerkmalen
WO1998003927A2 (en) * 1996-07-22 1998-01-29 Cyva Research Corp Personal information security and exchange tool
WO1998044695A1 (en) * 1997-03-31 1998-10-08 Apple Computer, Inc. Method and apparatus for updating and synchronizing information between a client and a server

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0810799A2 (de) * 1996-05-31 1997-12-03 Lucent Technologies Inc. Vorrichtung zum Erleichtern der Integration von Anrufmerkmalen
WO1998003927A2 (en) * 1996-07-22 1998-01-29 Cyva Research Corp Personal information security and exchange tool
WO1998044695A1 (en) * 1997-03-31 1998-10-08 Apple Computer, Inc. Method and apparatus for updating and synchronizing information between a client and a server

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2845174A1 (fr) * 2002-09-27 2004-04-02 Thales Sa Procede permettant de rendre l'interaction utilisateur-systeme independante de l'application et des medias d'interaction
WO2004029799A1 (fr) * 2002-09-27 2004-04-08 Thales Procede permettant de rendre l'interaction utilisateur­ systeme independante de l'application et des medias d'interaction
US8020174B2 (en) 2002-09-27 2011-09-13 Thales Method for making user-system interaction independent from the application of interaction media

Also Published As

Publication number Publication date
AU2000264312A1 (en) 2002-01-14

Similar Documents

Publication Publication Date Title
DE602004003135T2 (de) Einheitliches management von netzressourcen für gleichzeitige teilnahme mehrerer nutzer an einer sitzung
DE60306186T2 (de) Verfahren und system zur anordnung von dienste in einer webdienstarchitektur
DE60038707T2 (de) Internet-Schnittstellensystem
DE69729926T2 (de) Netzwerkbrowser
DE10003907B4 (de) Verfahren, Vorrichtung und Datenverarbeitungsprogramm für die Anwendung beim Zugriff auf Hypertext-Dokumente
DE60120822T2 (de) Meta-Dokument und Verfahren zum Verwalten von Meta-Dokumenten
DE69830457T2 (de) Netzwerkbasiertes Werkzeug zum Begutachten von Dokumenten
DE10311074A1 (de) Verfahren und Anordnungen in einem Telekommunikationsnetz
DE10303237A1 (de) Gefilterte Peer-To-Peer-Geschäftskommunikation in einer verteilten Computerumgebung
DE10144707A1 (de) Verfahren und System zum dynamischen Erzeugen von Web-Formularen in einer Vielzahl von Sprachen
DE102005033978A1 (de) Verfahren zum Erhöhen der Produktivität in einer Organisation
DE60319162T2 (de) Verfahren und vorrichtung zur benutzermodellierung
EP1716529A1 (de) Informationssystem
Millen Community portals and collective goods: Conversation archives as an information resource
DE60019345T2 (de) Elektronische glückwunschkarte
WO2002003648A1 (de) Kommunikationssystem
DE19835092C2 (de) Verfahren zum Betrieb eines computergesteuerten Vermittlungssystems
EP1043667A2 (de) Online Service zur effizienten Kontaktaufnahme zwischen Käufern und Anbietern chemischer Produkte
DE60014718T2 (de) Verfahren zum senden einer selektion auf einer webseite und dieser webseite zu einem anderen benutzer durch einen server
Lacher et al. A framework for personalizable community Web portals
Qureshi et al. Organizational transformation by activating knowledge: The Mediating role of collaboration technologies
DE69910352T2 (de) Verfahren zum Kontrollieren der Arbeitsumgebung von Betriebsangestellten
WO1999027679A2 (de) Datenarchitektur und datentransfer der strukturierten informationen im internet
DE10153500A1 (de) Verfahren zur Kommunikation zwischen Mitgliedern und Nichtmitgliedern eines Teams
DE10154306A1 (de) Verfahren für die Problemlösung innerhalb einer Teamumgebung

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: FESTSTELLUNG EINES RECHTSVERLUSTS NACH REGEL 69(1) EPUE

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP