WO2001084414A1

WO2001084414A1 - System for storing, processing and presenting data

Info

Publication number: WO2001084414A1
Application number: PCT/NL2001/000337
Authority: WO
Inventors: Hendrik Jan Kooij
Original assignee: Blue Polar B.V.
Priority date: 2000-05-02
Filing date: 2001-05-02
Publication date: 2001-11-08
Also published as: AU2001255105A1; NL1015093C2

Abstract

The invention relates to a system for storing, processing and presenting data with the aid of a computer. The system comprises a data memory with at least one table with records which are comprised of fields, data input means and data output means such as a workstation with a graphical screen on which processing screens can appear. The system comprises control means, which can be programmed and/or set by a manager, with a development system, inter alia for defining permissions of users for viewing, processing or deleting data fields on processing screens.

Description

SYSTEM FOR STORING, PROCESSING AND PRESENTING DATA

The invention relates to a system according to the preamble to claim 1. The disadvantage of known systems of this type is that it is very laborious to allocate permissions to users, for example in association with their roles. This must often be done by defining permissions of this type in the system using programming language. Mistakes are thereby often made, particularly in the event of subsequent modifications, as a result of which users sometimes obtain too much or too little permission, which is undesirable.

In order to avoid this disadvantage, the system is designed according to the feature of claim 1. Different permissions can hereby be allocated in a simple manner to a user group and/or users for different records and/or fields. Permissions can thereby be adapted in a simple manner.

In accordance with an improvement, the device is designed according to claim 2. This allows each user, in a simple manner, to be made responsible for the input of his own data, whereby data may possibly be viewed by other users, and whereby, for example, data cannot be modified by other users. In accordance with an improvement, the system is designed according to claim 3. This substantially simplifies the performance and implementation of modifications to the database and the associated processing screens. In accordance with an improvement, the system is designed according to claim 4. This allows the progress of data to be tracked in a simple manner and the permissions to view or modify to be made dependent on the use which is made of the data. In accordance with an improvement, the system is designed according to claim 5. This reliably prevents the system from being accessed by unauthorized parties.

In accordance with an improvement, the system is designed according to claim 6. This allows a user to make use of the system from any location via an Intranet or the Internet.

In accordance with an improvement, the system is designed according to claim 7. This simplifies data input.

In accordance with an improvement, the system is designed according to claim 8. This prevents the data memory from being filled with incomplete and/or unusable data. In accordance with an improvement, the system is designed according to claim 9. This makes the system suitable for users who speak different languages.

The invention is explained below with reference to a number of embodiments and a drawing, in which Figure 1 schematically shows the different components of an information system, and

Figure 2 shows a permission screen for allocating different permissions.

A data memory 1 is connected to a control system 2. The control system 2 allows the data stored in the data memory 1 to be used for a specific application A, such as a time-recording system, a telephone list or a course registration system. The control system 2 also forms part of this application A. For the different applications A, use is made of the data memory 1 which may comprise different compartments and whereby the data can also be used for a plurality of applications. Parts of the data memory 1 are also used exclusively by the control system 2. The data memory 1 is designed in a known manner as a database in which one or more tables with records are incorporated and whereby the records are comprised of fields.

The data which are used can be accessed directly through the use of the control system 2. The data memory 1 and the control system 2 are installed in a known manner on computers, whereby it is irrelevant whether the data memory 1 is located on one computer or the data memory is distributed among various locations on different interconnected computers. The control system 2 is installed on the computer, which is designed as a server and is connected via a network 3 to users 4.

The network 3 may be designed as a fixed network which interconnects computers present at a fixed location. The network 3 can also be designed as the Internet or an Intranet, whereby a user 4 establishes a connection from any given location, for example via a telephone line, to the control system 2. Here, the user 4 makes use of the browser installed on his computer, with which he has access via the network 3 to the control system 2.

There are different types of users 4 of the application A, who all make use of the application A in different ways. Some users 4 send data via the control system 2 to the data memory 1, for example an employee submitting his timesheet. Other users 4 approve specific data, for example a manager who approves an employee's timesheet. As a result of him giving his approval, these data are allocated a different status in the control system 2 and can then be used at a different location in the company, for example for payment of the employee's overtime. There will also be users 4 who will use the data stored in the data memory 1 to generate reports, such as financial reports or, for example, a list containing up-to-date name and address data. When reports are generated, no changes are made to the data. It will be clear that a number of users 4 perform the same tasks in the control system 2 and will use the data from the memory 1 in the same way. Users 4 who do this in the same way form a user group 5.

The application A with the control system 2 is created in the manner described below with a development system 7 which is set up by a manager 6 and which also forms part of the control system 2. The manager 6 carries out, inter alia, an analysis of the required functions and the components of the application A and of the required records, fields and the like. He then processes these data in the development system 7, whereafter the development system 7 defines all the required parameters of the different components in the control system 2 and, for example, designs the different screens which will be used by the users 4. The screens which are used are, for example, input screens which a user 4 uses in order to enter data, output screens on which the data stored in the data memory 1 are displayed for the frequently used processing screens on which data are displayed and on which data can also be entered. Different means can also be used to enter data in different embodiments. Thus, data can be entered by means of a chip card or barcode reader. Data may also be entered in a different manner. Output may also be performed in different ways,' for example in the form of reports with a printer, as messages via an automatic fax or as settings or processing instructions for machinery.

