KR100919606B1 - Distributed computing services platform - Google Patents

Abstract

Server federation collaboratively communicates to fulfill a service request by communicating using a data structure that conforms to a schema in which the meaning of the communicated data is implied by the schema. Thus, in addition to the data being communicated, the meaning of the data is also communicated and allows intelligent decision and reasoning based on the meaning of the data. Collaborative conversations are facilitated over a wide network by messaging through a common API that supports multiple transport mechanisms. In addition, mid-session transfers between client devices are facilitated by schema and transport-independent messaging structures. The user interface of the client device will look consistent even if the client device has other user interface functions.

Description

Distributed Computing Services Platform {DISTRIBUTED COMPUTING SERVICES PLATFORM}

The present invention relates to the field of communications. More specifically, the present invention describes a distributed computing services platform to facilitate advanced communications and coordination in all computer networks (such as the Internet).

The Internet has revolutionized the way people communicate and signaled the arrival of a new era in human history, sometimes called the "information age." In essence, the Internet involves a large crowd of networked computers spread throughout most of the world. High performance computers, software, and networking technologies have made communication over the Internet quite easy for end users.

For example, a user can compose an e-mail or "e-mail" message using commonly available e-mail software. After addressing the recipient, the user simply sends the message by activating the "send" icon on the computer display, for example using a mouse. The message is then routed through the Internet from one computer system to the next until the message arrives at the destination computing device.

In addition, conventional browser software allows a user to request information such as a web page from a remote computer. After the user enters the address of the web page, the browser allows the user's computer to send the request using a widely recognized communication protocol such as, for example, Hypertext Transport Protocol (HTTP). The request is then routed to the destination computer or website using the destination address.

The remote web site evaluates the request and returns a suitable response that may also contain the requested information. The requested web page is returned in a format, such as a hypertext markup language ("HTML") format, which is parseable by the web browser. The parsed web page is then rendered and shown to the user on a computer display.

Web browser software can be used in many types of widely available computers, including general purpose personal computers (PCs), television set top boxes, personal digital assistants, cellular telephones, and the like. In addition, there are numerous Web sites that are openly available to anyone by accessing such ordinary browser software and making an Internet connection. These factors combine to allow people to access more information with more information than ever before.

In short, the Internet provides simple global connectivity for many users. While the use of the Internet today provides a number of benefits to businesses and individuals in providing access to information, the Internet can be used more efficiently to access and use information in a more flexible manner. For example, one dominant use of the Internet can generally be characterized as "read-only". After the publisher has created and published a web page, the Internet can be used as a presentation tool that essentially allows the user to read the information on the page. The Internet itself provides little or no ability for users to write, edit or otherwise interact with web pages.

In addition, the Internet allows individuals to directly access numerous websites, although few standards exist, although there are standards that allow websites to communicate with each other or share information. Each web site typically maintains different identities, preferences, data formats and schemas, and connectivity. For this reason, it can take considerable time and money to enable a conversation between two websites as well as many websites. Thus, web sites typically do not obtain the vast and rich spectrum of information provided by other web sites on the Internet. Instead, many Web sites are forced to collect information independently and compile it into a somewhat static format, even if the information is already available from other Web sites. Thus, although there is a widespread connectivity between a vast number of sites and computers over the Internet, it has rarely been done using such connectivity in the form of innovative advances and automated conversations that can remain largely unrealized. .

In addition, the efficiency and flexibility of the Internet is limited by other factors that restrict users from accessing information and services. For example, a user with a personal computer may have access to a significantly larger set of Internet resources than, for example, a user of a restricted cellular phone associated with the underlying platform. When platform constraints are not an issue, other issues (such as security and storage) can still restrict access to the same user to Internet resources, and more so for other users on all platforms. Even though the same information and services can be accessed, the overall efficiency and flexibility are compromised, for example, when a user has to follow different protocols or receive quite different user interfaces to access their resources.

Furthermore, Internet users face too much information that is difficult to filter and organize. For example, web search engines typically return a number of possible "hits" for simple queries. The user must manually filter all of these hits to get relevant information. In addition, a user's email inbox may be attacked by junk email or "spam", which may be low priority or irrelevant to the user. Even if there are some inbox filters, the user still has to scan the rest of the messages to find high priority or important messages.

Thus, what is needed is a system and method that facilitates more consistent user conversations and coordination, and communication between Web sites over the Internet. In addition, the relevant information to be provided to the user needs to be more personalized to the individual without overwhelming the user with too much information.

The above problems in the prior art are overcome by the present invention, which is a distributed computing services platform that facilitates better internet-based collaboration and better inter-site communication. First, the general conceptual architecture of the platform is summarized. Thereafter, the platform's integrated technology components are summarized. These components include programmed models, schemas, user interfaces, events, messaging, storage, directories, security, and code management. Finally, a scenario is illustrated that illustrates how the present invention facilitates advanced coordination and communication in the lives of people at work and at home.

The distributed computing services platform of the present invention facilitates communication between client devices and server federations and between servers in server federations. Server federation may, for example, consist of servers and services on the Internet and / or corporate intranets. Clients and servers are integrated through semantic communication and information exchange, while maintaining some autonomy. This semantic exchange is possible by exchanging information through a common schema in the entire transport-independent messaging infrastructure.

The platform includes many distributed but integrated technology components and services, including programming models, schemas, user interfaces, events, messaging, storage, directories, security, and code management. The programming model defines a structure for applications that can be flexibly distributed between client and server federation. Applications that follow the programming model include pages, emissary, and fiefdom components. The page component hosts the controls typically used to project the user interface to a particular client device that is communicating with a server federation. The emission component provides a comprehensive representation of the client to the server federation. The FD dome component owns the data that makes up the primary resource of the application. Typically these components communicate with each other via asynchronous messaging. The message may be generated by logic inherent in the component, by an event inherent in the component, or in response to a message received from another component.

The platform depends on the schema to make the communication meaningful. A schema is a set of standards or rules that define how a particular type of data can be structured. Thus, a federated computer system uses a schema to recognize that data conforming to a particular structure represents a particular type of item used throughout the federation. Thus, the meaning of data may be communicated between computer systems rather than just the data itself. For example, a computer device may allow a computer to “understand” a component part of an address, so that a data structure conforming to a particular address scheme represents an address. The computer device can then perform intelligent actions based on understanding that the data structure represents an address. Such an action may include, for example, presenting an action menu to the user indicating the todo with the address. The schema may be stored locally on the device and / or globally in the "mega-store" of the federation. A device can continue to update its locally stored schema by subscribing to an event notification service (in this case, a schema update service) that automatically passes messages to the device when the schema is updated. Access to globally stored schemas is controlled by the security infrastructure.

User interaction with the device occurs primarily through the user interface. The user interface (UI) of the present invention is multi-modal, intelligent and responsive. The user interface scales appropriately with the technical capabilities of the server device and various clients. The user interface also remembers the user's preference status, session, and state at all devices. Thus, a user can switch from one device to another mid-session while all state and preference information is compatible, or another user can share the same device and be provided with another interface based on their preferences. Can be. After users have properly authenticated themselves via the security infrastructure, user preference information can be accessed through a directory service that stores user-specific information (such as favorites, contacts, etc.) specified by the schema. The user interface is also multi-modal, meaning that the user can interact with the UI through multiple modes. For example, user input may be through "traditional" methods such as keyboard entry or mouse click. In addition, the UI allows other input methods such as audio / voice input for devices with microphones or stylus / touch input for devices with touch screens or pads.

Events within the platform are used to provide notifications, reports, or synchronization for specific activities. The platform's event component includes an event source that generates an event that is communicated to an event sink across all federations. The system also includes an inference mechanism that converts input events to higher level events through logical or probabilistic inferences about the input events, thereby converting atomic events to higher level events. Include mechanisms Event synthesis mechanisms modify the set of available atomic events into observations that match the informational requirements of the software component, providing the component with information at the appropriate level of abstraction to make good decisions. 1) Subscription by a software component with events of a particular class provided by one or more event sources; 2) by intermittent polling of one or more sources; Or 3) the software component may access the event via several mechanisms, including by listening to a broader broadcast of the event by the event source. For any of these methods of accessing an event, an application may access the event via a messaging infrastructure, although the message delivery type may be dependent on the type of event. For example, an event may be associated with another tolerance in latency such that communication of the event may be guided by the cost associated with the delay in the transmission. For this reason, event notification that a mission-critical server is down requires assurance of immediate delivery to its destination. Other events, such as updates on the user's general location may be associated with a lower cost of delay. In addition, the user interface may inform the user of a particular event in a manner proportional to the urgency of the notification. For example, the network administrator may receive an urgent pop-up message that the server is down, or the teenager may receive a notification that one of the friends is in the zone via an instant messenger or chat interface. Event notification is also controlled by authentication and authorization security mechanisms.

Messaging component 160 is a mechanism by which events and other information can be exchanged across platforms. The messaging service provides efficient and reliable messaging over the Internet using any of a variety of transports, including HTTP. The messaging infrastructure establishes a standard interface for application developers to write applications that take advantage of the overall architecture of messaging services and other features associated with the present invention. Messaging can occur asynchronously and thus allow for constant updating of pages without requiring user-initiated page refreshing.

The storage service allows distributed storage across all server federations. As noted above, user preferences and files can be stored in a "mega-store" in the federation, and after proper authentication, the user can access this information from any location using any device. "Mega-stores" do not all have to be on a single server; Storage can be distributed across all servers in the federation based on efficiency, memory allocation, frequency of access, and the like. The information stored in the server federation can also be replicated locally to allow the user's off-line work. When the user goes back on-line, an event is generated that triggers the automatic synchronization of off-line and on-line data. The storage service includes a data engine built on a normal file system. A method of prioritizing information for local caching and allowing cached information to be removed based on the age and / or translation in the cached information may be used to maximize the value of the cached information.

In order to support the concept that a user can be easily recognized or identified by various services, a directory component is provided. The directory service of the present invention supports federation by synchronizing between meta-directories and including meta-directories per company or per web site. This synchronization is facilitated by a standardized schema used to communicate between directories. These meta-directories provide a reference to a specific adapted directory where more detailed information can be found. For example, the directory may include user identity information (name, address, etc.), security information (what information the user is authorized to access), and the like.

The security infrastructure of the present invention provides advanced security in all server federations. To ensure user mobility and privacy, the security infrastructure prepares for one person having multiple identities. For example, an individual may have a professional and personal identity. The present invention facilitates authentication and authorization in which these multiple entities are treated as one entity. Further, advanced firewall technology is described in which personal firewalls, perimeter firewalls, and security gateways operate independently from each other. Security can be implemented by any combination of technologies such as passwords, smart cards, biometrics (fingerprints, retinal scans, etc.), key exchange, encryption, and the like.

One goal of the platform is to ensure transparent access to the most recently updated applications and code that users need. The code management system of the present invention includes a manifest that describes the structure of the application, including configuration information, entry points, resources, and code for the application and its constituent components. Code management systems enable applications that conform to the programming model to be deployed and updated across all federations in an efficient manner.

Additional features and advantages of the invention will be described below, and to some extent will be apparent from the description, or may be learned from the practice of the invention. The features and advantages of the invention may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other features of the present invention will become even more apparent from the following description and the appended claims, or may be learned by practice of the invention as described below.

BRIEF DESCRIPTION OF THE DRAWINGS For the above and other advantages and features of the present invention to be obtained, the present invention briefly described above will be described in more detail with reference to specific embodiments shown in the accompanying drawings. It is to be understood that these drawings are only illustrative of exemplary embodiments of the invention and therefore should not be considered as limiting the scope of the invention, which will be described in more detail below with reference to the accompanying drawings.

Distributed computing services platforms, including programming models, schemas, user interfaces, events, messaging, storage, directories, security, and code management components, facilitate better internet-based collaboration and better inter-site communication.

1 illustrates an architecture that provides a suitable operating environment of the present invention;

FIG. 2 illustrates a programming model for an application that may be implemented in a distributed fashion in all architectures of FIG. 1;

3 is a diagram illustrating a schema store and a schema service according to the present invention;

4 is a schematic diagram of a user interface component in accordance with the present invention;

5 is a schematic diagram of an event system for providing event notification between a plurality of event sources and a plurality of event sinks in accordance with the present invention;

6 is a schematic diagram of a messaging architecture for use with the present invention,

7 is a schematic diagram of a storage architecture for use with the present invention,

8 is a schematic diagram of a directory architecture for use with the present invention,

9 illustrates an example communication flow using the directory architecture of FIG. 8;

10 is a schematic diagram of a security service for use with the present invention;

11 illustrates a data structure showing how a global identifier is used to maintain profile information;

12 illustrates an advanced firewall configuration for use with the present invention;

13 illustrates a code management manifest for use in software development.

A. Introduction

The present invention extends to computer program products, systems, and methods including distributed network services platforms that facilitate better Internet-based coordination and inter-website communication. The various architectural components of the present invention may be distributed in a variety of dedicated or general purpose pre-computing devices, including various hardware components such as personal computers, servers, laptops, hand-held devices, cell phones, and the like, as discussed in more detail below. .

Embodiments within the scope of the present invention also include computer-readable media for conveying or having stored computer-executable instructions or data structures. Such computer-readable media can be any available media that can be accessed by a general purpose or dedicated computing device. By way of example, and not limitation, such computer-readable media may be used to convey or store desired program code means in the form of computer-executable instructions or data structures, and may be accessed by a general purpose or dedicated computing device, Physical storage medium such as a ROM, EEPROM, CD-ROM, or other optical disk storage, magnetic disk storage or other magnetic storage device, or any other media. When information is transferred to the computing device via a network or other communication connection (hardwired, wireless, or a combination of hardwired or wireless), the computing device properly views the connection as a computer-readable medium. Thus, any such connection is properly termed a computer-readable medium. Combinations of the above should also be included within the scope of computer-readable media. Computer-executable instructions include, for example, data and instructions that cause any general purpose or dedicated computing device to perform a particular function or group of functions.

In this description, the general architecture of the present invention may be implemented as described first in the architecture section. Then, each of several technology components of the architecture is described. These sections include programming models, schemas, user interfaces, events, messaging, storage, directories, security, and code management. Finally, various scenarios will be described in the Scenarios section, which illustrates how architecture and technology components facilitate advanced Internet communications and collaboration.

B. Architecture

1 schematically illustrates an operating environment 100 in which the present invention may be implemented. Client device 110 has various processing and memory capabilities. For example, client device 110 may include a " rich " client (e.g., rich client; 112) and cellular phones and pagers capable of performing a high degree of data processing, such as a desktop personal computer (PC). Likewise, it includes a "thin" client 114 that can do less data processing. The difference between rich and thin clients is understood to be a spectrum; For example, there are many devices (hand-held or tablet PCs) in the middle of the spectrum.

Regardless of the client's processing function or device type, most client devices can be operated by a user online or offline. While online, each client device may communicate with the server federation 120 via the distributed computing services platform 115 of the present invention. Conceptually, server federation 120 includes one or more private computer networks, such as, for example, corporate intranet 130, as well as a world-wide network of computer systems, commonly referred to as “Internet” 125. Servers in the federation (ie, servers 140a and 140b in the Internet 125 and servers 140c and 140d in the corporate intranet 130) also communicate with each other via the platform 115.

