Apparatus and methods for provisioning services

[0001] This application claims priority and is a continuation-in-part of co-pending U.S. patent application, having application Ser. No. 09/820,966, entitled System and Method for Routing Messages between Applications, filed Mar. 30, 2001 by Lev Brouk et al., which application is herein incorporated by reference in its entirety for all purposes.

[0002] The present invention relates to methods and apparatus for processing data within a computer network. More specifically, it relates to facilitating provisioning of services within such computer network.

[0003] Corporate reliance on technology has become more complex and more pervasive. Increasingly, companies are identifying opportunities to extend their core business or cut costs using the Internet. Both trends have put increasing priority on integrating disparate business applications. For this reason, enterprise application integration (EAI) has emerged as a solution for allowing information technology departments to build bridges that are designed to unify their legacy systems into a single enterprise application. Ideally, the creation of this single enterprise application would not require sweeping changes to the underlying structures.

[0004] EAI suppliers typically offer end point solutions for managing business process interactions between end points within a computer network. Although a specific enterprise software package may be designed to transparently handle diverse business processes carried out by two or more end nodes, each specific enterprise software package requires releasing customized connectors or adapters which will work for the specific business processes and applications used by the specific end nodes. As a result, these enterprise solutions are not easily scalable. Additionally, scores of adapters need to be built for each vendor (e.g., Oracle, SAP and Peoplesoft). As each supplier releases new versions of their software, EAI vendors find themselves unable to gain traction under the burden of supporting their existing adapters.

[0005] Notwithstanding the benefits of EAI, the software costs and resource investments of EAI prevent small-to-medium enterprise (SME) customers from embracing EAI solutions. For SMEs, reliance on web service providers represents an increasingly attractive alternative.

[0006] The web service provider market is one of the fastest growing segments of the software industry. Service providers make enterprise applications (e.g., human resources administration, recruiting, travel and expense management, sales force automation) available to customers over the web at a server device. Those applications are fully managed and hosted by the provider, providing significant cost savings to enterprises.

[0007] Some providers merely host and manage third-party packaged software for their customers (managed hosters). Others build new applications from the ground up to take advantage of the benefits and cost-savings of web service provider model. Service providers enjoy the profit margins and operational scalability of consumer Web companies like eBay and Yahoo, while at the same time offering the feature sets of complex enterprise software applications such as PeopleSoft and Siebel.

[0008] Although the service provider approach allows a single business to set up a host server for allowing itself and its business partners to use third party or customs applications, this approach does not allow the set up and dismantling of complex arrangements between business partners. For instance, a first business may wish to allow a second business to access a first set of services, while the second business may wish to provide a second different set of services to the first business. Additionally, each business may wish to flexibly invite selected users (while denying other users) to access particular services.

[0009] In view of the above, there is a need for facilitating the flexible and efficient sharing of services between diverse business entities in a scalable manner. In other words, mechanisms for efficiently and reliably provisioning services between business entities (as well as other entity types) is needed.

[0010] Accordingly, the present invention provides methods and apparatus for effectively provisioning services for access by other entities or services. In general, a service manager is configured to manage the provisioning of services between remote entities within a computer network. In general terms, a remote entity offers a service to another remote entity through the service manager. The service manager facilitates formation of the offer to one or more Invitee(s) specified by the service provider. After an offer is formed, it may then be provided to the specified Invitee(s). After an Invitee receives an offer, the Invitee may accept the offer through the service manager or let the offer expire. The service manager also preferably tracks the status of each offer and whether each specified Invitee has accepted such offer. After an Invitee accepts an offer, the service manager preferably records information sufficient for the Invitee to use the offered service.

[0011] In one embodiment, a method for provisioning services within a computer network is provided. An offer pertaining to a service is received. The offer is created by a provider and transmitted from a first device to a second device within the computer network. Identifying information regarding one or more invitees to be invited to access the service of the offer are also received. The one or more invitees are also transmitted from the first device to the second device. In response to receipt of the offer and the identifying information regarding the one or more invitees, an invitation is then provided to each of the one or more invitees to access the service of the offer based on the received identifying information.

