WO2010111683A2

WO2010111683A2 - Customized secured user-data interface and storage system and method

Info

Publication number: WO2010111683A2
Application number: PCT/US2010/028964
Authority: WO
Inventors: Michael Shen; Jennifer Shen
Original assignee: Michael Shen; Jennifer Shen
Priority date: 2009-03-26
Filing date: 2010-03-26
Publication date: 2010-09-30
Also published as: WO2010111683A3

Abstract

A system for communicating customer personal data between organizations. Sensitive customer data is stored locally inside a Host (for example, a hospital or bank) and user's can access the sensitive customer data using Embedded Software Components (ESCs). Inside the Host, an ESC runs on a local computer where a Host user accesses SUDIS web services. The SUDIS web services may need to access the private information from the Host (not from outside SUDIS System Database) when the private information has to be displayed on the web pages. The ESC can retrieve the private information from a local database and insert the private information on the web pages.

Description

Customized Secured User-Data Interface And Storage

System And Method

[0001] This application claims the benefit of Application Serial No. 61/163,809 filed March 26, 2009 which is herein incorporated by reference in its entirety.

I. Technical Field

[0002] This invention relates to the field of data security and privacy. More particularly, the system relates to specific user-data management interface and customer sensitive data storage and access.

II. Background of the Invention

[0003] Information access and privacy in a computer system is important for any business in the information age. Currently, customer privacy is mainly restricted on the access from the user side and the information protected on the computer system side. However, there is no system and systematic methods to manage interfaces between the users and information stored in computer systems, and separate storage and access for customer sensitive data (SD) or customer non-sensitive data (NSD). [0004] (1 ). Lack of detailed security measures on specific data access. There is no customized flexible security method for a user to access number of customers' info. Such as in healthcare, if certain patient records were lost, the organizations, either healthcare provider or technical vendor, can face significant penalty and public criticism. Actually, if more than 500 patient records lost, it will be handled by the secretary of federal HHS. For another example, certain sensitive information, such as positive HIV test results, cannot be restricted for access without patient permission in presently known electronic medical systems, while remaining flexible and convenient to specific clinicians to access for care purposes at the same time.

[0005] (2). Lack of systematic approaches to anonymize customer sensitive data. For example, if a researcher performs a study analysis, it is difficult to access population based data which are anonymized without patient identity. It is particularly difficult for vendors to provide service on a customer system, such as, Electronic Medical Records (EMR) systems to access data without patient identity. Specifically, the challenge for the current web based systems is to store and display customer (such as a patient, or bank customer) SD inside of an organization, such as hospital, but restrict the access to patient identity information (only clinical info) outside of the hospital. However, in order to display the private information for an authenticated user, the web server, which is located outside of the organization, must often retrieve the private information and display it on local monitors. Solving these web-based security and privacy problems can save organizations significant costs since the web-based system is much cheaper to build and maintain compared with traditional client based system, which has much higher cost of on-site technical service and administration.

III. Summary of the Invention

[0006] The invention provides a method of managing customer information privacy and security by (A) providing a user-data interface defined by a matrix and (B) storing customer sensitive data separate from customer non-sensitive data . [0007] In one embodiment, the invention provides a method for securely managing and communicating customer personal data records including sensitive data and non- sensitive data over a global information network. In the method, a web page receives customer data including customer sensitive data and customer non-sensitive data from a user. The web page transmits the customer sensitive data to a module installed on a computer located at a secure host site responsive to a command initiated by the user. The module stores the customer sensitive data in a secure host database. The module generates a customer id corresponding to the customer sensitive data responsive to storage of the customer sensitive data and stores the customer id in the host database such that the customer id is correlated with the customer sensitive data. The web page transmits the customer id generated by the module and the customer non-sensitive data to a web server remotely inside of the secure data center to review. [0008] In another embodiment, the invention provides a method for managing and displaying customer personal data in a graphical user interface. In the method, a web page receives a request from a user to view customer data. The web page checks the user authorization level to determine whether the user has privileges to access the customer data. The web page receives sensitive customer data from a host database located at a secure host site responsive to the user request for where the user has a first level of authorization (a level sufficiently high to view customer sensitive data). The web page also receives non-sensitive data from a web server database responsive to the user request for a user having a first level of authorization. The web page then displays the sensitive data and non-sensitive data to the user having a first level of authorization. The web page receives non-sensitive data from a web server database responsive to a user request from a user having a second level of authorization. The web page displays only the non-sensitive data responsive to the user having a second level of authorization. IV. Brief Description of the Drawings