Conceptually, the platform 115 may include a programming model component 135, a user interface component 140, a storage component 145, a directory component 150, an event component 155, a messaging component 160, a security component ( 165, several platform components including technologies and services, including schema components 170, and code management components 175. Although conceptually illustrated as distinguished from FIG. 1, each of the platform components 135, 140, 145, 150, 155, 160, 165, 170, and 175, through the entire server federation 120 and the client device 110 Can be dispersed. Furthermore, many of the platform components provide services to client device 110 and server federation 120. Each platform component is loosely-coupled to other platform components as indicated by arrow 180, and enables platform 115 to provide integrated technology and services. In addition to the integration of supporting services and platform components, the distributed nature of the platform 115 contributes to and facilitates the advanced features and advantages of the present invention.

The server 140 of the client 110 and server federation 120 may, while maintaining some autonomy, as provided by the schema platform component 170 and the messaging platform component 160 discussed in more detail below. In the entire transport-independent messaging infrastructure, it is integrated through semantic communication and information exchange using a common schema. The bidirectional arrow 190 indicates this communication taking place between the server and the client. Bidirectional communication allows client device 110 to read from, write to, and talk to a server federation 120. The present invention may be implemented using any communication mechanism capable of communicating data bidirectionally according to a schema. In one example, the communication occurs via extensible markup language (“XML”) that enables communication of name / value pairs.

In some cases, the communication between client device 110 and server federation 120 may also be unidirectional or “read-only”. This one-way communication is the dominant form of communication on the Internet today. In this type of "read-only" communication, after the publisher has created and published a web page, the Internet can be used essentially as a presentation tool that allows the user to read the information on the page. Technologies that allow this presentation include a wireless application protocol ("WAP") that allows communication to wireless devices. In addition, a web page format called Hypertext Markup Language ("HTML") allows information to be downloaded from a network site. The information is then parsed and rendered and presented on the client display. However, the platform 115 of the present invention extends the conventional web presentation model to allow rich, interactive, bidirectional communication.

Platform 115 allows servers 140 in federation 120 to cooperate to share and / or perform information. Rather than having each server collect and compile the information on its own, the server can instead rely on the services of another server where information can be readily used to implement efficient division of labor. The user then receives the rich information without having to worry about all the complex server-to-server communication that takes place in the server federation to produce the rich information. For example, server 140 in server federation 120 causes stock quotes from one server to be displayed in a portion of the user interface of client device 110, and news articles from another server are displayed on the client device. And exchange information such that the instant message from another server is displayed on another portion of the user interface of the client device.

Servers 140 in server federation 120 communicate and share information using standardized data structures or schemas provided by schema platform component 170. The schema allows a more semantic conversation between the server and the application than just exchanging information between the servers. This recognition of meaning allows the server to perform a function based on the recognized meaning of the information. If the application recognizes the information as meaning, for example, the address of a given entity, the application can perform a specific function based on the recognized meaning. For example, an application may automatically fill in an address field of a template corresponding to a given entity with address information. The application can also detect if a house code or status is missing in the address and thus automatically query the other server for missing information so that all address fields can be filled in automatically without user intervention. Can be. Thus, cooperation between servers is more productive because each server is intelligent in that it can recognize the meaning associated with the data and then act on that information without requiring human intervention.

C. Programming Model

2 illustrates a multi-tier programming model component 135 of the platform 115. The programming model describes how the application 200 can be distributed to vary the degree between the client device 110 and the server federation 120 of FIG. 1. An "application" is defined as the body of software that performs a function and may include a website. In a distributed application, components of the application may be stored on the client device while other components are part of the web site. In general, application 200 is comprised of a number of application components, including page component 210, emission component 220, and FPM component 230. The page component 210 hosts the control to project a user interface or experience to the appropriate client device 110. Emissory component 220 presents the client comprehensively to the server federation, thus acting as an etymology between the client and server federation. The FPM component 230 directly controls most of the live data that constitutes a significant resource of the application 200. A single application can have a varying number of these components (eg, one or more page components). Also, some applications may not have all components.

Depending on the functionality of the client, the page and emission components can run on the client or server federation. For thin clients with little or no processing capability, the page and edge components will be more likely to run on server federation. For rich clients with better processing capabilities, such as desktop personal computers (PCs), the page and edge components may be more likely to run on the client.

Each of these application components (pages, emissaries, and piedoms) are logic 240 (ie, computer-generated) used to send and receive asynchronous messages from one component to the other, through messaging component 160. Body of executable instructions). For example, page level logic 240a may be used to asynchronously send a message from page component 210 to economy component 220 via messaging queue 250a. Emissory level logic 240b is used to asynchronously send a message from emissory component 220 to page component 210 via messaging queue 250b. Emissory level logic 240b is also used to asynchronously transmit messages from anesthetic component 220 to a FP dome component 230 via messaging queue 250c. The FD dome level logic 240c is used to asynchronously send a message from the FD dome component 230 to the accessory component 220 via the messaging queue 250d. Thus, asynchronous information exchange takes place between the pages, emissaries, and F. dome components of the application 200. In accordance with messaging component 160, message queues provide a reliable channel for transmitting messages between components and support various transmission semantics (ie, exactly once, delivery of guarantees, and delivery of guarantees). Messages are defined through schemas (eg, XML schemas).

In addition, the body of logic 240 within each application component is used to host the control 260. In general, control is indicative of the functionality that can be accessed and part of the functionality of a program component. For example, page level logic 240a hosts control 260a, emmy level logic 240b hosts control 260b, and F. dome level logic 240c hosts control 260c. do. Each control 260 exposes a callable method, properties that can be read or written synchronously, and events that can be fired asynchronously, and that can be invoked in a page, an aesthetic, and / or a Feddom component. Let the logic execute In general, the event triggered by the control is a low-level event, such as invocation of a method on an object. Thus, when a message is received by a component, it generates an event that causes code in the component to execute.

Page component 210 uses page level logic 240a to directly and synchronously manipulate control 260a to project a user interface or experience. Depending on the user interface functionality of the client, the page component can silently redirect the call to a specific version of the page that is compatible with the client. For example, one page may be suitable for a rich client and another page may be suitable for use with a thin client such as a phone or other such device. The page component 210 can recognize the client's identity by using the client's uniform resource locator or URL and can therefore redirect to the appropriate version of the page. However, regardless of the page version, the user interface may have a wide range of full clients, even if certain characteristics will be present or more fully developed in the higher rich version of the page, as discussed below in connection with the user interface component 140. It will look consistent on the device.

The page component can also invoke other page versions depending on the processing capabilities of the device that will implement the page component, regardless of the user interface available to the client. For example, if the page component is to be implemented on a server or client personal computer with high processing power, the page component can redirect to a rich control page that allows for extensive user conversation with the page. On the other hand, if the page component is to be implemented on a thin, low-robust client, the page component will typically redirect to an HTML-only version of the page that rarely contains, even if it contains control features that allow the user to interact with the page. Can be.

Emissary component 220 encapsulates a body of logic 240b that can interact synchronously with control 260b. Logic 240b is also designed to abstractly present the client to the server in a standardized manner whatever the client device type. Emissary components can access read-only data published by the FPM dome component and store such data in the replica data storage 271. The emission component also includes R / W data for each user, such as shopping cart data stored in the read / write (R / W) data storage device 272 for each user. The body of logic 240b may be executed in response to a message coming from message queue 250a or 250d.

The FD dome component 230 encapsulates a body of logic 240c that logically "owns" the live data stored in the live data store 280. The body of logic 240c executes in response to a message received from an anesthetic component, such as an anesthetic component 220 associated with the FPM component. The FD dome component 230 performs a security service on any emissory component that requests access to the service.

Each component in the application manages state information about explicit user and session state. Thus, each component supports an object used for the duplication of such user and session state information. Such state information may be shared with other components in the application through asynchronous messaging that supports communication of such state information. Thus, each component may be made aware of the user interface state at any given point in the session. In addition, each component may become aware of the user's preferences.

The benefits of programming model component 135 will now be described. Components in the application can do asynchronous messaging. Thus, a component is not required to explicitly request information in order to receive a message. In addition, the component is not required to receive an explicit request for information in order to send a message containing such information. Thus, the programming model supports the sending of messages to page components (and thus updating the user interface) without the user having to explicitly refresh the web site. Thus, the page may display an asynchronous user interface in which the page is automatically updated when the page component receives a message from the asset component. Also in such a situation, it may not necessarily be necessary for the misery to access the duplicate data since live data may be available through the FPM.

In addition, the programming model includes control that can be asynchronously fired upon the occurrence of a defined event, thus allowing logic within the component to execute. This logic sends an asynchronous message to other components in response to the event and thus causes any component in the application to execute in response to the defined event. Thus, the application is highly event driven. These events can drive how to run asynchronously in any component of the application.

For example, a FPM component may host a control that is configured to fire on an event when any new article containing a given word is added to the database. Triggering of the event may cause the FD dome to send an asynchronous message to the page component via the component component. In response to this asynchronous message, the page component can render a notification message for presentation on the client, thereby informing the user of a new article. For example, if the client device is a thin client, the user interface may include a small notification window indicating the presence of such a new article. If the client device is a rich client, the user interface can display the new article as a whole on the screen. In addition, any or all of the pages, emissaries, or F. dome components may take on other actions based on the same event, such as the creation of an e-mail that forwards the article to a colleague who is also interested in the article containing the given word. Can be. Thus, the programming model enables complex event driven applications.

In addition, the programming model facilitates the flexible positioning of these components between client and server federation and allows for online as well as offline use of applications. For example, an application can be built to allow offline or online execution. This can be done by having the page components hosted directly on the client while the page components communicate directly with the component that is also hosted on the client. When offline, the application accesses duplicate data in duplicate data storage 271 instead of live data in live data storage 280. Once online, access is restored, the epoxy component sends an update queued to the FD, and the duplicate data is updated to reflect the current state of the live data managed by the FD dome component.

The application can also be built so that all components, pages, assets, and FPMs are hosted on a server federation. In this case, the client must be online with the server federation to access the services of the page, the miscellaneous, and / or the Feddom component.

In addition, some portions of the application may be used when offline (hereinafter, the "offline portion") and other portions of the application may be used only when the client is online (hereinafter, the "online portion"). The page and ancillary components that enable offline components of the application are hosted by the client, while the page and anesthetic components that enable the online portion of the application are hosted by a server federation.

Thus, many other technology components of the distributed computing services platform 115 of the present invention may be implemented in accordance with the programming model component 135.

D. Schema

One way to enable better Internet-based coordination and inter-website communication is through more semantic communication of data. Such semantic or intelligent communication provides more than just data, and also provides inferences as to why and / or the content the data is being communicated with. This may be accomplished by "schema" such as by structuring the data in a standard manner or through standard data structures, protocols, communication transports, and other structured data exchanges. Information stored in the client device 110, in the server 140, and / or in accordance with the storage component 145 may be stored in accordance with the schema. The schema is also used when communicating information between servers in server federation 120, between server federation 120 and clients 110, and between platform components. In addition, asynchronous messages communicated between the various components 210, 220, and 230 of the application of FIG. 2 may be communicated using a schema.

In many situations, a user wants to use data from multiple applications and data sources to generate reports, analyze progress, predict what is needed, and detect changes in operating conditions. Unfortunately this type of data, though available, is soon found in a completely different format as each application typically uses its own set of schemas. In other words, even if the application describes similar data types such as contact and time, these data types may use different vocabulary and have different attributes from the application to the application. Thus, specialized translation or import / export functionality is usually required to allow applications that follow different schemas to communicate.

In order to facilitate cooperation and communication in the server federation 120, the schema and schema service components of the present invention may include dates, addresses, subscriptions, show times, product descriptions, prices, receipts, preferences, medical records, movie reviews. Provide a foundation for dialogue and cooperation on server federation 120 for various data structures such as, or other related data types.

Generic schemas are probably not realistic because different applications will have different needs and legacy and cross-platform applications will need to be supported. Instead, the schema component 170 of the present invention seeks to define a "core schema" which is the minimum common schema that defines only what most applications have in common. Since the core schema is extensible, new schemas may be defined and added to the core schemas described below that describe important data entities useful for facilitating data conversation and cooperation. In addition, the schema may function at several layers with a network that includes an operating system or user interface of the client device and server federation of FIG. 1.

Some types of core schemas include (i) base types, (ii) social types, (i) business types, (i) system types, and (i) application types.

(Iii) Base types are used as basic building blocks for other types. Typical base types include types such as objects, items, containers, databases, folders, messages, text, or other base data structures. Translation of various schemas to base type schemas used by various applications can be accomplished by translation filters described below.

(Ii) The social type represents or describes items used in everyday tasks and conversations. Typical social types include items such as contacts, profiles, calendars, tasks, times, locations, finances, and other socially exchanged information or identification. As with the base type, a translation filter can be created to transform the incompatible data structure into a social type schema.

(Iii) Business types are used to describe what is common in business environments and business-business (B2B) transactions. Typical business types include such types as products, accounts, customers, employees, distributors, retailers, suppliers, and other business data.

(Iii) The system type defines the structure of the information used to manage the system. Typical system types include such types as policies, schedules, services, devices, and other system related information.

(V) Application types define the structure of applications and services. Typical application types include types such as application manifests, assembly manifests, and COM + type technologies. System and application types are based on information specific to the system and hardware configuration.

Schema component 170 also provides several schema services 292 that are used to store, retrieve, query, publish, and share schema information and data. Referring to FIG. 3, the schema store 290 is a location where schema information is collected and shared. For example, schema store 290 may include mapping between known schemas and core schema types and descriptions of core schema types. In one embodiment of the invention, the schema is an XML schema and described in schema store 290 by a schema description language. (An example of a schema description language is XSD that can be extended for use with the present invention). Schema store 290 is an instance of the storage component 145 of the present invention (described in more detail below). Thus, schema store 290 may be distributed across all server federations 120. The schema store 290 is not the only place where an application can remember a schema by storing the schema in this location, but the application does not know that the schema service 292 and the application using them can discover and work with the schema. I can guarantee it. In addition, an application can use schema store 290 and schema service 292 to replicate and store schemas locally and update them as described in more detail below. Access to schema store 290 and schema service 292 may be controlled by various security authentication, authorization, and firewall services provided by security component 165.

Schema service 292 generally includes a schema registration service, a mechanism for applications to store, retrieve, query, and publish schema information. For example, schema store 290 may collect and reference various schemas via, for example, a schema registration service, which may include, for example, a schema registration API (application programming interface). The schema registration service allows an application to remove or add schema information from a schema store.