[0012] In a specific implementation, the invitation is provided in the form of an email. A unique URL address (Uniform Resource Locator) is also provided for each one or more invitees, and the corresponding URL address is provided in the each email to each invitee, wherein the URL address points to one or more web pages which allows the each invitee to register identifying information and accept terms for the offer. In one aspect, the unique URL address is provided to the provider by a provisioning service implemented on the second device, and the provider sends the each email to each of the one or more invitees. In another aspect, the each email is provided by a provisioning service implemented on the second device.

[0013] In a further implementation, the offer and its associated one or more invitees are stored. In one aspect, the offer and its associated one or more invitees are only stored when the provider is authorized to create the offer, and the invitation is only provided to the one or more each invitees when the provider is authorized to create the offer. An error message may be sent to the provider when the provider is not authorized to create the offer.

[0014] In yet another implementation, a registration input form is presented to a first invitee of the one or more invitees for the offer when the first invitee accesses the invitation. The identifying information received for the first invitee is preferably pre-filled into the presented registration form. In one aspect, the invitation to the each one or more invitees further allows the each one or more invitees to accept the invitation.

[0015] In another embodiment, an acceptance link is presented to the first invitee when the invitee submits the registration form with identifying information. In a further aspect, permissions are set up between the first invitee and the service when the first invitee registers and accepts the offer. In one aspect, permissions are not set up when the first invitee is not authorized to accept the offer.

[0016] In yet another embodiment, when the first invitee accepts the first offer, an indicator that the first invitee accepted the offer and the date of such acceptance are stored. When the first invitee does not accept the offer, an indicator that the first invitee did not accept the offer is stored. When the first invitee registers, an indicator regarding the registration and the date of such registration are stored. When the first invitee does not register, an indicator that the first invitee did not register is stored. In a further aspect, the indicator regarding the acceptance, the date of acceptance by the first invitee, and the indicator regarding registration are provided to the provider when the provider queries regarding the first invitee or the offer.

[0017] In another embodiment, the invention pertains to a computer system operable to provision services within a computer network. The computer system includes one or more processors and one or more memory. At least one of the memory and processors are adapted to provide at least some of the above described method operations. In yet a further embodiment, the invention pertains to a computer program product for provisioning services within a computer network. The computer program product has at least one computer readable medium and computer program instructions stored within at least one of the computer readable product configured to perform at least some of the above described method operations.

[0018] These and other features and advantages of the present invention will be presented in more detail in the following specification of the invention and the accompanying figures which illustrate by way of example the principles of the invention.

[0019] FIG. 1 is a diagrammatic representation of an exemplary network in which techniques of the present invention may be implemented.

[0020] FIG. 2 is a flowchart illustrating a procedure for creating an offer of a service to one or more Invitees in accordance with one embodiment of the present invention.

[0021] FIG. 3 is a diagrammatic representation of a plurality of data structures within the repository of FIG. 1 in accordance with one embodiment of the present invention.

[0022] FIG. 4A is a flowchart illustrating a procedure for handling new offers received by a Provisioning Web Service in accordance with one embodiment of the present invention.

[0023] FIG. 4B is a flowchart illustrating a procedure for handling the receipt of information regarding one or more Invitees at a Provisioning Web Service in accordance with one embodiment of the present invention.

[0024] FIG. 5 is a flowchart illustrating a procedure for handling an offer in accordance with a specific implementation of the present invention.

[0025] FIG. 6 is a diagrammatic representation of an example computer system in which embodiments of the present invention may be implemented.

[0026] Reference will now be made in detail to a specific embodiment of the invention. An example of this embodiment is illustrated in the accompanying drawings. While the invention will be described in conjunction with this specific embodiment, it will be understood that it is not intended to limit the invention to one embodiment. On the contrary, it is intended to cover alternatives, modifications, and equivalents as may be included within the spirit and scope of the invention as defined by the appended claims. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. The present invention may be practiced without some or all of these specific details. In other instances, well known process operations have not been described in detail in order not to unnecessarily obscure the present invention.

