Abstract:
A method for preventing unauthorized access by a requester to data sent via computer networks, including a) requesting, from a requesting computer, access to data from a first server, at the first server b) determining if the request is a valid request, c) receiving a ticket from a ticket server, if the request is a valid request d) providing the ticket identifying the requestor to a second server the data is stored, e) directing the requesting computer to request access to the data from the second server, at the second server f) receiving the request from the requesting computer, g) verifying the ticket as identifying the requester, and h) sending the data to the requesting computer in response to the request.

Description:
FIELD OF THE INVENTION  
         [0001]    The present invention relates to computer network communications in general, and more particularly to preventing unauthorized access to data sent via computer networks.  
         BACKGROUND OF THE INVENTION  
         [0002]    Methods for controlling access to data via computer networks are well known. Some methods require that IDs and passwords be provided to the data server in order to gain access to data. In other methods a data server provides encrypted data to the client, where the data is then decrypted using a key and decryption software previously provided to the client. In other methods digital watermarks are embedded into the data at the data source allowing for distribution of the data to be monitored for unauthorized distribution.  
           [0003]    These and other prior art approaches are suited for peer-to-peer architectures where the data resides at a single source, such as on one or more servers under the direct control of the data owner, and the data is provided directly from the data holder&#39;s server to the requesting client. Such peer-to-peer arrangements are currently in wide use on the Internet, and represents the most common default arrangement.  
           [0004]    Providing high-bandwidth content via computer networks, however, places a considerable load on peer-to-peer architectures. As a result, proxy servers are often used to “mirror” data stored at the data owner&#39;s server and provide data to clients. Unfortunately, these proxy servers are often not under the direct control of the data owner, and steps taken by the data owner at the original data source to protect unauthorized access to data are often not taken by the proxy servers, leading to unauthorized access.  
         SUMMARY OF THE INVENTION  
         [0005]    The present invention seeks to provide a system for preventing unauthorized access to data sent via computer networks that overcome disadvantages of the prior art.  
           [0006]    There is thus provided in accordance with a preferred embodiment of the present invention a method for preventing unauthorized access by a requestor to data sent via computer networks, including a) requesting, from a requesting computer, access to data from a first server, at the first server b) determining if the request is a valid request, c) receiving a ticket from a ticket server, if the request is a valid request d) providing the ticket identifying the requestor to a second server the data is stored, e) directing the requesting computer to request access to the data from the second server, at the second server f) receiving the request from the requesting computer, g) verifying the ticket as identifying the requester, and h) sending the data to the requesting computer in response to the request.  
           [0007]    Further in accordance with a preferred embodiment of the present invention the requesting computer is a client computer.  
           [0008]    Still further in accordance with a preferred embodiment of the present invention the second server is either of a proxy server and a cache server.  
           [0009]    Additionally in accordance with a preferred embodiment of the present invention the data is encrypted and the providing step d) further includes the first server providing a decryption key to the second server for decrypting the data.  
           [0010]    Moreover in accordance with a preferred embodiment of the present invention the data is encrypted and the providing step d) further includes the ticket server providing a decryption key to the second server for decrypting the data.  
           [0011]    Further in accordance with a preferred embodiment of the present invention the providing step d) further includes providing the ticket to the second server by way of the client computer.  
           [0012]    Still further in accordance with a preferred embodiment of the present invention the method further includes the client computer locating the second server using a search engine.  
           [0013]    Additionally in accordance with a preferred embodiment of the present invention the verifying step g) further includes i) sending the ticket to the ticket server for validation, and j) receiving a communication from the ticket server validating the ticket.  
           [0014]    Moreover in accordance with a preferred embodiment of the present invention the sending step h) further includes embedding a marking into the data prior to sending the data to the client computer.  
           [0015]    Further in accordance with a preferred embodiment of the present invention the marking is a digital watermark.  
           [0016]    Still further in accordance with a preferred embodiment of the present invention the marking is a personalized marking for the requester.  
           [0017]    There is also provided in accordance with a preferred embodiment of the present invention a method for preventing unauthorized transfer of data sent via computer networks, the method including the steps of instructing a first server to send content to a second server, notifying a ticket server of the instructions, validating the instructions at the ticket server, if the instructions are valid notifying either of the servers that the instructions are valid, sending the content from the first server to the second server, if the instructions are invalid notifying either of the servers that the instructions are invalid, performing any of ignoring the instructions, corrupting the content, and discarding the content.  
           [0018]    Further in accordance with a preferred embodiment of the present invention the method further includes the steps of embedding a marking into the data, checking the validity of the marking at either of the servers, and if the marking is invalid, performing any of ignoring the instructions, corrupting the content, and discarding the content.  
           [0019]    Still further in accordance with a preferred embodiment of the present invention the validating step includes validating the instructions in accordance with a policy.  
           [0020]    Additionally in accordance with a preferred embodiment of the present invention the embedding step includes embedding any of an identification unique to the first server, an identification unique to the second server, routing information, and rule-based information.  
           [0021]    Moreover in accordance with a preferred embodiment of the present invention the method further includes the first server receiving an encryption key from the ticket server, and encrypting the content using the encryption key.  
           [0022]    Further in accordance with a preferred embodiment of the present invention the method further includes the second server receiving a decryption key from either of the first server and the ticket server, and decrypting the content using the decryption key.  
           [0023]    According to a third aspect of the present invention there is provided a data transfer validation server for validating a request for data transfer, the server comprising:  
           [0024]    a request input for receiving a request from a distribution server to distribute data from said distribution server to a requesting client,  
           [0025]    a distribution parameter table comprising predetermined distribution parameters,  
           [0026]    a comparator for comparing said request against said predetermined distribution parameters,  
           [0027]    a verifier connected to said comparator for verifying said request, at least partly in accordance with an output of said comparator, and  
           [0028]    a ticket issuer for issuing ticket data indicating acceptance of said request.  
           [0029]    Preferably, said predetermined distribution parameters comprise approved times for providing content.  
           [0030]    Additionally or alternatively, the predetermined distribution parameters comprise approved regions for providing content.  
           [0031]    Additionally or alternatively, the predetermined distribution parameters comprise approved distribution portals.  
           [0032]    Additionally or alternatively, the predetermined distribution parameters comprise approved users.  
           [0033]    Additionally or alternatively, the predetermined distribution parameters comprise non-approved distribution portals.  
           [0034]    Additionally or alternatively, the predetermined distribution parameters comprise non-approved users.  
           [0035]    Additionally or alternatively, the predetermined distribution parameters comprise different parameters for content items from different content sources.  
           [0036]    Additionally or alternatively, the predetermined distribution parameters comprise different parameters for different content items.  
           [0037]    Additionally or alternatively, the predetermined distribution parameters comprise a requirement for an endpoint rights protection scheme. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0038]    The present invention will be understood and appreciated more fully from the following detailed description taken in conjunction with the appended drawings in which:  
         [0039]    [0039]FIG. 1 which is a simplified conceptual illustration of a system for preventing unauthorized access to data sent via computer networks, constructed and operative in accordance with a preferred embodiment of the present invention;  
         [0040]    [0040]FIG. 2 is a simplified flowchart illustration of a method of operation of the system of FIG. 1, the method being operative in accordance with a preferred embodiment of the present invention;  
         [0041]    [0041]FIG. 3 is a simplified conceptual illustration of a system for preventing unauthorized transfer of data sent via computer networks, constructed and operative in accordance with another preferred embodiment of the present invention; and  
         [0042]    [0042]FIG. 4 is a simplified flowchart illustration of a method of operation of the system of FIG. 3, operative in accordance with a preferred embodiment of the present invention; 
     
    
     DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS  
       [0043]    Reference is now made to FIG. 1, which is a simplified conceptual illustration of a system for preventing unauthorized access to data sent via computer networks, constructed and operative in accordance with a preferred embodiment of the present invention. In the system of FIG. 1, data, such as text-based or numeric data, graphical data, audio data, or any other kind or combination of data that may be transmitted via a computer network, is stored on a server  10 , such as a proxy or cache server, typically provided to server  10  by a data source server  12 , such as via a computer network  14 , such as the Internet. Preferably, the data provided by server  12  to server  10  is encrypted using any conventional encryption technique.  
         [0044]    A ticket server  18  provides data transfer verifications  20  hereinafter referred to as tickets, to server  12 , such as via network  14 , where each ticket includes an identifier that is preferably unique to all other tickets provided to server  12  and/or all other tickets provided by server  18  to any other server, and that is preferably encrypted using any conventional encryption technique. Tickets  20  may be provided to server  12  in response to a request sent by server  12  to server  18  for tickets, such as upon server  12  receiving a request from a user at a client computer  16  who wishes to access the data stored on server  10 , and/or may be provided not in connection with any such request, such as for future use by server  12 . Client computer  16  may be any network-connectable computer or appliance, such as a personal computer, a personal digital assistant, a cellular telephone, and a web-enabled television appliance.  
         [0045]    A typical operational scenario of the system of FIG. 1 may be seen with additional reference to FIG. 2, which is a simplified flowchart illustration of a method operative in accordance with a preferred embodiment of the present invention. In the method of FIG. 2 a user at client computer  16  who wishes to access the data stored on server  10  sends a request to server  12  to access the data, such as via network  14  (step  100 ). Server  12  identifies the user using any conventional technique, such as by a user identifier sent with the request or by the source address of the request being previously known to server  10  (step  110 ), and determines whether the user is authorized to access the data (step  120 ). This authorization process may include checking the user&#39;s current credit status or account balance or any other known authorization criteria (or other methods in use today). If the user is authorized to access the data, server  12  requests a ticket from ticket server  18  (step  130 ). Alternatively or additionally, server  12  may request or otherwise receive one or more tickets prior to receiving requests from clients. The ticket, preferably encrypted, is sent by server  12  to server  10  together with a user and/or client computer identifier identifying the requester and preferably a decryption key, where the data at server  10  is encrypted (step  140 ). Alternatively, the key may be provided to server  10  by ticket server  18  as part of the verification process (see step  180  below). Client  16  is then directed to server  10 , typically by server  12 , which client  16  then contacts (step  150 ). Alternatively, server  10  or another server on client  16 &#39;s request route may intercept the client  16 &#39;s request and redirect client  16  to server  10 . Yet another possibility is where client  16  receives ticket  20  from server  12  and searches for the most suitable server, in terms of distance, load and other parameters, where the desired data may be found. In this case, once client  16  locates an appropriate server  10  it sends ticket  20  to server  10  which validates it with server  18  and transmits the content to client  16 .  
         [0046]    Upon being contacted by client  16 , server  10  identifies the requesting user using any conventional technique, such as by a user identifier sent with the request or by the source address of the request being previously known to server  10 , and-searches for a ticket bearing the user&#39;s identity (step  160 ). Server  10  then sends information from the ticket, such as the ticket identifier and/or the user identifier, or the entire ticket  20  to ticket server  18  for verification (step  170 ). Ticket server  18  then verifies the ticket (step  180 ), preferably taking steps that the ticket either be cancelled or removed from the ticket pool (such as in the case where client  16 &#39;s access to the data is limited) or allowed to remain at ticket server  18  (such as where client  16 &#39;s access to the data is unlimited). Ticket server  18  then notifies server  10  that the ticket is valid (step  190 ). Server  10  then decrypts the data if required using the decryption key received with the ticket (step  200 ), and sends the data to the user at client  16  (step  210 ). Optionally, server  10  may, using conventional techniques, embed a digital watermark or any other type of known marking into the data before it is sent to client  16 . The embedded marking may be sent to server  10  as part of ticket  20 . The digital watermark may be personalized for the specific user. Server  10  may also encrypt the data before it is sent to client  16 , with the decryption key having been previously sent to client  16  by server  12  as part of the redirect message or otherwise.  
         [0047]    Alternatively to step  140 , server  12  may send the ticket to client  16  in addition to or instead of sending the ticket to server  10 . Where the ticket is sent to client  16 , client  16  provides the ticket to server  10  which then verifies the ticket with ticket server  18  as described hereinabove. Where server  12  does not provide redirection information to client  16 , server  12  may provide other information to client  16 , such as keywords identifying server  10 , that client  16  may then use to search for server  10  (which has the required content) using conventional techniques, such as by using publicly-available search engines.  
         [0048]    Verification step  180  may include determining the validity of the ticket in accordance with a policy table  8 , which typically includes distribution parameters preferably specified by the content owner. Examples of such distribution parameters may include approved times for providing content, approved sources of specific content, types of end-point protection schemes required (such as Microsoft Digital Rights Management, Intertrust DigiBox, etc.), as well as a list of unauthorized set-top boxes, and users. Examples of policies may include:  
         [0049]    Example I: The KickBox portal is not authorized to sell Disney movies.  
         [0050]    Example II: A user which is located in Belgium (region 2), is not authorized to receive/view Star Wars 8, which is currently authorized for users in region 1 only.  
         [0051]    Encryption keys referred to hereinabove may be alternatively provided by client  16  to server  10  for encrypting data prior to transmission to client  16 . The keys may be preconfigured with client  16  or generated by client  16  using conventional software techniques. Furthermore, decryption keys referred to hereinabove that are sent to client  16  may be likewise preconfigured with client  16 , thus obviating the need to transmit decryption keys to client  16 .  
         [0052]    Reference is now made to FIG. 3, which is a simplified conceptual illustration of a system for preventing unauthorized transfer of data sent via computer networks, constructed and operative in accordance with another preferred embodiment of the present invention, and additionally to FIG. 4, which is a simplified flowchart illustration of a method of operation of the system of FIG. 3, operative in accordance with a preferred embodiment of the present invention. In the system of FIG. 3 and method of FIG. 4 authorized content  30  resides on a server  32 , such as a proxy or cache server. A content delivery controller  36 , such as a server, instructs server  32  to send content  30  to a server  34  (step  300 ). Controller  36  may be configured to determine the current network load on servers  32  and  34  using conventional load balancing techniques, instructing server  32  to send content  30  to server  34  in order to redistribute the load in accordance with predefined load balancing criteria. A ticket server  38  is notified of the transfer instructions, either by server  36  or by server  32  (step  310 ). Ticket server  38  preferably checks the validity of the transfer parameters against a policy table  40  (step  320 ). Server  32  and/or server  34  are notified of the validity of the instructions by ticket server  38  (step  330 ), with server  32  and/or server  34  ignoring the instructions should they be proven invalid (step  340 ). Server  36  may also be notified of the instructions not having been carried out by server  32 ,  34 , or  38 .  
         [0053]    Ticket server  38  may send a ticket to server  32  and/or server  34  in anticipation of the transfer of content  30  (step  350 ). Prior to sending content  30  to server  34 , server  32  preferably embeds into content  30 , using digital watermarking or other known data embedding technique, an identification unique to server  32 , an identification unique to server  34 , and/or other routing and/or rule-based data, such as “do not pass through a specific region” where the region is identified by routers or proxies along the way (step  360 ). Server  32  preferably encrypts content  30  using an encryption key that server  32  receives as part of the ticket sent to it by ticket server  38  (step  370 ). Server  32  then sends content  30  to server  34  (step  380 ) and preferably reports to ticket server  38  that content  30  was sent to server  34  (step  390 ).  
         [0054]    Content  30  then arrives at server  34 . If content  30  is encrypted server  34  may decrypt it, preferably with a decryption key received from ticket server  38  (step  400 ). Server  34  then determines that content  30  is allowed to reside on server  34  by checking the validity of content  30 &#39;s embedded information (step  410 ). If content  30  lacks a correctly encoded digital watermark, or if the information embedded into content  30  otherwise contraindicates a valid content transfer, then content  30  is deemed to be invalid. Additionally or alternatively, server  34  may send a ticket to ticket server  38  with content  30 &#39;s ID for validation. If either server  34  or ticket server  38  determine that content  30  is improperly marked or otherwise identified, server  34  discards content  30  (step  420 ). Server  34  and subsequent servers may similarly mark and encrypt content  30  prior to sending content  30  to another server.  
         [0055]    The watermarking of content  30  in accordance with conventional techniques is preferably done such that if content  30  is modified, the watermark in content  30  will change. Thus, if server  34  does not identify a proper digital watermark in content  30 , or if server  34  determines that the watermark has been removed, content  30  is discarded.  
         [0056]    As an alternative to discarding unauthorized content, the content may simply be corrupted and thus rendered useless. It is appreciated that either technique may be implemented at suitable configured servers or at routers capable of being configured to perform the method of FIG. 4.  
         [0057]    It is appreciated that content that is received from a server in accordance with the present invention may identify the particular server from which it came where the digital watermark embedded by the server is unique to that server. Thus, any attempt to store content on a server in an unauthorized fashion will result in the content being discarded or corrupted in accordance with the method of FIG. 4.  
         [0058]    The validity of a ticket may be determined in accordance with policy table  40  including distribution parameters preferably specified by the content owner and implemented at ticket server  38 . Examples of such distribution parameters may include allowing only proxies located at specific geographical regions to receive and/or supply content, as well as a list of unauthorized servers, or servers whose security has been compromised. Examples of policies may include a server which is located in Italy (region 2) is not authorized to contain Star Wars 8, which is currently authorized for region 1 servers only.  
         [0059]    It is appreciated that functional elements of the invention described herein with respect to a specific server may be incorporated into any other of the servers mentioned herein in accordance with conventional techniques.  
         [0060]    It is appreciated that one or more steps of any of the methods described herein may be implemented in a different order than that shown while not departing from the spirit and scope of the invention.  
         [0061]    While the methods and apparatus disclosed herein may or may not have been described with reference to specific hardware or software, the methods and apparatus have been described in a manner sufficient to enable persons of ordinary skill in the art to readily adapt commercially available hardware and software as may be needed to reduce any of the embodiments of the present invention to practice without undue experimentation and using conventional techniques.  
         [0062]    While the present invention has been described with reference to a few specific embodiments, the description is intended to be illustrative of the invention as a whole and is not to be construed as limiting the invention to the embodiments shown. It is appreciated that various modifications may occur to those skilled in the art that, while not specifically shown herein, are nevertheless within the true spirit and scope of the invention.