Schema service 292 may also include a schema update service that allows an administrator, operating system, or other background schema modulator to update the schema. Schema service 292 may also include a distributed schema service to fetch a schema that does not persist in the store by following a reference in the instance data. To facilitate this service, the schema can be stored throughout the server federation 120 in accordance with the storage component 145 and the eventing component 155 can be used to inform the application when a new schema is published. And, therefore, allows global distribution of schemas. The schema service 292 may further include a schema validation service to maintain the consistency and integrity of the mapping and schema in the store. These services provide structural validation of the schema description language, checking for redundant and conflicting entries, and verifying the consistency of associations between schemas. Schema store 290 may also rely on the eventing component 155 of the present invention to provide notification of changes to the schema. Schema store 290 may also rely on the messaging component 160 of the present invention as a transport to distribute updates, events, subscriptions, and notifications.

For example, a local schema store may subscribe to a schema update service to update core types and schemas. One configuration uses an object manager to support registration for schema events that allows interested users to detect when any relevant schema change occurs. The local schema store can subscribe to one or more sources for updates. The update service pre-residents in the schema store the core types such as people and time, and the mapping of common schemas such as MAPI, vCard, LDAP, and WMI to these core types. Companies can host similar update services to maintain a schema store within their organizational network.

The schema conversion service (which is also part of the schema service 292) enables applications that use other schemas to share meaning. For example, schema conversion services include schema adapter services, schema recognizer services, and schema mapping services. The Schema Conversion Service provides a shared mechanism to recognize data and allows applications to dynamically support new schemas by converting data from one schema to another. Schema Conversion Services makes it easier for applications to understand a wide range of schemas by providing a shared mechanism for recognizing data and converting data from one schema to data in another schema, and robustness across all applications. And increase consistency and allow applications to dynamically support new schemas.

For example, a schema adapter service makes it possible to work with unstructured data in standardized languages such as XML. The schema adapter service receives non-XML data and converts it to XML data or any other type of data used to communicate with a schema.

The schema recognizer service identifies the schema type of the data instance so that the application knows what to do with the data. The schema recognizer service receives XML data or plain text as input. For XML, the schema recognizer service uses the XML namespace to narrow the list of possibilities, and uses the standard storage query service 294 to query the schema store 290 to determine the schema type. To infer schema types from plain text, the schema recognizer service relies on natural language services that can use the schema store 290 sequentially. Once the schema type is known, the application can use this information to provide its own user interface or to enable a system-wide user interface.

The schema mapping service takes XML data in one schema, transforms the data based on the mapping defined in schema store 290, and returns data in the XML representation of the other schema. In one configuration, the schema mapping service is often used by applications with write import or export functionality in combination with the schema adapter service.

A schema persisted within schema store 290 may describe an application, script, component, method binding, or data source that can be used to display or act on a particular schema type. For example, an application may provide a standard user interface to display data of a particular schema type, while another application may have business logic to operate on that data. Which action is appropriate for a given scenario depends on the user preferences of the context. These schema services work with the user interface component 140 to enable some end user features such as action menus (described below), auto-completion, and smart clipboard drag and drop.

The action menu feature presents a selection of actions available on one data in any application. In one configuration, these available actions are presented in a "factoroid" manner that allows the user to select or ignore. The application queries the schema store 290 using the storage query service 294 for registered actions associated with a particular data type. The retrieved action is used to generate an action menu. For example, when a user clicks on an address, the application inquires about the type "address" and the schema store 290 may print as "envelope" or "map this address" residing in the context menu. Return the action. The Action Menu API allows developers to expose these menus and other application-specific actions in their applications. Pre-resident action menus for each core type in the schema store can be exposed to the operating system, the Internet browser, and various active applications.

Schema services can also enhance the current "auto-completion" feature that makes it easier for users to fill out data fields in web formats and documents by presenting a selection from a data source that lists possible values. The list of possible values presented to the user may be based on registration in the schema store 290. For example, when filling out "Evite" or "electronic invitation" to invite a friend to a party, the email address field is the address from the user contact list bound to the email address property through registration in the schema store 290. Provide a list. This same functionality can be exposed through other applications to provide auto-completion in letters, invoices, spreadsheets, mailing lists, databases, or other documents. The same list of values is displayed in any application that chooses to expose this functionality.

Smart clipboard drag and drop uses a schema conversion service to allow data to be exchanged between applications that use different schemas. Thus, Schema Conversion Services enhances current drag and drop and clipboard routines to move data between applications that support different schemas, while preserving a shared understanding of what the data represents.

Thus, schema components working in concert with other technology components of platform 115, such as events, messaging, storage, schema, security, and the like, provide a mechanism for sharing semantic information across client and server devices.

E. User Interface

The user interface component 140 of the platform 115 of FIG. 1 provides a multi-modal, responsive, and intelligent user interface at various full client devices. 4 schematically illustrates a user interface component 140.

User interface component 140 provides a multi-modal user interface (UI), which means that a user can interact with the UI via multiple modes and the mode can be changed seamlessly on-the-fly. . User interface component 140 includes an advanced input / output component 400 to allow for multi-modal input and output. The input / output component 400 may receive user-entered input using "traditional" methods such as keyboard entry or mouse clicks. For example, the input / output component receives text 402. However, the UI is also a device that has audio / speech input (eg, audio / speech) 404 for devices with microphones, stylus / touch input for devices with touch screens or pads, and handwriting input capabilities. Accept other input methods, such as a bibliographic input (e.g., suseo; 406) for. As indicated by the bidirectional arrow 408, the input / output component 400 can also display traditional output such as text 402 as well as non-traditional computerized output such as audio / speech 404 and Suseo 406. Can provide.

In addition, the input / output component 400 incorporates a variety of conversion technologies that are particularly useful when entering information into the device. Such conversion includes speech-text technology that converts the user's audio / speech input into text. This conversion is helpful when it is inconvenient or impossible to enter text using traditional typing, such as when a user is driving a vehicle or otherwise lacks the ability to type. Another transformation useful for input includes the Sustain-Text technology, which converts the user's written stealth / touch input into text. This conversion causes text to be entered when a text input device such as a keyboard is not included with the device.

For example, a personal computer (ie, "tablet PC") in the form of a tablet is a device that allows handwriting input by writing directly on the screen, for example using a stylus. The tablet PC can then use the input / output component 400 to convert the curriculum to text so that the text can be edited in a manner not possible with the curriculum on the paper. For example, a space may be inserted between the paragraphs to cause comments to be inserted. The tablet PC may display the handbook itself or the text of the desired handbook.

Input / output component 400 may also present data to the user in multiple modes beyond “traditional” text and graphical displays. For example, the UI may incorporate text-speech technology that converts text (such as a typed email message) into audio ("reading" a message through a speaker on the device). Voice mail can also be incorporated into a unified messaging shell with text-based email messages. Speech-to-text conversion allows this voice mail to be converted to text if desired.

The multi-modal user interface allows the user to interact with various devices based on the user's status and proximity. For example, while using a rich client such as a PC, a user may choose to have a message displayed via video / audio and reply by text. However, while in the car, the user may choose to have the message played only by audio and also to be answered by audio.

Natural language communication is enabled based on the concept of user specific integrated user interface portal. Typical integrated user interface portal concepts include analysis of input strings, matching concepts via logical formal matching, generation of appropriate language-like sensations with results, useful feedback based on customized search parameters customized for the user, and user It includes a search infrastructure that allows smart execution through multiple heterogeneous database stores with a set of priorities at traditional storage locations.

In addition to being multi-modal, the user interface component 140 is responsive in that it is adapted and / or changed based on the user's state and context at many former client devices 110. For example, the user interface may be a different client device having a user interface that is consistent across the entire client device (although possibly modified, as discussed below) when the user switches the mid-session from one client device to another. It will be configured and rendered according to the user's preferences and session status so that the session can continue using.

Referring to FIG. 4, preference information may be stored in my state-adapted directory 905 in server federation 120. As the user works on the client device, the session status information is updated regularly in my state directory 905. When a user switches to another client device, after proper authentication using the security component 165, preference and session information is provided to the new client device. The preference information makes the display of the new client look consistent with the old client. Further, the session state information causes the new client device to continue in the session interrupted by the old client device.

In addition, the user interface scales seamlessly and with the technical capabilities of the client device. For example, mobile telephones have obvious technical limitations in their user interface due to space limitations on input keys and display area. The user interface for these mobile phones is scaled down to highlight only the more important characteristics of the user interface. Thus, although the user interface of the mobile phone will provide a more limited user experience of the session, the user can move the mid-session from the rich client personal computer to the thin client mobile phone. Such smooth scaling between client devices can be achieved through the use of a manifest supplied by the code management component 175 and described in detail below. For example, the manifest can describe the minimum user interface characteristic that is required to be displayed on the client device, and then describe the priority of the user interface characteristic to be displayed when not all components can be displayed on the client.

4 shows a full spectrum 412 of a user interface that may be used for a client device depending on the capabilities of the client device. The spectrum includes higher rich interactive UI page components (eg, page component R) for client devices with well developed multi-modal functionality and available processing power. The library also includes a thin page component (eg, page component T) for clients with less developed user interfaces and lower processing power. The user interface (UI) shown in FIG. 4 is derived from the page component 414 somewhere in this spectrum 412.

In addition, the user interface intelligently responds to user activity. For example, as noted above, user interface component 140 cooperates with schema component 170 (and schema service 292) to provide a user with an action menu of “smart tags”. If a user types on an address (in a web page, document, or contact list), the schema service 292 makes the address recognized as an address and thus provides a hot tag. The smart tag may be displayed by marking an item recognized as a distinguishing mark, for example, underlined by a blue dotted line.

The user can then select the marked address, for example by right-clicking the mouse, to obtain an action menu suitable for the type of recognized item. For example, an action menu for an item recognized as an address may provide the ability to view a map, print an address label, add to a contact list, and so on. One suitable action may include using the address to find further information such as, for example, a map that encompasses the address. In doing so, the user interface can consult the mapping service made available through the directory service component 150.

In addition, the user interface can detect that the user is typing and thus can focus the user interface characteristics on the word processing activity. For example, typing may trigger an event that the user interface determines that the user appears to intend to perform word processing. Such event triggering and inference building is provided by event component 155.

The user interface can also have an integrated command line that can be used to perform searches, navigate to web sites, access files in the file system, or perform natural language queries or commands. In a preferred embodiment, the integrated command line will be provided in some form on all types of devices. In performing the query, the user interface component 140 uses an intelligent feedback process to seek confirmation or clarify for the execution of a command, control or logical process. For example, a user may type "How is the market today?" On the integrated command line. This question is a bit vague and unclear. The user interface component 140 can then respond by saying, "What index are you interested in?" The user can then type "Dow Jones" in the command box. The user interface component 140 then has enough information to speak the answer. In order to return the requested information from the command line, the user interface component 140 must cooperate with the storage and messaging components to retrieve the information.

The integrated command line can also be used to perform natural language commands. For example, a user may type "Meeting with Hong Gil-dong at 3 o'clock". After the user interface component 140 clarifies the date, time, and location of the meeting, the user interface consults Hong Gil-dong's calendar if access has been granted by Hong. If the rules and preferences established by Hong Gil Dong allow the meeting to be scheduled for the requested time, at the time and place of the request, the meeting is scheduled on both Hong Gil Dong's calendar and the requestor's calendar.

The integrated command / search line parses and breaks out commands or queries to services provided locally and on the network. It resides in one place in the user interface accessed in the same way wherever they are, and all form-typing (keyboard), voice, and sequence of input can be received by the user interface. All level-keywords, booleans, and natural language (word fragments, phrases, and / or well-formed sentences) of intelligence can also be received and processed by the user interface.

The user interface component 140 may provide a single integrated shell that recognizes that the end user is a single person with many roles such as, for example, students, employees, managers, financers, patients, parents, consumers, and pianists. . The user interface via a single integrated shell brings together all these roles to create a rich, seamless experience.

The integrated portal of the user interface component 140 allows the end user to personalize and control the settings of the integrated portal, including the establishment of projection priorities, thereby creating a visual separation between the applications, documents, and operating systems used for the various activities. Minimize.

Through this personalization, the user interface component 140 intelligently resides and layouts the page. This personalization is stored in the form of preferences in my state directory 905. After the user logs on to the client device and authenticates to the secure component 165, the server federation 120 cooperates with these preferences (possibly stored in the mega-store of the storage component 145). And provide information to the user interface via link 410.

The user is also allowed to personalize and control the settings of the user interface component 140 to include knowing the user's working status and thus adjust the appearance of the user interface. Typical working conditions that may require a different user interface include when a user is working on a PC, when the user leaves the office, when the user is accessing data via a PDA or cordless phone, when the user attaches to the server federation 120. Electronic device or other location, or when working at home.

The user interface also includes the confirmation and prioritization of messages, allowing the end user to instruct the device to collect data as the user prioritizes. For example, a user can set preferences that should always be given high priority to messages from their owners and interrupted to receive them. Thus, notifications from the event component 155 where the message is received may be filtered based on these preferences. The integrated shell also allows web-based communities to provide data from individual PCs into community projections. This is particularly useful in the work community because it gives the manager the ability to control content from the PC portal.

Window sharing and document sharing are also possible so that when a user is communicating with someone on the communication list, either party can activate window sharing or document sharing so that other individuals can view the window or document. Such window sharing can be accomplished by accessing a document in the mega-store at the server federation and by configuring security settings such that others can have appropriate access to the document through the security component 165.

The user interface also creates temporary templates that allow users to quickly reuse existing reports and other data structures. Templates can be published, distributed, shared with other members of the working community through an integrated portal, or published on an intranet or the Internet. Template generation can be a useful property when working in the electronic work community where each participant contributes to the end product. Some templates may request specific information from each working community participant to complete a report.

The user interface also allows the use of a "buddy list" with certain settings as to how the listed individuals can be connected or reached. Typical connections include electronic mail, telephones, faxes, address information, video conferencing requests, wireless communication portals, or other communication mechanisms. These "buddy lists" are generated by an event component 155 that triggers an event when an individual logs on to a particular device. User interface component 140 receives these events and presents them to the user. Finally, the user interface allows standard personal and calendaring schemes to be used so that heterogeneous systems can communicate seamlessly.

The user interface includes the use of personal devices, the conferenceware of the user object in the associated security settings, the sharing of documents with local and distributed participants, the ability to move documents on the local device for instant access across the web, and the integrated user interface portal. Response to the written method annotations, and finally triggering the notifications as a result of event calendaring.

The user interface is the central place for the user to seamlessly move between the application and the communication. A single, integrated edit / control or edit and control allows the same place to host a query through a specific structured database. The system is given the ability to access the appropriate state of the application state and the application.

The system provides a "personal portal" for providing access to applications and services on a PC. For example, it uses perception of the user schema to intelligently live and layout pages. It provides key linkages required by the user to navigate personal, shared, and global information and to run a computer.

Thus, the user interface is multi-modal that allows flexibility in receiving input from the user and providing output to the user. The user interface is also responsive in that it scales properly to the functionality of the client device and allows the user to switch the client device mid-session. The user interface is intelligent in that when the user interface recognizes a particular item, it infers the intention behind the user action and takes the appropriate action, such as providing a smart tag with an associated action menu appropriate for the particular item.

F. Events