[0027] FIG. 1 is a diagrammatic representation of an exemplary network in which techniques of the present invention may be implemented. FIG. 1 is used herein as an example for describing techniques of the present invention. As shown, the network 100 includes a Service Manager 101 for facilitating the provisioning of services between a plurality of entities. In a specific example, one or more service(s) 103 are being provisioned by a Provider 102 to an Invitee 108. In this example, Service Manager 101 provides a mechanism for the Provider 103 to offer one or more service(s) to Invitee 108. Although not shown, of course, the Service Manager 101 is configured to provision service between multiple Providers and multiple Invitees.

[0028] A service may represent any computer application, entity, or device accessible to other applications, entities, or devices through an interface such as an application programming interface (API), user interface, or Internet web user interface by any of a variety of protocols over a network within an entity or over the public Internet. A service may also be comprised of multiple methods or applications on a single device or distributed across multiple devices.

[0029] In the present invention, services may be offered to any number and type of Invitees. The Invitees may represent any suitable entity for provisioning a service thereto. By way of examples, the Invitee is in the form of a user or individual entity from a particular organization or a particular organization entity. The Invitee may also itself be a provider of one or more service(s) to other entities (or to the Provider 102). In one embodiment, the Provider is an organization administrator from a first organization and the Invitee is a user from a second organization, where such organizations may represent distinct business entities, parts of the same business entity, or administrative domains of computer applications. In this example, the Provider and Invitee each represent a person. The Provider and Invitee may each communicate with the computer network 100 via two different remote computer nodes or systems (e.g., personal computer systems or computer work stations). Alternatively, the Provider and Invitee could simply use different user personas on a same computer system. In general, the Provider and Invitees are each defined as a unique entity which are each capable of interacting with one or more services. The Provider and Invitee may also be defined as services.

[0030] In one configuration of the present invention, the Service Manager 101 includes any number of mechanisms for facilitating provisioning of services between two or more remote entities (e.g., between a Provider and an Invitee). In the illustrated embodiment, the Service Manager includes a Provisioning Web Service 106 for provisioning the services of Providers to Invitees and an Invitee Manager 110 for handling offer acceptance with respect to Invitees. The Service Manager 101 also preferably includes a repository 112 for storing various information regarding the services and entities which provision and/or use such services.

[0031] The Service Manager preferably also includes mechanisms for creating services, registering users and their identifying information, and handling messages routed between services and/or users. Several embodiments for performing these additional tasks are described in the above referenced Lev Brouk et al. U.S. patent application. The techniques of the present invention may easily be incorporated with the additional tasks described in this Lev Brouk et al. application.

[0032] FIG. 2 is a flowchart illustrating a procedure 200 for creating an offer of a service to one or more Invitees in accordance with one embodiment of the present invention. FIG. 2 represents an example flow for offer creation, and permutations (e.g., error handling and database management) on this basic flow are further described below. As shown in FIG. 2, a Provider initially creates a new offer to a service using the Provisioning Web Service in operation 202. In general, an offer is created when a Provider provides information regarding the offer to the Provisioning Web Service 106. Offer creation is described further below.

[0033] The service referred to in the offer may, in fact, include a set of services or method objects which are configured to work together as a single entity. More typically, the service refers to a single service or method object.

[0034] In the illustrated embodiment, the Provisioning Web Service 106 then returns an offer identifier (ID) to the provider in operation 204. The Provider can then use this offer ID to add an Invitee to the new offer in operation 206. The Invitee is then notified of the new offer for the service and invited to access the new service in operation 208. As described further below, the Invitee may be notified by the Provider or by the Provisioning Web Service 106 in any suitable manner, such as via an email. The notification preferably allows the Invitee to provide identifying information (referred herein as Registration) and accept the offer. After the new Invitee is notified, it may then be determined whether this is the last Invitee for the new offer in operation 210. If this is not the last Invitee, other Invitees may then be added for the new offer and notified of such new offer in operations 206 through 208. When the Provider does not wish to add any more Invitees for the new offer, the procedure 200 ends.

[0035] In an alternative embodiment, information regarding all of the Invitees may be collected prior to notifying all of the Invitees of the offer. Preferably, the Provisioning Web Service 106 is configured to allow a Provider to add new Invitees to a new offer during multiple communication sessions. For instance, a first set of Invitees may be added to a new offer during a first session with the Provisioning Web Service 106 and a second set of Invitees added later to the new offer during a second session with the Provisioning Web Service 106.