[0009] Figure 1 illustrates a system diagram in accordance with the present invention.

[0010] Figure 2 depicts a block diagram of the functional modules of the present invention.

[0011] Figure 3 depicts an access control matrix.

[0012] Figures 4 illustrate an exemplary process for creating data groups for the access control matrix.

[0013] Figure 5 shows an exemplary process for creating an access control matrix.

[0014] Figure 6 depicts an exemplary process for managing an access control matrix.

[0015] Figure 7 shows a block diagram of functional system components in accordance with an embodiment of the invention.

[0016] Figure 8 illustrates an exemplary embodiment of the display of customer data and the system that stores customer data.

[0017] Figures 9 and 10 depict message exchanges between system components in accordance with the invention.

V. Detailed Description of the Drawings

OVERVIEW

[0018] The Secured User-Data Interface and Storage (SUDIS) system of the present invention offers a customizable and flexible system to provide access to distributed sensitive and non-sensitive customer data by authorized system users over the Internet. Users may only access data from an authorized computer according to the user's authorization category. For example, certain users may be restricted as to the number of customer records they may access, the duration of access and the specific data fields that they may access. In addition, certain computers may be likewise restricted. In some embodiments, the access history of each user may be recorded, tracked and monitored. In this way the SUDIS system provides security for personal customer data, while providing convenience and low cost maintenance of a web based system.

[0019] As illustrated in Figure 2, the UDI system contains two major functional modules: Interface Matrix module and Data Identification and De-identification module. The Interface Matrix module is used to establish user-data access matrix which defines user's access rights to the data. As described below, a system administrator uses this module to setup various kinds of data access rights within the access matrix. The access matrix defines different access rights for various data users. Based on that matrix, this module enforces data access in a way that the access can only be given to the users who have certain access permissions.

[0020] Data De-identification and Re-identification module is a user-data interface tool for handling two groups of data: customer sensitive data (SD) and customer non- sensitive data (NSD). Customer sensitive data contains data items relating to customer privacy such as name, social security number, credit card number, etc. NSD includes data that does not relate to customer privacy. To protect customer privacy, the Data Identification and De-identification module has a De-identification function which separates SD and NSD data. This module also has a Re-identification function. That function can re-build customer data by linking SD with NSD data for every customer, this linked data can only be reviewed by users having a high level of authorization, such as a patient's physician. On the other hand, customer NSD can be reviewed by users with low level authorization, such as research physicians for the purpose of analyzing patient clinical info, for example. Interface Matrix module

[0021] A data system contains various customer data items which may be used by a variety of users. Different data users should be given certain rights to access different groups of data items. As mentioned before, the Interface Matrix module is used to establish a user-data access matrix which defines the user's data access rights.

1.1 Access Matrix

[0022] Access Matrix is a 2D functional matrix of data access rights, as shown in Fig. 3. The X axis of the matrix is User Groups axis and the Y axis of the matrix is Data Groups axis. The Data Groups axis includes all the data groups in the systems. The User Groups dimension contains all of the user groups who can access the data that comprises the data groups. Accordingly, the Access Matrix defines each user groups' access rights to each data group. The Access Matrix comprises an MxN array of cells. Each cell includes the access right for the user group of the X axis to the data group of the Y axis. For example, the cell Ci₂ specifies the access right for the user group 1 to the data group 2.

[0023] The access rights specified in the cell contain one or more access right items. Exemplary access right items include the following: Access time periods -- defined as the starting and ending time period the data group can be accessed by the users inside the user group;

Record counts limits - the number of data records that can be accessed by the users inside the user group. The record count limit may be set based on a time period, e.g., a single day or the entire period of access.

Record counts limits for individual user in the group: how many data records can be accessed by one user. The record count limit may be set by time period, e.g., one call, one day or the entire period of access.

