Abstract:
A system and method are provided for enabling Web services to enforce multiple countries&#39; data protection laws and regulations during data collection, data processing storage and data transfer. The system maintains a dynamic list of countries or entities that have been recognized for their adequate data protection. A data collection form is provided that takes into consideration data protection laws of the sovereign in which the form is being filled out. The system prohibits the transfer of personal data in contravention of a local sovereign&#39;s data protection laws.

Description:
TECHNICAL FIELD 
     The invention relates generally to Web data service. More particularly, the invention relates to a system and method for enforcing multiple countries&#39; and/or entities&#39; data protection rules in data collection, data transfer, and data processing. 
     BACKGROUND OF THE INVENTION 
     Web services provide a way to expose some business functionality over the Internet using a standardized way of integrating Web-based applications using the extensible Markup Language (XML), Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL) and Universal Discovery and Description Interface (UDDI) open standards over an Internet protocol backbone. XML is used to tag the data, SOAP is used to transfer the data, WSDL is used for describing the services available, and UDDI is used for listing what services are available. Used primarily as a means for businesses to communicate with each other and with clients, Web services allow organizations to communicate data without intimate knowledge of each other&#39;s IT systems behind the firewall. 
     Unlike traditional client/server models, such as a Web server/Web page system, Web services do not provide the user with a GUI. Web services instead share business logic, data, and processes through a programmatic interface across a network. Developers can then add the Web service to a GUI, such as a Web page or an executable program, to offer specific functionality to users. 
     Web services are not independent of Web applications. Web applications form the technology foundation and Web services provide the glue for interactions and integration. Web services allow different applications from different sources to communicate with each other without time-consuming custom coding, and because all communication is in XML, Web services are not tied to any one operating system or programming language. For example, Java can talk with Practical Extraction and Report Language (Perl), Windows applications can talk with UNIX applications. 
     In a Web service system, a client who calls for a function formats a request with SOAP XML encoding and sends it to the server over a mutually agreeable communication protocol such as HyperText Transfer Protocol (HTTP) or Simple Mail Transfer Protocol (SMTP). The server runs some sort of a listener that accepts the incoming SOAP calls, reads the information from the XML SOAP packets, and maps them to business logic processing application software on the server. The application layer on the server processes the request and returns output to the listener, which formats the output into a response packet in the SOAP XML encoding and returns it to the client. 
     Security is a primary consideration when choosing a Web service for all applications. Web services security requirements include authentication, authorization, and data protection. 
     Authentication ensures that each entity involved in using a Web service is what it actually claims to be. Authentication involves accepting credentials from the entity and validating them against an authority. 
     Authorization determines whether the service provider has granted access to the Web service to the requestor. Basically, authorization confirms the service requestor&#39;s credentials. It determines if the service requestor is entitled to perform the operation, which can range from invoking the Web service to executing a certain part of its functionality. 
     With regard to data protection, Web services have to abide by relevant data protection laws if the transaction is conducted in the jurisdiction. Many countries and international organizations, such as U.S; Finland, Sweden, Germany, as well as OECD, have promulgated personal data protection laws and regulations. The laws and regulations are not same in all aspects. This brings difficulties in deploying the Web service product in multiple jurisdictions. 
     What is desired is a Web service that supports multiple countries&#39; and entities&#39; data protection laws and regulations. 
     SUMMARY OF THE INVENTION 
     A system architecture model for Web services is provided in which data protection laws and regulations are enforced during data collection, data processing storage, and data transfer. The system maintains a dynamic list of countries or entities that have been recognized for their adequate data protection. A data collection form is provided that takes into consideration data protection laws of the sovereign in which the form is being filled out. The system prohibits the transfer of personal data in contravention of a local sovereign&#39;s data protection laws. 
     Specifications of data protection legislation are formalized such that they can be treated as a configuration file. Each specification consists of four sections, i.e. legal properties; policies for data collection, policies for data processing, and policies for data transfer, and it describes a data protection legislation of the host country of a Web service. All data recipients of a Web service register its country code, organization ID, business classification, purpose IDs and contact information of its data controller. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is block diagram illustrating a system architecture model of Web service with law enforcement support according to the invention; 
         FIG. 2  is a flow diagram illustrating a method for enforcing data protection laws in collecting personal data; 
         FIG. 3  is a flow diagram illustrating the details of Step  204  of the method of  FIG. 2 ; 
         FIG. 4  is a flow diagram illustrating a method for enforcing data protection laws in transferring personal data; and 
         FIG. 5  is a flow diagram illustrating a method for enforcing data protection laws in other data processing. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       FIG. 1  is block diagram illustrating a system architecture model of Web service  100  with law enforcement support. In this system, data protection laws and regulations are enforced at three key stages, i.e. data collection  101 , data processing  102 , and data transfer  103 . In the data collection stage  101 , the Web service creates a data collection form while taking into consideration data protection laws. For example, Swedish law prevents Web services from collecting religious data. After the user completes the form and returns it via the user agent  104 , the Web service  100  processes the data collected and stores it in the cache  105 . In some countries, such as in Germany, data protection law prohibits sensitive personal data from being transferred to entities/countries that have not established “adequate” data protection. These laws are then enforced at the data transfer stage  103 . 
     The system  100  maintains a list of countries/entities  108  that have been recognized for their “adequate” data protection. This dynamic list can be assembled from various sources, such as USA&#39;s Safe Harbor List at http://web.ita.doc.gov/safeharbor/shlist.nsf/webPages/safe+harbor+list. 
     The Web service  100  also contains registration information about data recipients  106 . All data recipients of the Web service  100  have the following information registered:
         country code . . . This enables system to decide whether the country of a recipient has adequate data protection.   organization ID . . . This enables system to decide whether the organization of a recipient has adequate data protection.   business classification . . . e.g. ISP, Health, etc.   Purpose IDs . . . ie., the purposes of the data retrieval? e.g. research, commerce and marketing   contact information of its data controllers       

     The Web service  100  formally specifies data protection legislation so that such a specification could be treated as a configuration file. For example, each specification consists of four sections, and it describes a data protection legislation of the host country of a Web service:
         &lt;PatternDef&gt; &amp; &lt;LegalAttribute&gt; . . . Legal properties (attribute) specification for user data entries   &lt;DataCollectionPolicies&gt; . . . ACL policies for data collection   &lt;DataPorcessingPolicies&gt; . . . ACL policies for data processing   &lt;DataTrasferPolicies&gt; . . . ACL policies for data transfer       

     A list of &lt;PatternDef&gt; and &lt;LegalAttribute&gt; are used in the following format:
 