[0036] FIG. 3 is a diagrammatic representation of a plurality of data structures within repository 112 of FIG. 1 in accordance with one embodiment of the present invention. The repository may be formed from one or more databases located in one or more memory devices on one or more computer systems, and the data structures may be formatted in any suitable format for storing and correlating information regarding service provisioning. These data structures will be described in conjunction with the following techniques of the present invention.

[0037] As shown, the repository 112 includes an offer data structure 302 for encapsulating information regarding each offer, a service data structure 304 for holding information regarding various services which may be provisioned to one or more entities, an Invitee data structure 306 for encapsulating information regarding each Invitee, an organization data structure 310 for holding information regarding organizations which utilize services, a user data structure 312 for holding information regarding individual users or groups of users which utilize services, and a permissions data structure 308 for relating permissions set up between services, organizations, and users. In the illustrated embodiment, an Invitee becomes a user after it registers its identifying information in response to a service offer and accepts such offer. These data structures will be described further below.

[0038] The Provisioning Web Service 106 operates to retain information regarding a new offer for later use by a Provider when adding an Invitee to an offer or by the Invitee Manager 110 for handling offer acceptance, as well as any other procedures carried out with respect to an offer. FIG. 4A is a flowchart illustrating a procedure 400 for handling new offers received by the Provisioning Web Service in accordance with one embodiment of the present invention. Initially, new offer information is received from a provider in operation 402. It is then determined whether the provider is authorized to create the new offer in operation 404. If the provider is authorized, a unique offer ID is provided and stored along with the new offer information (e.g., in offer table 302) in operation 406. If the provider is not authorized, an error message may then be transmitted to the provider in operation 405. The procedure then ends. In a less preferred embodiment, authorization determination is skipped.

[0039] As illustrated in FIG. 3, the offer table 302 includes offer information for each offer (e.g., received from a Provider or provided by the Provisioning Web Service 106). The offer information 302 for each offer generally includes a unique offer ID and a unique identifier for the service being offered. The offer ID is provided by the Provisioning Web Service 106 to uniquely identify each new offer received into the Provisioning Web Service 106 and may be returned to the Provider for use in adding Invitees to the corresponding offer. The unique service identifier can also reference service information 304 for the offered service.

[0040] The offer information 302 also preferably includes a unique organization ID for identifying the organization providing the service, an offer description, an expiration date for the offer, and an expiration selection field to specify whether the Provider has provided an expiration date. The organization ID may be used to determine whether the Provider is authorized to create the new offer to a particular service. In one implementation, only organizations which own the offered service may offer such service. Additionally, authorization may include identification of the Provider. That is, the Provider may have to provide a user ID and/or password to create an offer. It may then be determined whether the particular user is authorized to create the offer. In one example, only organization administrators may create a new offer.

[0041] The offer description is optionally provided by the Provider and may be automatically included in the invitation to the Invitee. However, the Provider may opt to manually include an offer description when sending an invitation to an Invitee. In one implementation, the Provider may describe the offer in the body of an email sent to the Invitee, where the body of the email also includes a URL link to the invitation or alternatively the offer description may be automatically presented after the Invitee selects the URL link.

[0042] The expiration date for each offer may also be optional and may have any suitable format for specifying an expiration date or time. In the illustrated embodiment, the Provider may specify an expiration day, month, and year. When an expiration date is not specified by the Provider, the expiration selection field may be set to FALSE; otherwise, it is set to TRUE. This expiration selection field may be used to determine whether to automatically set a default expiration date (e.g., 60 days) for an offer. For instance, a default expiration date may be set when the expiration selection field is set to FALSE. Otherwise, the Provider's expiration date is used.

[0043] Preferably, the Provisioning Web Service 106 also operates to retain information regarding each Invitee for later use during offer acceptance by an Invitee, as well as any procedures carried out with respect to an Invitee and corresponding offer. FIG. 4B is a flowchart illustrating a procedure 450 for handling the receipt of information regarding one or more Invitees at the Provisioning Web Service in accordance with one embodiment of the present invention. Initially, information for one or more Invitees is received when the Provider adds an Invitee to an offer in operation 452. It may then be determined whether the provider is authorized in operation 454, e.g., as described above for authorization of the offer.

