Classifications

• • G—PHYSICS
  • G07—CHECKING-DEVICES
  • G07F—COIN-FREED OR LIKE APPARATUS
  • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
  • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
  • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
  • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
  • G06F21/31—User authentication
  • G06F21/33—User authentication using certificates
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
  • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/38—Payment protocols; Details thereof
  • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
  • G06Q20/401—Transaction verification
  • G06Q20/4014—Identity check for transactions
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/38—Payment protocols; Details thereof
  • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
  • G06Q20/401—Transaction verification
  • G06Q20/4014—Identity check for transactions
  • G06Q20/40145—Biometric identity checks
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/2113—Multi-level security, e.g. mandatory access control

Definitions

• the present invention relates to an authentication system and method for a user accessing an account.
• the present invention provides an authentication system in which a record is established with a subset of information about an entity.
• the subset of information is insufficient to identify the user.
• the record characterizes the information into a number of categories and selects questions regarding the available information from those categories in a predetermined sequence. Questions are forwarded to the user and the answers monitored to determine whether or not the required confidence of authentication is obtained. A decision to authenticate or reject a user is made on the basis of the results obtained.
• the record includes questions for which only the user can know the answer and this category of questions is included within the questions presented and the information updated for subsequent use.
• a method of authenticating a user of an account at a service system using an authentication system comprises: after the user successfully completes an initial sign-on procedure with the service system, providing an authentication question to the user from the authentication system; receiving and analyzing an answer from the user to the question; if the answer provides a sufficient level of confidence in the authenticity of the user, then providing a sign-on randomly generated password to the user and to the service system for use for the user to submit the random password to the service system which submit the random password to the authentication system for the user to access the account.
• the method may further automatically submit the sign-on random password from the user to the service system for verification by the verification system; and upon completion of verification, allow the user access to the account.
• the method may further have the authentication system storing account information related to the user obtained from the service system and the answer received from the user; and also, the answer for the question may be distinct from the account information.
• the system may not authenticate the user, h the method, for one of the questions, its expected answer may be a given answer provided by the user.
• the given answer may be stored with the expected answers and it may become an expected answer for the question.
• the sign-on password may be generated utilizing an answer from a question.
• a system for authenticating a user of an account comprises: an authentication system; a service system having a plurality of accounts and users for the plurality of accounts; and a set of security identification tags for the users.
• the authentication system may provide an authentication question or set of questions to the user. Also, after the user provides an answer to the authentication question, the authentication system receives and analyzes an answer from the user to the question.
• the authentication system provides a sign-on randomly generated password to the user and to the service system for use for the user service system to submit the password to the service system authentication system.
• the authentication system receives and analyzes the random password from the service system. Thereafter, if the random password matches that stored by the authentication system, the user is permitted to access the account.
• the authentication system may automatically submit the sign-on password from the user to the service system for verification by the authentication system. Also, upon completion of verification, the authentication system may automatically allow the user to access the account.
• Figure 1 is a schematic representation of an electronic transaction system relating to an embodiment of the invention
• Figure 2 is a block diagram of an authentication system of the transaction system of Fig. 1;
• Figure 3 is a flowchart showing operation of the transaction system of Figure 1;
• Figure 4 is a GUI showing a sign-on screen generated by the system of Figure 1 ;
• Figure 5 is a representation of a record relating to a user of the system of Figure 1;
• Figure 6 is a flowchart showing the generation of authentication information using the record of Figure 3.
• an electronic transaction system generally indicated at 10 includes client 12 and service system 14, which for the purposes of illustration is a financial institution.
• the service provider may be any on-line service provider offering services to account holders.
• Client 12 is connected through a communication network 16 to financial institution 14 and can request transactions and exchange information over the communication network.
• the communication network is provided by an Internet connection and network, but other networks may be provided, such as modem communication links, as are known in the art.
• Client 12 is also connected through a communication system 18, which follows networking protocols of the Internet, to authentication system 20.
• Authentication system 20 is also connected to the financial institution through a link 22, which may also follow Internet network protocols. As such, client 12, financial institution 14 and authentication system 20 are able to communicate with each other, separately and collectively.
• Authentication system 20 provides part of the authentication process for the user. It includes a database 24 representing records of users of financial institution 14 and its users. Authentication system 20 may be implemented in at least two forms. A first form is a model where it implemented as a local sub-system within client 12. A second form is an enterprise model wherein it is a separate system from client 12. In the second form, additional financial institutions may be in communication with authentication system 20 through other links. For the remainder of the description, authentication system 20 is described as being an enterprise model. [0028] For each user having an account at financial institution 14, it has a record in database 26 containing biographical particulars of the user, a list of his associated financial accounts, and an account access code, a password associated with the access code, as well as other data.
• the user at client 12 must provide financial institution 14 with the appropriate account access code and password. Upon full completion of the authentication process, the user is granted access to his associated financial accounts, allowing him to view their balances, initiate transfer of funds, pay bills and perform other processes which would ordinarily be made by the user in person at a branch of financial institution 14.
• each of client 12, financial institution 14 and authentication system 20 operates a computing device which each has a microprocessor (not shown), memory (not shown) such as RAM, secondary storage, such as a disk drive and data input/output modules (not shown) providing access to communication links which enable each element to operate software, firmware and hardware-based applications associated with the embodiment.
• a microprocessor not shown
• memory not shown
• secondary storage such as a disk drive
• data input/output modules not shown
• Client application 202 operates on client 12 and is composed of several modules embodied in software. Client application 202 collectively provides separate interfaces to applications operating on authentication system 20 and financial institution 14. In other embodiments, separate applications can be provided in client 12 for each interface. Details regarding application 202 focus on the initial log-in and verification steps occurring amongst client 12, financial institution 14 and authentication system 20.
• Interface 204A in client application 202 generally handles interactions between the client 12 and financial institution 14.
• Interface 204B is typically located at financial institution 14 and generally handles interactions between the financial institution 14 and authentication system 20.
• Each interface provides a series of sessions, streams for the system amongst the entities.
• GUIs related screens and windows are provided to the user, with each screen and window providing either a request for data from the user or a notification of an event to the user.
• the screens and windows are provided as a series of web pages to the user.
• Each interface 204 comprises of a series of screens and windows 206A and 206B and Application Program Interfaces AP!) 208A and 208B which controls presentation of the screens and windows to the user.
• All interfaces operate to provide a set of threads which collectively provide a seamless flow of windows and screens to the user, appearing that a single sign-on process is being executed.
• server processes 210A and 210B process requests and data and communicate with corresponding interfaces 208A and 208B.
• This API-process interface follows interfacing techniques l ⁇ iown in the art.
• process 210A communicates with database 24 and pipes/shared memory 214.
• Query processing engine 212 is also provided which controls operation of a second step of authentication, described in further detail below.
• Query processing engine 212 also has access to token database 214 for storage of temporary data relating to a sign-on session. It is noted that for the local sub-system, one or more of process 210B, query processing engine 212, pipes memory 214 and database 24 may be more closely associated with financial institution 14.
• Authentication system 20 also provides a separate API to financial institution 14.
• Client application 202 communicates through its API to financial institution 14 when communications are required between financial service 14 and authentication system 20 to its API-process interface.
• Financial institution 14 has a database 26 (Fig. 1) to store data relating to queries and temporary storage to store data before it is provided to database 214.
• a user having a financial account at financial institution 14 wishes to access the financial account at client 12, the embodiment provides a three step process to authenticate the user.
• the process is shown generally at 300.
• the first step, shown at 302 involves an mitial log-on of a user at client 12 to financial institution 14.
• the second step, shown at 304 involves authenticating the user by authentication system 20.
• the third step, shown at 306, involves distribution and checking of a confirmation randomly generated password amongst authentication system 20, client 12 and financial institution 14.
• successful completion of the three steps must occur within a timed session.
• a session may be tens of seconds long, e.g. 90 seconds or some other timed interval which is sufficiently long to allow the user and the system to complete the sign-on process. If the session expires prior to successful completion of the steps, the logon attempt is failed.
• Each step is described in turn.
• a user at client 12 accesses a web-site hosted by financial institution 14 which, upon navigation by the user to the log-in screen for financial institution 14, provides him with log-in screen 400 which prompts him to provide his access account code and a password in area 402 and submit the information to financial institution 14.
• user will input the requested information to client 12 via a keyboard and submit the data for transmission to financial institution 14.
• the data is provided as session information which provides the data, the I.P. address of client 12 and a time stamp to financial institution 14.
• session information which provides the data, the I.P. address of client 12 and a time stamp to financial institution 14.
• client 12 compares the provided information to data in its database for the account access code. If the information matches, then the authentication process continues to the second step of authentication. If the information does not match either through a password or an account code mismatch, then client 12 is provided with a rejection notice generated either at client 12 or financial institution 14. At such time, user at client 12 may be invited to try to log-on again.
• authentication system defines a set of security identification numbers (SIDs) which are used to track users of accounts for all of the financial institutions tracked by the system. SIDs are each uniquely defined to define unique users. A set of SIDs are defined by authentication system 20 and then it allocates a set of SIDs to each financial institution 14. The financial institution 14 is allowed to allocate an SID from its set to a particular user associated with a particular account offered by the financial institution 14. The financial institution 14 keeps a record of the allocation of SIDs to its individual users and provides the allocation information to authentication system 20.
• SIDs security identification numbers
• Authentication system 20 receives the SID and performs a combination of shuffling and encryption of the SID based on a preset algorithm to convert the SID to another form of the SID which is used by authentication system 20 to associate the SID with the proper account information stored by the authentication system. This conversion is done to prevent unauthorized association of data to actual account owners.
• authentication system 20 has a centralized core of information which it can use to evaluate the authenticity of a purported user against his assigned identification information which is stored at authentication system 20.
• authentication system needs to communicate with client 12.
• financial institution 14 provides an authentication signal to authentication system 20 containing the session information including the SID which is either extracted from the response provided by the user or generated from the responses provide by the user at the log-on screen.
• authentication system 20 extracts the I.P address of the user and the time stamp of from the session information.
• the I.P. address provides a known destination address for communications through link 18 with the unauthenticated user and the timestamp provides an initial starting time for the log-in session for the user.
• the user is provided with a question page generated by authentication system 20. Once the user has answered the questions, the answers are sent back to the authentication system 20 to be verified against data stored in shared memory 214. If the answers are verified, the answer to the learned question is stored in database 24 and a random password is generated by authentication system 20 and passed back to the user and to the financial institution where it is passed to the authentication system 20 for verification after which the user is permitted access if the random password matches that stored in shared memory 214.
• tracking signals and information may be provided to enable authentication system 20 to identify client 12.
• authentication system 20 In order to isolate usage of the account access code from other elements in the system, authentication system 20 identifies information to be provided separately to each of client 12 and financial institution 14 utilizing an internal access code associated with the user, hi particular, authentication system 20 has a mapping of internal account access codes to the access codes in database 24 containing account access codes of financial institution 14 mapped against the internal access codes, biographical information relating to the user.
• system 20 For the second step of authentication, system 20 provides a series of questions to the user in a timed session through section 404 of GUI 400 and requires that the user provide enough correct answers to enough questions to obtain a level of confidence that trie user has personal information which cannot be mimicked or spoofed by an impostor.
• Authentication system 20 poses each question to the user through a session on link 18 between authentication system 20 and client 12 using the I.P. address information derived from the authorization signal received from financial institution 14.
• the query process 212 (Fig. 2) controls selection and invocation of questions for the second step.
• query process 212 When initiated to identify a set of questions, query process 212 reads shared memory/pipes 214 and grabs an SID. Each SID has an associated financial institution and rules governing associated parameters for questions for it. Based on the SID, query process 212 reads the rules for the financial institution site that the SID is associated with and identifies or generates a predetermined question set. Typically the set comprises three questions; however more or less questions may be used.
• the questions are stored in the authentication system database and server process 210A selects one set randomly when a user logs in.
• the rules will outline what types of questions to ask, the frequency of any specific questions based on the history.
• Questions are posed from system 20 to client 12 and based on an analysis of answers provided to the questions, system 20 establishes a level of confidence of the authenticity of the user at client 12.
• the level of confidence indicates either that the user is authenticated or is an interloper and provides a decision to accept or reject client 12.
• the confidence score is increased. If a question is not answered correctly, the confidence score is decreased. Once a minimum number of questions have been answered, if the confidence score surpasses a set confidence level, then the user is deemed to have answered enough of the questions correctly and the second step is successfully completed.
• One confidence tlireshold requires that all questions are answered correctly.
• Another threshold requires that one question deemed significant question is answered conectly.
• Other thresholds quantitative thresholds may be defined. If the initial answers do not pass the required the level of confidence, the query engine may provide one or more sets of questions to the user. Subsequently, if enough answers are conect such that the level of confidence is surpassed, then the second step of authentication is passed.
• the method may either terminate the second step, marking it as unsuccessful.
• the results of the second step are conveyed over the link 22 to the financial institution, which then continues the transaction or advised the user that the transaction cannot be completed.
• the questions are categorized into two broad categories: known and learned.
• Known questions have expected conect answers which are identified from infonnation about the user provided from records from financial institution 14. Learned questions initially have no expected conect answer associated with them. When a learned question is provided to the user, what ever initial given answer the user provides is stored by system 20 as the conect answer for that question. If that question is posed again to the user, the expected answer is the initial answer.
• the user is provided with a series of individual questions sequentially. Typically, three questions or more are presented, with one question from each type provided.
• questions are provided in defined sets.
• database 24 contains sets of questions which may be presented to the user. Table A illustrates three exemplary sets of questions stored in database 24.
• the sets of questions may have different numbers of questions, and that some of the questions may be similar or identical to questions in other sets.
• authentication system 20 generates a confidence score which can be matched against a threshold in a manner as described above.
• system 20 first identifies a type of questions to pose to the user, e.g. either l ⁇ iown questions or learned questions. The specific question of that type is then selected from the record 32 and a further selection is then made as to the type of answer to be associated with the question. The type of answer is rotated and includes the option of a conect answer being present, the conect answer not being present and the conect answer not being known.
• the multiple choice answers are populated where either the answer is present or the conect answer is not present. If, however, no answer has been received then an alternative branch is followed.
• authentication system 20 has a query processing engine 212 which selects a method of presenting questions to the user, identifies a question set for that selected method, identifies an expected answer set for the questions and processes the provided answers from the user.
• questions are either known or learned.
• step 1 in section 302 has the user providing his username and password to financial institution 14 for verification against its records.
• step 2 in section 304 the financial institution 14 verifies the username and password provided with authentication system 20.
• the financial institution After authentication system software is implemented into the financial institution, the financial institution then requires the user to provide a random password to the financial institution to be verified to the authentication system 20. hi order for the user to acquire the random password, the user must successfully answer a series of questions presented by the authentication system 20.
• the user's session information, time and SID are sent to API 208B then passed to process 210B which starts a spawn of the authentication software which will handle this user session.
• Process 210A stores the SID in shared memory to be retrieved later by query process 212 for further processing.
• Process 210A validates the session information, then logs the session to the log database 24, then pulls the questions and stored answers from the database 24 into the spawn process.
• Process 210A then passes the questions to the back to the user via API 208 A. The user answers the question and the answers are passed back to process 210A via API 208 A and verified with the answers stored in the process 210A spawn.
• process 210A If the answer is verified as being conect, process 210A generates a random password, stores the random password in shared memory 214, and passes the random password to the user and financial institution via API 208 A which is then sent to process 210B for verification to the shared memory 214. If the random password matches along with a valid time on the random password, the user is permitted access. Finally in step 3 in section 306, authentication system 20 verifies the password, then generates a separate final password, based on input from the user provided in stage 2, which is used as a final automatic password provision and acceptance routine between client 12 and financial institution 14.
• the processing engine may cycle through the provided methods or utilize one preset method. Once a method is selected, sets of questions for the method may be identified using techniques described above. [0058] Referring to Fig. 6, to identify answers for known questions, expected answers are generated using a question template for the question and client information relating the user associated with client 12.
• the client information includes records 30 maintained by financial institution 14, including biographical details of the user (e.g., first name, last name, phone, address, username, and password). This information is maintained securely within the financial institution and is sufficient to fully identify the user. Included in the record 30 is a personal identification number 34 that identifies a common record within financial institution 14 and authentication system 20.
• First field 36 contains known information which is fixed infonnation from a known source, such as information in the bank record 30. Thus, the identification of first name, last name, phone number, and city is included in the known information but is incomplete in that it is compiled from a subset of the information contained in the bank record.
• the known information is infonnation that may be known by somebody other than the particular client 12.
• a second field of information, identified at 38, is known history. This known history information 38 includes questions with answers that are derived from activities of the individual in the site being accessed. The answers are specific to the site and may be known by the individual and someone other than the individual. For example, the value of the last transaction performed on the site may be an example of known history.
• third field 40 stores a set of questions whose answers would only be known by the user and which are not part of the biographical data present in bank record 30. Examples of such questions may relate to a personal preference of the user, such as his favourite colour. Alternatively, such questions may relate to additional personal biographical data, such as the maiden name of the mother of the user.
• the learned history type is subdivided into learned history for which the questions have been answered by the individual identified at 42 and questions which have yet to be answered identified at 44. For a learned question which has never been posed to the user, the expected answer is the first answer provided by the user; for a learned question which already has been provided to the user, the expected answer has is the first answer provided by the user.
• the records in authentication system 20 do not singularly contain sufficient information to positively uniquely identify any user associated with any account. Accordingly, privacy of information of the data of users stored in authentication system 20 is maintained, as it is not possible to positively identify a user by using simply only the records in authentication system 20. Further, the exchange of confidential information between the financial institution and the service is limited.
• the query engine provides a selection of possible answers to the user with each question in the form of radio buttons and input fields presented in the GUI of the session.
• questions are designed to require a single digit or character answer in a multiple choice format.
• GUI 400 Fig. 4
• the user When the user is presented with the question, he simply selects the radio button associated with the conect letter for the question utilizing a mouse input or a keystroke. It will be appreciated that using a mouse input reduces the ability for snooping answers by an unauthorized source.
• client 12 submits it to query processing engine 212 for processing against the expected answer. Assuming that a multiple choice question is to be provided to client 12, the questions are transmitted through the communication link 18 to client 12 and the answers received from client 12 are monitored. The received answers are compared with the expected answers and if a conect answer is provided, then the level of confidence is increased.
• the answer provided is then added to the record into the learned history category 42.
• the entry will only occur when a degree of confidence has been established that client 12 is authenticated, although such questions can be posed at any time.
• the third step of authentication provides a password passing routine between client 12, authentication system 20 and financial institution 14. While the session is still being monitored for expiry of its timed session, a sign-on password is generated by authentication system 20 and is separately provided to both client 12 and financial institution 14 for the user to submit the password to financial institution as a final sign-on procedure.
• the sign-on password is unique to every instantiation of the authentication process by all users.
• a first part of the password passing routine has financial institution 14 sending a request to client 12 for a password in a web page.
• the password is provided by authentication system 20 to client 12 and authentication system 20 also causes automatic population of a response containing the password in the web page and transmission of the response is provided to authentication system 20.
• the third step provides a further layer of security is provided as a hacker or unauthorized person or routine deters conect guessing or snooping of a password.
• the password is a pseudo-randomly generated alphanumeric string.
• the password is generated using a combination of criteria as seeds, which may include portions of questions, session information, SID, random information, and other relative infonnation.
• An answer provided in the second step of authentication may also be used as a key in generating the password, hi other embodiments a password is selected from a pre-existing list of passwords securely stored by authentication system 20. Once the password is generated, it is stored by authentication system in token database 214 (Fig. 2).
• the password may be generated from a combination of information related to, but not limited to one or more of the user's particular session information, host name, timestamp and SID. Once selected, the information can be segmented into pieces and particular pieces may be selected, then the selected pieces may be encrypted and parsed to define a random password for the user. It will be appreciated that other password generation algorithms may be used. Algorithms may change based on various implementation environments.
• the password is automatically passed from the authentication system 20 to the log-in screen 300 at area 304 (Fig. 3), which then sends the password to the financial institution 14 for further verification and processing.
• the duration of the session should be set in order to provide sufficient time to safely complete the authentication process, but provide as small an excess time as possible, in order to limit the ability of hackers to infiltrate and subvert the system in during the life of the session.
• financial institution 14 receives the password, it checks the password against what is provided by authentication system 20. hi the automatic mode, the password is verified and the user is provided access to its accounts on financial institution 14.
• system and method of the embodiment provide a continuous session for the user for the entire sign-on process.
• the user is provided with a one set of screens which appear to be originating from one source for the initial sign-on, question and answer, verification and password passing processes.
• the described invention and its embodiments provides a method of verifying the presence of an authorized user of an account without storing information that may be used to determine the user's identity.
• the embodiment uses personal preferences or items retained in a user's memory to assist in verifying the identity of the user.

Landscapes

• Engineering & Computer Science (AREA)
• Business, Economics & Management (AREA)
• Theoretical Computer Science (AREA)
• Accounting & Taxation (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Computer Security & Cryptography (AREA)
• Strategic Management (AREA)
• General Business, Economics & Management (AREA)
• Finance (AREA)
• Microelectronics & Electronic Packaging (AREA)
• Computer Networks & Wireless Communication (AREA)
• Computer Hardware Design (AREA)
• Software Systems (AREA)
• General Engineering & Computer Science (AREA)
• Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Applications Claiming Priority (3)

Publications (1)

Family

ID=34975957

Family Applications (1)

Country Status (2)

Families Citing this family (4)

Family Cites Families (4)

• 2005
  • 2005-03-15 EP EP05727243A patent/EP1738518A1/de not_active Withdrawn
  • 2005-03-15 WO PCT/CA2005/000385 patent/WO2005088901A1/en active Application Filing

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events