The event component 155 of the present invention distributes an event between any software component that publishes or raises an event ("event source") and any software component that subscribes to or receives event notifications ("event sink"). It facilitates communication transparently. In the present description and claims, events are observations about one or more states, such as, for example, the status of system components, activities of users, measurements of the environment, and the like. The event system enables software components and architectures to have access to continuously updated information about the context.

5 generally illustrates an event component 155 that provides for typical communication of events between one or more event sources and one or more event sinks. Events are generated at event source 602 in a variety of ways. The event may be generated by the event source 602 as broadcast or direct communication to the event sink 604. The event sink 604 can listen or actively poll the event source 602 to receive the event. Further, event sink 604 may subscribe to event source 602 or, alternatively, listen for events forwarded from intermediate points in server federation 120.

The event component 155 gradually converts the basic or atomic event 606 provided by the event source 602 to a higher level event through the event synthesis mechanism 608. The process of event synthesis is the construction of a new event or action from a set of stored event data and / or observed events. Event synthesis can be driven by rules, filters, and by more advanced pattern recognizers that span the elaborate spectrum all the way up to the rich inference mechanism. Thus, event synthesis adapts the set of available atomic events 606 into observations 610 that match the informational needs of the software components and provides them with information at the right level of abstraction to make good decisions. do.

Event synthesis 608 aggregates, filters, and converts lower-level events (atomic events) 606 into higher-level events 612 and sometimes converts the events into actions such as world action 614. Map directly. The action includes an information-accumulation action 616 and a real-world action 614 that can be used to actively accumulate new events via polling or listening. Event synthesis 608 provides a method for combining events and data whether an event is observed at a close time or at a very different time. Event-specific language 618 and composite compiler 620 may be used to build composite components. Event synthesis 608 may use a variety of methods, ranging from simple rules and filters in sophisticated full spectrum to combining events and data, to rich temporal pattern matching and inference of frank logical and plausibility.

By way of example, a consumer of an event, such as event store 622, performs inference 624 from a set of low-level (atomic events) 606 or higher level events 612 and takes action based on these inferences. . Reasoning 624 may range from simple retransmission of information to logical, Bayesian, and decision-theoretic reasoning. For example, the user's location, activity, and stream of events for the active device provide a set of probabilities for the user's goals that can be used sequentially to make ideal decisions about the most important services and notifications to provide to the user. This can be analyzed by Bayesian model. Although FIG. 5 illustrates event synthesis 608 as separate from event-based inference 624, a sophisticated synthesis mechanism for synthesizing high-level events from lower-level events is decision-making. Inference and conceptual merging

The event component 155 is " metareasoning " to occur with respect to subsystems and other aspects of the overall event system that give the system the ability to self-monitor, control and throttle event communication and reception. Provide events that can be distributed, registered, and accessed at all server federations 120 and client devices 100. Metarising refers to reasoning mechanisms and methods that ensure the maintenance and health of the event system.

Event component 155 allows any event source or sink to publish, subscribe, or listen to an event that is broadcast within a broad or scoped domain. This requires intelligent distribution of subscriptions, placement and decomposition of synthesis at intermediate nodes in the network, and routing. The event component uses the security service of the security component 165 to enable event sources, event sinks, and intermediate nodes to delegate functionality.

The event component 155 maintains the best degree of individual sink / source privacy and overall system security, while facilitating interoperable communication and prioritization between otherwise incompatible event sources and event sinks. It is designed. Event component 155 includes, but is not limited to, a publishing and subscription system, event synthesis mechanisms, event routing mechanisms, event storage and logging mechanisms, and event system metazoning. Event component 155 also uses the schema and schema services provided by schema component 170 and the quality of service and communication protocols provided by messaging component 160.

An event schema is a collection of relationships between these classes that define class descriptions and physical event structures. Relationships between classes include event classes, sources, targets, semantics, on-to-logical content information, observable reliability, and quality of service attributes known by the event source. In a preferred embodiment, the class description is an XML based schema class.

Event descriptions use a schema description language to express their structure and constraints and a declarative pattern language to express predetermined behaviors and synthetic characteristics. Within the schema language, the event structure is simple. The event has a private body that is used to privately carry the public envelope and end-to-end data used in pattern matching and routing. In this structure, the pattern language can use both instance data and schema information to capture the higher-level semantics and rules that will generate derived events.

The use of a schema language allows a wider representation than a simple name-based convention. Individual events are filtered and transformed, and multiple events are combined together into higher-level events. Pattern languages include operators for synthesis and encapsulation, temporal relationships, logical relationships, string manipulation and XML operations, endpoint naming and topology descriptions, and mathematical relationships. The language facilitates reuse of synthetic specifications through parameterization.

The event schema can be extended. A strong relational model based on inheritance allows backward compatible versioning. Event types have well-defined characteristics based on a powerful extensible type system. The model is described as protocol independent using the standard XML vocabulary. In addition to the event schema, various services are modeled including distributed event systems (e.g., publisher function schema, subscriber function schema, event forwarding schema, topology, event store schema, synthesis and filtering, etc.).

Schemaizing the services / components of the event service allows the achievement of interoperability, discovery, and the ability to browse all components of the event service. Schemaization also enables the ability to statically analyze / optimize synthesis scenarios, investigate / store the state of long-running synthesis scenarios, monitor the operation of event services, and use them as the main foundation for metarising. Let's do it.

The event system includes a highly optimized publishing and subscription service driven by model-based subscription registration. The event system includes, for example, kernel events using the kernel driver programming model (eg WDM driver events), non-COM APIs for event publishing using the low-level operating system services programming model (eg security audit events, directories, Service selection manager, a classic COM interface for regular applications, and a high-level COM + class that uses the native COM + programming model.

An "event subscription" is a request that the event infrastructure informs the subscribing component when certain conditions occur. Examples of such conditions may be "more than 90% CPU utilization", "Process A stop", and the like. These commands are stored as configuration objects in the schema repository.

Each command consists of two parts. The first part specifies the event of interest (filter). The second part specifies the action to be performed in response to the event. The filter contains a statement that defines the event of interest. A single filter can trigger multiple actions. The action can be driven by a set of user-defined rules. For example, a user may specify that interruptions in phone calls can occur only when receiving an email from some high priority sender. This allows the user to continue the phone call without interruption if he does not want to be interrupted. Thus, a user can balance work and personal time by specifying a rule that interrupts work time to personal time and personal time to work. If interruption is appropriate, the email message will then be served from the mega-store. In this way, the user maintains control over information and time.

Subscriptions can have a configurable lifetime, based on the concept of a lease. Subscriptions that need to live longer than a system reboot are stored in the schema repository. However, low-value, short-lived event subscriptions must also be supported. They can consist of simple callbacks and filters without requiring the subscriber to implement sustainable binding.

Subscriptions can be point-point or point-group. The distributed service is interested in the scenario "Inform when any server in domain X fails over" or "Log all security intrusions on all machines in domain X where application Y is installed." So instead of events happening on individual machines, distributed applications are interested in events that occur in groups of machines that are part of server federation 120. These scenarios require that a subscription be defined once and automatically distributed to all or several machines in the group and the subscription automatically applied to them as new machines enter the group.

Distributed subscriptions from groups to events are represented by objects in the distributed namespace provided by directory component 150. They may also contain routing configurations that instruct the forwarding service to which events should be sent. When a new machine enters the cluster, the availability of distributed namespaces ensures that all subscriptions are deployed and events start flowing to the subscribers.

The subscription builder must be able to specify the quality of service ("QoS") required for those subscriptions. The event component 155 cooperates with the messaging component 160 to ensure that QoS is met by using the appropriate transport parameters and thus conducting a reset of the business (e.g., if delivery is guaranteed to be specified, all Internal queues must persist QoS).

The number of events that occur in the environment can be very large. Thus, the cost of event delivery can incur significant operational overhead. In order for the publishing service to scale the system, events that no one expects should be discarded as early as possible in the event lifecycle. To achieve this, an efficient filtering service quickly validates the event for significant subscriptions. However, the number of existing subscriptions can also be very large. Therefore, the filtering service uses an efficient inverse query engine based on mechanisms such as decision trees.

In addition to filtering events, the event filtering engine provides subscription analysis services to publishers. The service informs the publisher when the subscriber is interested in the event and when no one is interested anymore. It is prepared for the publisher to perform any filtering that can be done instead of supplying useless events.

Distributed event-driven services include scenarios that are rarely important if individual events do not occur in any sequence or match any data state. Examples of such scenarios include "Notify me when all backup controllers are down", "Notify me when server crashes 5 times during load", or "User visits more than 5 menus without selection within 5 seconds of horizontality." Identification ". To detect these combinations, the system synthesizes events and data.

Event synthesis service 608 may be a state machine driven by event and data conditions. In one embodiment, each composition service is configured internally as a combination of objects describing state transitions. Since some services can be very complex, a composite language or template can be provided to simplify the task of setting up the composite service. A set of similar events (eg, "page me on all transaction-failure events that occur on any SQL server in my enterprise except when it happens in less than 5 minutes after the server is shut down"); Synthesis of events and data (eg, "don't bring it up if an email arrives while I'm reading something else"); Calculating status from events over time (eg, “What was the trend of my email queue size during the last days?”); And counting and heartbeat monitoring (eg, "Please let me know if no key is pressed and no mouse movement within 5 minutes") is a typical scenario.

G. Messaging

The messaging component 160 of the present invention allows the client device 110 and the server 140 to communicate. The term "message" extends to structured data exchanged between other components or applications of operating environment 100. Examples of messaging include application-application messaging, person-person messaging (e-mail), and cooperative applications. According to a preferred embodiment, the messaging component 160 is HTTP-enabled and is compatible with firewall configurations including a DMZ, load balancing server, and NAT service.

To facilitate interoperability, messaging component 160 provides a common set of services and common messaging layered on top of HTTP, SMTP, and / or other transports to provide common semantics to message applications independent of underlying transports. Provide an application program interface (API). In this way, the Internet and other wide area networks are leveraged to provide efficient and ubiquitous messaging independently of the transport protocol associated with a particular device as long as the transport is compatible with a common messaging API.

In addition, messaging component 160 may be highly scaled in the number of connected devices and users that may support and also in the type of network or device that may be used. In other words, messaging component 160 is readily suited for use with systems and devices ranging from small wireless devices to "mega-scale" networks and messaging systems. This scalable feature is characterized by the ability to build messaging applications on a messaging platform that allows small devices to participate in sophisticated distributed services as well as high quality of service (QOS) message exchanges. In other words, messaging component 160 may be highly scaled on a server or scaled down to a small device, meaning that it is possible to build a suitable "small footprint" subset.

In contrast to conventional messaging systems, the messaging component 160 of the present invention utilizes a platform messaging architecture. Rather than being a layered product, a messaging service may be a new application and message-based service, for example distributed events such as provided by event component 155 may be written by an entity operating the present invention or a third party messaging service. Present as a base platform substrate. Messaging component 160 is defined in a manner to recognize and accept Internet-based protocols and to utilize new and existing protocols in a common manner. In addition, messaging component 160 provides asynchronous, connectionless, exactly-once store-and-forward reliable messaging, in-order message delivery.

Messaging component 160 is targeted to an application or service-defined message "blob" that reliably delivers, in contrast to a messaging system that depends on or knows a particular message type, message content, or service protocol. The messaging component 160 does not directly implement a data dependent routing schema, topic or subject-based publishing / subscribe infrastructure, or other messaging conversion services.

Messaging component 160 provides a basis for the transport layer of distributed event support. Although messaging services can be further supplemented with additional functionality, the present invention may be practiced without a message service defining a complete integrated event system. In addition, the messaging service does not need to define an integrated high-level discovery message endpoint discovery service.

One embodiment of messaging component 160 is described in greater detail below with reference to FIG. 6. To meet the need for reliable and flexible messaging for applications, users, hardware, and the like, the messaging component includes a common API 702 for all messaging activities. API 702 exposes a common developer interface and provides a common implementation of shared performance, such as authentication, access control, and quality of service assurance. Messaging component 160 also preferably includes messaging application 704, gateway 706, routing 708, HTTP communication service 710, and transport 712, which will be described in greater detail below.

The layer (hereinafter API; 702 or layer; 702) designated as queue-based API & service 702 in FIG. 6 provides a common interface and common service in all other transports. API 702 establishes a simple programming model that enables a developer to deliver a message to a destination that can be identified by a URL in one of several URL namespaces. In a preferred embodiment, the underlying destination establishment of the API 702 may be a queue similar to that of the existing MICROSOFT® Message Queue (MSMQ) queue-based API developed by Microsoft Corporation of Redmond, Washington.

Since other transports 712 do not have the same level of intrinsic services inherently, many of the services are implemented in layer 702. Since different transports 712 have different levels of integration services, it is desirable to use them when transports have unique mechanisms for characteristics such as authentication or higher quality of service, so that layer 702 and specific transports The interface between the ports 712 is quite sophisticated. However, all of the basic functionality is also provided on top of any transport 712 that supports simple best-effort delivery of Abiteri messages.

In accordance with one embodiment of the present invention, layer 702 preferably associates it with a range of quality of service to message delivery. For example, the presentation QOS is defined as high performance in-memory based messaging that is not resilient to message host reboots. Ongoing QOS is disk-based messaging that provides at least one delivery guarantee. Exactly once / in-order QOS relates to ongoing messaging that provides exactly-once ordered delivery (copy is identified and removed, and inappropriate arrival is rejected).

The security service of layer 702 may enable authentication, access control, and / or secret services in accordance with security component 165. For example, authentication may be based on a certificate according to an end-end model, which may be user-based or machine-based, or may be XMLDSIG, MSMQ, Secure Multipurpose Internet Mail Extensions (S / MIME), or other suitable authentication system. It may be provided according to other models including. Access control (i.e., who is allowed to distribute and manipulate the queue) can be controlled in a user-oriented manner based on the credentials established in the message authentication. Secret services (ie, encryption and decryption) can be established using hop-hop secrets enabled over HTTPS, implying that the intermediate server is trusted. End-end secrets may be enabled via a key exchange protocol.

The messaging component 160 of the present invention may be adapted to operate with various existing and future transports. Indeed, the ability to interoperate with other transports is a major goal of the existence and design of the API. Although other transports may be used, FIG. 7 illustrates the API 702 being used in conjunction with four transports 712, which are examples of transport protocols that specifically maximize reach and functionality. HTTP / HTTPS 712a is a transport protocol that uses SOAP-based message presentation. MSMQ binary transport 712b supports a rich set of QOS. For example, MSMQ provides a highly optimized binary format that is compressed and enables structured access to message content. Multicast transport 712c supports applications that require simple messaging with high scalability of the recipient. The SMTP transport 712d is provided for applications that fit well with the traditional SMTP model. SMTP is well suited for larger message sizes and other scenarios typical of email traffic. SMTP also has the property (in deployment reality and protocol) to make it useful for business-business (B2B) applications where the use of existing infrastructure is desired. Although SMTP supports basic "at least once" quality of service and simple authentication, it has good performance except for a fairly low level of additional functionality.

Gateway 706 is treated somewhat differently than built-in transport 712. In general, the transport 712 does not support a fully pluggable model in which third parties can add new components. Instead, gateway 706 receives message traffic for a portion of the URL namespace. Gateway 706 can then connect to other types of communication systems, such as MQSERIES® or GROUPWISE® email connectors.

The messaging component 160 enables message exchange between multiple parties in an interoperable and transparent security manner. To do so, a common self-descriptive language encapsulates messaging metadata and payloads. In a preferred embodiment, XML is used as the description language to describe these needs.

Scalability is important for having messaging application 704 add a value to underlying messaging component 160 in a seamless manner. For example, the protocol should have a general mechanism to introduce application-specific modules. Examples are message tracing, logging, and data conversion. This should be exposed as a standard for inserting application-specific elements into an XML document that encapsulates a message.

In the preferred embodiment, messaging component 160 uses HTTP as a transport, which specifies that an "HTTP proxy" service can be used. Similarly, standard HTTP security mechanism (SSL) can be used by messaging component 160.

To scale, messaging component 160 can use the available load balancing service. For lower quality of service, messaging is essentially stateless and thus the underlying load-balancing mechanism being used is transparent. However, since higher QOS is inherently stateful, the messaging service is a mechanism for state preservation in all message exchanges, including both external mechanisms (application-specific) and internal mechanisms (generated by the messaging infrastructure). To provide. To do so, messaging component 160 may use a single back-end message store where end-end delivery semantics are preserved and a mapping facility from an external address to an internal message store address. Note that the mapping facility may be provided by an "incoming messaging proxy" service that may be deployed with the intranet as well as providing Internet presence.

In general, a messaging host that uses HTTP as a transport needs the ability to send and receive messages. This implies that it has both HTTP "listen" and "talking" services. In a preferred embodiment, the universal listener provides basic server-side HTTP protocol support. The universal listener, a system component shared by all HTTP servers on the machine, manages port 80 on behalf of all server applications and surfaces that make requests through the Universal Listener API (UL API). Services and applications can use the UL API to receive requests directly into their process environment. Optional process management facilities are provided to server applications (eg, active server pages) that wish to have their requests serviced within a system-managed process.

Universal listeners provide a kernel-mode listener shared by all HTTP-based server applications on a machine. All applications can share port 80 efficiently. The universal listener can also request parsing and provide a response cache for high performance delivery of static content and "stable" dynamic content. The application can control caching via the UL API and configuration. The cached response can be delivered without entering user mode.

The universal listener can further dispatch the request to a user-mode "worker process" based on the longest match URL prefix. These user-mode applications have complete isolation from the core listener components. Worker processes can receive and respond to requests using the "UL API". In addition, the worker process serves multiple parts of the URL namespace. One or more worker processes (“gardens”) serve the same set of applications for increased scalability, availability, and intra-application isolation.

The HTTP-server process manager is a system component that can optionally be used in conjunction with the UL to manage worker processes. The process manager provides on-demand launch of worker processes (eg triggered by incoming requests). In addition, the process manager may establish worker process "cycling" (shutdown / restart) and worker process "health monitoring" to recover from leaks, hung servers, and the like. Cycling can be triggered by the number, time of requests received, or as a result of health monitoring. Furthermore, process managers can provide management interfaces for ongoing configuration and control and configuration.

In one embodiment, the HTTP client is implemented in kernel mode. Reasons to implement in kernel mode include: 1) performance; 2) communication with kernel components; And 3) listener / talker integration. Listener / talker integration includes performance optimization and shared implementation.

