System and method for prioritizing components

• US 8,224,893 B2
• Filed: 07/01/2011
• Issued: 07/17/2012
• Est. Priority Date: 12/12/2002
• Status: Expired due to Term

• Current Assignee: Regional Resources Ltd (Imperial Metals Corp.)
• Original Assignee: Xerox Corporation (Xerox Holdings Corp.)
• Inventors: Newman, Mark Webster, Edwards, Warren Keith, Sedivy, Jana Zdislava
• Primary Examiner(s): DINH, KHANH Q
• Application Number:
  US13/175,789
• Publication Number:
  US 20110264785A1
• Time in Patent Office: 382 Days
• Field of Search: 709/203, 709/220, 709/224, 709/232, 709/228
• US Class Current: 709/203
• CPC Class Codes: G06Q 10/06 Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
• CPC Class Codes: H04L 67/04 specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
• CPC Class Codes: H04L 67/51 Discovery or management thereof, e.g. service location protocol [SLP] or web services
• CPC Class Codes: Y10S 707/99933 Query processing, i.e. searching
• CPC Class Codes: Y10S 707/99934 Query formulation, input preparation, or translation

Abstract

A system and method for prioritizing components is provided. Components, including at least one requester components and at least two service components are maintained. The components each include a historical context and access information. The requester component requests the historical contexts associated with one or more of the service components. The one or more service components are filtered to determine which of the one or more service components are accessible to the requester component using the access information. The accessible service components for the requester component are prioritized based on the associated historical contexts.

Claims

1. A system for prioritizing components, comprising:

a maintenance mechanism to maintain components comprising at least one requester component and at least two service components, each component comprising a historical context and access information;

a receiver mechanism to receive a request by the requester component for the historical contexts associated with one or more of the service components;

a filter mechanism to filter the one or more service components with access information that conflicts with access information of the requester component as unaccessible service components and to identify the unfiltered service components as accessible to the requester component; and

a selection mechanism to generate a configuration of components by selecting one of the accessible service components most likely to be used with the requester component based on the associated historical contexts.

2. A system according to claim 1, further comprising:

a prioritization mechanism to prioritize the accessible service components based on at least one of the historical context, an identity of a user associated with the requester component, the requester component itself, and a context monitor.

3. A system according to claim 1, further comprising:

a detection mechanism to detect prior usage patterns of at least one of the service components.

4. A system according to claim 1, further comprising:

a removal mechanism to remove the unaccessible service components from use by the requester component.

5. A system according to claim 2, further comprising:

an alteration mechanism to alter the prioritization of the accessible service components based on a preference of the user associated with the requester component.

6. A system according to claim 1, further comprising:

a template receipt mechanism to receive a template from a user associated with the requester component; and

a template filter mechanism to filter the one or more service components based on the received templates.

7. A system according to claim 6, wherein the template comprises at least one of specification of a unique field, components with particular interfaces, and components with particular properties.

8. A system according to claim 1, further comprising:

a rejection mechanism to reject unstrusted service components.

9. A system according to claim 1, wherein the historical context comprises at least one of supported data types, location, location requirements, usage history, and security policies.

10. A system according to claim 2, further comprising:

a presentation mechanism to present the prioritized service components to the user associated with the requester device.

11. A method for prioritizing components, comprising:

maintaining components comprising at least one requester component and at least two service components, each component comprising a historical context and access information;

requesting by the requester component, the historical context associated with one or more of the service components;

filtering the one or more service components with access information that conflicts with access information of the requester component as unaccessible service components;

identifying the unfiltered service components as accessible to the requester component; and

generating a configuration of components by selecting one of the accessible service components most likely to be used with the requester component based on the associated historical context.

12. A method according to claim 11, further comprising:

prioritizing the accessible service components based on at least one of an identity of a user associated with the requester component, the requester component itself; and

a context monitor.

13. A method according to claim 11, further comprising:

detecting prior usage patterns of at least one of the service components.

14. A method according to claim 11, further comprising:

removing the unaccessible service components from use by the requester component.

15. A method according to claim 12, further comprising:

altering the prioritization of the accessible service components based on a preference of the user associated with the requester component.

16. A method according to claim 11 , further comprising:

receiving a template from a user associated with the requester component; and

filtering the one or more service components based on the received templates.

17. A method according to claim 16, wherein the template comprises at least one of specification of a unique field, components with particular interfaces, and components with particular properties.

18. A method according to claim 11, further comprising:

rejecting untrusted service components.

19. A method according to claim 11, wherein the historical context comprises at least one of supported data types, location, location requirements, usage history, and security policies.

20. A method according to claim 12, further comprising:

presenting the prioritized service components to the user associated with the requester device.