Edit Privileges: read only, write, or delete.

[0024] The Interface Matrix module performs four functions: 1 ) establishes data groups for different data content, 2) defines user groups, 3) specifies data access rights using the access matrix, and 4) enforces customer privacy based on the access matrix.

1.2 Setup Data Groups

[0025] One customer data system, such as Electronic Medical Record (EMR) system or financial management system contains many data items. Different data items may have different privacy requirements. For example, social security numbers and credit card numbers are among the type of data which should never be shared with unauthorized users or transmitted to unauthorized locations outside of the host organization. Patient age and gender may be categorized as the lower level privacy which may be given to organizations unaffiliated with the host organization such as research organizations.

[0026] System administrators are responsible for establishing the data groups. This system provides a software tool to divide whole data system into multiple data groups based on their privacy requirements. Two types of computer data storages are supported: computer databases and computer data files. The data groups are setup using the following steps, as shown in Fig. 4:

• Name a data group.

• Specify data items for the data group. For database storage, the data items are specified using the following sub steps:

• Specify a database server (computer name or network IP address). A customer may choose all or a subset of the databases inside this database server for inclusion into this data group. If not all, go to the next sub-step.

• Specify a database. A customer may choose all or a subset of the database tables inside this database for inclusion into this data group. If not, go to the next sub-step.

• Specify database tables: A customer may choose all or a subset of the table columns inside this database table for inclusion into this data group. If not, go to the next sub-step. • Specify columns of database tables. A customer may choose all or a subset of the data fields inside this database column for inclusion into this data group. If not, go to the next sub-step.

• Specific data fields inside tables and columns if the data values match with a specific value or value range.

• For data file storage, the data items are specified using the following sub steps:

• Specify a computer (Computer name or network IP address).

• Specify a folder. A customer may choose all or a subset of the files inside this folder for inclusion into this data group. If not, go to the next sub-step.

• Specify a file. A customer may choose all or subset of the content inside this file for inclusion into this data group. If not, go to the next sub-step.

• Specific sections, if any, inside files if the section names match with a specified value or value range.

1.3 Define User Groups

[0027] System administrators are responsible for setting up the user groups. This system provides a computer software tool to categorize data users into multiple user groups based on privacy requirements. The software tool allows a system administrator to name a user group, add users to the group, or delete users from the group.

1.4 Specify Access Rights

[0028] After the data groups and user groups are created, system administrators may specify users' access rights by setting up the cells inside the Access Matrix, as shown in Fig. 5.

[0029] After the initial setup, system administrators can also update the Access Matrix by one or more actions below:

• Modify an existing cell in order to change the access right for a specific user group on a specific data group

• Define a new Data Group

• Define a new User Group

• Setup the new cells for those data groups and user groups

1.5 Enforce Customer Privacy

[0030] In this system, customer data privacy is enforced based on the access matrix specified in the previous section. The privacy enforcement contains the following steps, as shown in Fig. 10.

[0031] The first step of enforcing customer data privacy is to verify user account for different data users. In this system, to access SD, a user must login using valid user name and password. The user account is set up by a system administrator. System administrators are allowed to specify whether a single user or multiple users are required to login. For example, system administrators may demand that, to login successfully, three users have to type in correct user names and password at the same login operation. System administrators are allowed to specify from which computer

(network IP address) the user can log in the account.

[0032] The second step of enforcing customer data privacy is to check data access rights. After the access rights are defined into the Access Matrix, this system only gives data access rights which have been defined in the Access Matrix.

[0033] In this system, a customer may enable built-in system privacy log to trace privacy related activities. The following log functions may be selected.

• User account creation

• Who creates a user account, including system administrator names and passwords

• From which computer (network IP address) the system administrator logged in

• When the user account is created

• Why the user account is created

• Which user rights have been given to the account, including time durations, number of records, data groups, and access types

• User account access

• When the user logged in;

• From which computer (network IP address) the user logged in

• How many times of login failures on each login operation

• Which data records the user accessed (data selection statements)

• An explanation about the purpose of data access on each login

2. Data De-identification and Re-identification module