&lt;Pattern Def name=PatternName&gt;1. . . n
         A list of XML queries that describe the entries to be included or excluded       

     
       
         
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 &lt;/PatternDef&gt; 
               
               
                   
                 &lt;LegalAttribute name=Attribute Name&gt;1..n 
               
               
                   
                  &lt;LegalValue val=Attribute Value&gt;1..n 
               
               
                   
                  A list of Pattern names 
               
               
                   
                  &lt;/LegalValue&gt; 
               
               
                   
                 &lt;/LegalAttribute&gt; 
               
               
                   
                   
               
             
          
         
       
     
     For example, the following XML segments define  3  data patterns (Name, Birth-Year, and Religion), assign legal attribute value “Sensibility=NO” to Name/Birth-Year patterns, and assign legal attribute value “Sensibility=YES” to Religion pattern. 
     
       
         
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 &lt;PatternDef name=”Name”&gt; 
               
             
          
           
               
                   
                 &lt;include xpath=”contact/name”/&gt; 
               
             
          
           
               
                   
                 &lt;/PatternDef&gt; 
               
               
                   
                 &lt;PatternDef name=”Birth-Year”&gt; 
               
             
          
           
               
                   
                 &lt;include xpath=”demographic/birthDate/year”/&gt; 
               
             
          
           
               
                   
                 &lt;/PatternDef&gt; 
               
               
                   
                 &lt;PatternDef name=”Religion”&gt; 
               
             
          
           
               
                   
                 &lt;include xpath=”demographic/religion”/&gt; 
               
             
          
           
               
                   
                 &lt;/PatternDef&gt; 
               
               
                   
                 &lt;LegalAttribute name=” Sensibility”&gt; 
               
               
                   
                  &lt;LegalValue val=”NO”&gt; 
               
               
                   
                   &lt;Pattern ref=”Name”/&gt; 
               
               
                   
                   &lt;Pattern ref=”Birth-Year”/&gt; 
               
               
                   
                  &lt;/LegalValue&gt; 
               
               
                   
                  &lt;LegalValue val=”YES”&gt; 
               
               
                   
                   &lt;Pattern ref=”Religion”/&gt; 
               
               
                   
                  &lt;/LegalValue&gt; 
               
               
                   
                 &lt;/LegalAttribute&gt; 
               
               
                   
                   
               
             
          
         
       
     
     Access Control List (ACL) policies (&lt;DataCollectionPolicies&gt;, &lt;DataPorcessingPolicies&gt; and &lt;DataTrasferPolicies&gt;) could be stated in OASIS XACML format or other mechanisms. These policies refer to various data such as:
         Legal attribute values of data entries, as defined above   Characteristics of data recipients, such as their registration data and adequate data protection status   Data owner&#39;s permission information, such as whether an explicit consent was given for a request   Request parameters       

     The following XML segments illustrate some formal definition of German “Federal Data Protection Act” in OASIS XACML style. The following &lt;DataPorcessingPolicies&gt; states that non-sensitive personal data (as defined by &lt;LegalAttribute name=_”Sensibility”&gt; above) could be processed. Our &lt;DataTrasferPolicies&gt; states that personal data should not be transferred to a non-safe-harbor US requestor, i.e. the entity is not included in the Safe Harbor List  108 . 
     
       
         
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 &lt;DataPorcessingPolicies&gt; 
               
               
                   
                  &lt;XACML:rule Effect=”Permit”&gt; 
               
               
                   
                   &lt;Target&gt; 
               
             
          
           
               
                   
                 &lt;Resources&gt; 
               
               
                   
                  &lt;Attribute AttributeName=”Sensibility”&gt; 
               
               
                   
                  &lt;AttributeValue&gt;NO&lt;/AttributeValue&gt; 
               
               
                   
                  &lt;/Attribute&gt; 
               
               
                   
                 &lt;/Resources&gt; 
               
               
                   
                 &lt;Actions&gt;*&lt;/Actions&gt; 
               
             
          
           
               
                   
                   &lt;/Target&gt; 
               
               
                   
                  &lt;/XACML:rule&gt; 
               
               
                   
                 &lt;/DataPorcessingPolicies&gt; 
               
               
                   
                  &lt;DataTrasferPolicies&gt; 
               
               
                   
                  &lt;XACML:rule Effect=”Deny”&gt; 
               
               
                   
                   &lt;Target&gt; 
               
             
          
           
               
                   
                 &lt;Subjects&gt; 
               
               
                   
                  &lt;Attribute AttributeName=”CountryCode”&gt; 
               
               
                   
                  &lt;AttributeValue&gt;US&lt;/AttributeValue&gt; 
               
               
                   
                  &lt;/Attribute&gt; 
               
               
                   
                  &lt;Attribute AttributeName=”SafeHarbor”&gt; 
               
               
                   
                  &lt;AttributeValue&gt;NO&lt;/AttributeValue&gt; 
               
               
                   
                  &lt;/Attribute&gt; 
               
               
                   
                 &lt;Resources&gt;*&lt;/Resources&gt; 
               
             
          
           
               
                   
                   &lt;/Target&gt; 
               
               
                   
                  &lt;/XACML:rule&gt; 
               
               
                   
                 &lt;/DataTrasferPolicies&gt; 
               
               
                   
                   
               
             
          
         
       
     
     To empower the Web service to support multiple countries&#39; data protection laws and regulations, the system includes a separate legislation specification for each country. The Web service can decide which legislation to be applied based on various factors, such as request URL (http://profile.service.se or http://profile.service.de) and data owner&#39;s citizenship, etc. 
     Data protection laws are enforced at three different stages. 
     1. Enforcing Data Protection Laws in Collecting Personal Data: 
     The Web service  100  creates data collection forms from the predefined form templates and the legislation specification described above. 
     Then, the Web service  100  introduces form template language. Form templates are XML/HTML/WML forms embedded with tags %data_collected=Pattern(s)% that indicate what data are to be collected. For example: 
     
       
         
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 &lt;HTML&gt;... 
               
               
                   
                 &lt;XXX %data_collected=Pattern1% ...&gt; ... &lt;/XXX&gt; 
               
               
                   
                 ... 
               
               
                   
                 &lt;YYY %data_collected=Pattern2% ...&gt; ... &lt;/YYY&gt; 
               
               
                   
                 ... &lt;/HTML&gt; 
               
               
                   
                   
               
             
          
         
       
     
     An XML/HTML/WML element is removed if ACL policies &lt;DataCollectionPolicies&gt; states that such data should not be collected. 
     The following HTML template illustrates an HTML page collecting user&#39;s first/last names, birth year and religion. It has three &lt;pre&gt; elements that associate with %data_collected=Name%, %data_collected=Birth-Year%, and %data_collected=Religion%. By applying our formal specification of Swedish Law, the 3 rd  node (&lt;pre %data_collected=Religion%&gt;) will be removed from HTML form since Sweden does not allow collecting religious data. 
     
       
         
               
             
               
               
             
               
             
               
               
             
               
             
               
               
             
               
             
           
               
                   
               
             
             
               
                  &lt;HTML&gt; 
               
               
                  &lt;HEAD&gt;&lt;TITLE&gt;Your Data&lt;/TITLE&gt;&lt;/HEAD&gt; 
               
               
                  &lt;BODY&gt; 
               
               
                 &lt;FORM ACTION=”some.cgi” method=”post”&gt; 
               
               
                  &lt;pre %data_collected=Name%&gt; 
               
             
          
           
               
                   
                 &lt;b&gt;Last name:&lt;/b&gt; &lt;Input type=“text” name=last_name size=16 
               
             
          
           
               
                  maxlength=16&gt; 
               
             
          
           
               
                   
                 &lt;b&gt;First name:&lt;/b&gt; &lt;Input type=“text” name=first_name size=16 
               
             
          
           
               
                  maxlength=16&gt; 
               
               
                 &lt;/pre&gt; 
               
               
                 &lt;pre %data_collected=Birth-Year%&gt; 
               
             
          
           
               
                   
                 &lt;b&gt;Year of birth:&lt;/b&gt;&lt;Input type=“text” name=byear size=4 
               
             
          
           
               
                  maxlength=4&gt; 
               
               
                 &lt;/pre&gt; 
               
               
                 &lt;pre %data_collected=Religion%&gt; 
               
               
                  &lt;b&gt;Religion:&lt;/b&gt; &lt;select size=“1” name=“religion”&gt; 
               
               
                  &lt;option value=“Buddhism”&gt;Buddhism 
               
               
                  &lt;option value=“Christianity”&gt;Christianity 
               
               
                  &lt;option value=“Ecumenical”&gt;Ecumenical 
               
               
                  &lt;option value=“Hinduism”&gt;Hinduism 
               
               
                  &lt;option value=“Islam”&gt;Islam 
               
               
                  &lt;/select&gt; 
               
               
                  &lt;/pre&gt; 
               
               
                 &lt;/FORM&gt; 
               
               
                  &lt;/BODY&gt;&lt;/HTML&gt; 
               
               
                   
               
             
          
         
       
     
       FIG. 2  is a flow diagram illustrating a method to enforce data protection law in collecting personal data. The method comprises the following steps:
     Step  201 : Create a DOM tree from the given XMUHTML/WML form template;   Step  202 : Identify the total list (L) of DOM tree nodes containing a tag %data_collected%;   Step  203 : Identify the list of policy statements (P) included in &lt;DataCollectionPolicies&gt; of a formal specification of an appropriate legislation;   Step  204 : Construct a sublist (S) of L that should be removed from the DOM tree by policies P;   Step  205 : Remove all DOM sub-trees with root node included in the Sublist S; and   Step  206 : Export the result DOM tree into an XML/HTML/WML document.   
     Now referring to  FIG. 3 , which is a flow diagram illustrating the details of Step  204 :
     Step  301 : Initialize R to be an empty list;   Step  302 : Check whether there is any node in list L (see Step  202 );   Step  303 : If the check result in Step  302  is no, then return R as the node sublist for removal;   Step  304 : If the check result in Step  302  is yes, then let D be the first node in list L;   Step  305 : Let PT be the data pattern referred by %data_collected% tag node D;   Step  306 : Compute the corresponding legal attribute values based on &lt;LegalAttribute&gt; section of a legislation specification;   Step  307 : Apply &lt;DataCollectionPolicies&gt; to determine whether the data of pattern PT could be collected or not;   Step  308 : If the result in Step  307  is not, then add D into sublist R for removal, continuing with step  309 ; and   Step  309 : If the result in Step  307  is yes, then remove the current DOM substree D from the list L.
 