The messaging system can optionally implement an HTTP protocol extension and supports being established in both listener and talker implementations. One extension involves "web muxes" that enhance HTTP connection management to support more efficient connection multiplexing, which can be particularly valuable in high volume B2B scenarios.

As noted above, messaging component 160 provides efficient and reliable messaging using any of a variety of transports, including HTTP. Messaging component 160 is used by other technology platform components to pass information. Messaging component 160 establishes a standard interface that allows developers to write applications and to take advantage of the overall architecture of messaging services and other features associated with the present invention.

H. Memory

In describing the storage component 145 of the distributed computing services platform 155, the term “data engine” is a desired program in the form of a data structure or computer-executable instructions that can be accessed by a general purpose or dedicated computing device. It refers to any medium that can be used to carry or store code mints.

Data engines can be associated with many types of devices. By way of example, the data engine may be associated with any client device 110 (such as a desktop PC, laptop computer, personal digital assistant (PDA), cellular telephone, pager client, etc., as described above in conjunction with FIG. 1). The data engine may also be a server device 140, such as an application, audio, database, fax, file, intranet, mail, merchant, modem, network access, print, proxy, remote access, telephone, terminal, video, or web server. May be associated with These servers may be located in server federation 120.

FIG. 7 illustrates a typical architecture for storage component 145, illustrating the use of a data engine, accessibility of data, and execution of one or more applications. The storage component 145 may be classified into three areas that are generally characterized according to the type of entity that uses each particular area. These regions are shown as regions 802, 804, and 806 in FIG. 7. By way of example, a user generally uses area 802, a developer generally uses area 804, and an administrator typically uses area 806.

The foundation of the storage component 145 is, for example, a file system of an operating system, such as the MICROSOFT® WINDOWS® operating system. In FIG. 8, the file system is shown as file system 808.

The data engine 810 is the heart of the storage component. In a preferred embodiment, the data engine 810 may be a SQL server storage engine based on a SQL server from Microsoft Corporation. For example, various data models such as messaging data models (e-mail, calendar, group productivity), relational data models, XML data models, such as exchange data models (not shown) based on exchange servers from Microsoft. It is built on top of this data engine 810. The data engine stores the data in the most efficient format. A data model or engine layered on top of the data engine understands how to access the stored data and present the correct view to the developer. The data can be presented in many formats such as, for example, tables, hierarchies, or a series of name / value pairs. The data model may include one or more engines. By way of example, the XML data model includes an XML engine 812. Similarly, the relationship data model includes a relationship engine 814.

Developers use Database Programming Language (DBPL) technology to communicate with various data models through a common query system. DBPL technology includes a data access application program interface (API) 816, which is a format used by application programs to communicate with a system. The format uses a function call that provides a link to the subroutine required for execution. In a preferred embodiment, DBPL technology is based on XML (XML 818), can use a relational model (relationship 820), and uses object technology (object 822).

The upper layer, shown as area 802, includes various applications 840a, 840b, etc. used by the user / consumer. The application integrates documents, mail, calendaring items, contacts, stock portfolios, customers, orders, media-based product catalogs, for example. The application sits on top of various data models and talks to the system using specific protocols 824. In a preferred embodiment, the protocol 824 is a simple object access protocol (SOAP) 824.

In the preferred embodiment, the components of the storage component 145 are based on XML as integrated technology so that all types of data are processed as XML documents. The communication and server federation 120 associated with the distributed computing services platform 115 of the present invention is built on an XML Foundation. Messages, method calls, object descriptions, and data engines all use XML. The language of the statement works on the hierarchy and returns the hierarchical XML. Because storage component 145 is based on XML, storage and query operations are the same in the entire data spectrum from tabular format to document.

Storage component 145 is a key component that enables a storage mechanism named herein "mega-store". In a mega-store, the server federation 120 of FIG. 1 acts as an integrated storage mechanism from the end-user viewpoint. Mega-stores are illustrated by the following scenario. The user goes to the PC and logs on. This logon authenticates the user with an Internet authentication service provided by security component 165. After the user is authenticated, directory component 150 may be used to determine where the user's information is stored. Storage component 145 then retrieves the data and provides it to user interface component 140. Thus, personalized information appears in user interfaces such as history lists, favorites lists, inboxes, etc. without requiring additional user intervention. Thus, when a user moves from device to device, they follow their data and applications.

Mega-store includes end-user components and developer components. End users simply understand that when they log on to the site their personal data and information are automatically accessible and stored for them. As such, the user does not need to understand or engage in what servers or cookies their personal data and information are stored, for example, in server federation 120. Rather, the user only needs to understand that their personal data and information can be easily accessed wherever they go, whether at home, at work, or elsewhere.

I. Directory

Typically, a directory is an enterprise-wide naming authority that creates an illusion that data is sorted into an organized structure when data is often scattered throughout the enterprise. Examples of data contained in the directory include address book data, such as contact information about an entity (eg, user, computer, and user group), authentication data used to authenticate the entity, and a basis from entity to object to object. Contains authorization data used to control access. Two kinds of directories include adaptive directories and meta-directories.

An adaptation directory is a data store that is also adapted to one or more specific purposes. Directory functionality may be application-specific. The information stored in the adaptation directory is either authoritative data or "true" data (ie, data that is not synchronized from other sources), but the adaptation directory can also store duplicate data (ie, data synchronized from other sources). Examples of adaptation directories will be described further below.

A meta-directory is a data store that contains or maintains a subset of objects found in an adaptation or other meta-directory. For each object, the meta-directory maintains a subset of the attributes of that object. The meta-directory also contains a reference to a directory that contains more complete information about the object. Examples of meta-directories will also be described below.

Well-defined schema and meta-directories are more easily synchronized than those directories with poorly defined schema. Synchronizing the adaptation and meta-directories is useful because the information stored in the meta-directory may also be related to the association between related entries in the various adaptation directories. Often, data stored in meta-directories can be used or read by anyone. In some cases, however, more security is required and access to the meta-directory is more controlled.

In order to enable coordination and communication through the entire server federation 120, the directory component 150 preferably provides a meta-directory per portal or per web site synchronized between meta-directories. Directory component 150 includes the use of both adaptive directories and meta-directories.

8 illustrates a directory component 150 in accordance with the present invention. Directory component 150 includes an adaptation directory 905 that is specific to an individual or entity and referred to herein as a "my state" directory. My state adaptation directory 905 is used to store information such as name, address, phone, etc. for an individual or entity.

Since an individual can have more than one identity (eg, family / personal and workplace / occupational identity), my status directory may contain information about more than one identity for any given user. Can be. For example, a user may have an adaptation directory specific to a home or personal identity and an adaptation directory specific to a user's work or professional identity. An example of an adaptation directory specific to an identity at home is shown in FIG. 8 as the home presence directory 910.

These adaptation directories 905 and 910 are structured according to the schema. Through the use of services provided by schema component 170, external services and applications can access and extend these adaptation directories. In combination with security component 165, the schema also allows a user to have other entities access special or specific portions of the adaptation directory. Through the use of event component 155 and messaging component 160, my state directory can also terminate the relationship between an entity and my state directory, as well as notify other entities of changes and updates to my state directory. have. Directory component 150 also includes portals with meta-directories such as, for example, enterprise portal 915 and portal 920. In one example, the portal can be viewed as an industry wide website. Thus, there exists a healthcare portal, a shopping portal, a music portal, and the like. Each portal implements one or more meta-directories to maintain information from related business and entities. For example, some of the healthcare portal's meta-directories may contain information about related entities or people, including but not limited to doctors, clinics, pharmacies, and patients. The portal meta-directory will maintain or store an object for each authenticated user. Each object may, for example, accept authorization information provided by the user because the user accessing these meta-directories is often authenticated. Portals also synchronize the relationships between other portals and the adaptation directory. For example, the physician's adaptation directory may be synchronized with the patient's adaptation directory via its respective meta-directory or by a healthcare portal.

Directory component 150 preferably includes various enterprises. For clarity, only one of these enterprises (ie, enterprise 925) is shown in FIG. 9. Enterprise 925 includes an internal meta-directory 930 and an internal adaptation directory 935 as commonly accepted by today's enterprise. Thus, enterprise needs only need to be migrated by using a portal such as enterprise portal 925 to tap into the vast directory services provided by directory component 150. By making the internal enterprise to be migrated an enterprise portal, third parties will be able to access the entity's information more easily.

Directory component 150 also includes Internet meta-directory service 940. Internet meta-directory services can search the Internet to find documents or data with a particular schema. Such a directory may include information such as products sold by the company, services provided by the company, and the like. Each document (or a subset thereof) is incorporated into the meta-directory along with the document's URL. Applications and services may thus access the Internet meta-directory 940 to point them to the information or services they need.

Directory component 150 may use Internet authentication service 945 (provided by security component 165) to provide an authentication service to the portal as desired. An example of an Internet authentication service 945 is called a passport provided by Microsoft Corporation.

9 is an example of a conversation between various adaptations and meta-directories. These examples do not limit the scope of the present invention, but are examples of some of the functions made possible by the present invention. This example illustrates a new employee starting work with a new employer. Employer has enterprise portal 1022 which houses employer meta directory 1024. When an employee starts work, an employee record directory 1002 is added to the adaptation directory 1000, which is also maintained by the employer in this example. Thus, employee record directory 1002 is an adaptation directory that holds authoritative data for employees according to a schema.

Employee record directory 1002 adds employees to employer meta directory 1024 and promotes many attributes to employer meta directory 1024. Information between these directories is synchronized by automated attribute aggregation (AAA). Accordingly, employer meta directory 1024 has employee object 1018 having associated attributes 1020 that contain redundant data related to authoritative data stored in employee record directory 1002. Employer meta directory 1024 also sets up an adaptation directory, work presence directory 1004, work calendar directory 1010, and a mail directory (not shown).

Next, the new employee visits the security office to obtain a security badge. He uses a personal digital assistant (PDA) or other device to register a previously existing authentication directory 1008, which is another adaptation directory with a passport key, for example. The authentication directory 1008 is then linked to the employee's identity or object 1018 in the employer meta directory 1024.

The employee instructs the PDA device to update the employer with personal information such as address, phone, and the like. This is accomplished by establishing an AAA between my state directory 1006 and the employer meta directory 1024. My state directory 1006 is also an adaptation directory. This connection allows an employee's PDA to use the employer meta-directory 1024 to find a work presence directory 1004 that has a presence server and an interface with that presence server or access to an employee's universal inbox. After these associations and connections are made, the employee can receive an email from an employee record directory 1002 that asks the employee to select a health provider. The employee's selection is stored in employer meta-directory 1024. Next, employer meta directory 1024 connects with health provider portal 1016 and health provider meta directory 1026 to create an entry for the employee. Thus, the health provider meta-directory has an object 1012 and attributes 1014 for the employee. The AAA aggregation between employer meta-directory 1024 and health provider meta-directory 1026 may accommodate other items. For example, the aggregation may include periodic audits as well as aggregation by the employer meta-directory to forward changes to the health provider meta directory.

The health provider meta directory 1026 sends an employee a web page asking the employee to select a primary car provider. In response, the employee asks the health provider meta-directory 1026 to supply a list of doctors. After the physician is selected, the health provider meta-directory 1026 will contact the clinic or physician portal and create an entry for the employee in the clinic meta directory 1028. The clinic meta directory 1028 sends an email to the employee requesting the employee's medical record. An employee can release only the medical information portion of my status directory 1006 to the clinic meta directory 1028. This allows both the employee and the clinic to maintain both complete sets of records. At the same time, employees can approve sharing their calendars with doctors who can exchange each other. Finally, the clinic meta-directory 1028 may signal the workflow service to schedule their first appointment with the employee using their mutually accessible calendar.