[0034] This system supports data storages shared over different network locations. A customer may need to send original data from one location to another location for certain kinds of data sharing. Some privacy levels of data should not be sent. Those data items have to be de-identified before the data is sent out to protect data privacy.

The implementation of data transformation contains the following steps:

• Define a data transformation group. Inside this group, all the data items are transferred using the same destination, same authentication, and same algorithm;

• Specify network destination (computer name or network IP address);

• Choose data items to be sent. The data selection operation is similar to the data selection for data encryption. • Choose data items to be de-identified. The data selection operation is similar to the data selection for data encryption.

• Select when the data item will be transferred.

• Specify authentication (username and password) before data transferred.

2.1 An algorithm of securing customer data privacy on a web system

[0035] Fig. 1 shows an exemplary system in accordance with the invention. The system includes the following components:

• one SUDIS Web Server

• one SUDIS Server Database

• distributed SUDIS Service Modules with ESCs

• multiple SUDIS Host Managers, one for each Host

• multiple SUDIS Related Agents, one for each Affiliate company (doing related business with a Host company)

• multiple SUDIS Local Databases, one for each SUDIS Host Manager or Related Agent

2.1.1 Functionalities of system component

[0036] The SUDIS Web Server is a web server (using PHP Java, or similar web programming) which provides different kinds of SUDIS System web services, such as customer registration to a Host, customer activities inside the Host, and customer process analysis. The web server runs outside of the Host. Therefore, the host computer server (software and/or hardware) can be secured. (If the Server runs at a Host site, people there may easily access or change the PHP/HTML source code). The server can be also conveniently serviced and maintained at a central remote site. In keeping with an aspect of the invention, the web server will not store customer SD, such as customer name. In the web server, a customer will be identified by a Customer ID (CID). In this way, the customer information is secured from the web software company as well as it travels through the Internet. [0037] SUDIS Web Server has the following functions:

• providing full web services, from customer creation to customer checkout (for example, from patient registration to medical reimbursement);

• calling the SUDIS ESC functions as needed to set up communications between web browser and SUDIS Local Databases.

[0038] The SUDIS System has Embedded Software Components (ESCs, such as ActiveX Controls). Each of ESCs runs on a computer terminal inside a company (such as a Host or Affiliate). Customer private information may only be stored inside a local database (SUDIS Local Database) inside the company. The ESC provides functions for the SUDIS web page to access customer sensitive data stored inside the Host or

Affiliate company through a web browser.

[0039] SUDIS ESC has the following functions:

• Save customer SD into the SUDIS Host Database inside a Host. This function will be called when a new customer is created using SUDIS web page.

• Update customer SD into the SUDIS Host Database. This function will be called when customer data is updated using SUDIS web page.

• Switch the status of customer SD from active to inactive inside the SUDIS Host Database. This function will be called when a customer is deleted using SUDIS web page.

• Retrieve customer SD from SUDIS Local Database based on a Customer ID and pass the SD to a SUDIS web page displayed inside a Host or Affiliate.

[0040] In order to access customer sensitive data using a web browser, the ESC must be installed on a local computer where the web browser runs. One Host or Affiliate company may have multiple SUDIS ESCs which run on different computers inside of the company. Fig. 4 gives an example of how customer sensitive and non- sensitive (de-identified) data is stored inside a SUDIS System and displayed on a web page.

[0041] The SUDIS System allows Affiliate companies to access its web services by logging into SUDIS site. An Affiliate company may view customers who had filed or share their information (such as patient claims) with them. The SUDIS ESCs help the web users inside an Affiliate company to view customer SD which is not stored on the

SUDIS Web Server as well.

[0042] Generally, a Host company needs to file its customer information with its

Affiliate companies. The Host Company has the right to choose its affiliations to share their common customer sensitive data.

[0043] To forward customer SD to an Affiliate company, a Host company may set up a data sharing process using a SUDIS Host Manager. One Host company has only one

Host Manager.

[0044] A Host Manager is an application which runs on a machine located inside a

Host company. The Host Manager allows a Host company's administrator to choose:

1. which Affiliate companies the SD will be shared with,

2. which items of the SD will be shared, and

3. when the data will be sent out through an Internet connection.