[0044] If the provider is authorized, a URL (Uniform Resource Locator) is then assigned for each Invitee in operation 456. The URL for each Invitee generally provides a mechanism for presenting a new offer to each Invitee. Although the present invention is described in terms of presenting an invitation in the form of a URL, of course, any other suitable interface to the Service Manager 101 may be utilized, such as an API, for presenting an invitation to an Invitee. A unique Invitee ID is then provided and stored along with the Invitee information in association with the new offer in operation 458. For example, the Invitee information is stored within Invitee table 306. If the Provider is not authorized, an error message may be transmitted to the Provider in operation 460 and the offer information is preferably not stored.

[0045] As illustrated in FIG. 3, the Invitee table 306 includes Invitee information for each Invitee (e.g., received from a Provider or provided by the Provisioning Web Service 106). The Invitee information 306 for each Invitee generally includes a unique Invitee ID, a corresponding offer ID, Invitee Identify Information, an Accept field for indicating whether the Invitee has accepted the corresponding offer, an Accept date, and a Register field indicating whether the Invitee has registered identifying information with the Invitee Manager 110.

[0046] As shown, the Invitee table 306 includes information for Invitees 1 through 4. Invitees 1 and 2 have been offered Offers A, while Invitee 3 has been offered Offer B and Invitee 4 has been offered Offer C. In general, each service may be offered to multiple Invitees and each Invitee may be offered multiple services. The Invitee table 306 also shows that Invitees 1 and 4 have registered their identifying information, while Invitees 2 and 3 have not. This table 306 also shows that Invitees 1, 3, and 4 have accepted their corresponding offers A, B and C (and the acceptance dates), while Invitee 2 has not accepted offer A.

[0047] The Invitee Identifying Information for each Invitee may include any relevant information about the Invitee. Preferably, this information includes the Invitee's email address which may be later used to verify the Invitee during acceptance of an offer and registration of the Invitee. By way of examples, this information may also include any combination of the following for the Invitee: address, name, surname, title, phone number, phone extension, fax number, and organization name or ID.

[0048] After an Invitee receives an invitation or offer to access a service, the Invitee may then register identifying information regarding itself and/or accept the offer through the Invitee Manager 110. To accomplish this, the Invitee may be presented an interface for providing registration information and for accepting offer terms in any suitable order. The Invitee's authority to accept such offer may also be verified during any point in the invitation handling process. The Invitee may also let the offer expire. These tasks for handling an invitation/offer may be accomplished in any suitable manner.

[0049] FIG. 5 is a flowchart illustrating a procedure 500 for handling an offer in accordance with a specific implementation of the present invention. Initially, an Invitee receives an email with a URL for a specific offer in operation 502. In this embodiment, the URL corresponds to the specific offer and a specific Invitee. When the Invitee accesses the URL, the unique Invitee ID and Offer ID (provided by the Provisioning Web Service 106 when the Invitee was added to the specific offer by the Provider) are incorporated into the resulting request sent to the Invitee Manager 110. Thus, the Invitee Manager 110 obtains information regarding when an Invitation is accessed for a particular offer by a particular Invitee.

[0050] After an Invitee accesses the URL in operation 504, it may then be determined whether the offer has expired and the Invitee is not authorized in operation 506. In the illustrated embodiment, if the offer has not expired and the Invitee is authorized, the Invitee is presented with an Invitation page having a registration link in operation 507. Authorization of the Invitee may be determined in any suitable manner. In one implementation, when the Invitee access the invitation (e.g., through the URL), the Invitee's email address may be verified against the email address which was stored for the Invitee during the offer creation process.

[0051] When the Invitee accesses the registration link in operation 508, the Invitee Manager then presents the Invitee with a registration form which may contain pre-filled information in operation 510. This pre-filled information may include Invitee Identifying Information as provided by the Provider. The Invitee may then submit the registration form with pre-filled or modified information in operation 512. After submission of the registration form, it may optionally be determined again whether the offer has expired (not shown) prior to proceeding.

