Abstract:
An electronic transaction may be implemented in a fashion that allows the security burden to be adjustably set based on the nature of the transaction. By receiving information about the type of transaction, a system may implement a variable security protocol. For example, the higher the value of the transaction, the greater the security protocol that may be implemented. Of course in such case, the higher security protocol may result in greater overhead or burden to the users. In other cases when the nature of the transaction permits, a lower security burden may be applied.

Description:
BACKGROUND  
         [0001]    This invention relates generally to security protocols for electronic systems.  
           [0002]    Electronic systems may communicate with one another, providing information and services over wired and wireless networks. In many cases, there is a need for security in such communications. As one example, confidential information may be provided over the network between two communicating entities. As another example, payment information may be provided, which, if intercepted, could be used to defraud one of the two entities. Likewise, in a number of business transactions, it is essential to be sure that the parties that are dealing with one another actually know the identities of the party with whom they are dealing.  
           [0003]    For all these reasons, security may be provided in connection with a wide range of electronic communications. One example of such security is an authentication protocol, which enables one user to get information about the identity of another user. Authentication is a process by which a system validates a user&#39;s identity, such as the user&#39;s logon information. The user&#39;s name and other information may be compared against an authorized list and if the system detects a match, access to the system may be granted to the extent specified in the permission list for that user. Many authentication systems are controlled by logon passwords.  
           [0004]    Encryption is a process of encoding data to prevent unauthorized access especially during transmission. Encryption may be based on a key that is essential for decoding. An encryption key is a sequence of data that is used to encrypt other data and that consequently must be used for the data&#39;s decryption.  
           [0005]    Still another digital security technique is the use of digital signatures. A digital signature is a personal authentication method based on encryption and secret authorization codes used for signing electronic documents. In some cases, digital signatures, being legally binding, may involve hardware security regardless of the value of the transaction being processed.  
           [0006]    Generally, certain types of electronic transactions have predefined or fixed security protocols. A given type of protocol, generally involves a predetermined type of security, be it digital signature, encryption, authentication or some combination of these. Moreover, the burdensomeness of the security protocols may be fixed as well. Some cases may require a fingerprint input, a password input, a second password input alike, while other transactions or communications may simply involve a simple password.  
           [0007]    Whatever the security protocol, it is generally predetermined and fixed. Thus, in some cases, relatively small value transactions must proceed with heightened security protocols designed for very high value transactions. This frustrates the user&#39;s ability to undertake routine transactions. In general, to facilitate the completion of a large variety of transactions, the highest possible security protocol may be necessitated in all cases.  
           [0008]    Thus, there is a need to enable transactions of a variety of different values and types to be initiated using the same electronic systems. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0009]    [0009]FIG. 1 is a schematic depiction of a system in accordance with one embodiment of the present invention;  
         [0010]    [0010]FIG. 2 is a flow chart for software in accordance with one embodiment of the present invention; and  
         [0011]    [0011]FIG. 3 is a flow chart for additional software in accordance with one embodiment of the present invention. 
     
    
     DETAILED DESCRIPTION  
       [0012]    Referring to FIG. 1, a system  44  enables communications between a server  32  and a client  42 . While one embodiment is described with a server/client architecture, any other communication architectures may be utilized, including peer-to-peer, multicast and broadcast type systems to mention a few examples.  
         [0013]    The server  32  may communicate with the client  42  over a network  40 . Communications to and from the network may be via links  46  and  48 . The links  46  and  48  may be wired or wireless links. They may be radio frequency links or infrared links to mention a few examples.  
         [0014]    The network  40  may be a computer or telephone network to mention a few examples. Computer networks include the Internet, local area networks, and metropolitan area networks to mention a few examples.  
         [0015]    The server  32  includes a processor  36  coupled to an input/output port  34 , which may provide an interface to the link  48 . The processor  36  may also be coupled to storage  38 , which stores software  20  and  50 .  
         [0016]    Ideally, the server  32  communicates with the client  42  to undertake a series of transactions. These transactions may include financial transactions, data transmissions and provision of services to mention a few examples. In each case, it is desirable to complete the transaction with the least amount of security overhead that is appropriate given the type and value of the transaction. Thus, a transaction involving a very large amount of money may need a relatively high security overhead while merely downloading a script may involve a relatively low security overhead.  
         [0017]    In accordance with embodiments of the present invention, the level of the security overhead may be adjustably or variably determined in a dynamic fashion. This may be determined based on code information provided by an initiator of the transaction, or it may be deduced dynamically during the course of the transaction.  
         [0018]    Referring to FIG. 2, the security software  20  stored in the storage  38  in FIG. 1, begins by receiving transaction type information as indicated in block  10  in accordance with one embodiment of the present invention. The type information may indicate the nature of the transaction and may be provided by the initiator. For example, the initiator of the transaction may enter information in a graphical user interface, which allows the type of the transaction to be determined. Alternatively, in another embodiment, a variety of information may be obtained from the initiator. As still another embodiment, the entity that receives the initiated transaction by the initiator may provide information. The nature of the transaction may be indicated to a degree sufficient to enable the security overhead to be dynamically adjusted.  
         [0019]    Once the type information has been received as indicated in block  10 , a check at diamond  12  determines whether or not the transaction is a low value transaction in one embodiment of the present invention. If so, a determination at diamond  14  determines whether hardware encryption is required. If not, the low value security assets may be utilized as indicated in block  16 . This facilitates the execution of the transaction by reducing the security overhead. In some cases, the low value security assets may be essentially no security whatsoever and in other cases, the low value security assets may be as simple as a password. Still other security assets may be utilized in other cases. For example, in some situations, relatively low value transactions may be sufficiently valuable to require some significant level of security while still using less security overhead than would be required in other cases. If hardware is required, as determined in diamond  14 , the flow iterates to another leg of the security software  20 .  
         [0020]    If a low value transaction is not involved, a check at diamond  18  determines whether a higher value or mid-value transaction is determinable based on the received type information. If so, a check at diamond  20  determines whether hardware is required. If not, a mid-value security asset may be applied as indicated in block  22 . This may involve some authentication or less time consuming encryption as examples. A variety of other security assets may be applied depending on the context.  
         [0021]    If hardware is required as determined at diamond  20 , based on the type of transaction, or if hardware was required in diamond  14 , a check at diamond  26  determines whether high value assets are present. If high value security assets are available, those assets may be implemented including hardware encryption as indicated in block  28 . Otherwise, the transaction may not be permitted as indicated in block  30 .  
         [0022]    Finally, a check at diamond  24  determines whether the transaction is determined to be a high value transaction. If not, the transaction is not determinable and may not be permitted in one embodiment. If the transaction is determinable to be a high value transaction and high value assets are present as determined in diamond  26 , the high value security assets may be applied as indicated in block  28 . In such case, the security overhead or burden may be enhanced, but would be appropriate under such circumstances.  
         [0023]    Turning finally to FIG. 3, the software  50  for assessing the value of a particular transaction may be utilized to dynamically determine the nature of the transaction. In some embodiments, the software  50  may request specific pieces of information in order to make that assessment. It may progressively ask for more information until it gets sufficient information to make the determination. In other cases, information that is naturally provided in the course of the transaction may be sufficient to make the assessment. For example, in a sales transaction based on the amount of money that is involved, or based on the type of credit that is being utilized, if any, an assessment may be made of the appropriate security asset level.  
         [0024]    In one embodiment, transaction type information may be received as indicated in block  52 . This may include whether or not it is a provision of a service, downloaded software, an online sales transaction, or the like. Information may be stored in a database about different types of transactions and their appropriate security protocols.  
         [0025]    Next, information may be received about the transaction value as indicated in block  54 . This information may be requested from the initiator or may be naturally received in the course of receiving the transaction information. In one example, the transaction value may be merely the price of the assets being purchased in an online transaction.  
         [0026]    Next, initiator preferences may be received as indicated in block  56 . In some cases, initiators may choose to undertake less security burden and in other cases, higher security burden may be desired. Thus, the initiator&#39;s own preferences may be waived in the evaluation of the appropriate security assets. Finally, the transaction security level may be assessed in block  58 .  
         [0027]    With embodiments of the present invention, the security level that is applied may be dynamically adjusted. This has advantages in enabling sufficient security while preventing overburdening a given transaction with excessive security.  
         [0028]    While the present invention has been described with respect to a limited number of embodiments, those skilled in the art will appreciate numerous modifications and variations therefrom. It is intended that the appended claims cover all such modifications and variations as fall within the true spirit and scope of this present invention.