[0045] SUDIS Host Manager has a graphic user interface which enables three groups of functions: • sensitive data management o Define customer SD - which data items should be de-identified o Search/list customers from the SUDIS Host Database o View/update customer SD o Add/delete customer SD o Export selected customer data (for example, export to MS Excel file) o Save settings o Write and view audit log

• affiliation process management o Set up which Affiliate companies the SD will be shared with o Set up how to share: methods (only choice for now: direct network connection), IP, port, username, password, etc. o Define/select customers o Specify which items of the SD will be shared o Set up a time plan: when to send the sharing data o launch service applications manually or automatically o Monitor data transaction o Save settings o Write and view audit log

• analysis report management o Select analysis reports: which report(s) o Define analysis filters o Set monthly or weekly report (time schedules, email addresses, file folders) o Set one time analysis report o Run analysis report o Send de-identified data if needed o Select/view analysis reports o Save settings o Write and view audit log

[0046] A SUDIS Affiliation Agent is an application which runs inside an Affiliate company. The Affiliation Agent is responsible for receiving customer SD sent by the SUDIS Host Manager. After the data is validated, the Affiliation Agent saves the data into its local database (SUDIS Affiliation Database) inside the Affiliate Company. One Affiliation company has only one Affiliation Agent.

[0047] When an authenticated Affiliation user logs onto SUDIS web site, the user's web browser may access customer SD from the local database if a SUDIS ESC is installed on the user's computer. One Affiliation company may have multiple SUDIS ESCs which run on different computers inside the Affiliation Company. [0048] SUDIS Related Agent has the following functions:

• Verify data senders

• Accept customer SD sent by a SUDIS Host Manager

• Save customer SD to SUDIS Affiliate Database

• Search/list customers from SUDIS Affiliate Database

• View/update customer SD

• Delete customers • Export selected customer data (for example, export to MS Excel file)

• Write and view its own audit log for each action

[0049] The following section gives the detailed functional description about how SUDIS ESCs assist a SUDIS System to access customer SD inside a SUDIS Local Database. Fig. 8 shows a summary of data communication among SUDIS System components. Detailed message exchanges among the SUDIS System components are shown in Fig.9 and Fig.10.

2.1.2 System Working Processes 2.1.2.1 New Customer Creation

[0050] When a new customer visits a Host company, an authenticated Host user may use the SUDIS web form to collect the customer data. The customer data contains non-sensitive customer data unrelated to the identity of the customer (such as customer service, a purchase, etc) and sensitive customer SD (such as customer name, Credit Card Number, SSN, etc). When the user presses the "Submit" button on the web form, the web page needs to perform three tasks.

• Save customer SD into SUDIS Host Database through SUDIS ESC

• Save customer public data into SUDIS Server Database

• Set up a customer identification (CID) which is used as a link between the customer SD and the customer public data

[0051] The new customer creation function contains the following steps:

Step 1 : Set Up Customer Identification (CID): The SUDIS System allows two ways to set up a CID. One is type-in CID. The other is a system generated CID. The SUDIS System administrator has to choose one of them to be used inside a SUDIS System, (a). Input CID [0052] A user may type-in a CID through the web form.

(b). System-generated CID

The SUDIS ESC will generate a unique customer ID for the customer when customer SD is saved into SUDIS Host Database. The system generated customer ID is 32 bytes long. The first 16 bytes are a system ID which is predefined for each Host (or hospital group). The last 16 bytes are sequence number generated by the SUDIS ESC. [0053]

(c). Synchronize multiple IDs [0054] The System is better used in situations with multiple IDs from variety locations, such as a patient from multiple hospitals and clinics or a customer from multiple banks. This synchronization can simplify the communications, and avoid errors of Communications among the variety hosts (hospitals/clinics). This also can improve security monitoring and security controls if the transaction of a customer exceeded the standard (tax, nation security from oversea transactions) or/and security measures, such as from variety banks.

Step 2: Update SUDIS Host Database

[0055] To save the customer SD, SUDIS System web page runs an ESC calling program (such as JavaScript function) to call an AddCustomer function implemented inside the SUDIS ESC. The AddCustomer function will save customer SD, as well as CID, into SUDIS Host Database. At the end, the CID will be sent back to the ESC calling program.

