WO2002095545A2 - Systeme permettant une confidentialite reseau basee sur une session, une mise en memoire privee, permanente et un controle d'acces discretionnaire pour le partage de donnees privees - Google Patents

Systeme permettant une confidentialite reseau basee sur une session, une mise en memoire privee, permanente et un controle d'acces discretionnaire pour le partage de donnees privees Download PDF

Info

Publication number
WO2002095545A2
WO2002095545A2 PCT/US2002/008275 US0208275W WO02095545A2 WO 2002095545 A2 WO2002095545 A2 WO 2002095545A2 US 0208275 W US0208275 W US 0208275W WO 02095545 A2 WO02095545 A2 WO 02095545A2
Authority
WO
WIPO (PCT)
Prior art keywords
user
server
data
client
encrypted
Prior art date
Application number
PCT/US2002/008275
Other languages
English (en)
Other versions
WO2002095545A3 (fr
Inventor
Colin Savage
Petro Christopher
Sascha Goldsmith
Original Assignee
Ponoi Corp.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ponoi Corp. filed Critical Ponoi Corp.
Priority to AU2002339711A priority Critical patent/AU2002339711A1/en
Publication of WO2002095545A2 publication Critical patent/WO2002095545A2/fr
Publication of WO2002095545A3 publication Critical patent/WO2002095545A3/fr
Priority to US10/695,507 priority patent/US7437550B2/en
Priority to US12/206,079 priority patent/US8572119B2/en
Priority to US14/038,513 priority patent/US8826021B2/en
Priority to US14/341,099 priority patent/US9262608B2/en
Priority to US14/808,805 priority patent/US9619632B2/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • G06F21/6254—Protecting personal data, e.g. for financial or medical purposes by anonymising data, e.g. decorrelating personal data from the owner's identification
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H04L63/0414—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden during transmission, i.e. party's identity is protected against eavesdropping, e.g. by using temporary identifiers, but is known to the other party or parties involved in the communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/168—Implementing security features at a particular protocol layer above the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • This invention generally relates to the field of communications and more particularly to systems and methods for providing secure and private communications over a digital network, including session protection privacy, private remote data storage of data and user access control over such remotely stored private data.
  • a client system 100 is connected over a telecommunications link 110 to an Internet Service Provider (ISP) (not shown) and ultimately to the Internet 150.
  • ISP Internet Service Provider
  • a Web server (Third-Party HTTP server 160) is connected over its own link 161 to the Internet 150.
  • IP Internet Protocol
  • Figure 1A shows the layout of a typical IP packet, including a header 191 containing, among other information, a source address 192 and a destination address 193, as well as data portions, 194, 195, comprising, in this example, 452 "octets" (bytes) of data.
  • Client system 100 runs Web browser software 105 which establishes a display window visible to the user.
  • Web browser 105 submits an http request 125 over the internet.
  • the IP packet containing request 105 contains a header that is encoded with the IP address of client 100.
  • Web server 160 may have previously given a "cookie" to client 100, containing informa- tion regarding the user of client 100. Information from this cookie may also be encoded as data within the IP request.
  • Web server 160 may acquire considerable identity information regarding the user, and will of course further have complete information about the action requested by the http request.
  • the correlation of action and identity is particu- larly valuable to marketers, yet at the same time most threatening to users when in the hands or people outside their confidence and control.
  • Web server 160 parses the http request, and processes it, serving up the Web page requested by the user, and/or conducting further processing via a "common gateway interface” (CGI) 185, which in turn may invoke further processing via scripts and programs 180, which may in turn communicate with databases such as database 190 and/or other facilities.
  • CGI common gateway interface
  • the requested informa- tion is sent back to client 100 by http response 175, again encoded in addressed IP packets and sent to client 100 over the Internet 150.
  • Web browser software 105 receives the http response 175 and from it creates the appropriate screen displays or multimedia effects for the end user.
  • the system commonly used in the prior art to provide some means of isolating an end user from total exposure to the Internet is known as a "firewall" or "proxy server”.
  • Proxy server 140 is shown in Figure 1 as an optional addition to a prior art Internet communication system.
  • Web browser software 105 is adjusted through a setup or configuration facility to direct and receive IP packets in the first instance from proxy server 140, instead ofthe usual router, gateway or similar facility ofthe ISP.
  • Proxy server 140 can then intermediate, and thereby filter undesired or unacceptable input or output (which may be so deemed for any number of reasons, including security and censorship, in addition to privacy), and can also reconstruct IP packets so as to some extent mask the user's identity.
  • the operator ofthe proxy server can readily retrieve, and perhaps secretly misuse, any of this information. Therefore, to be effective, the end user must trust the administrator ofthe proxy server in question, h a commercial setting, and most particularly in a mass market setting, establishing and maintaining such trust in an entity may not be practicable.
  • Crowds which was developed by AT&T, enhances privacy by sharing http requests randomly among a group of subscribed users.
  • the identity of a request sender can trace the identity of a request sender to the group of users, the third party cannot be traced to any specific user.
  • server On receipt of data at server, server generates cryptographic key and stores the data.
  • the result of such systems is that data is protected in transit and while stored.
  • such systems still suffer from the drawbacks that the identity of end user is known to storing server, and that the contents of stored data are known to storing server just prior to the data being encrypted for local storage.
  • a data is request sent to server through protected channel such as Secure Socket Layer (SSL) connection; and
  • SSL Secure Socket Layer
  • the server On receipt ofthe data request at the server, the server checks the request against secondary access control system that contains an index of data objects, users, and associated access privileges.
  • the system disclosed here provides greater security than prior solu- tions.
  • the system described here goes beyond masldng the identity ofthe sender from third parties and masks the identity ofthe sender from both third parties and the system itself. This masking is accomplished by separating action from identity on the client computer.
  • the Crowds system prevents third-parties from knowing the identities of senders, the Crowds system itself, and the other systems discussed above, have the ability to know both the identity and actions of its users.
  • the greater security provided by the system has the additional benefit of enabling more personal communications to be sent through the system. Because the system does not rely on removing identifying information for its functionality, end users can receive the benefits of identity protection without sacrificing the ability to act as individuals rather than anonymous entities.
  • the invention seeks to provide users with a greater degree of privacy than is available with existing technologies.
  • the system separates a user's identity and action.
  • the identity and action information are encrypted and forwarded to an identity server (which knows the user's identity but cannot decrypt the ac- tion information); the identity server forwards the encrypted action information to a action server (to which the action is anonymous), which carries out the action, encrypts the results and forwards them to the identity server (which cannot know them because they are encrypted), which in turn returns them to the user, which has a de- cryption key for the returned data.
  • the system allows individuals and computer applications to store data remotely onto the network in such a way that the storage provider cannot identify the owner or contents of stored data; in such a way that other individuals and computer applications can access all or part ofthe stored data; and in such a way that the access control manager cannot identify the identity or access privileges of indi- viduals or computer applications and cannot identify the contents of stored data.
  • this may be done by treating the data storage request as an "action” an also creating a "user object" to be held by the action server but retrievable by the user, to catalog the user's privately stored data.
  • the client encrypts all data prior to storage in the database • In this system, the system is not able to decrypt any individual object
  • the system stores data privately as discussed above. A further "ac- tion" is permitted, in which one user can grant access to a second user, or to a group of users. The access is effectuated by passing keys and pointes through a "message queue" maintained on the action server and examinable by users when they retrieve their respective user objects. • In this system, the system enforces access control restrictions on the server, not on the client, without knowing the identity ofthe accessor, the contents ofthe data he is accessing, or their access privilege.
  • the system allows end users and client applications to grant, change, or revoke access to stored data and user groups.
  • Figure 1 shows a prior art system whereby Web browser software communicates over the Internet with a Web server, optionally through the intermediate means of a proxy server.
  • Figure 1A shows the header and data layout of a typical IP packet as used over the Internet.
  • FIG. 2 is a block diagram showing the system architecture employed in connection with an embodiment ofthe Ponoi session protection aspect of the invention.
  • Figure 3 is a diagram showing a range of additional functions that may be provided based in part on the technology ofthe Ponoi session protection aspect ofthe present invention.
  • Figure 4 is a block diagram showing the request transmission side of a transaction in accordance with an embodiment ofthe Ponoi session protection aspect ofthe invention.
  • Figure 5 is a block diagram showing the action response side of a transaction in accordance with an embodiment ofthe Ponoi session protection aspect of the invention.
  • Figure 6 is a block diagram showing the principal physical components utilized in connection with an embodiment ofthe Ponoi session protection aspect ofthe present invention, and their interconnection over the Internet.
  • Figure 7 is a flow chart showing the steps involved in the session initialization portion ofthe methods employed in connection with an embodi- ment ofthe Ponoi session protection aspect ofthe invention.
  • Figure 8 is a flow chart showing the steps involved in the request transmission portion ofthe methods employed in connection with an embodiment ofthe Ponoi session protection aspect ofthe invention.
  • Figure 9 is a flow chart showing the steps involved in the response transmission portion of the methods employed in connection with an embodiment ofthe Ponoi session protection aspect ofthe invention.
  • Figure 10 is a flow chart showing the steps involved in the session termination portion ofthe methods employed in connection with an embodiment ofthe Ponoi session protection aspect ofthe invention.
  • Figure 11 is a component-level block diagram showing some ofthe functional components employed in connection with additional embodiments ofthe invention that provide private persistent storage and access control.
  • Figures 12 - 16 are Unified Modeling Language (UML) diagrams of certain objects employed in the implementation of various embodiments of the invention.
  • UML Unified Modeling Language
  • HTML Hypertext Mark-up Language
  • MIME Multimedia Internet Mail Extensions IP: Internet Protocol (version 4)
  • SSL Secure Socket Layer URI: Universal Resource Identifier
  • WWW World Wide Web
  • “Ponoi session protection” means conducting communications over a network with the use of a system as claimed in the parent United States patent application, US 09/453,239, specifically, "A system for providing communications over a network, by means in- eluding at least a client and a remote server, wherein a user may submit a request through said client for a specified action to be performed in response to said request by said remote server, said user-submitted request comprising identity information that identifies the user making the request, and action information that specifies the action requested from said remote server by said user, and wherein said communications are provided in a secure and anonymous manner in that said action information is submitted to said remote server without revealing said identity information to said remote server, and in that only said client, and not any facility through which said action information or any re- sponse thereto passes in the course of being submitted to or received from said remote server, possesses both said identity information and said action information, said system comprising (in addition to said client and remote server):
  • the present disclosure makes a distinction between enabling anonym- ity, in which case privacy results from stripping all unique information from a user, and privacy, in which case identifying information is retained but kept secure.
  • the first component ofthe system is a client application (for example, Java applet client 606) that acts as an HTTP proxy for a user's web browser software while they are connected to the system.
  • client application for example, Java applet client 606
  • This application is the only portion ofthe system that resides on client systems (such as client system 100) and will be communicated to those systems via the world-wide-web (for example, by ftp or http download from a server (not shown) associated with what is re- ferred to in Figure 6 as the "privacy" or "system” facility 300.
  • the second component is an identity server 251, which is part of privacy facility 300, that receives requests 225 from the client application and forwards them for further processing.
  • the identity server 251 maintains the information required to transmit informa- tion back to a user for the duration of that user's HTTP session.
  • the third and final component ofthe system is an action server 252 that performs HTTP requests on behalf of the system's users (e.g., user 200, etc.).
  • the action server (252) must never have access to information that is specific to an individual user ofthe system, rather, it acts on behalf of the identity server 251 and return the results 275 of a user's HTTP request to the identity server 251 for transmission to the client.
  • the mechanism by which the identity server 251 is prevented from accessing information about the destination of an HTTP request and by which the action server 252 is prevented from accessing information about the source of a request is a communication protocol that employs public key cryptographic techniques. See generally, Rivest, et al., US 4,405,829.
  • cryptographic techniques to guarantee that the system internally separates identity information from action information, we also guarantee that this separation is maintained on either side ofthe system facility 300.
  • third parties monitoring network traffic going to or coming from any ofthe servers in the system facility, either legally or illegally are never able to connect an action taken by the server to the identity of a user who is connected to the server.
  • the persons administering such servers also do not have any means for making such a connection. Thus, it is not necessary for such administrators to be trusted by users ofthe system in order for such users to derive the security and anonymity benefits provided by the inven- tion.
  • the identity server, action server and other elements thereof can be separate processes on a single machine or processor, processes on separate machines or processors. Such servers and other elements can be under the same administration or sepa- rate administration. The determination of such matters is not critical to the invention. Rules:
  • the system preferably functions in accordance with the following rules:
  • the action server 252 has full knowledge of individual's actions but no knowledge of individual's identity
  • the identity server 251 has full knowledge of individual's identity but no knowledge of individual's actions
  • the Java applet client 606 separates identity and action information
  • Each of the action server 252, identity server 251 and Java applet client 606 have a unique pair of public-private keys •
  • the action server 252 and Java applet client 606 can communicate with one another only by passing encrypted requests through identity server
  • system initialization 710 begins when user 200 who is running a Web browser 105, downloads the code for Java applet client 600 from a server associated with the system facility 300.
  • the Java applet client 606, running under Web browser 105 changes browser 105's proxy setting to direct http requests through the Java applet.
  • the Java applet client 606 creates public-private key pair.
  • Java applet client 606 receives identity server's (251) public key.
  • step 750 the Java applet client 606 encrypts its public key with the identity server's (251) public key and sends its public key, so encrypted, to identity server 251.
  • step 760 the identity server 251 encrypts action server's (252) public key with the Java applet client's (606) public key, and sends action server's (252) public key, so encrypted, to Java applet client 606.
  • step 770 Java applet client 606 encrypts its public key with the action server's (252) public key and sends its public key, so encrypted, to action server (252) via identity server 251.
  • request transmission comprises the following steps:
  • Java applet client 606 monitors the input-output streams from browser 105.
  • Java app- let client 606 which has been configured as such browser's http proxy, receives the request and parses it into separate identity and action information.
  • Java applet client 606 creates a first sealed object containing the action information for the http request 125, encrypted with the action server's (252) public key.
  • the Java applet client 606 creates a second sealed object containing the identity information for the http request 125 encrypted with the identity server's (251) public key
  • Java applet client 606 sends both sealed objects to the identity server 251.
  • identity server 251 forwards the action sealed object to the action server 252.
  • step 870 action server 252 decrypts action information for the http request and forwards it, preferably through another intermediate http proxy (not shown), to the destination third part server. Response transmission
  • response transmission comprises the following steps:
  • step 910 the action server 252 receives http response 275 from the third-party server, preferably through said intermediate http server.
  • action server 252 encrypts http response 275 with the Java applet client's (606) public key.
  • step 930 action server 252 forwards encrypted http response 230 to identity server 251.
  • identity server 251 forwards encrypted http response 230 to Java applet client 606.
  • Java applet client 606 decrypts http response 230 and forwards it to browser 105 for display.
  • Session termination As shown in Figure 109, session termination comprises the following steps:
  • Java applet client 606 purges public-private key pair it has created.
  • Java applet client 606 resets browser 105 proxy settings to previous values.
  • Figure 3 reflects other functionality in addition to simple network navigation and Web browsing 301 that is provided in connection with the invention.
  • Such functionality includes without limitation Web browsing with passwords 302, electronic mail 303, file storage and transfer 304, chat 3Q5, telephony 306, transactions 307, and electronic commerce 308.
  • the proxy client ofthe first embodiment is the system component responsible for connecting end-users to the system. It functions as an HTTP proxy server and service HTTP requests from a user's web browser. Requests transferred through the system proxy client are encrypted and transferred to the identity server. Responses received by the proxy client from the action server via the identity server are decrypted and returned to a user's web browser. Upon invocation from a known URL on the world- wide- web, the proxy client is loaded from a JAR file by a client web browser.
  • the proxy client Once loaded, the proxy client generates and/or retrieve the cryptographic data required to establish a secure communication channel with the system action server, and automatically configures the user's web browser to use the proxy client as a proxy server for browsing the world- ide- web (or alternately prompts the user to make this setting manually).
  • the proxy client After receiving an HTTP request generated by a user's web browser, the proxy client establishes a secure connection to the identity server using the communication protocol discussed later in this disclosure. In the event of connection failure, the proxy client informs the user of the failure via a dialog box, and configuration changes to the user's web browser are reversed. Assuming a connection to the identity server can be successfully established, the proxy client filters all identifying information from the current HTTP request, removing HTTP header data or replacing header values with non- identifying defaults as neccessarry. The HTTP request is then be appended to any cryptographic data required for response transmission and both are be encrypted using the cryptographic protocol specified as part ofthe the system communication protocol (see Communication Protocol section below). Encrypted data is then be placed within a well formed the system protocol request, and the request is transmitted to the identity server.
  • the proxy client waits for a response. If a valid response is received, that response is be decrypted and returned to the user's web browser. Should the system fail to respond to a proxy client's request for a specified timeout interval, the proxy client aborts request processing and returns an error page to the user's web browser.
  • the proxy client applet Upon receiving a request from a web browser, the proxy client applet initiates a connection to the identity server. Once this connection is established the identity server reads the contents of an encrypted HTTP request from the proxy client. Should a valid request not be received within a specified time-out interval, the identity server 251 terminates the connection with the proxy client applet.
  • the identity server After receiving an encrypted client request, the identity server estab- lishes a communication connection with the action server, and forward the request for further processing, i the event that a connection between the Identity and action servers cannot be established, the identity server terminates its connection with the proxy client applet. Once a connection is successfully established and those portions ofthe client request not related to the client's identity have been transferred, the identity server waits for a response from the action server. Again, in the event that a response is not received within a specified time-out interval, the identity server terminates its connection with the proxy client applet. Finally, valid response data received from the action server is forwarded to the proxy client applet, and all IP connections are terminated.
  • Action Server After receiving an encrypted client request, the identity server estab- lishes a communication connection with the action server, and forward the request for further processing, i the event that a connection between the Identity and action servers cannot be established, the identity server terminates its connection with the proxy client applet. Once a connection is successfully established and
  • the action server 252 is a background process that resides on a computer system associated with system facility 300. Its role is to execute HTTP requests on behalf of users ofthe system, and act as an end-point for the cryp- tographically secure communication channel by which data is transferred be- tween the system's back-end facilities and its users.
  • a connection is established between the identity server and an action server residing on a different physical computer. This connection is used to forward the HTTP request to the action server where it is decrypted. After decryption, the clear text HTTP request is forwarded to a standard HTTP proxy server that retrieves the requested URL and returns it to the action server.
  • the action server terminates its IP connections with both the proxy server and the identity server. If a valid HTTP response is received by the action server, that response is encrypted using the cryptographic data provided along with the HTTP request, and the response is returned to the proxy client via the identity server.
  • a single communication protocol is used to relay HTTP requests from the proxy client applet to the identity server and from the identity server to the Action Server.
  • This protocol contains encrypted HTTP data augmented with a cryptographic key exchange mechanism and a minimal amount of control information.
  • Two transmission formats are defined by this specification, the first for communication to the action server, and the second for communication by the action server.
  • HTTP requests transmitted by the proxy client to the identity server for processing by the action server is formatted as follows:
  • Each transmission consists of three distinct parts.
  • the first is a 96-bit long clear text header block that contains control information for the transmission.
  • the second and third portions are encrypted data blocks of variable length.
  • the header is immediately followed by the proxy client's public key in order to permit responses from the action server to be encrypted for transmission to the proxy client.
  • the HTTP Request received from a user's web browser follows the public key.
  • Magic Cookie An identifier used to rapidly indicate a valid transmission. All components ofthe system shall terminate communications that do not begin with this sequence.
  • HTTP responses transmitted by the action server to the proxy client are formatted as follows:
  • Each transmission consists of two distinct parts. The first is an 80-bit long clear text header block that contains control information for the transmission. The second portions is an encrypted data block of variable length containing the HTTP response for a client's request.
  • Magic Cookie (bits 0-31): A unique identifier used to rapidly indicate a valid transmission. All components ofthe system shall terminate communications that do not begin with this sequence.
  • Protocol Version (bits 32-39): A number used to identify the version ofthe protocol for future compatibility. The version ofthe protocol used in the prototype implementation will be 0x01 (one).
  • HTTP Response Data Length (bits 40-72): Length ofthe encrypted HTTP Response in bytes.
  • Persistent objects include binary data, collec- tions and users.
  • Access control data is used to validate that a given user's request is allowed under the permissions set up by the object's owner.
  • Cryptography protects both the persistent objects and their associated access control entries such that the system never has sufficient information to decrypt both, or to associate a given access control entry with an object persistently.
  • a client application residing on the end user's (or end computer's) computer (1101).
  • server (1105) The system has the goal of protecting stored, or persistent, data such that:
  • the client application is a Java applet within an end user's web browser; the first intermediate server is known as the identity server; the second intermediate server is known as the action server; and there are no further intermediate servers.
  • (c) generating a data object identifier within the client application.
  • This can be a pseudorandom number, preferably a very large pseudorandom number to minimize any possibility ofthe same identifier being de- rived in a subsequent session and/or by a different user;
  • the requested user object residing on the action server comprises a data object decryption key and a data object identifier is encrypted with a user object encryption key;
  • a client application residing on the end user's computer or interoperating with a computer application.
  • the system has as a goal protecting stored, or persistent, data such that:
  • the server portions ofthe system cannot associate one object with another •
  • the server portions of the system cannot associate an object with its owner or others with access rights to stored data
  • the server portions of the system cannot know access privileges associated with a set of data and/or a set of individual(s) or application ⁇ ).
  • the client application is a Java applet within an end user's web browser; the first intermediate server is known as the identity server; the second intermediate server is known as the action server; and there are no further intermediate servers.
  • the following steps are employed:
  • the action server storing the encrypted data in a database (1106, 1109) under the control ofthe action server, using the data object identifier as a locator and maintaining an association with the public challenge key.
  • the accessing user providing authentication token to client application (1102); (b) generating within the client application a user object identifier based on the authentication token in the same manner previously used to generate the user object identifier associated with the accessing user on the action server; (c) sending the user object identifier and a request for a user object to the action server (1105) through the identity server (1104) in accordance with the method of claim 1; (d) if the user object identifier matches a user object identifier previously stored by the action server, sending the requested user object to the client application through the identity server in accordance with the method of claim 1, the requested user object comprising a reference to the accessing user's message queue on the action server and a message queue decryption key;
  • the action server retrieving the message queue from a database (1106, 1108) under control ofthe action server, and returning the message queue to the client application through the identity server, in accordance with the method of claim 1, the message queue comprising a message object previously inserted in the message queue in accordance with claim 4; (g) reading the message queue decryption key from the user object;
  • Central data holder does not know the contents or owner ofthe stored data. Central data holder does not know access rights of others to the stored data. Central data holder is able to apply access privileges to stored data.
  • Groups (actually known as a collection, inside the code) are treated as meta-collections of users. That is, just as a user has a message queue, so too does a group have a message queue. Just as an object has a challenge key, so too does a group have a challenge key. In practice, a user would have, in his user object, a reference to a group and group challenge to which he belonged.
  • Ponoi session protection could use any other means of network storage, such as a standalone storage server with which client applications communicate via secure socket layers (SSL).
  • SSL secure socket layers
  • a system involving the use of Ponoi session protection could be configured such that data transfers were broken down into data increments and a plurality of identity and action servers were employed in a distributed processing manner.
  • Persistent data is protected with stronger encryption than session traffic.
  • the client generates additional symmetric keys to encrypt persistent data. Since the data may be retrieved during a subsequent session, the private, the key must be stored persistently to decrypt the data.
  • Top-level objects use a pass phrase-based cipher to encrypt the top- level object data.
  • This cipher uses a base-64 encoded, one-way hash ofthe user's name and password as the seed for a symmetric DES key.
  • Top-level objects are thus protected with the strongest level of encryption.
  • the user's name and password are re-hashed and encoded to create a new DES symmetric key to decrypt the user object.
  • the user is thus the only agent capable of decrypting the top-level object without mounting a dictionary attack.
  • the client regenerates its persistent-strength 3DES or Blowfish key.
  • the object will be encrypted with this key.
  • the key will be stored in the parent ofthe object being created. In addition to storing the key, the parent also contains a locator for the child object.
  • the client creates nearly all locators in the system. These are based on a series of one-way hashes of data the user knows but could not be readily guessed (e.g., user name and password).
  • the client creates the appropriate hashed locator. All other locators in the system are stored encrypted under a top-level object. Users may navigate their 'tree' in memory on the client one level at a time. For example, given a decrypted object, the client application may reference the object locators and decrypters of all child objects directly linked to the parent object. When that object is retrieved and decrypted, it may contain locators to other collections or persistent objects, as well.
  • Challenges verify that a given user has the credentials necessary to execute a request, typically a persistent storage or retrieval request requiring use ofthe access control system. All challenges use asymmetric, or public- private, cryptography. To protect against a "known ciphertext" attack against the client by the server, these challenges do not use standard encryption/decryption, but rather use signing/verifying. Thus, the algorithm chosen must support digital signatures.
  • the challenge system functions as follows:
  • Client request requires verification of identity without furnishing personally-identifiable data
  • Server sends RI to client (may be sent in plaintext)
  • Client generates random number R2 6.
  • Client signs RI and R2 with private, signing key - S(R1R2)
  • Client sends server signed bytes (may be sent in plaintext)
  • a core component ofthe Ponoi service is to provide encryption and decryption services that secure users both within single sessions and across multiple sessions. Authentication begins within a basic Ponoi session and is therefore secure. Successful authentication prompts a registered user Ponoi session. The idServer receives and stores only digests of user name and password for added security.
  • the access control entry for a user object is encrypted by the server at account creation with passphrase-based encryption (PBE).
  • PBE passphrase-based encryption
  • This cipher is generated by taking a hashing a hash ofthe user name and double-hash ofthe user password.
  • the actual user object is protected by the inverse of this (e.g., hashing a double-hash of the user name and a single-hash ofthe password). Since only the user knows both the name and password of the account, neither hash can be computed from the other.
  • the client uses the standard access control system to authenticate to an account (user) object. If the user can decrypt both the access control entry and the user object, the user has been authenticated.
  • access control is primarily a server- centric component.
  • the client initiates the create request.
  • the server creates an empty database record and an access control entry for the object, which is returned after the database creation is successful.
  • the client then updates the object with the access control entry. It then encrypts the object and uploads it to the server, which fills the remainder ofthe database record.
  • the access control record is stored encrypted on the server.
  • the access controller on the server returns the location ofthe access control record in the database, as well as two sets of decrypting keys for the access control record.
  • the first key known as the access decrypter
  • the second key known as the owner de- crypter, is used solely to grant and revoke access to other users.
  • Each access control list may have one or more access control entries. These entries are identified by a random hash, called the access control locator. These locators do not map in any way to the user or account locators discussed earlier. Each locator also has an asymmetric private key used to verify the identity ofthe requestor, without actually using personally-identifiable information. The client maintains a set of public signing keys that will be used to correctly respond to cryptographic challenges from the server (see Challenges in Cryptography above).
  • the client To read, modify or delete an object, the client must supply the correct access locator and decrypter for the access control entry. If the server can lo- cate and decrypt the access control entry successfully, and if the permissions decrypted match the permissions required for the request, the server will execute the request. Otherwise, a permission denied exception will be thrown and displayed to the user.
  • create privilege works slightly differently than read, update and de- lete. Create acts on a parent collection, and the create privilege translates to "has privileges to create child objects under this collection". Thus, create acts on a parent, containing object while all other privileges act on the object itself.
  • Grant and revoke extend the discretionary access control system by allowing rights to objects to be shared among users and collections.
  • the user To issue a grant, the user must supply the owner decrypter ofthe access control record for that object. If the system is able to successfully decrypt both the permissions and the owner encrypted portions ofthe access record, the server will process the grant request.
  • a new access control entry is created, based on the existing access control entry.
  • the client portion of this entry (locator and decrypters) will be placed in the requesting user's public in-box.
  • the in-box will be read by the client and decrypted.
  • the user object will then be updated by the client with the new access control information and saved to the database.
  • the access control grant is deleted from the user's in-box.
  • Revoke Revocation is the mirror-image of granting access.
  • his or her corresponding access control record in the database is invalidated. If the user attempts to use the system to access that record in the future, the locators and decrypters to the data will now be invalid.
  • the user will receive a notification, in their public in-box, that access to a specific object has been revoked.
  • the client will remove the entry from the user's internal list of access control entries and re-save the object. Even with a corrupted client attempting to re-transmit previously valid data will not be able to access the system. No key on the client will decrypt a valid access control en- try in the system any longer.
  • Ponoi The database design of Ponoi provides persistent, anonymous, encrypted data storage. All data stored in Ponoi is encrypted. All primary keys consist of a one-way hash of the actual primary key name. Only the client application or applet has the ability to locate and decrypt records. See Figure 12 for a general depiction of this data model.
  • Collections may contain other collections or an object.
  • One special type of collection is a user or owner collection. These collections use Ponoi 's authentication protocol, currently based on a user name and password, to validate a user's identity. All other object requests take place through the access control sub-system.
  • the assertion column maps to a server AccessRecord or GroupRecord meta-object.
  • the data column maps to a client PersistentObject, Collection, Group, User or File object.
  • Queue Table All objects contain a 'public' inbox that other users in the system may drop encrypted data into.
  • the encrypter column contains the key that will encrypt all data put in the inbox.
  • the verifier is used to challenge the owner for access to view the queue. No challenge is required to add new messages to a queue.
  • the crypto_settings column maps to a server CryptoSettings meta- object.
  • Each public collection may have zero or more public item children.
  • the encrypter from the parent public collection will be used by the client to encrypt the data for the public item.
  • One use of the public inbox for a user is the granting and revocation of access control rights to other objects or users.
  • the data column maps to a client Message meta-object.
  • the system values table holds global data not pertaining to any user or group's persistent data. The only current use of this table is to hold the server, private trust key, used to assure secure key exchange (see Ses- sion.Cryptography above).
  • Persistent objects include binary data, collec- tions and users.
  • Access control data is used to validate that a given user's request is allowed under the owner's specified permissions.
  • Cryptography protects both the persistent objects and their associated access control entries such that the system never has sufficient information to decrypt both, or to associate a given access control entry with an object.
  • All persistent data in the system whether a user account, collection or binary data is stored as a PersistentObject.
  • Each object must have a name, which is unique within its parent Collection (if a child object) or the all top- level objects (if a top-level object).
  • all objects contain an ObjectRecord, which contains the information needed to locate the object in the database and the keys to decrypt it.
  • Each object contains an ObjectRecord. This describes which database tables the object and its associated access control data are stored.
  • the primary key for both the object and its access record, as well as all persistent private keys needed to decrypt the data are stored in the ObjectRecord.
  • These ObjectRecord entries are also stored in the children element of a Collec- tion. This way, a parent collection 'knows' how to locate all child objects or collections once decrypted properly.
  • Any object in the system may have zero of more text attributes associated with it.
  • a file object for example, may store the actual local filesystem location that the file was uploaded from as well as the unencrypted size ofthe file.
  • Collection inherits from PeristentObject.
  • a Collection may contain other PersistentObject or Collection objects, forming a hierarchical tree.
  • the children element contains the records of these other objects.
  • Each child record must be loaded from the database separately. Only the ObjectRecord of a given child is loaded when the object is decrypted. It contains the information needed to locate and decrypt the object and its associated access control record. To actually retrieve the object, a request for the object must be made and access control validated before the actual object will be returned to the client.
  • Access Control Objects ( Figures 15 and 16) AccessRecords exist only in the database and on Ponoi servers.
  • AccessRecord contains the permissions of for a given PersistentObject as well as the encrypting keys needed to re-encrypt the access control record in case of an access control change request (grant, modify or revoke).
  • the ownerEncryp- ter is actually stored encrypted with itself. To assert ownership over an object, the user must additionally correctly respond to a challenge using the own- erVerifier, which differs from the standard verifier.
  • Any request that furnishes a valid accessDecrypter that decrypts the access control entry and successfully responds to a cryptographic challenge from the server allows a permission check.
  • the system checks the parent collection for the rights to create child objects (create privilege).
  • create privilege For other object requests (read, update and delete privileges), the system checks the access confrol permissions on the object itself.
  • the client For access control modifications (grant, modify and revoke privileges), the client must correctly respond to an ownership cryptographic challenge, as above. If successful, then the owner is allowed to re-save the access control entry or create a copy to place in another user's public inbox.
  • the primary components of Ponoi, the client, Identity Server, and Action Server exist as processes on computers.
  • the client would exist as a code library inside a client application on a portable digital assistant (PDA).
  • PDA portable digital assistant
  • the Identity Server and Action Server would exist as one or more code libraries or objects interoperating with a network-based server such as a database or content management system.
  • the functions of protecting session traffic, data stor- age, and access control would occur through the intercommunication of these Ponoi processes residing on multiple computers.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Databases & Information Systems (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Medical Informatics (AREA)
  • Computer And Data Communications (AREA)
  • Storage Device Security (AREA)

Abstract

La présente invention permet l'établissement de communications sûres et privées sur un réseau, ainsi que la mise en mémoire privée, permanente et le contrôle d'accès privé aux informations mises en mémoire, par imposition de mécanismes qui séparent les actions d'un utilisateur de leur identité. Ledit système permet (i) la navigation anonyme sur réseau, auquel cas le système d'anonymat n'est pas averti de l'identité de l'utilisateur et des activités de navigation, (ii) la mise en mémoire sur réseau privé et l'extraction de données telles que des mots de passe, des profils et des fichiers de sorte que les données peuvent être mises en mémoire dans le système et ensuite extraites sans que le système ne connaisse les contenus ou propriétaires des données, et (iii) à l'utilisateur de contrôler et gérer l'accès aux données mises en mémoire de manière éloignée sans que le système ne connaisse les contenus, les propriétaires, ou les accesseurs aux données.
PCT/US2002/008275 1999-12-02 2002-04-19 Systeme permettant une confidentialite reseau basee sur une session, une mise en memoire privee, permanente et un controle d'acces discretionnaire pour le partage de donnees privees WO2002095545A2 (fr)

Priority Applications (6)

Application Number Priority Date Filing Date Title
AU2002339711A AU2002339711A1 (en) 2001-04-20 2002-04-19 System and method for secure and private communication
US10/695,507 US7437550B2 (en) 1999-12-02 2003-10-28 System for providing session-based network privacy, private, persistent storage, and discretionary access control for sharing private data
US12/206,079 US8572119B2 (en) 1999-12-02 2008-09-08 System for providing session-based network privacy, private, persistent storage, and discretionary access control for sharing private data
US14/038,513 US8826021B2 (en) 1999-12-02 2013-09-26 System for providing session-based network privacy, private, persistent storage, and discretionary access control for sharing private data
US14/341,099 US9262608B2 (en) 1999-12-02 2014-07-25 System for providing session-based network privacy, private, persistent storage, and discretionary access control for sharing private data
US14/808,805 US9619632B2 (en) 1999-12-02 2015-07-24 System for providing session-based network privacy, private, persistent storage, and discretionary access control for sharing private data

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US28520001P 2001-04-20 2001-04-20
US60/285,200 2001-04-20

Related Parent Applications (3)

Application Number Title Priority Date Filing Date
US09/453,239 Continuation-In-Part US6442687B1 (en) 1999-12-02 1999-12-02 System and method for secure and anonymous communications
PCT/US2000/030168 Continuation-In-Part WO2002045335A1 (fr) 1999-12-02 2000-11-30 Systeme et procede pour securiser les communications anonymes
PCT/US2000/030168 Continuation WO2002045335A1 (fr) 1999-12-02 2000-11-30 Systeme et procede pour securiser les communications anonymes

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US10/695,507 Continuation US7437550B2 (en) 1999-12-02 2003-10-28 System for providing session-based network privacy, private, persistent storage, and discretionary access control for sharing private data

Publications (2)

Publication Number Publication Date
WO2002095545A2 true WO2002095545A2 (fr) 2002-11-28
WO2002095545A3 WO2002095545A3 (fr) 2003-01-23

Family

ID=23093198

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2002/008275 WO2002095545A2 (fr) 1999-12-02 2002-04-19 Systeme permettant une confidentialite reseau basee sur une session, une mise en memoire privee, permanente et un controle d'acces discretionnaire pour le partage de donnees privees

Country Status (2)

Country Link
AU (1) AU2002339711A1 (fr)
WO (1) WO2002095545A2 (fr)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008065341A2 (fr) 2006-12-01 2008-06-05 David Irvine Maidsafe.net
WO2013077935A1 (fr) * 2011-11-22 2013-05-30 Google Inc. Navigation privée sur le web faisant appel à un chiffrement
BE1021435B1 (fr) * 2014-07-28 2015-11-20 Elegio Methode pour gerer un vote electronique
US9619632B2 (en) 1999-12-02 2017-04-11 Ponoi Corp. System for providing session-based network privacy, private, persistent storage, and discretionary access control for sharing private data
CN111179008A (zh) * 2019-07-22 2020-05-19 腾讯科技（深圳）有限公司 一种信息状态的更新方法、装置、系统及存储介质
CN112688949A (zh) * 2020-12-25 2021-04-20 北京浪潮数据技术有限公司 一种访问方法、装置、设备及计算机可读存储介质
CN112948874A (zh) * 2021-02-10 2021-06-11 上海凯馨信息科技有限公司 一种密态数据访问方法
CN113177216A (zh) * 2021-04-30 2021-07-27 北京市商汤科技开发有限公司 一种数据传输方法、装置、计算机设备和存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5748739A (en) * 1994-11-05 1998-05-05 International Computers Limited Access control for sensitive functions
US5923885A (en) * 1996-10-31 1999-07-13 Sun Microsystems, Inc. Acquisition and operation of remotely loaded software using applet modification of browser software
US5961593A (en) * 1997-01-22 1999-10-05 Lucent Technologies, Inc. System and method for providing anonymous personalized browsing by a proxy system in a network
US6088799A (en) * 1997-12-11 2000-07-11 International Business Machines Corporation Security method and system for persistent storage and communications on computer network systems and computer network systems employing the same
US6195432B1 (en) * 1996-03-11 2001-02-27 Kabushiki Kaisha Toshiba Software distribution system and software utilization scheme for improving security and user convenience

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5748739A (en) * 1994-11-05 1998-05-05 International Computers Limited Access control for sensitive functions
US6195432B1 (en) * 1996-03-11 2001-02-27 Kabushiki Kaisha Toshiba Software distribution system and software utilization scheme for improving security and user convenience
US5923885A (en) * 1996-10-31 1999-07-13 Sun Microsystems, Inc. Acquisition and operation of remotely loaded software using applet modification of browser software
US5961593A (en) * 1997-01-22 1999-10-05 Lucent Technologies, Inc. System and method for providing anonymous personalized browsing by a proxy system in a network
US6088799A (en) * 1997-12-11 2000-07-11 International Business Machines Corporation Security method and system for persistent storage and communications on computer network systems and computer network systems employing the same

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9619632B2 (en) 1999-12-02 2017-04-11 Ponoi Corp. System for providing session-based network privacy, private, persistent storage, and discretionary access control for sharing private data
WO2008065341A2 (fr) 2006-12-01 2008-06-05 David Irvine Maidsafe.net
EP2472430A1 (fr) 2006-12-01 2012-07-04 David Irvine Cryptage automatique
WO2013077935A1 (fr) * 2011-11-22 2013-05-30 Google Inc. Navigation privée sur le web faisant appel à un chiffrement
AU2012238335B2 (en) * 2011-11-22 2015-05-07 Google Inc. Private web browsing using encryption
BE1021435B1 (fr) * 2014-07-28 2015-11-20 Elegio Methode pour gerer un vote electronique
CN111179008A (zh) * 2019-07-22 2020-05-19 腾讯科技（深圳）有限公司 一种信息状态的更新方法、装置、系统及存储介质
CN111179008B (zh) * 2019-07-22 2024-02-20 腾讯科技（深圳）有限公司 一种信息状态的更新方法、装置、系统及存储介质
CN112688949A (zh) * 2020-12-25 2021-04-20 北京浪潮数据技术有限公司 一种访问方法、装置、设备及计算机可读存储介质
CN112688949B (zh) * 2020-12-25 2022-12-06 北京浪潮数据技术有限公司 一种访问方法、装置、设备及计算机可读存储介质
CN112948874A (zh) * 2021-02-10 2021-06-11 上海凯馨信息科技有限公司 一种密态数据访问方法
CN112948874B (zh) * 2021-02-10 2023-04-18 上海凯馨信息科技有限公司 一种密态数据访问方法
CN113177216A (zh) * 2021-04-30 2021-07-27 北京市商汤科技开发有限公司 一种数据传输方法、装置、计算机设备和存储介质
CN113177216B (zh) * 2021-04-30 2023-03-14 北京市商汤科技开发有限公司 一种数据传输方法、装置、计算机设备和存储介质

Also Published As

Publication number Publication date
WO2002095545A3 (fr) 2003-01-23
AU2002339711A1 (en) 2002-12-03

Similar Documents

Publication Publication Date Title
US9619632B2 (en) System for providing session-based network privacy, private, persistent storage, and discretionary access control for sharing private data
US9781114B2 (en) Computer security system
Feamster et al. Infranet: Circumventing web censorship and surveillance
US9537864B2 (en) Encryption system using web browsers and untrusted web servers
JP4907895B2 (ja) プライベートデータを露出せずに通信ネットワークを介してパスワードで保護されたプライベートデータを回復する方法およびシステム
US7441116B2 (en) Secure resource distribution through encrypted pointers
US8145898B2 (en) Encryption/decryption pay per use web service
EP2020797B1 (fr) Appareil et procédé de passage de jetons opaques pour le serveur client
JP4366037B2 (ja) 暗号化された媒体へのアクセス権を制御・行使するシステム及び方法
CA2714196C (fr) Systeme de distribution d'informations et programme s'y rapportant
EP2544117A1 (fr) Procédé et système pour partager et stocker des données personnelles sans perte de confidentialité
US20030081774A1 (en) Method and apparatus for dynamic generation of symmetric encryption keys and exchange of dynamic symmetric key infrastructure
US20030208681A1 (en) Enforcing file authorization access
JP2007200316A (ja) ネットワーク通信システムおよびネットワーク・サーバとクライアント・デバイスの間に、コンピュータネットワークを通じてセキュアな通信リンクを確立する方法
JP2009526322A (ja) 変化識別子を使用するセキュアなデジタル・コンテンツ管理
CN114244508B (zh) 数据加密方法、装置、设备及存储介质
WO2002095545A2 (fr) Systeme permettant une confidentialite reseau basee sur une session, une mise en memoire privee, permanente et un controle d'acces discretionnaire pour le partage de donnees privees
Gritzalis et al. Addressing threats and security issues in World Wide Web technology
WO2009005698A1 (fr) Système de sécurité informatique
Maheshwari Database Security for the Web.
Rogers Proposals for a Revision of Kerberos When Run in Conjunction with the IPsec Protocol Suit
Polemi et al. A framework for the security of telemedical services
Manchala Role-based access control with constrained delegation for the Internet

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG US UZ VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
AK Designated states

Kind code of ref document: A3

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG US UZ VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 10695507

Country of ref document: US

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase in:

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP

DPE2 Request for preliminary examination filed before expiration of 19th month from priority date (pct application filed from 20040101)