Abstract:
Information rights management (IRM) systems enable information to be protected after it has been accessed by or delivered to an authorized individual. For example, this might be to allow an email to be viewed for a limited time by specified individuals but to prevent that email from being forwarded. However, existing IRM systems are limited in the situations in which they may operate. An IRM server is provided which communicates with one or more policy evaluators which are independent of the IRM server. Results from the different policy evaluators may be combined by the IRM server and one or more identity providers may be used in conjunction with each policy evaluator. By enabling the IRM server to act as a broker between authors, recipients and policy evaluators situations in which IRM systems may operate are greatly extended.

Description:
BACKGROUND 
       [0001]    Information rights management systems enable information to be protected after it has been accessed by or delivered to an authorized individual. They typically use persistent usage policies which remain with information when that information is transferred. For example, consider a chief executive officer (CEO) who wishes to send an email message that contains confidential information about a forthcoming reorganization to his or her executive staff. Using an information rights management system enabled email application, such as those currently known, the CEO is able to select a template to specify that recipients may read the email message but not copy, paste, edit or forward that message. When the recipients receive the email message they are able to view it using the email application. The email application enforces the permissions so that the recipients are unable to copy, paste, edit or forward the message. Existing information rights management systems also enable other policies to be used. For example, the CEO might set a time limit after which the recipients are no longer able to view the email. These types of restrictions can also be applied to intranet content and electronic documents using known information rights management systems. 
         [0002]    Typically information rights management systems are implemented in a single organization, enterprise or trust domain and may be known as Enterprise Rights Management (ERM) systems. 
         [0003]    Existing information rights management systems can only be applied in limited situations. 
         [0004]    The embodiments described below are not intended to be limited to implementations that solve any or all of the noted disadvantages. 
       SUMMARY 
       [0005]    The following presents a simplified summary of the disclosure in order to provide a basic understanding to the reader. This summary is not an extensive overview of the disclosure and it does not identify key/critical elements of the invention or delineate the scope of the invention. Its sole purpose is to present some concepts disclosed herein in a simplified form as a prelude to the more detailed description that is presented later. 
         [0006]    Information rights management (IRM) systems enable information to be protected after it has been accessed by or delivered to an authorized individual. For example, this might be to allow an email to be viewed for a limited time by specified individuals but to prevent that email from being forwarded. However, existing IRM systems are limited in the situations in which they may operate. An IRM server is provided which communicates with one or more policy evaluators which are independent of the IRM server. Results from the different policy evaluators may be combined by the IRM server and one or more claim providers may be used in conjunction with each policy evaluator. By enabling the IRM server to act as a broker between authors, recipients and policy evaluators situations in which IRM systems may operate are greatly extended. 
         [0007]    Many of the attendant features will be more readily appreciated as the same becomes better understood by reference to the following detailed description considered in connection with the accompanying drawings. 
     
    
     
       DESCRIPTION OF THE DRAWINGS 
         [0008]    The present description will be better understood from the following detailed description read in light of the accompanying drawings, wherein: 
           [0009]      FIG. 1  is a schematic diagram of an information rights management system; 
           [0010]      FIG. 2  is a block diagram of a method of using an information rights management system; 
           [0011]      FIG. 3  is a schematic diagram of another example information rights management system; 
           [0012]      FIG. 4  is an example message sequence chart for a method of operation of an information rights management system; 
           [0013]      FIG. 5  is an example of an issue license data structure; 
           [0014]      FIG. 6  is an example of a use license data structure; 
           [0015]      FIG. 7  is a schematic diagram of another example information rights management system; 
           [0016]      FIG. 8  is a schematic diagram of another example information rights management system; 
           [0017]      FIG. 9  is a schematic diagram of another example information rights management system; 
           [0018]      FIG. 10  illustrates an exemplary computing-based device in which embodiments of an information rights management server may be implemented. 
       
    
    
       [0019]    Like reference numerals are used to designate like parts in the accompanying drawings. 
       DETAILED DESCRIPTION 
       [0020]    The detailed description provided below in connection with the appended drawings is intended as a description of the present examples and is not intended to represent the only forms in which the present example may be constructed or utilized. The description sets forth the functions of the example and the sequence of steps for constructing and operating the example. However, the same or equivalent functions and sequences may be accomplished by different examples. 
         [0021]    The term “information rights policy” refers to one or more conditions or criteria which must be met before granting the right to perform specified actions on data, such as “read”, “write”, “print” or “forward”. This differs from policies which might be used to control whether data may simply be obtained from a source without any control over later actions on that data such as its dissemination, “read”, “write” etc. 
         [0022]    The term “identity provider” is used herein to refer to an entity which is able to issue authentication tokens to authenticate another entity to an information rights management system. 
         [0023]    The term “claim provider” is used to refer to an entity which is able to issue authorization tokens with claims which may be used by a policy evaluator of an information rights management system. 
         [0024]    In some cases, a claim provider may also act as an identity provider although this is not essential. 
         [0025]    Consider the information rights management (IRM) system of  FIG. 1 . This comprises an IRM server  100 , an identity provider  102 , an author  103  and a recipient  106  all connected by a communications network. The author  103  comprises an IRM client  105  and an IRM enabled application such as an email application for example. The recipient  106  also comprises an IRM client  107  and the same IRM enabled application  108  as available at the author  103 . There may be many more recipients and authors although these are not shown in  FIG. 1  for clarity. 
         [0026]    The author registers with the IRM server and receives a user certificate from the IRM server. 
         [0027]    Suppose that the author  130  requires to send an email to a specified group of recipients whilst ensuring that an information rights policy is enforced so that the recipients are able to view the email but not print, copy, edit or forward that email. Referring to  FIG. 2 , the author creates the email using the IRM enabled application and specifies usage rights and conditions for the email (block  200 ). Those usage rights and conditions together form an instance of an information rights policy. For example, in this case, the conditions include that the recipient should be a member of a specified group of recipients and the usage rights include that the recipients may only view the email. The author&#39;s IRM client and the IRM server together create an encrypted issue license containing the specified usage rights and conditions (block  201 ). For example, the IRM server generates the issue license and sends this to the IRM client. The IRM enabled application  104  or IRM Client  105  at the author encrypts the email and incorporates the encrypted issue license into that email (block  202 ). The issue license is encrypted with a symmetric key which is then encrypted to a public key of the IRM server. The encrypted key is inserted into the encrypted issue license. As a result only the IRM server is able to issue a use license to decrypt the file. 
         [0028]    The author then emails the encrypted email to the recipient (block  203 ). The recipient opens the file using the IRM enabled email application  108  and sends a request for a use license to the IRM server. The request includes the recipient&#39;s public key and the issue license which contains the symmetric key that encrypted the file. The IRM server validates the recipient as being in the specified group using the identity provider  102  and creates and issues a use license that contains the usage rights and conditions that were specified in the issue license (block  204 ). During this process, the IRM server decrypts the symmetric key using its private key and adds the encrypted session key to the use license. This step ensures that only the intended recipient can decrypt the symmetric key and thus decrypt the protected file. Using the use license, the recipient IRM enabled application  107  or IRM Client  108  then decrypts the email content and enforces the usage rights and conditions (block  205 ). In the IRM system described above with reference to  FIGS. 1 and 2  the IRM server itself validates the information rights policies and is the only entity able to do this and to issue use licenses. In addition, only a pre-specified, limited list of authentication tokens may be used. Also the language used to express the information rights policy is fixed. 
         [0029]    It is recognized here that this is restrictive in situations where it is required to allow different types of information rights policy validation process, perhaps using third party information rights policy validation systems. For example, the author has no choice over the type of information rights policy validation process used. In addition, different types of information rights policy validation process may require input from different sources of information about recipient; that is, different claim providers. However, the architecture of  FIG. 1  only enables a single identity provider  102  to be used as source of the authentication token to authenticate a user to the IRM server and the same token is used as an authorization token to validate the information rights policy. In addition, the identity provider is one of a pre-specified list of supported identity providers for interaction with the IRM server  100 . 
         [0030]    For example, consider a situation in which data is created using a first application. That application has functionality to specify user roles which may be used to specify an information rights policy using an IRM system such as that described above. In this case the identity provider for the IRM system comprises a system for checking the user roles of the application. 
         [0031]    Suppose that it is required to export the created data to a second application. The data is saved using that second application and is then disseminated. However, it is required to use an information rights policy to control use of the disseminated data. The second application does not have understanding of the user roles of the first application and so that information cannot easily be used to set up the information rights policy. Instead another identity provider needs to be used which is associated with the second application. However, this is inconvenient in many situations and can lead to errors and/or failure to specify information rights policies at all. This is because it is usually more straightforward to allow an author to specify information rights policy information using the first application in which the data is created. 
       An Exemplary System 
       [0032]      FIG. 3  is a schematic diagram of an improved information rights management system. It comprises an IRM server  300 , one or more policy evaluators  301  in communication with the IRM server  300 , and an IRM client  305 ,  307  at each author  303  and recipient  306 . Only one author and recipient are shown for clarity although in practice there may be many more such authors and recipients. The information rights management system may be used in an arrangement such as that illustrated in  FIG. 3 . Each author also comprises an originating application which provides functionality at least to create data and to specify information rights policy information. Each author is in communication with the IRM server  300  and with recipients  306  via a communications network of any suitable type. 
         [0033]    Each recipient comprises a target application  308  for carrying out actions such as viewing or reading information controlled using the IRM system. The target application  308  is in communication with the IRM client  307  at the recipient  306 . That IRM client  307  is also in communication with an identity selector  309  at the recipient. The identity selector is in communication with one or more claim providers  302 . In this case one or more of the claim providers also act as identity providers. However, this is not essential. The claim providers and identity providers may be separate entities. 
         [0034]    In contrast with the system described above with reference to  FIG. 1  it is not essential for the IRM server  300  of  FIG. 3  to validate information rights policies itself. Instead policy evaluators  301  may perform that function instead of or in addition to the IRM server itself. The IRM server can be thought of as acting as a broker between the authors  303 , policy evaluators  301 , claim providers  302 , and recipients  306 . Several different claim providers  302  may be used in contrast to the situation of  FIG. 1 . Also, it is not essential for the originating application  304  and the target application  308  to be the same as in the example described above with reference to  FIG. 1 . In this way the information rights decision component (IRM server) can be thought of as being decoupled from the identity (authentication) and policy mechanism (authorization). 
         [0035]    In some examples the architecture of  FIG. 3  is modular in that different policy evaluators  301  may be plugged into the system. For example, these may be bespoke policy evaluators and may be application specific or application independent. In addition, different claim providers may be plugged in and if a plurality of claim providers are available, dynamic selection of one or more of these is possible as described in more detail below. 
       Exemplary Method 
       [0036]      FIG. 4  is a high level message sequence chart for an example method of operation of the IRM system of  FIG. 3 . Each vertical line in the chart represents an entity of the IRM system or an entity with which the IRM system interacts and the same reference numerals are used for these entities as those used in  FIG. 3 . Arrows between the vertical lines represent messages sent between the entities and the relative position of those arrows with respect to one another represents the sequence of the messages in time. Processes carried out at the entities themselves may be represented using rectangles on the vertical lines. Only one policy evaluator and one claim provider and combined identity provider are shown for clarity. However, in practice, more than one policy evaluator may be used and more than one claim provider. 
         [0037]    At the author machine or system, information is received or generated automatically to specify an information rights policy (block  401 ) for content that it is required to control use of. For example, this information may be automatically generated using pre-specified rules or criteria or may be specified by an end user. More detail about how this information may be specified is given later. 
         [0038]    The content that it is required to control use of may be provided in one or more parts each of which may have its own specified information rights policy information. 
         [0039]    The author machine  303  sends a request message (arrow  402 ) for an issue license to the IRM server  300 . This request message comprises the information about the specified information rights policy. The request message may take a similar form as that used in the system of  FIG. 1 . 
         [0040]    The IRM server  300  creates an issue license (block  403 ). It encrypts a content key on a public key of the Author. This process may take a similar form to that described above with reference to  FIGS. 1 and 2  although the method of creating the issue license and the issue license itself takes a different form from that used in the method of  FIG. 2 . 
         [0041]    The created issue license is sent from the IRM server to the author (arrow  404 ). The IRM client at the author decrypts the content key and uses that key to encrypt the content parts. The issue license is attached to the encrypted content parts and together these are sent to the recipient (dotted arrow  406 ). For example, the issue license is attached to an encrypted email, document or other protected item and this is sent to the recipient. 
         [0042]    The recipient requests information rights to the content in order to perform an operation such as reading that content (block  407 ). The recipient is able to access information from the issue license about the specified claim requirements (of the specified information rights policy) because that information is not encrypted. The IRM client at the recipient then requests one or more authorization tokens with claims from a claim provider (message  408 ) which would fall within the specified claim requirements. The recipient then receives one or more security tokens from the identity provider (message  409 ). 
         [0043]    The recipient generates and sends a use license request (arrow  410 ) to the IRM server. The use license request comprises the issue license, the received authorization tokens and optionally a list of actions relevant to the target application. 
         [0044]    The IRM server then proceeds to authenticate the recipient (block  411 ). This authentication process is carried out in any suitable manner, such as that described above with reference to  FIGS. 1 and 2 . For example, authentication tokens obtained from an identity provider are used for this purpose. This authentication process is not illustrated in detail in  FIG. 4  for reasons of clarity. The next part of the process is concerned with authorization. 
         [0045]    The IRM server accesses information about the information rights policy from the issue license. This information comprises information about which type or types of information rights policy apply in this case. This information is used to identify the relevant policy evaluators to be used. That is, each type of information rights policy is associated with a particular policy evaluator. 
         [0046]    Once the IRM server has identified which one or more policy evaluators are to be used, it forwards the use license request to each of those policy evaluators (arrow  412 ). Note that in  FIG. 4  only one policy evaluator is shown for clarity but it is also possible to use more than one policy evaluator. As before, the use license request comprises the issue license, the authorization tokens, and the actions list requested by the target application. 
         [0047]    Each policy evaluator that receives a request message (arrow  412 ) then proceeds to carry out an evaluation. The policy evaluator input parameters comprise the information rights policy information from the issue license, the authorization tokens, and a list of actions to query. The policy evaluator output comprises a list of granted actions also referred to as effective rights. This output is returned to the IRM server (arrow  414 ). During the evaluation process the policy evaluators are carrying out an authorization process in contrast to the authentication process previously carried out at block  411 . 
         [0048]    In the case that evaluation results are received at the IRM server  300  from two or more policy evaluators the IRM server combines or aggregates the lists of effective rights on the basis of a combination description held in the issue license. For example, the combination description is a Boolean expression such as AND. In this case the aggregated list of effective rights comprises the intersection of the lists of granted actions in the individual policy evaluator results. If the combination description is the Boolean expression OR, the aggregated list of effective rights comprises the union of the lists of granted actions in the individual policy evaluator results. Any suitable method of combining or aggregating the lists of granted actions may be used. 
         [0049]    If there are some allowed actions in the policy evaluator response the IRM server proceeds to decrypt the content key from the issue license. The IRM server also proceeds to encrypt and sign corresponding parts of a use license for the particular recipient (block  415 ). This process may be similar to that described above with respect to  FIG. 1 . The use license is then sent to the recipient (arrow  416 ). 
         [0050]    At the recipient the IRM client receives the use license. The IRM client uses its private key to decrypt the content key and then uses that decrypted key to decrypt the corresponding content part. The use license is applied (block  417 ) such that only the effective rights may be applied to the content. 
         [0051]    An example of an issue license data structure is now given with reference to  FIG. 5 . It comprises an owner field or part  500  which is used to store information about the author who created the issue license and who requires to protect the content. For example, this information may comprise information from the IRM server which identifies the author such as an authorization token or internal credentials. Optionally, display attributes may be stored with the owner information in order to specify how the owner information is to be presented to targeted recipients. 
         [0052]    The issue license data structure may also comprise a validity time part  501 . This may be used to store information about a time at which the issue license itself will expire. 
         [0053]    A use license acquisition endpoint reference part  502  may be provided to store an endpoint reference to the IRM server to which a use license request is to be sent. This is the endpoint reference of the issuing IRM server. In some embodiments in which federation is used this information may be modified. 
         [0054]    The issue license data structure may comprise one or more content information rights information sections  503 . Each of these may comprise a content reference part  504 , a content key part  505 , a policy container part  506  and one or more policy evaluation information parts  507  (one for each policy evaluator to be used). 
         [0055]    The content reference part  504  may be used to store a URI or other identifier for a content part in the scope of the originating application. The content key part  505  may be used to store a key that is used to encrypt the content part data. It may be encrypted with the IRM server public key. 
         [0056]    The policy container part  506  is used to store policy description information that encapsulates the information rights policies for the specific content part. This part may also comprise information about how to combine or aggregate the evaluation results of different policy evaluators in to a single information rights result. It is also possible for the policy container part to be used to store a reference to another location where this information is stored. 
         [0057]    Each of the policy evaluator information parts  507  comprises an information rights policy part  508  and one or more claim provider information parts  509 . The information rights policy part  508  may be used to store information that is to be sent to a policy evaluator. For example, this may comprise conditions and identity information that is to be evaluated. This information may be encrypted using the IRM server public key. 
         [0058]    Each claim provider information part  509  comprises data about a claim provider. These data may be stored using one of more of the following parts: endpoint reference part  510 , a token type part  511 , claim requirements part, and/or other decriptors. 
         [0059]    The policy container  506  is able to encapsulate multiple, and different types of, information rights policies. This enables the content information rights information section  503  to deal with more than simply a single information rights description. Also, the policy container comprises information that enables results from more than one policy evaluator to be combined into a single information rights result. 
         [0060]    The issue license also enables, for each information rights policy description, information to be provided regarding the required authorization tokens needed for policy evaluation. 
         [0061]    An example of a use license data structure is now given with reference to  FIG. 6 . The use license data structure may comprise an owner part  600  for storing information about the author of the issue license. This information may be copied from the issue license. A validity time part  601  is also provided which may also be copied from the issue license. 
         [0062]    A use license acquisition endpoint reference part  602  may be provided to store a use license request endpoint reference of the IRM server. In embodiments using federation this endpoint reference may be changed as described in more detail below. 
         [0063]    A content information rights information section  603  is provided comprising a content reference part  604 , a content key part  605 , a granted information rights part  606  and a content information rights validity time part  607 . The content reference part  604  may be used to store a URI or other identifier for a content part in the scope of the originating application. This information may be copied from the issue license. A content key part  605  may be used to store a key to decrypt the content part data. It is encrypted with the recipient&#39;s public or symmetric key associated with a token that was used to authenticate to the IRM server. The granted information rights part  606  may be used to store a list of allowed actions for the particular recipient in the particular context. It may be encrypted with the recipient&#39;s public or symmetric key associated with a token that was used to authenticate to the IRM server. The content information rights validity time part  607  may be used to store a validity time of the information rights given for the particular content part. 
         [0064]    In the example use license data structure given above, the granted information rights part  606  may be used to store combined results of different policy evaluators and may comprise actions from different applications. 
       Another Exemplary Method 
       [0065]    Earlier in this document a situation was considered in which data is created using a first application. That application has functionality to specify user roles which may be used to specify an information rights policy using an IRM system such as that described above. In this case the claim provider for the IRM system comprises a system for checking the user roles of the application. 
         [0066]    Suppose that it is required to export the created data to a second application. The data is saved using that second application and is then disseminated. However, it is required to use an information rights policy to control use of the disseminated data. The second application does not have understanding of the user roles of the first application and so that information cannot easily be used to set up the information rights policy. Instead another claim provider needs to be used which is associated with the second application. However, this is inconvenient in many situations and can lead to errors and/or failure to specify information rights policies at all. This is because it is usually more straightforward to allow an author to specify information rights policy information using the first application in which the data is created. 
         [0067]    Using the improved IRM system of  FIG. 3  it is possible for a first and second application to be used in this way. For example, suppose that the first application is the originating application  304  and the second application is the target application  308 . The originating application  304  might be a financial data processing application and the target application might be a word processing application for example. Two policy evaluators  301  are provided, one associated with the originating application and one associated with the target application. In addition, two claim providers are given, one associated with the originating application and one with the target application. 
         [0068]    The author creates a content using the financial data processing application and exports that content to a document of the target application type. Information rights policy information is created and stored in the issue license at this stage. Some of the information rights policy information comprises a read only right for users of the financial data processing application having a role of specified type. Additionally, the information rights policy information comprises read only rights for particular recipients having an identity specified using an identity provider such as an organization&#39;s directory (e.g. LDAP directory). The information rights policy information thus comprises information rights policies of two different types, one associated with the financial data processing application and one associated with the organization&#39;s directory. 
         [0069]    The method of  FIG. 4  is followed such that recipients of the document have read only rights providing they meet the information rights policy and claims requirements. Thus as shown in this example, it is not essential for the originating application and the target application to be the same. In addition it is possible to protect content of a document of the target application using information rights expressed using the originating application. 
       Another Example System 
       [0070]      FIG. 7  shows an example of another IRM system. In this case the arrangement is similar to that of  FIG. 3  with a single IRM server  700  in communication with one or more policy evaluators  701 . An author  703  and a recipient  706  are in communication with the IRM server  700  and the recipient has access to a first claim provider  702 . However, in this example, the recipient also has access to one or more second claim providers  711  via a communications network  710 . For example, the second claim provider  711  may be in a different enterprise or trust domain from the first claim provider. At least one of the policy evaluators  701  is arranged to trust authorization and optionally authentication tokens provided by the second claim provider  711 . The term “trust” is used here to mean that at least one of the policy evaluators is arranged to accept and interpret authorization and optionally authentication tokens provided by the second claim provider  711 . As in  FIG. 3 , the claim providers may also act as identity providers. Alternatively, separate identity providers may be used. 
         [0071]    The term “trust domain” is used to refer to the set of systems and/or applications which share a single identity provider in order to authenticate to each other using the authorization tokens from that identity provider. 
       Another Example System 
       [0072]      FIG. 8  shows another example of an IRM system. Here there are two IRM servers  700 ,  800  but a single claim provider  702 . The IRM servers  700 ,  800  are connected via a communications network  802  and may be in different enterprises or trust domains as indicated by the dotted lines. A first one of the IRM servers  700  is connected to policy evaluators  701  and to at least one author  703 . The second IRM server  800  is also connected to policy evaluators  801  as well as to a recipient  706  which has an associated claim provider  702 . 
         [0073]    In this example, the recipient  706  is registered with the second IRM server  800 . Thus the recipient  706  is unable to request a use license directly from the first IRM server  700 . Instead the recipient  706  requests the use license from the second IRM server  800  and that IRM server forwards the request to the first IRM server  700  with which it has a trust relationship. That is, the first and second IRM servers are arranged to accept and interpret communications from one another. This arrangement enables independent, global claim providers to be provided. Such claim providers (e.g.  702  of  FIG. 8 ) are able to issue authorization tokens for validation of corresponding authorization policies in different IRM domains (where the IRM domains are indicated by the dotted lines in  FIG. 8 ). 
         [0074]    In a similar manner it is also possible to use more than two IRM servers where each IRM server is in communication with and trusted by at least one other IRM server. 
       Another Example System 
       [0075]      FIG. 9  shows another example IRM system. Here the arrangement is the same as that of  FIG. 8  except that a second claim provider  900  is connected to the communications network  802  between the first and second IRM servers. As in  FIG. 8  the recipient  706  is able to request a use license from the second IRM server  800  and that IRM server forwards the request to the first IRM server  700  with which it has a trust relationship. The recipient is able to use claim information provided by either or both of the first and second claim providers when it makes its request for a use license. 
         [0076]    In some embodiments the IRM client at the author interacts with the originating application to automatically (or manually) create information rights policy information to be included in the issue license. 
         [0077]    For example, a graphical user interface may be displayed at the author machine to enable an end user to select policy evaluators. A policy builder graphical user interface may be displayed in order to enable an end user to create a policy in an evaluator&#39;s policy language. 
         [0078]    In some examples, each policy evaluator is able to accept authorization tokens from one or more claim providers of a specified type. The policy builder graphical user interface may enable an author to specify claim providers. Alternatively, default settings for the claim provider information may be used. 
       Exemplary Computing-Based Device 
       [0079]      FIG. 10  illustrates various components of an exemplary computing-based device  1000  which may be implemented as any form of a computing and/or electronic device, and in which embodiments of an information rights management server may be implemented. 
         [0080]    The computing-based device  1000  comprises one or more inputs  1004  which are of any suitable type for receiving input from an author comprising issue license requests and other input. The device also comprises communication interface  1008  for communicating with other entities such as policy evaluators, other information rights management servers, recipients, authors and other communications network nodes. 
         [0081]    Computing-based device  1000  also comprises one or more processors  1001  which may be microprocessors, controllers or any other suitable type of processors for processing computing executable instructions to control the operation of the device in order to carry out the functions of an information rights management server. Platform software comprising an operating system  1002  or any other suitable platform software may be provided at the computing-based device to enable application software  1005  to be executed on the device. 
         [0082]    The computer executable instructions may be provided using any computer-readable media, such as memory  1003 . The memory is of any suitable type such as random information memory (RAM), a disk storage device of any type such as a magnetic or optical storage device, a hard disk drive, or a CD, DVD or other disc drive. Flash memory, EPROM or EEPROM may also be used. 
         [0083]    An output  1007  is also provided such as an audio and/or video output to a display system integral with or in communication with the computing-based device. The display system may provide a graphical user interface, or other user interface of any suitable type although this is not essential. 
         [0084]    The term ‘computer’ is used herein to refer to any device with processing capability such that it can execute instructions. Those skilled in the art will realize that such processing capabilities are incorporated into many different devices and therefore the term ‘computer’ includes PCs, servers, mobile telephones, personal digital assistants and many other devices. 
         [0085]    The methods described herein may be performed by software in machine readable form on a storage medium. The software can be suitable for execution on a parallel processor or a serial processor such that the method steps may be carried out in any suitable order, or simultaneously. 
         [0086]    This acknowledges that software can be a valuable, separately tradable commodity. It is intended to encompass software, which runs on or controls “dumb” or standard hardware, to carry out the desired functions. It is also intended to encompass software which “describes” or defines the configuration of hardware, such as HDL (hardware description language) software, as is used for designing silicon chips, or for configuring universal programmable chips, to carry out desired functions. 
         [0087]    Those skilled in the art will realize that storage devices utilized to store program instructions can be distributed across a network. For example, a remote computer may store an example of the process described as software. A local or terminal computer may information the remote computer and download a part or all of the software to run the program. Alternatively, the local computer may download pieces of the software as needed, or execute some software instructions at the local terminal and some at the remote computer (or computer network). Those skilled in the art will also realize that by utilizing conventional techniques known to those skilled in the art that all, or a portion of the software instructions may be carried out by a dedicated circuit, such as a DSP, programmable logic array, or the like. 
         [0088]    Any range or device value given herein may be extended or altered without losing the effect sought, as will be apparent to the skilled person. 
         [0089]    It will be understood that the benefits and advantages described above may relate to one embodiment or may relate to several embodiments. It will further be understood that reference to ‘an’ item refers to one or more of those items. 
         [0090]    The steps of the methods described herein may be carried out in any suitable order, or simultaneously where appropriate. Additionally, individual blocks may be deleted from any of the methods without departing from the spirit and scope of the subject matter described herein. Aspects of any of the examples described above may be combined with aspects of any of the other examples described to form further examples without losing the effect sought. 
         [0091]    It will be understood that the above description of a preferred embodiment is given by way of example only and that various modifications may be made by those skilled in the art. The above specification, examples and data provide a complete description of the structure and use of exemplary embodiments of the invention. Although various embodiments of the invention have been described above with a certain degree of particularity, or with reference to one or more individual embodiments, those skilled in the art could make numerous alterations to the disclosed embodiments without departing from the spirit or scope of this invention.