Again, the authoritative information stored by the adaptation directory is linked by the meta-directory in this example. Clinics, employers, and health providers are also understood to have various adaptation directories. The conversation with those directories and meta-directories is not shown in FIG. The meta directory may store hint information or redundant information related to authoritative information. The schema of the adaptation directory may allow other meta directories to access certain portions of the adaptation directory. Authoritative and redundant information is synchronized to ensure that the data is up to date.

In FIG. 9, each of the adaptation directories in the adaptation directory 1000 has a specific purpose or set of purposes. The employee record directory 1002 indicates a job identity, while my status directory 1006 indicates a personal or home identity. Authentication Directory 1008 The adaptation directory can accommodate information such as passwords used to authenticate individuals. Work calendar directory 1010 is a calendar or contact list. Using an adaptation and meta directory as shown in this example enables advanced communication between entities. In this example, communication is enhanced because employees are not required to talk to each individual portal. Directory component 150 causes communication to occur automatically because they are all connected and linked via messaging component 160.

J. Security

As noted above, the Internet has been rapidly adopted over the past few years, with associated dramatic increases in the use of Internet-based services, both consumers and businesses. The present invention allows for greater Internet connectivity and cooperation, with increased inter-site communication. Unfortunately, as the number of users of the Internet and Internet-based services increases, consumers and businesses are increasingly worried about security and privacy issues. For example, many consumers and businesses rely on various Internet Service Providers (ISPs) that can track consumer and business on-line activities in considerable detail. Many consumers also use multiple service providers with widely changing business relationships and absolute trust (subscriptions, transactional transactions, and rice fields). In addition, 'always on' Internet access (Digital Subscriber Line (DSL), cable modem), multiple Internet Capable Devices (Personal Computers (PCs), Cell Phones, Personal Digital Assistants (PDAs)), and Internet Conversations With the increasing use of multiple home network devices that can communicate with each other in different ways, consumers and businesses achieve greater connectivity, but the number of access points for unscrupulous individuals or businesses to "get" personal and / or confidential information. To increase.

To minimize the above limitations, the present invention optionally includes a security component 165 that provides a number of security protection tools such as, for example, authentication, privacy, and firewall security boundaries. 10 is a schematic diagram of one embodiment of a security component 165 of the present invention. The schematic representation of FIG. 10 illustrates optional functionality of security component 165 and does not limit the applicability of other functionality to be recognized by those skilled in the art in view of the teachings contained herein.

In accordance with one aspect of the present invention, security component 165 may be configured with various hardware and / or software used to perform an authentication process for an entity that accesses data and information within server federation 120 and client device 110 of FIG. 1. An authentication module 1102 that includes the component. An entity can access stored information and data when it is involved in a multi-party conversation involving a wide range of configurations and transaction participants, whether the entity is a consumer-business or a business-business, for example.

In one embodiment, in more detail, the authentication module 1102 prevents the hiding or "repudiation" of an entity's identity from another user or entity of the system 100, while the page component of FIG. 210, hardware and / or software modules that control access to the entity component 220, and / or the FD dome component 230. The term "entity" as used herein includes not only (individual or grouped) users, but also machines, authorized software arbiters, server and proxy services, various other hardware and / or software modules and components, and the like.

To determine whether an entity is the entity they are describing, whether it is a consumer, business, hardware module, or software module, each entity must have an identifier called a "global ID". Each global ID corresponds to one of a variety of "identities" that a person or other entity may choose to take. Most people (including other entities) will have at least two identities that belong to their occupation (students, employees of an organization, etc.) that will be used when performing business-related activities and personal identities that will be used for other conversations. Additional identities can be used to explain the need for a user to maintain a privacy or higher level of assurance associated with some of their conversations.

In combination with the system 100 and / or the application 200, the security component 165 provides a user experience that allows the end user complete control over how identities are used and the level of confidentiality and privacy associated with each identity. In doing so, they will manage these identity and associated certified credit guarantees and ensure that their identity is kept separate.

Referring now to FIG. 11, a schematic representation of a conversation between a user's global ID and various other exemplary services and information is described. In general, security component 165 may communicate with various global IDs 1220a-1220n owned by various individuals, businesses, machines, and the like. Each global ID 1220a-1220n is used for authentication of an entity accessing a portion of system 100. Global IDs 1220a-1220n are not intended to contain profile properties of the entity they represent. Rather, in one embodiment, the profile is stored using the "My Status" adaptation directory 905 provided by directory component 150. The "My Status" adaptation directory 905 may optionally include various portions indicated by reference numerals 905a-905n. My state adaptation directory 905 provides a place to store user profiles that contain user data according to the grid. In general, each global ID 1220a-1220n provides an index to profile information stored in individual portions of my state service in an application or in a site-specific data store. Thus, an entity may have multiple global IDs 1220a-1220n, each of which has a different profile associated with it.

Alternatively, in one embodiment of security component 165, each global ID 1220a-1220n may be architecturally referred to herein as a "group membership" service 1224, which may optionally include various sub-parts. It may be associated with another distinct service, and only a portion of the group membership service 1224 is shown and shown by reference numeral 1224c. Sub-part 1224c allows for one global ID, such as global ID 1220b, which will have one or more profiles in the profile list for each category 1226a-1226n of the user. Alternatively, each category 1226a-1226n may include one or more pointers to the requested or defined profile. For example, in a business-business scenario, group membership service 1224 may be used to accommodate a list of authorized buyers that many suppliers may examine. In a cooperative scenario, the group membership service may accommodate project members of another legal entity that is allowed to access project confidential documents. In another example, each global ID 1220a-1220n may be one or more digital signatures, X.509 certificates, extensible markup language (XML) certificates or "licenses" that bind the key to an identity and prevent denial of identity. ", Or other certificate formats. In such cases, various CAs may issue such certificates, such as, but not limited to, Microsoft® Passport, Microsoft® Hotmail, and / or various other third party businesses.

Referring again to FIG. 10, in accordance with another aspect of the present invention, security component 165 includes an authorization module 1104. Authorization module 1104 provides various hardware and / or software modules and components to determine group memberships, roles, and actions that an authenticated entity may perform in a dynamic environment in which delegation of the rights of each entity may change. It includes. As such, the authorization module 1104 of the security component 165, such as "licensed content" and private data, such as copyrighted books, songs, and movies, is more complex than the traditional "user-based" authorization model. You can, but are not limited to, enforce enforcement of restrictions on entity use for controlled data. In addition, the control mechanism of the wider and more flexible delegation and authorization module 1104 extends the traditional role of authorization.

One way in which the authorization module 1104, in combination with other modules of the security component 165, achieves advanced in authorization fields and technologies is through digital rights management. Digital Rights Management (DRM) involves the automated enforcement of conditions and rules for the distribution and use of information and content. Premise, executed against traditional system security intuition, is at the heart of DRM. In typical system security, the source of the authority to access the data or information is the user. Once the user is authenticated, access to the service is authorized based on the user's identity. As such, the software is authorized for extent rights granted to the underlying user. Typically, an authenticated super-user (or administrator) is essentially granted infinite access to any and all resources. DRM changes these premises in several ways. In DRM, the source of an institution is the owner of the content or information. The owner's rights (and the permissions granted to the user) are named in the standard language. A right may include, but is not limited to, a variety of hardware and / or software modules and components (but limited to) that only trusted software that has been pre-certified and obliged to enforce the restrictions and rights specified by the owner is granted access to the information. But not enforcing by a "device". This allows the content owner to delegate rights to one software that will restrict access to the content based on terms defined by the owner, not to the user.

One example "device" in which DRM can be achieved is a trusted device called an authenticated boot / isolated executable personal computer. A "device" may include a trusted (and tamper-resident) hardware component that holds one or more private keys unique to the hardware component. In the operation of an authenticated boot / isolated executable personal computer, client-class software is used by a trusted device to name a hash signed by an organization (eg, hashing its code and "trusted" by the hardware). By comparing the certificate with the hash). As a side effect of authentication, the physical address used by the requesting software is isolated and other programs (including the OS) are then denied access to that physical memory. Finally, the operation of the private key unique to the hardware becomes available to the (now trusted) software. Those skilled in the art can recognize that various other devices, whether hardware, software, or a combination thereof, can perform the desired functions of the devices used for DRM.

According to another aspect of the invention, the security component 165 includes a privacy module 1106. Privacy module 1106 includes various hardware and / or software modules and components that retain the privacy and confidentiality of information transmitted and retrieved by various entities utilizing the beneficial properties of system 100 and application 200. In general, the privacy component 1106 of the secure component ensures that personal or high-value information stored on a shared public server in the server federation 120 is only opened to authorized entities. In addition, privacy module 1106 maintains data integrity of all types of information and data stored and / or on and off public servers, thus preventing unauthorized modification of transmitted data within the transition between one or more entities. Although the privacy module 1106 is shown as an independent module of the security component 165, the functionality of the privacy module 1106 does not have a specific independent modular format, but an authentication module 1102, an authorization module 1104, and a security service 1100. Those skilled in the art will appreciate that one or more of the various other modules that form.

In view of the above and other teachings contained herein, the functionality of the privacy module 1106 may be accomplished in a variety of ways. For example, in one embodiment, digital integrity may be maintained through the use of digital signatures and the ability of security component 165 and / or privacy module 1106 to manage denial of identity. In another exemplary embodiment, an encrypted transport is used to transfer data and information between multiple hosts or multiple points of client device 110 and server federation 120. Whether the encrypted transport is host-host or point-point depends on whether the communication is online and offline (store-and-forward) communication. One aspect of the encrypted transport process of one embodiment of the invention is that the transmitted data and information are optionally partially or fully encrypted. By selectively encrypting in data and information, such as messages (end-ends) for application-specific transactions, security component 165 provides secure private information without the cost of encrypting all network traffic.

For host-host transports, a security protocol called Internet Protocol Security (IPSEC) is required to implement virtual private network (VPN) tunnels and to authenticate the network connections of participating systems. Intermediate servers (but not limited to cache, airstream, content-based routers, etc.) used for host-host transport typically have lower-level network services because they do not encapsulate unique confidentiality policies for each application. It is designed to use selective message encryption. The use of selective message encryption is optional because only application content that benefits from performing the cache or requires an intermediate server to filter the content benefits from it. In contrast, personal or high-value information is encrypted for confidentiality and generally does not benefit from the services of intermediate network devices such as intermediate hardware and / or software modules and components.

In point-to-point communication, the Secure Sockets Layer (SSL) protocol is used and continues as the least-common-dinaminator legacy for applications not designed to use selective message-based encryption. Those skilled in the art can appreciate that IPSEC can optionally be used as a point-point transport. In general, the confidentiality and privacy of the transported data and information can be achieved using a combination of known methods.

In another embodiment of the present invention, security component 165 optionally maintains all data transmitted via the Internet in encrypted form. At present, the vast majority of information transmitted on the Internet today is not encrypted. With sufficient hardware and system support, the security component 165 of the present invention can selectively shift the transformation of information and data from the current "encryption on (limited) demand" to an "always encryption" solution. Encryption is a useful way to protect information and data, but by itself is not a perfect solution for all security needs. As such, the security component 165 of the present invention may combine the characteristics of the overall encryption of the transportable data and the characteristics of authentication and / or authorization hardware and / or software modules, components, and functions within beneficial properties. .

According to another aspect of the present invention, the security component 165 is distributed throughout the entire server federation 120 and thus provides distributed network security. In general, the distributed nature of security component 165 allows the intermediate proxy server to route events and messages correctly, while providing end-to-end confidentiality and the integrity of the message content, whether host-host or point-point. Overall network security controls the data flow to prevent malicious interference with computing nodes (eg, flooding, destructive viruses) and unauthorized dissemination of sensitive data. Typically, many of these functions are performed by firewalls. Unfortunately, with the advent of XML messaging over Hypertext Transfer Protocol (HTTP), a typical firewall is less effective at distinguishing between entities and requests. As mentioned above, the selective use of encryption in the message stream allows filtering of message content without loss of confidential personal data; However, this also limits the kind of protection that can be provided by a firewall.

Currently, firewalls work mostly in the transport layer, which examines transport level information such as source and destination Internet Protocol (IP) addresses and Transmission Control Protocol / User Datagram Protocol (TCP / UDP) ports. Although useful, many traditional firewalls have already been extended to scan accessed data for viruses in binaries or text for illegal content. Thus, the classic firewall model is based on two independent trends: whether the use of encryption prevents even the inspection of data or ports, and whether the use of HTTP by XML-based applications sharing a single TCP port reduces the value of the TCP level filter. The problem has been raised. As such, current firewalls are limited in their effectiveness because they mix two functions: protection against external attacks and enforcement of policy. As such, the present invention shares the effectiveness of a firewall by sharing its functionality among three or more other modules and components that may be localized within a single hardware and / or software module or alternatively distributed throughout the entire server federation 120. Increasing firewall module 1108.

Referring now to FIG. 12, which illustrates an exemplary element of firewall module 1108, part of advanced firewall module 1108 is personal firewall 1310. Personal firewall 1310 performs data inspection locally after decryption and performs various other protection functions. For example, personal firewall 1310 performs various functions of the "virus check" system; However, when a new attack is detected, the attack signature is quickly propagated to all personal firewalls, thus blocking the attack without having to wait for the next system or application upgrade. Once the personal firewall is installed on all internal hosts, the host can detect Trojan activities on the same network as the system 100 or from another host. This reduces the likelihood of a Trojan attack that can be instigated directly against the local host without being monitored by a perimeter firewall.

The second portion of the advanced firewall module 1108 is a security gateway 1312 that encapsulates the entity policy of the entity that owns the particular hardware and / or software modules and components that form part of the server federation 120. Each security gateway 1312 performs checks based on the source and destination uniform resource locators (URLs) as well as the HTTP method: GET, POST, NOTIFY. The security gateway 1312 is explicitly inserted into the application 200 as an HTTP proxy and, for example, which external pages can be easily accessed at which time of day, or which users can receive external notifications. Can be determined. The security gateway 1312 is a host and thus may be an IPSEC or SSL endpoint. In addition, each security gateway 1312 may have access to XML structured data and thus have access to the content of a message sent from a particular host.

One optional function of the security gateway 1312 is to “punch holes” within the perimeter or transport level firewall 1314 (discussed below) to authorize end-end media streams. The stream may be set up by an HTTP or SIP exchange monitored by the security gateway 1312 but will be transmitted using User Datagram Protocol / Real-Time Transport Protocol (UDP / RTP) rather than HTTP. The security gateway 1312 determines a pair of authorized IP addresses and TCP / UDP ports. Each secure gateway 1312 also has the ability to authorize the use of IPSEC between two pairs of IP addresses.

The third part of the advanced firewall is a perimeter (transport layer) firewall 1314, which grants or denies access to the local network of the system 100, perhaps under the control of the security gateway 1312. Transport layer firewall 1314 is responsible for controlling which " outside " traffic reaches machines on the inside and restricting such access to those " outside " sources that are well managed. In the default configuration, those authorized machines include a security gateway 1312.