The data memory 1 is set up as a relational database, of a type which is commonly used. A database, of this type usually comprises fields with specific characteristics or definitions, and these fields are grouped into records which form part of tables. The' tables have a specific structure and relationships also exist in many cases between the tables. For use in the application A, tables stored in the data memory 1 can be used and new tables can also be created and stored in the data memory 1. The characteristics of the tables, records and fields are known in the control system 2 and synchronization means are provided to ensure that modifications to the characteristics of the fields and the characteristics of the data memory 1 are known and possibly processed in the various components of the application A, such as input fields, forms, reports and the like.

The characteristics of the fields in the data memory 1 are known in the control system 2. The control system 2 is designed so that a direct link is established between the characteristics of the fields as they are used in the different processing screens and the reports, and as they are defined in the data memory 1. Changes can be made more easily due to this direct linking of the characteristics of the fields. If, for example, it is decided to change a specific text field into a date field, this change is made in the database 1. Since the characteristics of this field, which is used, for example, in ten processing screens and five reports, are also used directly in all screens and reports by the control system 2 or the development system 7 which forms a part thereof, this change is implemented quickly and error-free. Similarly, in a table, if a data record comprising data from a number of fields, for example the name and address data, is expanded with a field in which the e- mail address is included, this field is added to the data memory 1 and all screens and reports in which this record is included are expanded with this field by the control system 2 or the development system 7. The task of the manager .6 is thereby substantially simplified through the use of the development system 7 in settinc up the application A or implementing changes.

In order to enable the progress of data through' the organization also to be defined, an identifier may be added to fields or records, indicating the state that the field or record has attained. A user 4 enters, for example, his time data. As long as he has not approved these data, he is able to modify them. By giving his approval, the user 4 moves the data into a new state. This is defined in a record field designated for this purpose. The manager 6 specifies in the control system that the user 4 concerned may not make further changes in this state. By adding the "state" identifier to fields or records, the different user groups can be allowed to view or process the data in different states. Once approval has been given by the user 4 who entered the data, the manager of this user 4 may, for example, further modify the data before he forwards them. The manager may also add an identifier whereby the data are returned for correction to the user 4 who originated them.

In order to use the application A with a plurality of users 4, the manager 6 has allocated different permissions to different users 4. In the first instance, the users are divided up into different functional user groups (5), each with different permissions for entering, viewing, modifying and/or deleting reports, input screens, records and/or fields. These permissions are mostly dependent on the status, origin and/or provenance of records or fields, and are defined as data linked to records or fields. In the second instance, additional permissions are allocated by the manager 6 to members of a user group 5 for viewing, modifying and/or deleting data in respect of which this user has additional rights. This involves, for example, data relating at least to additional permissions entered by a person himself, but may also relate, in the case of a head of department, to data from his department. In these cases, the members of the same user group 5 who do not have the additional permissions do not have access to these data, unless the whole group has a general permission to view, modify or delete data. The additional permissions may be made dependent on the status, origin and/or provenance of the records or fields.

Given that the definition of permissions for individual users 4 must be carried out carefully and must be easy to check, the development system 7 contains a special input screen which is provided with fields which can be marked in order to define the general permissions of a user group 5, and additional fields which can be marked to define the additional permissions of the members of the user group for data in respect of which they have additional permissions. A table is also provided for each user 4, indicating the characteristics in terms of the status, origin or provenance in respect of which this user 4 has additional permissions. In this way, it is implemented that an employee views and can modify only his own expense claims, or that he can view his own and his colleagues' time accounting, but that he can modify only his own time accounting. Since an input screen is used with fields which must be marked to indicate what the additional permissions are, adaptation or modification of the permissions is simple. The development system 7 transforms the marked fields automatically into tables which are defined in the data memory 1 and which are used for setting up and using the processing screens.

The input system in which the permissions are defined includes columns with the names of the user groups 5, indicating after each user group 5 the input, viewing, restricted viewing, modification, restricted modification, deletion and restricted deletion options. The screen also includes options for entering state- dependent permissions for a user group 5. The permissions may also possibly be surrendered per selected field and also per state. The surrendered permissions are processed by the development system ,_",7- in all reports and input screens. Also, if permissions are modified, the manager 6 can incorporate these in *3? simple manner so that mistakes are avoided. Figure 2 shows an example of a permissions screen. It concerns the permissions for the "ExpenseClaimForm: ExpenseForms" table. This application includes the "Employees", "Managers" and Prototype" user groups. A record includes the "ExpenselD", "FormNumber", "EmployeelD", "BeginDate", "EndDate", and "Status", "StatusHistory" and "LastActionDate" fields. Four designations are included for "Status", i.e. "New", "Send", "Agree" and "NoAgree". After the different user groups (see top left in Figure 2) , columns are included in which permissions can be indicated such as the "View", "ViewPrivate" and "ViewConditions", "EditPrivate" and "EditAllowed-script" columns. Columns for "Delete", "DeletePrivate" and "DeleteAllowed- Script" are also included. If "view" is marked, each member of the group may view the fields, whereas if only "ViewPrivate" is marked, only those members who have filled in the fields may view the fields and, in the case of "viewConditions", a script with conditions for viewing by the group may be included. Corresponding rules apply to "Edit" and "Delete".

