U.S. patent application number 14/740881 was filed with the patent office on 2015-12-10 for method and system for easily and securely managing multiple keys used to have access to multiple computing resources.
The applicant listed for this patent is International Business Machines Corporation. Invention is credited to Frederic Bauchot, Jean-Luc Collet, Francois X. Drouet, Gerard Marmigere.
Application Number | 20150356067 14/740881 |
Document ID | / |
Family ID | 37591232 |
Filed Date | 2015-12-10 |
United States Patent
Application |
20150356067 |
Kind Code |
A1 |
Bauchot; Frederic ; et
al. |
December 10, 2015 |
METHOD AND SYSTEM FOR EASILY AND SECURELY MANAGING MULTIPLE KEYS
USED TO HAVE ACCESS TO MULTIPLE COMPUTING RESOURCES
Abstract
The present invention is directed to a system, method and
computer program for easily and securely managing multiple keys on
a computer, each key being used to access one or a plurality of
computing resources. The method comprises the steps of receiving a
command for selecting a key among one or plurality of keys, each
key comprising one or a plurality of key fields; receiving a
command for activating a computing resource corresponding to the
selected key in order to have access to the computing resource;
retrieving and displaying on a computer screen, the one or
plurality of key fields associated with the selected key;
displaying on the computer screen one or a plurality of input
fields, each input field being used to enter the content of an
appropriate key field associated with the key selected to access
the activated computing resource; passing, in response to an action
of a pointing device on a displayed key field, the content of the
key field in an appropriate input field of the activated computing
resource; and having access to the activated computing resource
when all key fields of the selected key have been passed to the
appropriate input fields.
Inventors: |
Bauchot; Frederic;
(Saint-Jeannet, FR) ; Collet; Jean-Luc; (La Gaude,
FR) ; Drouet; Francois X.; (La Gaude, FR) ;
Marmigere; Gerard; (DRAP, FR) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
International Business Machines Corporation |
Amonk |
NY |
US |
|
|
Family ID: |
37591232 |
Appl. No.: |
14/740881 |
Filed: |
June 16, 2015 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11451678 |
Jun 13, 2006 |
9088551 |
|
|
14740881 |
|
|
|
|
Current U.S.
Class: |
715/224 |
Current CPC
Class: |
G06F 3/0486 20130101;
G06F 3/04842 20130101; G06F 3/04817 20130101; G06F 3/0482 20130101;
G06F 21/10 20130101; G06F 40/177 20200101; H04L 63/062 20130101;
H04L 63/06 20130101; G06F 40/174 20200101 |
International
Class: |
G06F 17/24 20060101
G06F017/24; G06F 3/0486 20060101 G06F003/0486; G06F 3/0484 20060101
G06F003/0484; G06F 3/0481 20060101 G06F003/0481; G06F 3/0482
20060101 G06F003/0482 |
Foreign Application Data
Date |
Code |
Application Number |
Jun 29, 2005 |
EP |
05300530.2 |
Claims
1. A method for securely managing multiple keys on a computer
system, each key being used to access one or more computing
resources, each of the keys including a plurality of key fields,
and each of the key fields having a name and a value, said method
comprising: storing the multiple keys in a key file, each of the
keys including a plurality of key fields, including storing the key
fields of each of the multiple keys in a key table; receiving a
command from a user to access the key file; the computer system
displaying the key file on a display screen of the computer system,
including displaying a list of the multiple keys in the key file;
the user selecting one of the keys in the key file, said one of the
keys being used to access an associated one of the computing
resources; displaying the selected key on the display screen,
including displaying the key fields of the selected key; displaying
on the display screen a plurality of input fields for receiving the
values of the key fields of the selected key; identifying on the
display screen each of the input fields with one of the names of
the key fields of the selected key; the user interacting with the
display of the selected key and the display of the plurality of
input fields, using a graphical user interface, to pass the value
of each of the key fields of said selected key, one value at a
time, from the key table to said input fields, including entering
the value for each of the key fields into the input field
identified on the display screen with the name of said each key
field; and giving the user access to the associated one of the
computing resources when the values of all the key fields of the
selected key have been passed to the input fields.
2. The method according to claim 1, wherein the user interacting
with the displays on the display screen, comprises: dragging the
value of one of the key fields of the selected key to one of the
input fields.
3. The method according to claim 1, wherein the user interacting
with the displays on the display screen, comprises: updating a
pointing device icon displayed on the computer screen according to
the remaining fields that are still to be passed before the
computing resource can be accessed.
4. The method according to claim 1, wherein the user interacting
with the displays on the display screen, comprises: updating a
pointing device icon displayed on the computer screen according to
the passed key field.
5. The method according to claim 1, wherein the user interacting
with the displays on the display screen, comprises: updating a
pointing device icon displayed on the computer screen according to
the key fields that have already been passed.
6. The method according to claim 1, wherein the receiving a command
from a user, comprises: displaying on the computer screen one or
plurality of the multiple keys.
7. The method according to claim 1, further comprising associating
with each key field of a key: means for identifying the key field;
a content to paste in an input field; and an indication specifying
that the content to paste must only be pasted in a protected input
field, each input field of a computing resource being defined as
either protected or unprotected, the content pasted in a protected
input field being hidden from the user.
8. The method according to claim 1, further comprising: recording
one or a plurality of the multiple keys in a key ring file.
9. The method according to claim 1, further comprising associating
with each key; means for identifying and reaching one or a
plurality of computing resources.
10. The method according to claim 1, further comprising: retrieving
a secret private key under which information recorded in the key
file is encrypted; and encrypting and decrypting said key file
using said secrete private key.
11. The method according to claim 1, wherein the steps of the
method are transparent for said one or more computing
resources.
12. A system for securely managing multiple keys on a computer
system, each of said keys being used to access one or more
computing resources, each of the keys including a plurality of key
fields, and each of the fey fields having a name and a value, said
system comprising: a storage device on the computer system for
storing the multiple keys in a key file, including storing the key
fields of each of the multiple keys in a key table; the computer
system receiving a command from a user to access the key file; the
computer system displaying the key file on a display screen of the
computer system, including displaying a list of the multiple keys
in the key file; the computer system receiving input from the user
selecting one of the keys in the key file, said one of the keys
being used to access an associated one of the computing resources;
the computer system displaying on the display screen the selected
key, including displaying the key fields of the selected key; the
computer system displaying on the display screen a plurality of
input fields for receiving the values of the key fields of the
selected key; and identifying on the display screen each of the
input fields with one of the names of the key fields of the
selected key; the computer system receiving input from the user, by
the user interacting with the display of the listing of said
selected key and the display of the plurality of input fields using
a graphical user interface, to pass the value of each of the key
fields of said selected key, one value at a time, from the key
table to said input fields including entering the value for each of
the key fields into the input field identified on the display
screen with the name of said each key field; and the computer
system giving the user access to the associated one of the
computing resources when the values of all the key fields of the
selected key have been passed to the input fields.
13. The system according to claim 12, wherein the input from the
user includes: input for dragging one of the key fields of the
selected key to one of the input fields.
14. A program storage device including a tangible storage medium
readable by machine, tangibly embodying a program of instructions
executable by the machine to perform a method for securely managing
multiple keys on a computer system, each of said keys being used to
access one or more computing resources, each of the keys including
a plurality of key fields, and each of the key fields having a name
and a value, the method comprising: storing the multiple keys in a
key file, including storing the key fields of each of the multiple
keys in a key table; receiving a command from a user to access the
key file; displaying the key file on a display screen of the
computer system, including displaying a list of the multiple keys
in the key file; receiving from the user input for selecting one of
the keys in the key file, said one of the keys being used to access
an associated one of the computing resources; displaying on the
display screen the selected key, including displaying the key
fields of the selected key; displaying on the display screen a
plurality of input fields for receiving the values of the key
fields of the selected key; identifying on the display screen each
of the input fields with one of the names of the key fields of the
selected key; receiving input from the user, by the user
interacting with the display of the listing of said selected key
and the display of the plurality of input fields using a graphical
user interface, to pass the value of each of the key fields of said
selected key, one value at a time, from the key table to said input
fields including entering the value for each of the key fields into
the input field identified on the display screen with the name of
said each key field; and giving the user access to the associated
one of the computing resources when the values of all the key
fields of the selected key have been passed to the input
fields.
15. The program storage device according to claim 14, wherein the
receiving input from the user, by the user interacting with the
display of the listing of said selected key and the display of the
plurality of input fields using a graphical user interface,
comprises: receiving input from the user for dragging one of the
key fields of the selected key to one of the input fields.
Description
CROSS REFERENCE TO RELATED APPLICATION
[0001] This application is a continuation of U.S. patent
application Ser. No. 11/451,678, filed Jun. 13, 2006 the entire
content and disclosure of which is hereby incorporated herein by
reference.
BACKGROUND OF THE INVENTION
[0002] 1. Field of the Invention
[0003] The present invention is directed to security in the field
of data processing, and in particular to a method, system and
computer program for easily and securely managing multiple keys
used to have access to one or a plurality of computing
resources.
[0004] 2. Background Art
[0005] To reach sensible pieces of information, users must first be
authorized to have access to the applications, web pages, or
databases containing this sensible information. In fact, sensible
information can be in any kind of information repository,
application or computing resource. Such information repositories or
computing resources, regardless of their nature and implementation,
will be referred to herein as "DataSets". The access to a DataSet
is usually protected to avoid unauthorized users to retrieve
information that they are not allowed to reach. The protection of
information and the control of its access are typically achieved by
means of user identifiers (UserId) and passwords. In some cases,
the protection and control means are not limited to UserId and
password, and may also comprise other fields like an account
identifier (AccountId), or a server identifier (ServerId), etc . .
. All these pieces of information required to get access to a given
DataSet will be referred to herein as the "Key", regardless of the
number of individual fields (such as UserId, or password, or
AccountId, etc . . . ).
[0006] The number of Keys that typical users must own (either for
business or personal needs) is such that the observance by these
users of the password management policies (like the rules password
must comply with, or the frequency for updating password) lacks
efficiency, safety and friendliness. Indeed all users have to
record one way or the other, multiple Keys. The record of these
Keys rends them either unsecured or difficult to locate. Typical
examples of this situation are:
[0007] To record all the Keys on a piece of paper. This turns the
Key update into a poorly convenient task. This requires that this
piece of paper is always available, and this is by far unsafe, as
Keys are obviously not ciphered when they are hand written on a
piece of paper.
[0008] To record all the Keys within a text file recorded on the
computer from where the DataSet are accessed. Key updates are
becoming less cumbersome as they consist in editing the file, and
the availability of the Keys is ensured. Nevertheless this creates
a security breach as an individual getting access to the computer
where the file is recorded would automatically get access to all
the Keys this file records.
[0009] To record all the Keys within a DataSet, the access of which
is controlled by a Key. This solves to some extent the risk issue
described above, but creates a "chicken and egg" situation because
the access to the Keys requires a Key.
[0010] Furthermore, assuming that the user accepts to afford the
above limitations and deficiencies, once a Key has been accessed,
it must then be properly specified by the user to the target
DataSet. This is a task prone to error as the elements constituting
the Key must be specified in the right fields (do not swap the
UserId and the AccountId for instance), and must be entered without
spelling error (everybody has already once given a password with
the Caps Lock key on . . . ). If the maximum number of retries for
specifying the Key is reached, then the access can simply be lost,
potentially putting the user in a tricky situation if the access to
the DataSet is required for instance for critical business
needs.
[0011] Put in other words, the problem is to manage a set of keys
that can open doors with the following concerns:
[0012] Which is the right key for opening this door?
[0013] How to use this key for opening the door?
[0014] Where did I put the key?
[0015] Is the key strongly secured?
SUMMARY OF THE INVENTION
[0016] An object of the present invention is to safely and securely
record multiple keys, each Key comprising one or a plurality of
fields, each Key being used to have access to one or a plurality of
controlled computing resources.
[0017] Another object of the invention is to exchange in a
user-friendly way, one or a plurality of fields constituting a Key
with a computing resource.
[0018] Another object of the invention is to exchange in a user
friendly way, one or a plurality of fields constituting a Key with
a computing resource by means of a "copy-and-multiple-paste"
operation (by clicking the pointing device each time it overlays on
of the target entry fields).
[0019] Another object of the invention is to exchange in a
user-friendly way, one or a plurality of fields constituting a Key
with a computing resource, by dynamically updating the pointing
device according to the currently exchanged field.
[0020] Another object of the invention is to exchange in a user
friendly way, one or a plurality of fields constituting a Key with
a computing resource, by selectively navigating within the set of
fields constituting the Key (by scrolling among the set of
fields).
[0021] Another object of the invention is to manage Keys using
means for creating, updating or deleting keys.
[0022] Another object of the invention is to avoid any modification
of computing resources (applications running on the computer
system).
[0023] The present invention is directed to a method and system for
easily and securely managing multiple keys on a computer, each key
being used to access one or a plurality of computing resources. The
method comprises the steps of receiving a command for selecting a
key among one or plurality of keys, each key comprising one or a
plurality of key fields; receiving a command for activating a
computing resource corresponding to the selected key in order to
have access to said computing resource; retrieving and displaying
on a computer screen, the one or plurality of key fields associated
with the selected key; displaying on the computer screen one or a
plurality of input fields, each input field being used to enter the
content of an appropriate key field associated with the key
selected to access the activated computing resource; passing, in
response to an action of a pointing device on a displayed key
field, the content of the key field in an appropriate input field
of the activated computing resource; and having access to the
activated computing resource when all key fields of the selected
key have been passed to the appropriate input fields.
[0024] The foregoing, together with other objects, features, and
advantages of this invention can be better appreciated with
reference to the following specification, claims and drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
[0025] The novel and inventive features believed characteristics of
the invention are set forth in the appended claims. The invention
itself, however, as well as a preferred mode of use, further
objects and advantages thereof, will best be understood by
reference to the following detailed description of an illustrative
detailed embodiment when read in conjunction with the accompanying
drawings, wherein:
[0026] FIG. 1 shows the different components of the KeyRing
application according to the present invention.
[0027] FIG. 2 shows the KeyRing table according to the present
invention.
[0028] FIG. 3A shows the dialog box displayed on the computer
screen when the user decides to launch the KeyRing application for
the creation of a new KeyRing File or for the opening or saving of
an existing KeyRing File according to the present invention.
[0029] FIG. 3B shows the dialog box displayed on the computer
screen in order to retrieve the secret private Key under which all
the information recorded in the KeyRing File will be encrypted
according to the present invention.
[0030] FIG. 3C shows when the secrete private Key has been
successfully specified, the dialog box displayed on the computer
screen according to the present invention, with the Key labeled as
"Delphion" in the list box.
[0031] FIG. 3D shows the dialog box displayed on the computer
screen aimed to assist the user to update the current definition of
the fields constituting the selected Key according to the present
invention.
[0032] FIG. 3E shows the pop-up window displayed on the computer
screen listing the different Keys defined within the current
KeyRing File according to the present invention.
[0033] FIG. 3F shows the screen corresponding to the step where the
user has already dropped the first field "Jean-Luc" onto the first
input area aimed to host a first name according to the present
invention.
[0034] FIG. 3G shows the screen corresponding to the step where the
user has dropped the second field "COLLET" onto the second input
area aimed to host a last name according to the present
invention.
[0035] FIG. 4A shows an example of execution according to the
present invention with a Key comprising two fields.
[0036] FIG. 4B shows the same screen as in FIG. 4A after pasting
the first value according to the present invention.
[0037] FIG. 5 is a flow chart of the method of passing Keys
according to the present invention,
PREFERRED EMBODIMENT OF THE INVENTION
[0038] The following description is presented to enable one of
ordinary skill in the art to make and use the invention and is
provided in the context of a patent application and its
requirements. Various modifications to the preferred embodiment and
the generic principles and features described herein will be
readily apparent to those skilled in the art. Thus, the present
invention is not intended to be limited to the embodiment shown but
is to be accorded the widest scope consistent with the principles
and features described herein.
[0039] The present invention is based on a virtual "KeyRing" which
allows:
[0040] To safely and securely record multiple Keys.
[0041] To easily manage Keys (creation/change/deletion of
Keys).
[0042] To establish an association between a DataSet and a Key
(this association may be a 1-to-N association as a given Key may
give access to multiple DataSets).
[0043] To easily and error free pass the Key from the KeyRing to
the DataSet.
[0044] To define a Key as a set of individual fields.
[0045] To identify, and potentially select, each field of a Key
through a dynamic display of the pointing device icon, when passed
to the DataSet
[0046] The solution described hereafter is considered as a
preferred embodiment of the present invention. This preferred
solution relies on the Microsoft Windows operating system
family.
[0047] In the preferred embodiment of the present invention
described herein, it will assumed that any Key comprises up to 8
different fields, but no more. This limitation does not limit the
scope of the present invention, as any alternate implementation
with more than 8 fields per Key would be a straightforward
extension of the preferred embodiment.
KeyRing Application
[0048] The core of the present invention is the concept of a
KeyRing File, which is used to record multiple Keys associated with
DataSets. This file is ciphered as it records very sensitive
information, and it can only be accessed by means of relevant
KeyRing processes through dedicated interfaces. This overall
solution concept is further described in the following FIG. 1,
which positions the different components comprising the KeyRing
application 100.
[0049] The KeyRing User Interface Manager 101 is the process
interfacing the user for interacting with the other components of
the KeyRing solution. In the preferred embodiment of the present
invention, this KeyRing User Interface Manager complies with the
GUI standards as defined in the Microsoft Windows environment. The
Key Update Manager 102 is the component in charge of managing any
update in the definition of the Keys as recorded within the current
KeyRing File. This component interacts on one hand with the KeyRing
User Interface Manager 101 for interfacing with the user, and on
the other hand, with the KeyRing File Access Manager 105 for read
& write operations onto the KeyRing File 106.
[0050] The KeyRing File Manager 103 is the component in charge of
managing the creation and the use of the KeyRing Files 106. This
component interacts on one hand with the KeyRing User Interface
Manager 101 for interfacing with the user, and on the other hand
with the KeyRing File Access Manager 105 for read & write
operations onto the KeyRing File 106. The KeyRing Manager 104 is
the component in charge of passing Key fields to selected DataSets.
This component interacts on one hand with the KeyRing User
Interface Manager 101 for interacting with the user, and on the
other hand with the KeyRing File Access Manager 105 for read
operations onto the KeyRing File 106. The KeyRing File Access
Manager 105 is the component in charge of accessing the KeyRing
File 106, as required by the above components: Key Update Manager
102, or KeyRing File Manager 103, or KeyRing Manager 104. The
KeyRing File Access Manager 105 interacts directly with the KeyRing
File 106, either for file read operation, or for file write
operation, or for file creation operation, or for file load
operation, or for file save operation. As the KeyRing File 106 is
encrypted through an AES (Advanced Encryption Standard) based
algorithm, the KeyRing File Access Manager 105 is in charge of the
file corresponding encryption and decryption operations.
[0051] The KeyRing File 106 is the repository where Keys are
recorded. KeyRing Files 106 are created under the control of the
KeyRing File Manager 103, whereas the KeyRing File records
corresponding to individual Keys are managed under the control of
the Key Update Manager 102. Finally Key fields, as recorded in the
KeyRing File 106, are passed to the DataSets under the control of
the KeyRing Manager 104. These three components 102, 103 and 104
use the services of the KeyRing File Access Manager 105 for
interacting with the KeyRing File 106.
KeyRing Table
[0052] The structure of the KeyRing File 106 is depicted in FIG. 2.
This file is structured as a two dimension KeyRing Table 200 (KRT
for short) comprising one or a plurality of records 220, each
record 220 corresponding to a given Key, and comprising the
following elements: the "Path Process Owner" element 201, the
"Label" element 202, and the "Field1 to Field4" elements 203 to
206. The "Path Process Owner" element 201 specifies the name of the
DataSet associated with the Key. For the cases where the DataSet
corresponds to an executable application, then this element 201 is
the path of this application (for instance "c\program
files\Notes\Notes.exe"). For the cases where the DataSet is reached
through a Web browser, then this element 201 is the URL identifying
the DataSet (for instance "www.delphimcom"). The "Label" element
202, allows the user to define a nickname for the DataSet
associated with the Key.
[0053] The "Field1" to "Field4" elements 203 to 206 are used to
record each field constituting the Key defined by the record 220.
Each Field element is comprised of 3 sub-fields:
[0054] The sub-field "Name" 230 which comprises the nickname
associated with the Key (value displayed together with the mouse
cursor).
[0055] The sub-field "Key" 231 which comprises the value of the Key
field to be pasted on the Dataset entry field.
[0056] The sub-field "P" 232 which indicates whether the value is
protected "1" or not "0". If the value is protected, then the value
can/must only be pasted in a protected field.
Generic Process Workflow
[0057] The following description gives flow is an example of one
possible scenario illustrating the different operations available
with the KeyRing solution, according to a preferred embodiment of
the present invention.
Launching the KeyRing
[0058] The KeyRing generic process starts when the user decides to
launch the KeyRing application. This leads to invoke the KeyRing
User Interface Manager 101, which displays on the computer screen
the dialog box corresponding to figure FIG. 3A. This dialog box
window comprises the following objects: A menu bar with an icon 301
invoking the KeyRing File Manager 103 for the creation of a new
KeyRing File 106, an icon 302 invoking the KeyRing File Manager 103
for opening of an existing KeyRing File 106, an icon 303 invoking
the KeyRing File Manager 103 for saving of the currently opened
KeyRing File 106, an icon 304 invoking the KeyRing File Manager 103
for saving of the current KeyRing File 106 under a new name ("Save
As" operation), an icon 305 invoking KeyRing options, and an icon
306 invoking an on-line Help tool.
[0059] The dialog box also comprises an information field 307 where
the user can find hints and tips for using the KeyRing system, and
1A gold Key Icon 308 that the user must drag for passing the fields
of the current Key to the target DataSet, under the control of the
KeyRing Manager 104. 1A list box 309 where the user can select one
of the Keys defined as part of the current KeyRing File 106. A
push-button "Edit Key" 310 invoking, when clicked, the Key Update
Manager 102 for changing the definition of the existing key whose
"Label" element 202 appears in the list box 309. 1A push-button
"Remove Key" 311 invoking, when clicked, the Key Update Manager 102
for deleting in the current KRT 200, the existing key whose "Label"
element 202 appears in the list box 309. A push-button "Add Key"
312 invoking, when clicked, the Key Update Manager 102 for
introducing a new Key in the current KRT 200 recorded in the
KeyRing File 106. A check box 313 used to specify if the KeyRing
dialog box 300 must be kept or not in the foreground of the window
display.
Loading a KeyRing File
[0060] This operation is triggered by clicking with the pointing
device (e.g. the mouse) on the second icon 302 on the left side of
the menu available on the top of the KeyRing user interface dialog
box as shown on FIG. 3A. This allows an existing KeyRing File 106
to open through conventional file system navigation windows.
Alternatively the user can also create a new KeyRing File 106 by
clicking on the left most icon 301 on the menu bar available on the
top of the KeyRing user interface dialog box. In both cases, the
KeyRing File Manager 103 takes control for calling first the
KeyRing File Access Manager 105 in order to open an existing or
create a new KeyRing File 106, and second the KeyRing User
Interface Manager 101 for displaying the dialog box shown in FIG.
3B, in order to retrieve the secret private Key under which will be
encrypted all the information recorded in the KeyRing File 106,
according to the structure described in the KRT 200. When the
secret private Key has been successfully specified, then the
current KeyRing File 106 becomes available; with all the Keys it
records, so that further KeyRing operations can take place. At this
point the KeyRing User interface dialog window takes the form
illustrated on FIG. 3C where one can see that a Key labeled as
"Delphion" appears in the list box 309 ("Delphion" is a trademark
of Thomson Scientific Inc. in certain countries).
Editing an Existing Key
[0061] As previously said, this operation is triggered by clicking
on the icon 310, and invokes the Key Update Manager 102. This leads
to open another dialog box 320, as illustrated in FIG. 3D, aimed to
assist the user to update the current definition of the fields
constituting the selected key. This dialog box 320 includes several
means (entry fields, push-buttons, list box, etc . . . ) which will
not be further detailed here as their usage is obvious to a person
used to deal with windows based computer systems. When the user
will close the dialog box 320 without canceling any done change,
the KRT 200 table, recorded in the current KeyRing File 106, will
be updated by reflecting the new definition in the record 220
corresponding to the selected Key.
Adding a New Key
[0062] As previously said, this operation is triggered by clicking
on the icon 312, and invokes the Key Update Manager 102. This leads
to open a dialog box identical to the dialog box 320, as
illustrated in FIG. 3D, but where all the entry fields are left
void. This dialog box 320 includes several means (entry fields,
push-buttons, list box, etc . . . ). The Nickname field 321 is the
name associated with the Key. This nickname is displayed on the
mouse cursor indicating the type of value to be pasted. The Key
field 322 is the value to be pasted. The Checkbox 323 indicates, if
checked, that the value specified in the Key field 322 is protected
and may be not be pasted in an unprotected field for security
reason. The buttons Up 326 and Down 327 allow the user to reorder
if necessary the couple nickname/key. When the user will close the
dialog box 320 without canceling the new Key definition, the KRT
200 table, recorded in the current KeyRing File 106, will be
updated by introducing a new record 220 corresponding to the new
Key definition.
Removing an Existing Key
[0063] As previously said, this operation is triggered by clicking
on the icon 311, and invokes the Key Update Manager 102. This leads
to update the KRT 200 table, recorded in the current KeyRing File
106, by removing the record 220 corresponding to the selected
Key.
Passing a Key to a DataSet
[0064] This operation must be easily performed to allow the user to
take full advantage of the present invention. In a preferred
embodiment of the present invention, a combined mouse and keyboard
short cut is defined to activate the KeyRing application 100. When
a given application is active, if the user hits altogether the F12
key and the right mouse button, the KeyRing application 100 gets
active, so that the KeyRing User Interface Manager 101 displays a
pop-up windows listing the different Keys defined within the
current KeyRing File 106. This is illustrated in the FIG. 3E where
the active application is a web browser represented by the window
330. When the (F12+Right mouse button) short cut is hit, the pop-up
window 331 is displayed, and the user can for instance select the
Key 332 identified by the label "JLC Identity Infos".
[0065] Then the user can very easily pass the different fields
defined as part of the selected Key to the target DataSet. This is
performed by first clicking on the selected Key 332 with the left
button of the pointing device, and without releasing this left
button, dropping one after the other each field of the Key by
clicking the right button of the pointing device onto the
destination input area. At each step of this operation, the mouse
icon takes a different form to indicate to the user the current
stage of the key field dropping process. This operation is
illustrated in FIG. 3F and FIG. 3G, where the form of the mouse
icon shows how many remaining fields are still to be passed to the
target DataSet.
[0066] The first FIG. 3F corresponds to the step where the user has
already dropped the first field "Jean-Luc" onto the first input
area 333 aimed to host a first name. At this stage the mouse icon
334 takes the form of a triple Key, meaning that there are still
three remaining fields not yet passed from the Key.
[0067] The FIG. 3G corresponds to the step where the user has
dropped the second field "COLLET" onto the second input area 335
aimed to host a last name. At this stage the mouse icon 336 takes
the form of a double Key, meaning that there are still two
remaining fields not yet passed from the key. The last two Key
fields are then dropped similarly onto the last two entry areas 337
and 338.
Another Example of Execution
[0068] FIGS. 4A and 4B show a sample execution with a Key of 2
fields, and where the mouse icon form is changed in order to
display a short text specifying the nature of the current Key
field. In FIG. 4A, a prompt is displayed 400 to logon the
"Delphion" server, mouse pointer 410 display the nickname
associated with the value which is pasted when the mouse key is
pressed (in our case "logon").
[0069] FIG. 4B shows the same screen after pasting the first value.
The logon which is a non protected value is displayed in User Name
field 470, while the nickname associated to the next value is
displayed with the mouse cursor 480 (In our case "password")
KeyRing Method
[0070] FIG. 5 illustrates the method according to the present
invention, for passing the plurality of fields associated to a Key,
onto the plurality of input areas associated with a DataSet. At
step 501, the method starts by launching the KeyRing application,
typically as the result of a user trigger such as hitting
altogether the F12 keyboard key and the right mouse button. At step
502, the pop up window 331 is displayed, showing all the different
Keys defined within the KeyRing table 200. At step 503, the user
selects a Key by using conventional means, such as the click with
the left mouse button on one entry within the pop-up window 331. At
step 504, the KeyRing table 200 is accessed for retrieving the
attributes of the Key selected at the previous step, including the
number of associated fields. At step 505, the local variable
"current field" is set equal to the first field of the selected
Key. Furthermore the mouse pointer form is updated to reflect the
stage of the process. In a preferred embodiment of the present
invention, this icon takes a form specifying the number of
remaining fields to be passed (see 334 on FIG. 3F and 336 on FIG.
3G).
[0071] At step 506, the KeyRing application waits for a user event
specifying that the "current field" must be passed to the DataSet.
In a preferred embodiment of the present invention, this event
corresponds to the click on the right mouse button, while the left
mouse button remained pressed. At step 507, a user event is
detected for passing the "current field" of the selected Key. At
step 508, the KeyRing passes the "current field" onto the DataSet
input area pointed by the mouse pointer. At step 509, a test is
performed to check if the "current field" corresponds to the last
field of the selected Key, as recorded in the KeyRing table 200. If
it is the case, then control is given to step 510; otherwise
control is given to step 512. At step 510, the pop-up window 331 is
closed. At step 511, the KeyRing applications ends. At step 512,
the "current field" local variable is set equal to the next field
associated to the selected Key, as recorded in the KeyRing table
200. Then control is given to step 506.
[0072] While the invention has been particularly shown and
described with reference to a preferred embodiment, it will be
understood that various changes in form and detail may be made
therein without departing from the spirit, and scope of the
invention.
* * * * *