In general, the split of the perimeter control function between the "transport level firewall" and the "secure gateway" takes into account the scalability and performance of the system 100 and / or the application 200. Transport level firewalls 1314, similar in nature to routers, can be connected in parallel to achieve scaling while the security gateway 1312, which is an application server, can utilize the scaling technology used for the scaling web server.

FIG. 12 shows that each portion 1310, 1312, and 1314 of the firewall module 1308 is integrated, but each portion 1310, 1312, and 1314 is distributed throughout the server federation 120. Can be. Furthermore, security service component 165 may include multiple firewall modules 1108 and multiple portions 1310, 1312, and 1314.

According to another aspect of the present invention, security component 165 may include various hardware and / or software modules and components that allow for the use of digital signatures, time-stamping, and notarization services. The use of electronic signatures provides the user with many of the benefits of physical signatures in electronic transactions, such as, but not limited to, legal compensation, proof of authorization, proof of origin, etc. in case of subsequent disputes. Furthermore, the ability to seal documents integrity (any modification invalidates the signature) is also valuable in the electronic world, where information may travel between unreliable communication and processing channels.

The security component 165 of the present invention is currently used for electronic signatures such as, but not limited to, digital signature algorithms (DSAs), elliptic curves developed by RSA Data Security, Inc., and cryptographic technologies (RSAs). It can be configured to support the technology. In addition, the security component 165 is flexible in that it can be manipulated to generate secure digital signatures for use with XML and XML schemas. For example, in a typical signed email system (Secure / Multiperforce Internet Mail Extensions (S / MIME) or Pretty Good Privacy (PGP) technology), the user may sign the email encoding of the email they synthesized. Absolutely trust. Unfortunately, more protection may be required for documents involving high values and potential capabilities. The use of XML or generic XML schemas to mark such important documents allows the creation of general purpose tools that provide canonical representation of XML documents. The occurrence of the canonical representation of the document is a requirement for generating and verifying the digital signature.

The security component 165 may further include a time stamping and notarization service, which may optionally be incorporated into hardware and / or software modules that perform digital signature functions and services. Like digital signatures, time-stamping services provide strong evidence that documents (in the most general sense) existed at some point in time. Similarly, digital notary services provide evidence that someone has electronically signed a document at a point in time. Examples of these types of services that can be incorporated within security service 300 are Surity, Entropic, E-Timestamp with both X.509-based and PGP-based trust models being used. Including but not limited to. In addition, a draft standard time-stamping protocol is proposed that covers the interface to such services. The security services of the present invention allow for the interoperability of existing services while providing hardware and / or software flexibility to follow relevant services that are currently evolving.

In general, security component 165 may be incorporated within the platform core operating system (OS) of the device, and thus may affect the tools, applications, services, and all other modules and functions of the OS. Alternatively, security component 165; The modules 1102, 1104, 1106, and 1108 and functions provided therein may be deployed at various locations within the server federation 120, the client device 110, and / or the application 200, or may be distributed everywhere. . In another configuration, the security component 165 may be positioned between the asset component 220 and the FD dome component 230 of the application 200. In addition, as shown in FIG. 10, each module of the security component 165 may be in communication with one or more other modules 1102, 1104, 1106, and 1108 contained therein, as shown by the dotted lines. It may not.

Security component 165 may be used in a variety of communication scenarios to help consumers, businesses, governments, etc., allow for greater Internet connectivity and cooperation with increased inter-site communication. For example, the first scenario is in a consumer-service or business environment. The security component 165 of the present invention provides for greater communication, notification, streaming media, and security for home computer security with “always on” digital subscriber lines (DSL) and / or cable modem systems and other home networking scenarios. Allow gaming and cooperative services. The security component 165 may be used to: (i) abuse the Internet signaling messages, such as instant messages or Internet telephony, for the equivalent of random doorbell ringing, ii) track the user's activities, and thereby " precision " Activities that reduce targeting, (i) abuse of personal resources through Trojan processes using a personal computer as part of an attack mounted against third parties, (i) denial of Internet services, and (i) literal stealing from consumers. Protect consumers in a consumer-service environment from criminal activities such as illegal access of an individual's computer resulting in unauthorized purchases, money transfers, and the like.

Another scenario is a small business-oriented service platform for hosting application service providers (ASPs). The security component 165 of the present invention is an integrated electronic document management and online business service, such as employee personal web storage, online business activities, such as increased, for hosting, messaging, file and print services of enterprise resource planning (ERP) applications Provide protection. In addition, security component 165 allows various businesses to have hosted web presence, delegated role-based management, and vanity domains. As such, the present invention and more particularly security component 165 have the ability for small businesses to have secure access to multiple ASPs to obtain all of their business application addresses addressed.

Another scenario is a consumer-business-business environment. This scenario includes many of the needs already described above with regard to the consumer-services scenario, while the needs and problems of business-business relationships. As such, security component 165 provides security for multiple entities in a heterogeneous environment. Security component 165 provides on-wire persistent information protection while providing non-denial of customer information functionality. Furthermore, security component 165 may authenticate and authorize middle tier transactions, client-server activities, and may accept peer-to-peer trust.

The final example scenario is a business-business environment. Security component 165 may be configured to support supply chain applications, business-business cooperation, and the like. Furthermore, management of cross-enterprise trust relationships independent of a particular authentication mechanism is provided. In addition, the security component 165 may include (i) unauthorized transactions leading to financial losses, (ii) fraud claims by business partners that the request for the transaction is not real because the credit guarantee was inadvertently initiated, and (i) no authorization. (B) business partners in unauthorized access to the server 140 or client 110 by a personality, (i) information leakage to competitors who are responsible for judging data access requests and responses, and obtaining confidential data; An attacker who pretends to return wrong data and makes a wrong decision, (i) an unreliable system operator at a site where the data is stored to leak valuable data to the conspirator by sending it over the net; An insider using the internet to send unsolicited information to outsiders, and (iii) leaked information, It reduces the possibility of unlimited transactions, or authorization of the transaction does not cause interference, or misunderstood the fault generation to the applied policy.

K. Code Management

The code management component 175 ensures that the user has transparent access to the most recently updated application and the code they need. 13 illustrates the use of a manifest in various aspects of code management. Code management is primarily concerned with formalizing conversations and abstractions between interoperable components, services, and applications. This formalization provides a layer of isolation at each level to manage the software consisting of these basic building blocks. Manifests are essentially databases that describe components, services, or applications in more detail. By describing the code components, the relationships between the code components, and the applications made from them, the manifest allows the system to understand what the application is and thus effectively manage the application. An application or service is defined by a root manifest similar to the code component manifest, except that the root manifest includes a starting point for executing the application or service.

Manifest 1400 includes various categories of information for describing software associated with the manifest. It should be understood that the identified categories are exemplary only and do not necessarily limit the invention in any way. Likewise, the description of the information in each category is also exemplary. No description of information in the context of a particular category should be construed as a request that the information only appear or be typical of that category. Note that when the term "software" is used in conjunction with Figure 13, the term should be interpreted broadly to include components, servers, applications, and the like.

Manifest 1400 is a superset of information for enabling its associated software to be used in one or more computing environments. For example, manifest 1400 identifies resource 1420 and executable code 1410 that is part of software. Depending on the operational requirements and the needs of the associated software, executable code 1410 and resources 1420 may reference private (local) or external dependencies. Since the manifest 1400 is associated with all software and every manifest describes any external dependencies, the software object may be garbage collected without managing the reference count for the shared DLL as in the prior art. have.

Dependent manifest 1430 identifies external dependencies of manifest 1400. This is a reference to manifest and software that is not local to manifest 1400. For example, a manifest can cascade when one software object is just an extension of some other software object. This allows for easy deployment of simple personalized applications. Personalized applications may override some settings or resources used by the base application to change the appearance and behavior of the application. The base application provides a constraint on what part of itself is open to this kind of variant to properly limit the scope of individualization to the intended area. These references to manifests and other software external to manifest 1400 are stored in dependent manifest 1430. The dependency manifest 1430 may also identify a manifest that is local to the manifest 1400 but is individually defined. Alternatively, dependency manifest 1430 may include a manifest stored logically or separately stored linked to manifest 1400. Such an arrangement may be beneficial when the information is relevant only for limited purposes, such as the development of software, and is not needed during normal operation.

Entry point 1440 exposes a public name for software objects (such as entry-points, resources, and services) that manifest 1400 and its associated software make available to external software. Software object names local to manifest 1400 may also exist within entry point 1440. The name and metadata are used to identify a particular software object and all other software objects used by that software object. (Metadata includes information such as version, locale, and platform.) Building is the process by which name dependencies are resolved. After the name is resolved to the resulting object, the object can be used in the application. All bindings between software objects go through the manifest and can be influenced by the policy applied to the manifest by the computing environment itself, the administrator, or an independent software developer. Thus, name resolution offers the opportunity to insert policy and security decision. Because the name is indirectly resolved to access the code and data rather than actually providing the code or data, it is possible to redirect or restrict access as needed during the building process.

For example, the application's manifest 1400 may request to use a particular runtime software object with version 1 requesting metadata. However, an administrator can set a policy so that newer versions of specific runtime software objects are used for all requests. Note that if an application breaks with a newer version because of metadata information, the administrator can change the policy to make the application use a version of the runtime that is known to work with the application. Name resolution also provides the opportunity to inject security into the process by not allowing any name resolution to depend on the security policy in the system.

Configuration information 1450 identifies the data table and platform services needed by the software. Configuration information 1450 may also describe how software associated with manifest 1400 can be used or how it should behave. For example, the software may provide a credit card clearing service. There are two options for managing credit card transactions: (1) the service provider maintains control over processing, or (2) the service provider manages the developer's own credit card transactions. Let's do it. If the service provider implements only one of these options, the information can be captured in configuration information 1450 used to run the service. A monitor can also be included in the configuration information 1450 to provide the developer with performance and debugging information.

As noted above, manifest 1400 facilitates maintaining various versions of software. This feature can be very useful when deploying new software. The nature of manifest 1400 allows various state and configuration information of various components, services, and applications to be isolated from each other. This isolation means that different versions of components, services, and applications can run side by side and allow access to other software objects to specific versions of the software they are designed and tested on. As a result, while the new version starts up, the old version allows for paged deployments to finish work, isolated and shared deployments, and multi-tier deployments (from front end server to back server).

Manifests, such as manifest 1400, provide significant benefits for code management. For example, a manifest can (1) allow self-description of components, services, and applications, (2) enable application synthesis from components, services, or other applications by developers and administrators, and (3) components Facilitate binding at / service / application naming, discovery, and runtime, (4) enable development / design time scenarios with added issues of licensing, versioning, distribution, and documenting, and (5) legacy It enables the interoperability of the system, (6) easy distribution / installation of components, services, and applications, and (7) on-going management of application / service / component health.

The code management uses manifests to allow developers, administrators, and end users to write, consume, deploy, update, name, and place applications in the entire client and server tier shown in FIGS. The following example illustrates how the manifest can be used to install and run an application from a client with reference to FIGS. 1 and 2.

In this example, via a search engine or other shell, the user uses one of the clients 110 of FIG. 1 to navigate to a uniform resource locator (URL) for a particular word processing application, the URL being a server federation ( Located within 120). If such an application is already "installed" on the client (ie already running), the application runs from the local cache when navigated to the URL. If the application is not "installed" on the client (ie, not already running on the client), the application will be downloaded and run using the process described now.

The installer module downloads the manifest associated with the application. The installer then compares the client's configuration and manifests for both platform requirements and known incompatible assemblies. In the event that the application cannot run on the client, an error message appears on the client. If the application can run on the client, the installer uses the URL to connect to the site in server federation 120. The client then displays some user interface, such as a purchase / lease / authentication decision, as well as an End User Licensing Aggregation (EULA). The application is then downloaded as a package of on demand or typical functionality. Automatic servicing of the application will be driven via regular updating of the manifest from the installation URL using asynchronous messaging in accordance with the present invention.

L. Scenario

The scenario below illustrates how the distributed computing services platform 115 of the present invention empowers a user by enabling easier coordination and communication. Scenarios fall into three categories of users: (1) knowledge workers, (2) consumers, and (3) developers.

Knowledge Worker / Business Scenario

The manufacturer of a small business bike called seven cycles is owned by Alex. The 7th cycle has just designed a new high-end bike and needs to market a new bike to a sports product distributor. These scenarios illustrate several business themes (eg, access to and integration of information at any time and from where) and technology themes (eg, federation across all devices, next generation productivity tools, schema-based integration).

Alex's personal computer (PC) displays a personalized user interface that includes her "start page" or "home page" representing messages, calendars, contacts / "buddy lists", and the like. The user interface is multi-modal in that it includes e-mail messages and voice messages in a single integrated interface. Voice messages can be converted to text messages and e-mail messages can be converted to voice messages when desired. In addition, the user interface is content-based, not application-based. For example, a start page includes information typically provided by various applications (ie, voice mail messages, calendars, contacts, etc.).

Alex uses her PC to log on to services designed to help her management business (e.g., bCentral ^TM provided by Microsoft) and uses the service to add new bikes to the 7-cycle online catalog. . The service documents up the template for the catalog entry. She then browses the 7-cycle corporate intranet (including her personal data store and other sources) and drags the appropriate information to the catalog template to find information about the new bike (photos, marketing courts, product specifications, etc.). And drop it. Product specifications for bikes are provided in a common description language (ie XML) and follow the schema (see schema section above) to allow the catalog template service to understand the information in the specification and populate the template with the appropriate information. Alex previews and publishes the updated catalog page. The new bike is then listed on seven cycles of the website.

Alex then uses the service to query the directory for listings from other sites / company that may characterize the new bike. These types of robust Internet-wide directory listings are greatly facilitated because directory services (see the Directory section above) provide Internet-wide directory services through schema-easy synchronization of enterprise-level meta-directories. Alex then shares information about the new bike with these other companies.

Alex also uses the service to automatically generate lists of keywords for new bikes and share them with several search engines so that people can immediately find information about new bikes.

Alex receives an email from Sandra, an employee of a sports product distributor who saw seven new bikes on the web. Sandra suggests Alex meet her at the trade show. Alex receives a message on a portable client device such as a cell phone. The user interface of such a client device is smaller than that of the PC, but the characteristics provided by the user interface are consistent with those provided by the user interface of the PC. For example, the phone displays a scaling down version of Alex's start page with a personalized highlight page representing contact and emergency messages.

Alex navigates to a contact management page that links Alex to Sandra's schedule and provides a map to her booth at the trade show. Sandra's schedule can be accessed through an adaptive directory linked to Alex's My Status directory (see the Directory section) that enables such schedule publication. Alex replies to Sandra's message using speech-to-text conversion, causing Alex to dictate an e-mail message. She checks Sandra's calendar and suggests meeting him around 2 o'clock.

Alex uses Proximity / Location Awareness Service to arrive at the trade show and bring up a map on her cell phone showing her personal location and the location of Sandra's booth. The map tracks her location as she approaches the booth.