Step 3: Forward Customer Public Data to SUDIS Web Server [0056] After the ESC calling program receives the customer ID, the SUDIS web page will forward the customer ID, as well as customer public data, to SUDIS Web Server. When the Web Server receives the de-identified customer data, the data will be saved into the SUDIS Server Database. If the customer data is saved successfully, an "Add Customer OK" web page will be sent back to the local web browser. If the customer data cannot be saved correctly, an "Add Customer Error" web page will be sent back to the local web browser.

2.1.2.2 Delete Existing Customer

Step 1 : Initialize the deletion from Front Desk

[0057] SUDIS Web Server provides a web page to allow an authenticated Host user to delete a customer from the SUDIS System. When the user presses the "Submit" button on the web page, the web page performs two tasks.

• Delete customer SD from SUDIS Host Database

• Delete customer public data from SUDIS Server Database

Step 2: Update SUDIS Host Database

[0058] To delete the customer SD, SUDIS web page runs an ESC calling program which calls the DeleteCustomer function implemented inside the SUDIS ESC. The DeleteCustomer function will update SUDIS Host Database by marking the customer as "deleted".

Step 3: Forward "Delete Customer" Request to SUDIS Web Server [0059] SUDIS web page will forward a "Delete Customer" request to the SUDIS Web Server. When the "Delete Customer" request is received, SUDIS Web Server will update its server database by marking the customer as "deleted". If the delete process finishes successfully, a "Delete Customer OK" web page will be sent back to the local web browser. If the delete process fails, a "Delete Customer Error" web page will be sent back to the local web browser.

2.1.2.3 Update Existing Customer

Step 1 : Front Desk Input

[0060] When customer data needs to be updated, an authenticated Host user may use SUDIS web form to modify customer data. When the user presses the "Submit" button on the web page, the web page performs two tasks.

• Update customer SD inside SUDIS Host Database

• Update customer public data inside SUDIS Server Database

Step 2: Update SUDIS Host Database

[0061] To update the customer SD, SUDIS web page runs an ESC calling program which calls the UpdateCustomer function implemented inside the SUDIS ESC. The UpdateCustomer function will save the updated the SD into SUDIS Host Database.

Step 3: Forward "Update Customer" Request to SUDIS Web Server [0062] SUDIS web page will forward an "Update Customer" request, as well as updated customer data, to the SUDIS Web Server. When the "Update Customer" request is received, the SUDIS Web Server will update its server database using the updated customer data. If the update process finishes successfully, an "Update Customer OK" web page will be sent back to the local web browser. If the update process fails, an "Update Customer Error" web page will be sent back to the local web browser.

2.1.2.4 Synchronize Customer Display on a Host Web Browser [0063] When a Host user selects a customer from a SUDIS web page, the web page runs an ESC calling program which calls the GetPrivateData function implemented inside the SUDIS ESC. The GetPrivateData function will retrieve the customer SD from SUDIS Host Database and send the data back to the web page.

2.1.2.5 Synchronize Customer Display on an Affiliate Web Browser

[0064] When an Affiliate user selects a customer from a SUDIS web page, the web page runs an ESC calling program which calls the GetPrivateData function implemented inside the SUDIS ESC. The GetPrivateData function will retrieve the customer SD from SUDIS Affiliate Database and send the data back to the web page.

2.1.3 Transfer Customer SD from SUDIS Host Manager to SUDIS Affiliate Agent

[0065] In a predefined time period, a Host Manager may launch a data sharing process. In this process, the Host Manager will retrieve a timestamp from SUDIS Host Database. The Host Manager uses this timestamp to retrieve customer SD which needs to be updated from SUDIS Host Database to SUDIS Affiliate Database. The customer SD will be encrypted and inserted into an "Update Customers" request. The "Update Customers" request will be sent to a predefined Affiliate Agent through a secure network connection.

[0066] When an Affiliate Agent receives a network connection from a Host Manager, the Affiliate Agent has to verify the connection by checking username and password from the Host Manager. If the connection is authenticated, the Affiliate Agent will retrieve the customer SD from the "Update Customers" request and save the data into SUDIS Affiliate Database. After the data process is finished, the Affiliate Agent will send an "Update Customers OK" message back to the Host Manager.

