Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1999-11-29
2004-08-03
Robinson, Greta (Department: 2177)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000, C715S252000, C715S252000
Reexamination Certificate
active
06772156
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to computer implemented systems and methods for creating a security-enhanced report containing information useful to multiple users. More specifically, the invention relates to systems and methods for generating and displaying a table of content for the security-enhanced report.
2. Discussion of Related Art
Many enterprises and organizations today often deal with large amounts of data in the form of reports. The number of reports in a particular organization can vary from dozens to thousands of various types and to levels of employees. It is often the case that some employees in an enterprise are authorized to view certain data while other employees, typically those at a higher level, can see more data than those who report to them. Security with respect to which employees are authorized to see certain data has become an increasingly complex task to manage. For example, executive employees can see more types of data items than other employees in the corporation but the rules as to who can see what are constantly changing. This is made more complex by the high employee turnover rate at many large corporations.
Generally, techniques presently in use to address security needs at large organizations involve two ways of dealing with data security and reports. One method widely used can be referred to generally as a code-based method in which the format and contents of the report are essentially determined through a custom-written program in a language such as Cobol or some other language typically used in large data processing environments. A traditional way to implement “page security” with paper reports, for example, is to print one large report. Sections of pages in the report contain visible headers that indicate who receives that section. An employee goes through the report and “bursts” it into separate printed sections. These sections are then sent to the particular users. Historically, it was cheaper to have a person perform the bursting than to have it done by the computer. One advantage of a code-based technique is that there is significant flexibility with respect to formatting and determining what data will be in a particular report. However, such code-based reports require specialized knowledge of the custom-written program in the particular programming language. This lack of flexibility with respect to making updates and general maintenance of the program is a significant constraint.
Another technique used to generate reports having security features can be referred to as the user-interface (UI) driven process. With UI-based report generation, users essentially fill-in blanks on the screen to generate a particular report. The advantage to using a UI-based report generator is that it is generally easy for a user to generate a report. But, to keep the UI easy to use, most tools omit advanced features such as security. The user simply tells the program where certain text or data should be placed or formatted in a particular report. However, the drawbacks are significant in that such UI-based report generators do not have the flexibility or features to allow for different types of reports or different formatting because the user interface itself is preprogrammed.
As stated above, security with respect to which users can see particular portions of data is a particularly complex issue in large companies. In order to address the security issue, in some situations a company would typically run a single printed report and perform the physical bursting of the pages as described above. For example, a company would execute a report executable for the East, West, and Central regions and have different security rules for each report. Such report executables would typically be stored on a report server and would be executed periodically throughout the day. Essentially, different reports and files would be generated and security features would be attached to each one.
In many cases, a significant issue with running multiple reports in a given day is ensuring that the correct data is contained in each report and that the large set of reports are managed properly. It is not unusual for the number of reports to reach the hundreds or thousands in a single day. This can lead to complex maintenance issues and create an error-prone environment. This is especially true if security rules change for any of the reports or if the time a particular report should run has to be changed. In addition, running a large volume of report executables every day also requires high utilization of an organization's computer resources.
Another practice used in implementing security based on what individual users can see is creating “views” of a database by modifying a query with appropriate restrictions on what fields and tables, for example, a user can see. These restrictions are often implemented with specific SQL statements in a data retrieval instruction. A report based on a particular view in which the report only contains data in that view is created. A user's access to a report is then restricted to that view or a subset of that view if more restrictions are in place. Defining views of a large report is one technique used in solving the security issue.
However, there are several drawbacks with using database views for report security. One disadvantage is that the database for which a view is created has to be accessed each time the user tries to view a report. Alternatively, a database subset must be created for each possible secure view of the data (i.e. report) resulting in a proliferation of persistent objects in the system, eventually matching the number of possible reports. Another drawback is that the calculations and formatting instructions for a view (i.e. report) have to be done each time the user views the report and cannot be cached in advance. Yet another disadvantage of using views to create security-enhanced reports is that the user is not able to view control break or summary information from rows that they are not permitted to view on an individual level. For example, a manager should be allowed to see summarized sales figures from other departments while not allowed to see the detailed sales information from those departments. Using views to create reports, the manager is not able to see even the non-restricted summarized sales figures.
Therefore, it would be desirable to minimize computer resource utilization and reduce the complexities of managing report generation by having one large report with enhanced security features. It would desirable that such a report have different security rules apply to different categories or groups of data printed in the report. It would also be desirable to have the user believe that he or she is receiving an individual, customized report. In other words, it would be desirable that the security and logical “bursting” of the report be transparent to the user.
SUMMARY OF THE INVENTION
According to the present invention, methods, apparatus, and computer program products are disclosed for generating and viewing an electronic report having security features that allow for “virtual bursting” of the report for multiple users. A single report having multiple pages is generated such that each or some of the pages have security tags that are compared to a security identifier list of a particular user that acts as a security clearance for that user. Through this comparison, a subset of pages from the report is formed which makes up a “report” from the user's point of view that contains only data the user is allowed to see.
In one aspect of the present invention, a method for creating a report having security based on content of the data contained in the report is described. A data row from a data source which is to be “printed” or displayed in the report is retrieved. The data source can be a flat file, a relational database, or other data storage component. It is then determined whether data in the data row causes a level or group break in the report. If the data r
Nierenberg Nicolas C.
Rogers Paul A.
Actuate Corporation
Beyer Weaver & Thomas LLP
Doods, Jr. Harold E.
Robinson Greta
LandOfFree
Method and apparatus for creating and displaying a table of... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for creating and displaying a table of..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for creating and displaying a table of... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3305562