[0052] After the Invitee submits the registration form (and the offer has not expired), the Invitee Manager stores the Invitee's registration or identifying information, and a registration indication and/or date and presents the Invitee with offer terms in operation 514. For example, a TRUE is stored in the Register field of the Invitee in the Invitee table 306 to indicate registration of the specific Invitee and the Invitee's identifying information is stored in the User Table 312. As shown in FIG. 3, the User Table 312 generally includes a unique User ID and user identifying information. The unique User ID for a new registered Invitee may be identical to the unique Invitee ID provided by the Provisioning Web Service 106. Identifying information regarding the registered Invitee's organization is also preferably stored in the Organization Table 310. The Invitee Manager may also store service information representing the Invitee in the Service Table 304.

[0053] A registration completion date may also be stored in the Invitee table (not shown). Registration completion may also be inferred by addition of the Invitee and their corresponding identifying information into the User Table 312.

[0054] The offer terms may include any suitable terms as worked out with the Provider or as preconfigured within the Service Manager 101. When the Invitee accepts the offer terms in operation 516, the Invitee Manager 110 then sets up permission between the Invitee and the accepted service and information regarding the offer acceptance is stored in operation 518. The procedure 500 then ends.

[0055] In the illustrated embodiment, an entry is added to the Permission Table 308 indicating that the accepted service is associated with a Grantor ID (e.g., from the Provider) who has provisioned the service and a Grantee ID (e.g., from the registered Invitee/User) who has accepted the service. Additionally, the Accept field for the particular Invitee in the Invitee table 306 is set to TRUE, when an accept occurs. Otherwise, this field defaults to FALSE. An Accept Date may also be specified in the Invitee Table.

[0056] If the Invitee fails to access the URL, register, or accept the offer terms, the offer is subject to expiration in operation 520. The Invitee can, however, access the URL, register, and accept the offer at a later time prior to the offer expiring. If the offer expires, the offer and Invitee information is still preferably retained for later access by the Provider. Alternatively, the offer may not have an expiration date. If the offer has expired and the Invitee is still attempting to access the invitation or the Invitee is not authorized, error handling may then be performed in operation 516. When the Invitee also attempts to access the Registration link at operation 508, it may also be determined whether the offer has expired. If the offer has expired, error handling may then be performed. Error handling may include sending an error message indicating offer has expired or access denied to the Invitee.

[0057] In the above described invitation handling procedure 500, the operations for registering the Invitee may be skipped if the Invitee is already registered. In this case, an option may be presented in the invitation page for registered users. When the Invitee selects this option, the offer terms are immediately presented to the registered Invitee/User for acceptance by same.

[0058] The repository 112 may also include a directory of services and an indication as to whether particular users can view a service. In some cases, a user may be allowed to view a service, but not permitted to use such service. In other cases, a user may be allowed to both view and use a service. In this application, after an Invitee is registered and accepts an offered service, this service directory is also updated to indicate that the Invitee can view the service, in addition to setting up access permissions (e.g., in the Permission table 308).

[0059] At any point after sending an invitation to an Invitee, the Provider may check the status of an offer or a specific invitation. In one embodiment, the Provider queries the Service Manager 101 (e.g., via the Provisioning Web Service 106 or the Invitee Manager 110) regarding a specific offer or Invitee. The Service Manager then compiles information regarding the specified offer or Invitee and sends a status update back to the Provider. For instance, the status update for a particular Invitee to a particular offer may include an indication as to whether the Invitee has registered, date of registration, whether the Invitee has accepted the offer, date of acceptance, and whether the offer has expired. This status information may be gleaned from the tables of FIG. 3. The status update of a particular offer may include a list of Invitees and their corresponding status.

[0060] The above described embodiments for provisioning services advantageously provide an efficient mechanism for providing access to services to various entities. The provisioning mechanisms allow diverse services to be provisioned among a diverse set of entities. The service access arrangements can be any suitable complexity and merely depend on the size of the memory for holding information regarding such services and their provisioning. Accordingly, the provisioning services of the present invention are easily scalable.