When she meets Sandra, she asks if she can see the specifications for her new bike. All the information is located on a seven-cycle corporate intranet, Alex says. She borrows Sandra's tablet PC and logs in as a guest user-her start page (such as on her working PC) has a lower geo-related information (eg, local to the interest in Alex). Are displayed together. Thus, the storage, directory, and security components described above allow Alex to authenticate himself on a new client device and make all her personalized information available through the client device. From the recent contact list, Alex finds a bike specification and asks Sandra to share the information. After Sandra logs in, the bike specification can be used on her tablet PC in a secure manner through the federated security domain.

After Sandra returns from the trade show, Sandra uses her work PC to access voice and e-mail messages. Sandra's start page displays a mix of personal, professional, and web information. Sandra sends a message to the co-worker who is needed to prepare a proposal to the sporting goods chain retailer for the new bike. As she types, the system recognizes some content suitable for the action menu, such as the name of another collaborator and the due date of the offer. The system recognizes the relevance of the data types that enable them to be automatically and properly linked to contact & calendar information. This semantic communication is described in the schema section.

Sandra then creates a "project page" for suggestions, using the auto-completion properties described in the schema section to set up a web page to automatically include all names in the email and share information / cooperation. It is suggested that the document be included in the project. Alex (from another company / security domain) is also included on the project. Sandra then begins to write suggestions shared in real time with other team members. This can be accomplished using asynchronous messaging as described in the messaging section. They use instant messaging / chat to discuss the changes that are being made. Proposals are multimedia documents that include text, graphics, video, and the like. Third party content (eg, photos from image houses) can be integrated directly into the shell. Video content may be annotated.

Sandra is driving home from work, talking to her husband from her car phone when her AutoPC tells her that she has received a message regarding a proposal (which she specified should be interrupted). These notifications are issued in response to certain events as described above in the Events section. Part of these predetermined events includes user-defined rules. Sandra, for example, specified the conditions on which she should be interrupted on her car phone. The email is a message from the retailer that they want additional demographic information included in the offer. Upon arriving home, Sandra uses her home PC (who has a personal "skin" on the start page and her profile may be slightly different). The preference information that forms the personal "skin" can be stored in the home presence or my state adaptation directory discussed in the Directory section. She incorporates additional demographic information into the proposal by filtering / merging / mapping the information into documents from external websites and databases of her company. This merging of information from other websites is facilitated by the schema.

The next day, Alex receives a message from Sandra that, as originally processed, she needs to change her order to transport the bike overnight to 30 other retailers rather than to Sandra's business. Alex logs on to a business service written by Sandra in a template for a changed purchase order that is already flagged to Alex in a notification format. When Alex reviews and hits "Accept Changes" on the toolbar, the system uses the schema to realize that he needs to ask Alex if he wants to confirm the shipment via UPS. If she says yes, the system creates a new shipping event and connects UPS and Alex to arrange the shipment. Calendar transfers between UPS and 7 cycles set the pickup time that is automatically displayed in Alex's calendar. Sandra receives a notification that the change order has been processed. Business services can track events (received orders, shipped orders, etc.) for users by using a distributed event system. The business service sends a notification to Sandra via the notification manager. The Notification Manager, part of the overall notification system that provides her with context-sensitive notification services, can be used to monitor various incoming notifications. The notification manager forwards important and context-sensitive messages to Sandra depending on the inference of Sandra's current context, attention, location, and availability of the device.

Consumer scenario

This scenario focuses on the benefits of the present invention for a typical user or consumer. The scenario describes the day of life of the family and teenage daughter going on vacation.

This scenario illustrates the advanced messaging, simplification of everyday tasks, and advanced entertainment provided by the present invention. Some key features include a common personality for anyone who exists everywhere, a consistent set of conversations across device spaces, consistent data capture, and access to all resources in the digital era (privacy, natural bidirectional communication across all device spaces, A consistent user experience, personalized entertainment, and the web as a natural part of human life).

The father uses a home PC to plan a family vacation to Los Angeles and the San Diego Zoo. Using one service, the father sends some key data to the PC, and the system only enters the information once, suggesting and booking flights, hotels and cars and getting zoo tickets. Because the server enjoys the ability to semantically exchange information under schema-based messaging, the server uses a single user request as a server federation to obtain various data such as flight, hotel, and car reservation data and zoo ticket availability. Can communicate. Thus, the father does not have to connect to each server to obtain this information independently.

The system also indicates that you can save money by leaving early one day and check everyone's calendars to see if they are available. Because calendar information is stored in XML format, the system can synchronize everyone's calendars to see what time is available. The system can further save money by suggesting discount-related information (eg prime cards, AAA membership). Based on the stored personal preferences, the service also interrupts the newspaper while the family is on vacation, sends an email to the neighbor to feed the cat, and so on. This illustrates the system's ability to automate routine tasks based on profiles and rules. The events described in the Events section can be used to detect events and perform tasks based on the events.

After that, the mother and father get a reminder for their grandparents' day on the PC. They use videoconferencing to make reservations at the restaurant and order special cakes. This proves the multi-modal nature of the user interface. Grandparents receive and accept invitations (via a WebTV unit or PC).

Children who go to school by bus receive planned travel notices. Such notification may take place via asynchronous messaging described in the messaging section. Links to zoo applications / services allow children to check zoo maps, showtimes and more.

When a family picks up a rental car at the airport, it has a downloaded music / video preference for each family member (the father specified these options and paid when the car was booked). The preference information for the individual was accessed from the mega-store as described in the storage section. Thus, the available preferences can be readily used in rental cars.

While in the car, the daughter is hungry and uses the proximity / location awareness service to locate one of her favorite fast food restaurants within a certain radius of the car, get directions and pre-order food for the family. do. The Proximity / Location Awareness application accesses the adaptive directory through the directory architecture described in the Directory section. The family has the option to go to the shorter pre-order line to bring food. They pay by smart card.

When entering the zoo, the son downloads a copy of the zoo's application to his PDA. Zoo applications include maps, events (animal feeding), data about individual displays in the zoo (eg chimpanzee details), shopping promotions, and the like. He receives a notification that one of his buddies from the school is also at the zoo and they exchange messages and plan to meet later. To facilitate this notification, a location sensor associated with the PDA can provide data to the location wearer application program. These applications provide a location in the Internet-wide directory architecture described in the Directory section. The buddy also has an application that forwards the buddy's location to the Internet-wide directory service. An event hosted by a location awareness program is triggered when the buddy is within some distance of the son or in a common area with the son (eg a zoo). These events are communicated from the application's FPM component to the application's page component via asynchronous messaging. The event then triggers a notification to be communicated to the son via the PDA's user interface.

Mothers take digital family photos at the zoo where they post on their community websites. Grandparents receive a notification on their television Internet browser that they have new photos while watching TV. They love photos and download them to electronic frames all over the house. Grandparents are running an application with a layer of F dome that hosts an event that monitors the website for new photos. The event is triggered when a new picture is posted so that messaging is sent to the grandparents. The message may be generated by the body of the code, for example in response to the event, in the FPM component (see section Programming Model).

Returning from vacation, teenage daughter Jenna uses her PC in her room and retrieves messages from the time she is away. Jenna has a "Teen Girl" skin on her UI. A friend left a message about going to a concert but said it was sold out. While listening to the message, she receives a notification that she has an associated message. She opens the message and informs her that two tickets have been booked (luckily, Jenna subscribes to a music service that automatically purchases tickets for her when her favorite band is in town). The service also offers new music clips from her favorite bands. Jenna was able to purchase tickets and get these new music clips automatically because of the events described in the Events section.

Xena conducts videoconferencing with her friends on concert tickets and thus proves the multi-modal nature of the UI. Then they cooperate with their homework (video report on the rain forest issue). During the video conference, they link to the project site for real-time editing of video / text. Jenna contributes a video she made while at the zoo. When finished, submit a report on the school's website.

Jenna uses her school's website to download a video of the class she missed and upload some homework. She learns to report on current environmental issues. She finds recent environmental news clips from selected sources and instructs intelligent news agents to use them when she wakes up. Environmental news clip retrieval is facilitated by internet-wide synchronization of the adaptive directory described in the Directory section.

When Jenna wakes up, she receives a notification that her news clip is available. This notification was generated by an event triggered when a news clip is available. She starts scanning all of them but is running late and has audio delivered to her auto PC so she can hear them all on her way to school. While in the car, she selects her clip and allows it to be downloaded to her tablet PC. This proves that Jenna used the mega-store described in the storage section to store the audio in the server federation and then get the audio back from the server federation while on another client device. Upon arrival at school, Jenna checks the school website on her tablet PC, reads the school newspaper, and checks the lunch menu.

After school, Jenna uses her PC to remotely play video games with her friends. The game includes face mapping / scanning technology in which Jenna's face appears on the video game character. During the game, Jenna receives an instant message from her teacher who praised her for her report. Jenna also receives a notification that one of her favorite movies is now available for download. This notification was generated in response to an event triggered when a favorite movie is available.

developer

This scenario describes a person (ie Steve) who is susceptible to accidents during a business trip. Key points in this scenario are universal secure access to personal information in a mega-store or "cloud", tiered user access to information, and easy exchange of information.

Steve is at the rental phone location in the airport and he is very embarrassed because he has left his smartphone at home and needs access to his information. Luckily, Steve has a smart card and he can use the smart card to rent a phone and download his personal information from a mega-store in the server federation. This illustrates using the schema and using the Internet as a single way to access information. Authentication to access information from anywhere in the "mega-store" is described in the security section. The smart card authenticates Steve and tells the rental phone where Steve's information is located (ie, calendar information is stored in X, contact information is stored in Y, etc.). The phone then retrieves this information and downloads it for Steve.

On the way out of the airport, Steve hit his bike messenger and injured his ankle. He is in an unfamiliar city and does not know where to go for medical attention. Steve calls his home doctor and asks a nearby clinic to accept his insurance. The reception uses a clinic referral service for a more efficient collection of information to locate the percent coverage and location of the clinic near Steve under his and his existing health plan. She also uses calendaring sharing and talks directly with the clinic so Steve can find the appointment immediately. This illustrates the automatic mapping of business and personal schemas. In addition, listings or clinic and clinic calendars may be made available through the directory architecture described in the Directory section.

The reception asks Steve if he approves sharing his medical records with the new clinic. Steve authenticates himself and receives a list of his medical records (on his smartphone). He then checks which records he wants to make available to the clinic. This illustrates "tiered access"-denial of access to information by any application and rule-based validation, with security built in at the system level and supported by rich schema and data storage / access. The new clinic says Steve has sprained ankles. They send a notification to Steve's regular doctor. They can also transmit x-rays so doctors can confirm the diagnosis.

M. Lack

Distributed computing services platforms, including programming models, schemas, user interfaces, events, messaging, storage, directories, security, and code management components, facilitate better internet-based collaboration and better inter-site communication.

The invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The described embodiments are to be considered in all respects only as illustrative and not restrictive. Accordingly, the scope of the invention is indicated by the appended claims rather than by the foregoing description. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims (19)

10. A method of performing a mid-session transition between a first client device and a second client device in a network comprising a plurality of servers in communication with a plurality of client devices including a first client device and a second client device. (A) retrieving status information of a user stored on at least one server, (B) communicating in a session with a first client device such that the status information is updated, (C) storing the updated state information on the at least one server, (D) retrieving the updated status information when the session continues on a second client device, and (E) communicating with a second client device in the continued session based on the updated status information, Said plurality of servers forming a server federation, wherein said steps (a) to (e) are performed cooperatively by two or more servers of said server federation. 2. The method of claim 1, further comprising authenticating a user of the first client device before allowing the status information to be updated in response to step (b) of conversing with the first client device in a session. How to. 3. The method of claim 2 further comprising the step of authenticating the user of the second client device as being the same user as the user of the first client device prior to (e) communicating with the second client device in the continued session. Characterized in that. The method of claim 1, wherein the status information is stored on the at least one server using a data structure conforming to a schema recognized by a plurality of servers, and the meaning of the status information is implied by the schema. How to. 5. The method of claim 4, wherein the data structure is structured according to Extensible Markup Language (XML). The method of claim 1, wherein at least some of the status information includes user interface information, and wherein (b) conversing in session with the first client device comprises: Determining a first user interface characteristic of the first client device, and Providing a first set of user interface information to a first client device, wherein the first set of user interface information is tailored to a first user interface characteristic. 7. The method of claim 6, wherein (e) conversing with the second client device in the continued session Determining a second user interface characteristic of the second client device, and Providing a second set of user interface information to a second client device, wherein the second set of user interface information is adapted to a second user interface characteristic. 8. The method of claim 7, wherein the first and second client devices have the same user interface functionality and the first and second sets of status information are substantially to allow the first and second client devices to display the same information. And comprising the same user interface information. 8. The method of claim 7, wherein the first and second client devices have different user interface functions and the first and second sets of user interface information are different. 10. The method of claim 9, wherein (b) conversing in session with the first client device comprises conversing in session with a personal computer. 11. The method of claim 10, wherein the personal computer comprises a first personal computer, and the step (e) of conversing with the second client device in the continued session comprises the step of conversing with the second personal computer in the continued session. Characterized in that. 11. The method of claim 10, wherein said step (e) of conversing with said second client device in said continued session comprises conversing with said mobile telephone in said continued session. 10. The method of claim 9, wherein (b) conversing in session with the first client device comprises conversing in session with a mobile telephone. 15. The method of claim 13, wherein the mobile telephone comprises a first mobile telephone, and the step of communicating with the second client device in the continued session (e) comprises the step of communicating with the second mobile telephone in the continued session. Method comprising a. 14. The method of claim 13, wherein (e) conversing with the second client device in the continued session comprises conversing with the personal computer in the continued session. 2. The method of claim 1, further comprising at least temporarily suspending step (b) of conversing with the first client device, wherein step (e) of conversing with the second client device in the continued session. And after at least temporarily suspending a conversation in the session with the first client device. 2. The method of claim 1, wherein retrieving status information stored on the at least one server comprises retrieving preference information stored on the at least one server. 2. The method of claim 1, wherein storing (c) the updated state information on the at least one server comprises storing session state information for the session on the at least one server. Way. A method of performing a mid-session transition between a first client device and a second client device in a network comprising a plurality of servers in communication with a plurality of client devices including a first client device and a second client device. In a computer-readable recording medium recording a program to be implemented, Computer-executable instructions for detecting receipt of status information of a user stored on at least one server, Computer-executable instructions for causing a conversation with the first client device in a session, Computer-executable instructions for causing the status information to be updated in response to a conversation in a session with the first client device, Computer-executable instructions for causing the updated status information to be stored on the at least one server, Computer-executable instructions for detecting receipt of the updated status information when the session continues on the second client device, and Store computer-executable instructions for causing a conversation in the continued session with the second client device based on the updated status information, The plurality of servers form a server federation, the retrieval of the status information, a conversation in a session with the first client device, the storage of the updated status information, the retrieval of the updated status information, and the second client device. And further store computer-executable instructions for causing a conversation operation in said continued session to be performed cooperatively by two or more servers of said server federation.