2.1.4 Generate Analysis Reports based on Customer Data directly from Host Main Database

[0067] An authenticated Host user may launch customer data analysis on the data which is saved in the existing main database inside a Host. To do that, the user has to select analysis requirements, including which report(s) to create, which groups of customers to be analyzed, etc. The user may choose when the analysis process should be launched. After an analysis process is started, the SUDIS Host Manager transfers the de-identified customer data to SUDIS Web Server. Using the data, the web server creates the analysis reports and sends the reports back to the Host Manager. The user may view the analysis reports using the Host Manager or other document viewers.

2.1.5 Data Privacy and Security

[0068] The SUDI System provides multiple security protections for off-site customer privacy. Those protections are summarized as the following:

• Host Manager never forward customer SD to the SUDIS Web Server.

• A Host Manager administrator can set up data transfer from the Host Manager to Affiliate Agent through Internet connection. Customer SD may be forwarded to Affiliate Agent only if the data transfer is set up.

• Affiliate Agent must authenticate the Host Manager after a network connection request is received.

• Customer SD has to be encrypted before it is forwarded to the Affiliate Agent.

• The network connection among SUDIS Web Server, Host Manager and Affiliate Agent is secured using SSL.

• SUDIS Web Server, Host Manager and Affiliate Agent must log all of the data transfer activities for audit. A customer may enable built-in system privacy log to trace privacy related activities. The following log functions may be selected.

• Affiliate Agent account creation

^■ Who creates an Affiliate Agent account, including super user names and passwords

^■ From which computer (network IP address) the super user logged in

^■ When the Affiliate Agent account is created

^■ Why the Affiliate Agent account is created

^■ Which network IP address(es) the data should be sent for the Affiliate Agent account

^■ Which account rights have been given to the account, including time durations, number of records, privacy levels, and access types.

• Affiliate Agent account access

^■ When a data transfer happened;

^■ Which network IP address the data was sent to

^■ Which data records were sent (data selection statements)

Claims

IN THE CLAIMS:We claim:

1. A method for securely communicating customer personal data records including sensitive data and non-sensitive data over a global information network comprising:

receiving customer data including customer sensitive data and customer non- sensitive data from a user;

transmitting customer sensitive data to a module installed on a computer located at a secure host site responsive to a command initiated by the user;

storing the customer sensitive data in a secure host database;

in the module, generating a customer id corresponding to the customer sensitive data responsive to storage of the customer sensitive data;

storing the customer id in the host database such that the customer id is correlated with the customer sensitive data;

transmitting the customer id generated by the module and the customer non- sensitive data to a web server remotely located inside the secured data center.

2. The method of claim 1 further comprising storing non-sensitive customer data and the customer id in a web server database such that the non-sensitive data is correlated with the customer id.

3. The method of claim 2 further comprising displaying a message indicating successful completion of the method responsive to a message that indicating storage of the non-sensitive data.

4. A method for displaying customer personal data in a graphical user interface comprising:

receiving a request from a user to view customer data;

checking the user authorization level for access to customer data; receiving sensitive customer data from a host database located at the secure host site responsive to the user request for a user having a first level of authorization;

receiving non-sensitive data from a web server database responsive to the user request for a user having a first level of authorization; and

displaying the sensitive data and non-sensitive data together responsive to a request from a user having a first level of authorization;

receiving non-sensitive data from a web server database responsive to the user request from a user having a second level of authorization; and

displaying only the non-sensitive data responsive to a request from a user having a second level of authorization.

5. The method according to 4 wherein the second level of authorization permits the user to access only a subset of the non-includes one or more of the sensitive data.

6. The method of claim 4 wherein the second level of authorization permits the user to access the non-sensitive data for a limited period of time.

7. The method of claim 4 wherein the second level of authorization permits the user to access data associated with a subset of the customers.

8. The method of claim 4 wherein the second level of authorization permits the user to access only preidentified tables within the web server database.

9. The method of claim 8 wherein the second level of authorization permits the user to access only preidentified columns within the tables.