[0061] In a particular application of the provisioning embodiments of the present invention, a first business entity may provision a service to a second business entity who may or may not be registered with the Service Manager. The second business entity may also provision its own services back to the first business entity, to a third business entity, or any suitable number and type of other business entities. In sum, each entity (e.g., business invitee, user or organization) may provision any number of its services to any number and type of entities. Said in another way, each service may be provisioned to any number and type of entities or entity objects (e.g., user or organization services). The provisioning techniques of the present invention may also allow a user who has successfully been provisioned a service to then provision that service to another invitee, user or organization. That is, a user of a service may be given authorization (e.g., by the original provider) to provision such service, as well as the original provider being authorized.

[0062] Generally, the techniques for securely handling service provisioning of the present invention may be implemented on software and/or hardware. For example, it can be implemented in an operating system kernel, in a separate user process, in a library package bound into network applications, on a specially constructed machine, or on a network interface card. In a specific embodiment of this invention, the techniques of the present invention are implemented in software such as an operating system or in an application running on an operating system.

[0063] A software or software/hardware hybrid packet processing system of this invention is preferably implemented on a general-purpose programmable machine selectively activated or reconfigured by a computer program stored in memory. In one embodiment, portions of the service provisioning system (e.g., Provider 102, Invitee 108, Provisioning Web Service 106, Invitee Manager 110, or Service Manager 101) may be implemented on a general-purpose network host machine such as a personal computer or workstation.

[0064] Referring now to FIG. 6, a computer system 600 suitable for implementing the present invention includes a master central processing unit (CPU) 602, one or more memory 604, input and output interfaces 606, and a bus 608 (e.g., a PCI bus). When acting under the control of appropriate software or firmware, the CPU 602 is responsible for implementing various portions of the techniques of the present invention. It preferably accomplishes all these functions under the control of software including an operating system and any appropriate applications software. CPU 602 may include one or more processors such as a processor from the Motorola family of microprocessors or the MIPS family of microprocessors. In a specific embodiment, a memory 604 (such as non-volatile RAM and/or ROM) also forms part of CPU 602. However, there are many different ways in which memory could be coupled to the system. Memory block 604 may be used for a variety of purposes such as, for example, caching and/or storing data, programming instructions, etc.

[0065] The input and output interfaces 606 typically provide an interface to various I/O devices, such as mouse, keyboard, display, as well as providing an communication interface with other computer systems over a computer network. Among the communication interfaces that may be provided are Ethernet interfaces, frame relay interfaces, cable interfaces, DSL interfaces, token ring interfaces, and the like. In addition, various very high-speed interfaces may be provided such as fast Ethernet interfaces, Gigabit Ethernet interfaces, ATM interfaces, HSSI interfaces, POS interfaces, FDDI interfaces and the like. Generally, these interfaces may include ports appropriate for communication with the appropriate media. In some cases, they may also include an independent processor and, in some instances, volatile RAM.

[0066] Although the system shown in FIG. 6 is one specific computer system of the present invention, it is by no means the only system architecture on which the present invention can be implemented.

[0067] Regardless of system's configuration, it may employ one or more memories or memory modules (such as, for example, memory block 604) configured to store data, program instructions for the general-purpose network operations and/or the inventive techniques described herein. The program instructions may control the operation of an operating system and/or one or more applications, for example. The memory or memories may also be configured to store information in repository 112, etc.

[0068] Because such information and program instructions may be employed to implement the systems/methods described herein, the present invention relates to machine readable media that include program instructions, state information, etc. for performing various operations described herein. Examples of machine-readable media include, but are not limited to, magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROM disks and DVDs; magneto-optical media such as floptical disks; and hardware devices that are specially configured to store and perform program instructions, such as read-only memory devices (ROM) and random access memory (RAM). The invention may also be embodied in a carrier wave travelling over an appropriate medium such as airwaves, optical lines, electric lines, etc. Examples of program instructions include both machine code, such as produced by a compiler, and files containing higher level code that may be executed by the computer using an interpreter.

[0069] Although the foregoing invention has been described in some detail for purposes of clarity of understanding, it will be apparent that certain changes and modifications may be practiced within the scope of the appended claims. Therefore, the described embodiments should be taken as illustrative and not restrictive, and the invention should not be limited to the details given herein but should be defined by the following claims and their full scope of equivalents.