2. Enforcing Data Protection Laws in Transferring Personal Data:
   

     Each request made by a recipient (e.g. 107  in  FIG. 1 ) includes a request header:
         requesterID . . . indicates who is making the request   purpose ID . . . indicates the purposes of this data inquiry p Now referring to  FIG. 4 , which is a flow diagram illustrating a method for executing the request:       Step  401 : Identify the set of requested data entries (DE) that the requester wants to access;   Step  402 : Apply &lt;PatternDef&gt; section of the formal legislation specification to compute the corresponding set of data patterns (PT), for these data entries DE;   Step  403 : Compute the legal attribute values of data patterns PT by applying &lt;LegalAttribute&gt; section of a legislation specification;   Step  404 : Apply &lt;DataTransferPolicies&gt; to determine whether the request should be accepted or denied; and   Step  405 : Record the data request and result status in a log database.
 
3. Enforcing Data Protection Laws in other Data Processing:
   

     Now referring to  FIG. 5 , which is a flow diagram illustrating a method for enforcing data protection laws in other data processing:
     Step  501 : Identify the set of requested data entries (DE) to be processed;   Step  502 : Apply &lt;PatternDef&gt; section of the formal legislation specification to compute the corresponding set of data patterns (DP) for these data entries DE;   Step  503 : Compute the legal attribute values of these data entries (DE) by applying &lt;LegalAttribute&gt; section of a legislation specification; and   Step  504 : Apply &lt;DataProcessingPolicies&gt; to determine whether the request should be accepted or denied.   

     Although the invention is described herein with reference to the preferred embodiment, one skilled in the art will readily appreciate that other applications may be substituted for those set forth herein without departing from the spirit and scope of the present invention. 
     Accordingly, the invention should only be limited by the Claims included below.