Along with the general permissions, specific permissions may also be specified per group, depending on the status (see top right in Figure 2) . In these columns, gray indicates that general permission is allocated, white indicates that no permission has been allocated, and a cross indicates that a permission has been allocated, also to the group or to the member who filled in the field. Permissions can also be indicated per field (see Figure 2, bottom left) and also, permissions per field, depending on the status (see Figure 2, bottom right) . The filling in of the permissions screen begins with the selection of the user group and the selection of the general permission for this group. The general permissions per status are then selected. If necessary, separate permissions are selected per field, possibly depending on status-;,

Everything is then repeated for a subsequent group. ;•

In order to define the identity of a user, a software token can be used which forms part of the data held on the computer of the user 4. A hardware token i.e. a preset calculator which produces a specific output following a specific input, and which includes a key, may possibly be used instead of the aforementioned software token installed on the computer.

Since the connection between the user 4 and the control system 2 can be established via a network 3 such as the Internet, there is the risk that hackers may pose as users, infiltrating and causing damage to the system. In order to prevent this, following login with a user identification, a code comprising, for example, eight digits is sent by the control system 2 to the logged-in user 4. The user 4 has a computing program on his computer which forms part of the software token, to which he has identified himself with a personal identification code. This software token uses a key. In the control software 2, this key is linked to the identity of the user 4. The control software 2 also comprises a computing program which processes the code sent to the user 4 in the same manner with the aid of the key as the software token. The code received from the control system is entered by the user 4 into the software token and the result of the computation is forwarded via the network 3 to the control system 2 and compared with the response received in the control system 2. A constantly changing password is entered by each user by means of the software token. If an incorrect password is entered, the user may re-enter the password a limited number of times. If, after, for example, three attempts, an incorrect password is entered, the connection is interrupted. Hackers are thereby excluded because they have a limited number of opportunities to log in with a constantly changing password.

In internationally-operating companies, it is desirable for the different input screens or reports to be available in a plurality of languages. The texts for the different processing screens are available in a plurality of languages in the control system 2. The processing screen can be set by the user 4 to the language which he requires by clicking in the processing screen on the language which he requires.

During the design of the application A, the manager 6 can specify whether the user is able to choose from a plurality of records for specific fields in an input screen. The input of lists into the data memory 1 is thereby substantially simplified. An example of an input screen of this type for a course- registration system entails the definition in the data memory 1 of the course participants. By entering the repeat function for the name of the course participant, a plurality of participants can be simultaneously selected. The remaining fields are entered and participation on the course is registered for all participants during data storage.

Another option for simplifying data input and improving the quality thereof is the setting by the manager of the "required" option, which indicates that the user 4 is obliged to fill in this field. The creation of incomplete records is thereby prevented.

Claims

PATENT CLAIMS

1. A system for storing, processing and presenting data with the aid of a computer, comprising at least one data memory (1) with at least one table with records which are comprised of fields, input means such as a workstation with a graphical screen for the input of data by users (4), processing of data or deletion of data, output means such as a workstation with a graphical screen for providing users (4) with available data, whereby processing screens can appear on the graphical screen, and control means (2) , which can be programmed and/or set by a manager (6), with a development system (7), inter alia for defining permissions of users for viewing, processing and/or deleting fields with data in processing screens, characterized in that the development system (7) comprises a permissions screen which 'is to be used by the manager (6) with setting facilities for allocation to user groups (5 ) and/or users of different permissions for viewing, ' processing and/or deleting records and/or fields.--'

2. The system as claimed in claim 1, characterized in that the permissions screen comprises means for allocating permissions to a group of users and also additional permissions to the user who has entered the data into a field.

3. The system as claimed in claim 1 or 2, characterized in that the development system (7) comprises means for allocating to the fields in the processing screens the same characteristics as the fields in the data memory (1) corresponding to these fields.

4. The system as claimed in claim 1, 2 or 3, characterized in that the development system (7) comprises means for defining the possible states of a field or record in a table, and the permissions screen comprises means for allocating different permissions to different states.

5. The system as claimed in claim 1, 2, 3 or 4, characterized in that the development system (7) comprises means for storing a key for each user and means for incorporating checking means in the control means (2) for checking the result calculated by the user with the aid of his key on the basis of a code visible on a processing screen.

6. The system as claimed in one of the previous claims, characterized in that control means can generate processing screens which can be retrieved with a browser.

7. The system as claimed in one of the previous claims, characterized in that the control means can generate processing screens from, which data can be entered from one processing screen into a plurality of records and/or tables.

8. The system according to one of the previous claims, characterized in that the control means can generate processing screens with, one or more mandatory fields.

9. The system according to one of the previous claims, characterized in that the control means can generate processing screens with texts in a user-definable language.