[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

WO2001033361A1 - Service de fichiers communs sur internet a acces aux pc clients originels et semantique - Google Patents

Service de fichiers communs sur internet a acces aux pc clients originels et semantique Download PDF

Info

Publication number
WO2001033361A1
WO2001033361A1 PCT/US2000/030077 US0030077W WO0133361A1 WO 2001033361 A1 WO2001033361 A1 WO 2001033361A1 US 0030077 W US0030077 W US 0030077W WO 0133361 A1 WO0133361 A1 WO 0133361A1
Authority
WO
WIPO (PCT)
Prior art keywords
file
node
client node
file server
remote
Prior art date
Application number
PCT/US2000/030077
Other languages
English (en)
Inventor
Robert S. Phillips
Scott H. Davis
Daniel J. Dietterich
Scott E. Nyman
David Porter
Original Assignee
Mangosoft Corporation
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 Mangosoft Corporation filed Critical Mangosoft Corporation
Priority to AU14509/01A priority Critical patent/AU1450901A/en
Publication of WO2001033361A1 publication Critical patent/WO2001033361A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/17—Details of further file system functions
    • G06F16/172—Caching, prefetching or hoarding of files

Definitions

  • the present invention pertains to a multi-user shared file access service provided over a wide area network, such as the Internet.
  • computing resources such as data, programs and applications
  • processing capacity, storage capacity, etc. outside of the home, e.g., at the enterprise campus.
  • a local area network provides some measures of security against eavesdropping and other unauthorized
  • Local area networks enable sharing at two levels. First, groups of
  • users may simultaneously access files in a common storage space. More importantly, users can contemporaneously or simultaneously access the same file.
  • write access to a file, or a specific portion of a file is typically exclusive to one user.
  • privilege access rights are typically specifiable for directories and files.
  • read, write and delete privileges can be restricted to individual users and groups. For example, one user might be provided read, write and delete rights to an entire directory.
  • An entire user group might have only read and write privileges for all files in a directory, but certain users of that group might have only read privileges for a certain file within that
  • a third user group might have only read privileges for all files in a directory.
  • remote storage device which the user can access while executing a web browser program on
  • the user must take deliberate actions while executing the web browser program to transfer files from the user's computer terminal to the remote storage device for storage or to
  • the user uses the pointing to device to select a
  • the user selects a locally stored file for uploading (by locating the file and
  • the application may access locally stored data and configuration files, unbeknownst to the user. On the other hand, if one of these data or
  • configuration files is located at the remote storage device at the time the application is executed, the application is incapable of automatically accessing such a remote file. Rather, the user must know which remote files will be needed for access and must take deliberate
  • a private network e.g., a local area network or a private wide area network link.
  • SSL secured socket layer transfers
  • the files may be subject to
  • StoragepointTM provides a WindowsTM ExplorerTM Name Space extension
  • X-DriveTM provides a more extensive file service for a single user.
  • StoragepointTM, X-DriveTM enables the user to transfer files between the remote storage device and the user's computer terminal using the same actions for transferring the files between locally physically present devices of the user's computer terminal (i.e., icon dragging
  • X-DriveTM also allows applications and programs executing at the user's terminal to seamlessly access files which reside at the remote storage device as such applications or programs would access files stored locally at the user's computer terminal.
  • files are seamlessly, and automatically transferred from the remote stored device to the user's computer terminal by other software provided by X-DriveTM, when such applications or
  • StoragepointTM offers server encryption but X-DriveTM
  • StoragepointTM uses a secured socket layer to transfer encrypted information between the user's computer terminal and the remote file storage device. Once at the remote
  • the information is "re-encrypted" prior to storage to prevent against
  • encryption is performed at the site of the remote file storage device. Again, security can still be
  • Punch NetworksTM provides a version control system whereby every version of a file
  • none of the wide area network services available provide for remote file access which maintains the integrity of files by ensuring that each access to a file at the remote file server is to the most up-to-date copy of the file. Nor do these services enable
  • Each user of a user group of one or more users is enabled to operate an arbitrary client node at an arbitrary geographic location to communicate
  • Each user of the user group is
  • an interface is provided for adapting file access at
  • the interface designates at the first client node each of the one or more accessible files of the file group as stored on a virtual storage device.
  • an encrypted key is transferred from the remote
  • the key is encrypted
  • the key is decrypted at the first client node.
  • the key is used at the first client node to decrypt information of the files downloaded from the remote file server node or to encrypt
  • a manger node which chooses which users may
  • join the group transmits a message to an Internet email address of a user inviting the user to
  • the message is usable only once to join the user
  • remote file server node is authenticated. Specifically, the particular client node verifies the identity of the remote server node, and the remote server node verifies the identity of the user of the particular client node.
  • the particular client node illustratively encrypts data of a file using an
  • the remote file server node stores the encrypted file data.
  • the remote file server node illustratively retrieves from storage the
  • the client node decrypts the data.
  • the remote file server node determines whether or not
  • the remote file server node only permits the access to the particular file by the specific client node if permitted by the privilege access rights
  • one of the files is delegated to a version control node.
  • FIG 1 shows an illustrative network in which an embodiment of the present invention
  • FIG 2 shows an illustrative computer terminal or remote file server of the network of
  • FIG. 1 A first figure.
  • FIG 3 shows an illustrative architecture according to an embodiment of the present invention.
  • FIG 4 shows an illustrative screen displayed on a client node according to an
  • FIGs 5, 6 A and 6B show a flowchart describing a process for joining a new client user
  • FIG 7 shows a flowchart describing an authentication process according to an embodiment of the present invention.
  • FIGs 8 and 9 show flowcharts describing, respectively, a download process and an
  • FIG 10 shows a flowchart describing a file access process according to an embodiment of the present invention.
  • FIGs 11-12 show tables illustrating a reconciliation process according to an
  • FIG 13 shows an illustrative environment of use of another embodiment of the present
  • FIG 14 shows a flowchart illustrating distributed access control according to an
  • FIG 15 shows a flowchart illustrating distributed version control according to an embodiment of the present invention.
  • FIG 1 shows a wide area network 100 such as the Internet. This network is composed
  • devices asl-as4 denote access servers.
  • Computer terminals typically originate and terminate
  • switches, routers and access servers typically merely route messages and communications to another device in transferring such messages or
  • Access servers also control access of
  • the Internet 100 is an interconnection of a plurality of private
  • NAPs network access providers
  • ISP Internet service providers
  • the interconnection of the access networks may be carried by various high capacity (i.e., TI, T3, T4, OC-3, OC-48, etc.) privately leased lines
  • IP Internet protocol
  • TCP control protocol
  • ftp file transfer protocol
  • http hypertext transfer protocol
  • the Internet 100 can carry (in packets) messages for requesting information, and such
  • FIG 2 depicts a typical node in the form of a computer terminal 10.
  • the computer
  • terminal 10 typically includes a processor 11 or CPU, memory 12, one or more I/O devices 13-1, 13-2,..., 13-N (e.g., modems, cable modems, network interface cards, etc.), disk 15 (fixed magnetic, removable magnetic, optical, etc.), graphics accelerator and display monitor
  • An illustrative example of the computer terminal 10 is a "PC" compatible computer
  • processors 11 of appropriate sizes, number and/or capacity.
  • the memory 12 can be any type of memory 12 that can be used to store data.
  • main memory e.g., implemented with SDRAM circuits
  • smaller main memory e.g., implemented with SDRAM circuits
  • cache memory e.g., implemented with SRAM circuits.
  • PC computers such as desktops, laptops and
  • file servers as nodes.
  • the invention is also applicable for other types of nodes such as
  • nodes will be presumed to include "pointer devices"
  • an input device such as a mouse, track pad, joy stick, track ball, stylus,
  • Such a pointer device accepts user input regarding direction and selection and supports the
  • the invention is illustrated herein for the Internet as the wide area network, but of course is applicable to other wide area networks.
  • Client node describes a device such as a computer terminal hl-h8, adapted according to the invention for purposes of enabling access to files stored locally in the memory 12 or disk 15 of the client node or remotely as described herein.
  • Remote file server node describes an apparatus, such as a file server
  • computer h9-hl0 including a storage device, such as one or more disk drives 15, memory
  • circuits 12, etc. adapted according to the invention to enable multiple simultaneous client node access to groups of files.
  • remote file server nodes e.g., nodes h9-hl0, which can be implemented using Proliant
  • disk storage capacity e.g., implemented using EMC Symetrix SANsTM, distributed by EMC Corp.TM, a company located in Hopkinson, Massachusetts. This disk storage capacity is
  • a group of users is enabled to access the group of files on such a virtual storage
  • server nodes effectively provide a consistent and persistent "home" at which a master copy of
  • each file of the group is persistently maintained.
  • the remote file server nodes h9-hl0 enable access to the files in a shared fashion-multiple client nodes operated by users can
  • the copies of the files on the remote file server nodes serve as a master or true source copy
  • the accesses to the copies of the files at the remote file server nodes illustratively are
  • the files "appear,” i.e., entirely behave, and can be accessed
  • remote file server nodes are geographically remote and may be operated by
  • a manner is provide for each of the client nodes and the remote file server nodes to authenticate each other prior to communicating sensitive information.
  • Second, a secure channel is provided to enable transfer of file data over the Internet, which
  • the users illustratively can access the files while operating client nodes on a local area
  • client node h8 can access the files using portable client nodes, such as laptops.
  • client node h8 can access the files using portable client nodes, such as laptops.
  • client node h8 can access the files using portable client nodes, such as laptops.
  • client node h8 can access the files using portable client nodes, such as laptops.
  • client node h8 can access the files using portable client nodes, such as laptops.
  • any available communication channel to the Internet 100 e.g., a land-line
  • the remote file server nodes can implement several virtual storage devices.
  • a group FI of one or more virtual storage devices can be provided for
  • a group F2 of one or more additional virtual storage devices can be provided for an entirely contained subset of users of that group G2 Gl .
  • Yet another group F3 of one or more additional virtual storage device can be provided entirely for a distinct
  • user gl can freely
  • One remote file server node may contain all of the files of a given group Gl and
  • the storage of the files of a group are divided amongst multiple remote file
  • server nodes which may be in close geographic proximity to one another or which may be in close geographic proximity to one another or which may be in close geographic proximity to one another or which may be in close geographic proximity to one another or which may be in close geographic proximity to one another or which may be in close geographic proximity to one another or which may be in close geographic proximity to one another or which may be in close geographic proximity to one another or which may be in close geographic proximity to one another or which may be in close geographic proximity to one another or which may be
  • the client nodes can access one or more files via each of multiple remote file server nodes.
  • the specific remote file server node believed to perform a file access most efficiently is chosen for a file access operation by a given client node. For example, according to a load balancing
  • node which is least "busy" servicing other file accesses is allocated to the next incoming
  • FIG 3 shows a typical architecture for implementing the invention.
  • Blocks "Volume Management” 20 and "File System” 30 can be implemented by suitable software executing on the processor 1 1 of a client node.
  • the "Local Disk Store” 40 is a software subsystem executed by the processor 11 of the client node which manages storage of
  • Each "volume” 42, 44 figuratively represent a different virtual storage device which is
  • a volume index 45 assists in identifying file data and directory information
  • the public server 50 is provided as a point of first contact for the client
  • the public server 50 is initially contacted by the public server 50 .
  • client nodes when a user desires to join a particular virtual storage device.
  • the client nodes when a user desires to join a particular virtual storage device.
  • public server 50 can redirect each client node to the correct or most efficient file server 61, 62, ... for providing the file access and integrity maintenance features described below.
  • public server 50 is shown as including a component labeled "volume management web pages" 54 and a component labeled rendezvous server" 56. Both the public server 50 and the file servers 61, 62, ... are implemented by suitable software executing on the processor 11 of each remote file server node. Given that the specific division of functions of a remote file server
  • remote file server node is arbitrary, below, the term remote file server node will be used for sake of generality, without reference to specific components to which each function has been allocated in a given configuration.
  • the client software may be deployed at one, all or some of the computer terminals on
  • a local area network such as the host computer terminals h4, h5 and h6 on subnetwork 12 of
  • the client software can be deployed on moveable computer terminals (such as
  • laptops and or computer terminals at multiple different geographic locations, e.g., host
  • the client software/client node is capable of performing the following functions:
  • Locating remote file server nodes on the wide area network As noted above, the client nodes access one or more virtual storage devices 42, 44 identified as distinct units without regard as to where such virtual storage devices are
  • a file server can provide file access for (actually store, retrieve or
  • one file server is disabled), ease of maintenance, or traffic control.
  • the client software transparently accesses locally stored information
  • version checks may be performed at the file level or on individual portions of a
  • the client software also maintains separate storage for file data and directory information, which cannot be reconciled with the remote file server node and other integrity warning messages. This is described in greater detail below;
  • an interrupted download may be restarted at the
  • At least one client node is provided with client manager software, which
  • node is to provide the customer who uses the service to manage and administer each of the
  • the customer designates one or more of the
  • client nodes as client manager nodes with the ability to provide system wide client side management of the file service.
  • the client manager node is provided with the ability to create and delete entire virtual storage devices on the remote file server nodes.
  • the client manager node is provided with the ability to create and delete entire virtual storage devices on the remote file server nodes.
  • client manager node is provided with full access privileges for all of the files and directories
  • the client manager node is able to designate new user accounts and to provide
  • the public server and file server software illustratively is deployed at the remote file
  • server nodes e.g., computer terminals h9 and hlO.
  • the public server and file server software performs the following functions:
  • pre-subscribed user groups of the virtual storage device and requests from client manager nodes to delete client user accounts
  • FIG 3 shows three client
  • node software elements namely, the volume management, file system and disk subsystem.
  • the client node software is integrated with the operating system/native file system 48 may be specific to each operating system/native file system 48 and is normally dictated by
  • MicrosoftTM specifies an API for integrating software affecting the manner by which files are identified and retrieved by other applications and programs
  • client node software for each operating system/native file system with which the client node
  • FIG 4 shows an illustrative image which is depicted on the display monitor of a client
  • the displayed image is the familiar image of a window 1000, including "buttons"
  • menu bar 1010 with selectable drop-down menu buttons 1012
  • "standard button bar” 1020 with selectable “navigation buttons” 1022
  • address bar 1025 includes a graphical icon representing a network connected storage device
  • the "folders" sub-window 1030 displays a hierarchical list of identifiers 1032,
  • Sub-window 1040 displays another hierarchical
  • sub- window 1040 is intended to show individual files and a hierarchical organization for such files into directories and storage devices.
  • the storage devices shown graphically in the window 1000 can represent entire actual locally present physical storage
  • the identifiers "F” and “Lets Work on '@v-drive'” refer to a virtual storage device provided by the system and service according to the invention. To that end,
  • the client software provides the appropriate information according to the operating system
  • operating system lists identifiers in the graphical display portion of the user interface (i.e., the
  • the operating system enables the user to access these identifiers for the virtual storage device in the same identical fashion as the identifiers for any other storage device. The user can thus "click”, “double click,”
  • the client user may also use the DOSTM
  • client node software also provides certain functionality for
  • the storage device or directory/folder which requires identification of the appropriate hierarchical sub-directory information for retrieval and listed display by the operating system.
  • the client node software provides such information to the operating system
  • the client node software identifies the object (if the file contains data).
  • the client node software provides sufficient integration of the functionality
  • the client node software performs such tasks at all times for automatic application initiated file execution or retrieval. That is, suppose an application is currently executing. In the course of execution, the application
  • the application generates the appropriate request to the operating system to perform the
  • client node software intervenes and assists the operating system in identifying the appropriate
  • the virtual storage device, and its contents i.e., all of the files, directories/folders, etc. stored in the virtual storage device
  • the client node user and the application executing at the client node access the virtual storage device and its contents in the same manner as an
  • the client node is aware of the actual location or home of the files as the integration is perfectly transparent and seamless.
  • client node software merely serves to locate and obtain valid copies of remotely stored or
  • the client node software may determine if a copy of the directory/folder information or file data is cached locally (e.g., in a cache memory, main memory, or disk actually physically present at the client node). The client node software may verify that the locally cached copy of the directory/folder information or file data is cached locally (e.g., in a cache memory, main memory, or disk actually physically present at the client node). The client node software may verify that the locally cached copy of the
  • the client node software may download
  • the client node software may upload the directory/folder information or file data to permanently store
  • each client node has the ability to simultaneously write to a file or part of a file. To achieve this, each client node may actually perform its respective write indirectly, e.g., through a single intermediary node which actually performs each access on behalf of each client node.
  • a directory file is a file containing data for locating and accessing all of the files and subdirectories of a given directory. Each time a new file or subdirectory is added to the
  • the remote file server node functions as an intermediary node which performs each required access (most notably a modification or write operation) on behalf of each client node.
  • the client node creates a new file or subdirectory in a directory, in fact, the client node does not actually create a new file or subdirectory in a directory.
  • the directory file access is performed by the remote file server node as an intermediary.
  • the client node software assists in achieving such file accesses in a coherent fashion.
  • the client node software can transmit to the remote file server commands for
  • the client node software can transmit query commands to
  • the remote file server regarding the lock status of files and can receive and forward the
  • access can be performed in view of the lock status on files, is achieved according to the operating system or other applications executing at the client node.
  • the client node software
  • client node software merely serves as a proxy for forwarding such commands and statuses between the client node and the appropriate remote file server node. All such functionality performed by the client node software is automatic and transparent to the client node user and applications executing at the client node.
  • FIG 5 shows a process for creating a virtual storage device and adding users. Assume
  • manager node issues a message containing a command to invite a new user, the email address of the new user, a user name for the new user and an identifier of the virtual storage device ("drive id") of the virtual storage device on which the new user is to be invited.
  • drive id an identifier of the virtual storage device
  • file server node determines if the virtual storage device indicated by "drive id" exists but the
  • the remote file server node is already contained on a list of users.
  • the remote file server node is already contained on a list of users.
  • the remote file server node rejects the request in step SI 04, by transmitting back to
  • the client manager node via the Internet, a rejection message.
  • the client manager node displays a failure message to the user.
  • the remote file server node creates a record for the new user in step
  • step SI 08 the client manager node creates a one time password ("OTP").
  • OTP is a bidirectional encryption/decryption key.
  • the client manager node communicates to the new client user an invitation to join
  • user name (“user id”)
  • drive id the identifier of the virtual storage device
  • the client manager node can email the invitation to the new client
  • the email message is transferred in a secure fashion, e.g., in encrypted form,
  • the OTP may not be included in the email invitation.
  • the new client user may have to communicate with an intermediate Internet address to receive the OTP upon validation of the
  • the client manager node encrypts
  • the client manager node then transmits OTP(data key) to the remote
  • FIGs 6A and 6B each show a flowchart illustrating alternative processes by which a
  • new client user joins a pre-subscribed user group permitted to access a virtual storage device.
  • step SI 20 the client user
  • the email message includes the URL of the remote file server node at which the client node user can join the pre-subscribed user group for the virtual storage device.
  • the message includes the URL of another site from which the client node subscription request can be redirected to
  • server node Inventions, this is achieved using the so-called https protocol. For example,
  • the remote file server node to be contacted may be registered with a trusted third party.
  • VerisignTM a company located in Verisign
  • step SI 22 the remote file server node accesses the list of
  • the remote file server node deems the message invalid and ceases processing. If desired, the remote file server node can be adapted to transmit a message to the client node
  • node can proceed with the subscription process. If the client node does not already have the
  • this message may be in the form of, or include, a download
  • This download can include one or more URL addresses of one or
  • the client node executes the client node software.
  • the client node creates a drive container to store information
  • the client node also generates a public key/private key pair Puc, Pre.
  • the client node then transmits the public key Puc to the remote file server node.
  • this pair of keys is randomly generated according to any well-known algorithm for so doing.
  • the client node permanently stores the private key Pre for subsequent use as described below.
  • step SI 28 the remote file server node stores the public key of the client node in the record associated with the client node.
  • the remote file server stores the public key of the client node in the record associated with the client node.
  • node encrypts the already encrypted message OTP(data key) using the public key Puc to
  • the remote file server node also transfers it's own public key Pus to the client node.
  • the client
  • node stores the remote file serve node's public key Pus for further use as described below.
  • step SI 32 the client node receives the twice encrypted message Puc(OTP(data key)). Using the client node's private key Pre and the one time use key OTP, the client node
  • step SI 34 the client node encrypts the clear text data key using its public key Puc to produce the encrypted data key Puc(data key). The client node then transmits this encrypted data key Puc(data key) to obtain the data key.
  • step SI 36 the remote file server node receives the encrypted
  • step SI 50 activates the join process in step SI 50 by clicking on the email message.
  • the email message includes the user id, the drive id, and optionally a hash of the OTP.
  • step SI 52 a trusted token
  • VerisignTM validates the "certificate” or authenticity of the remote file
  • step S 154 the remote file server validates the user id, drive id, and the hash of the OTP. If there is a match, i.e., the remote server validates the above, then the process proceeds to step S 164 which will be described below.
  • the remote file server validates only the user id and drive id. As stated above, the new client user obtains the OTP separate from the invitation email. If there is a match,
  • step SI 60 the remote file server prompts the client user to supply the OTP which is
  • step SI 62 validated in step SI 62. If there is no match in either step SI 56 or step SI 62, then the invite is
  • step SI 64 the process proceeds to step SI 64.
  • step SI 64 the client node creates a drive container and generates a public
  • the client node then transmits the public key Puc to the remote
  • step SI 66 file server node in step SI 66.
  • the client node permanently
  • step SI 68 a
  • step S 170 the authenticated client user updates the new client user record at the server with the encrypted
  • step SI 72 server drive data corresponding to the data key
  • the data key is a two-way encryption/decryption key which is
  • file server node have a clear-text version of the data key. Rather, the remote file server node
  • the remote file server node has one encrypted version of the data key for each client node, as encrypted with the public key of that client node.
  • the public/private key pair Puc, Pre are one-way keys. That is, the public key Puc can be used to encrypt a message. However, such a message can only be decrypted with the corresponding private key Pre. Thus, while the remote file server node maintains the public key Puc and the data key encrypted by the
  • each OTP can be used only once.
  • the client node creates an identity profile which is a locally stored data file with sufficient information for enabling the client node to access the virtual storage device.
  • the identity profile includes the private key Pre which is necessary
  • the copy of the identity profile is encrypted on the client
  • the (encrypted) identity profile may be copied onto a removable
  • the client storage medium (e.g., a floppy diskette) and/or placed on multiple client nodes.
  • the client e.g., a floppy diskette
  • node user can then access the virtual storage device from each client node provided with a
  • a copy of the identity profile e.g., on a removable medium, enables the user to restore the identity profile on any given client
  • the remote file server node under the given client user account should the client node software be damaged or corrupted.
  • FIG 7 shows a flowchart describing a process for authenticating a connection between
  • step S200 the client node issues a connection request message via the Internet to
  • the client node issues the message to a pre-established URL address assigned to the appropriate remote file server node
  • the virtual storage device to be accessed by the client node.
  • step S202 the remote file server node
  • the remote file server node fails to confirm that the user name is contained in a list of active user names for the virtual storage
  • the remote file server node denies the connection in step S204. In denying the connection, the remote file server node may issue an appropriate rejection message to the client node.
  • the remote file server node confirms that the user name is listed as active on the list associated with the virtual storage device indicated by the identifier in the message.
  • step S206 the remote file server node encrypts the random string S with its private key Prs to produce the encrypted random string Prs(S).
  • step S208 the remote file server node
  • step S210 the client node decrypts the encrypted random string Prs(S) with the
  • step S212 the client node determines if this decryption of the received
  • the client node presumes that only the remote file server node has the capability (most
  • step S216 the client node encrypts the second random string K with
  • the client node then transmits the encrypted second random data string Prc(K) to the remote file server node.
  • the remote file server node attempts to decrypt this received encrypted second random data string Prc(K) with the public key Puc stored for this client node (for accesses to this virtual storage device).
  • the remote file server attempts to decrypt this received encrypted second random data string Prc(K) with the public key Puc stored for this client node (for accesses to this virtual storage device).
  • the remote file server attempts to decrypt this received encrypted second random data string Prc(K) with the public key Puc stored for this client node (for accesses to this virtual storage device).
  • step S222 the remote file server determines that it has failed to authenticate the identity of the client node
  • the remote file server node determines that it has successfully authenticated the identity of the
  • the remote file server node determines that only the client node has the
  • the remote file server node grants the connection in step S224.
  • the client node authenticates the identity of the remote file server node and the remote file server node authenticates the identity of the client node.
  • the connection is deemed authenticated only if the client node authenticates the identity of the
  • remote file server node and the remote file server node authenticates the identity of the client
  • the client node After the connection is authenticated, the client node can access file data at the remote
  • the Internet actual consists of several private networks maintained and operated by unknown parties. Neither the client node nor the remote file server node makes any
  • the client node also does not presume that the remote file server node is secured and takes measures to ensure that no unauthorized access to the file data can occur at the site of the remote file
  • FIG 8 illustrates a process carried out for secured uploading of file data from the client
  • step S300 the client node creates a file header including the
  • the offset can, for example, be specified by the number of segments or empty
  • the file header illustratively includes an object
  • OID identifier
  • the OID can be used to identify which data key must be used
  • step S302 the client node transfers the next to-be-uploaded segment of file data to
  • the buffer is a portion of main memory storage space of sufficient capacity for holding the segment data temporarily.
  • step S306 the client node encrypts the compressed data in the buffer using the data key.
  • the particular bit i.e., number of bits
  • step S308 the client node appends the header created in step
  • TCP/IP Internet protocol
  • step S310 the remote file server node receives the transmitted encrypted
  • remote file server locates the correct storage space, within the respective (master) copy of the file at the remote file server node, at which writing is to begin.
  • the remote file server node then writes (causes the storage device to write) the encrypted, compressed file data segment
  • the client node determines if the transfer of the portion of the file has
  • step S302 the client node returns to step S302 and transfers the next to-be-uploaded
  • step S308 the client node may omit or suitably modify the
  • step S312 the upload process stops.
  • FIG 9 illustrates a download process for securely transferring file data from the remote
  • server node to download part of the file.
  • the request can be a new request, i.e., a request not previously initiated, or a request
  • step S320 the remote file server node initially
  • step a) determines if the download request is new or if the download request is to resume/complete transfer of file data which request has been partially satisfied. If this is a new request, in step
  • the remote file server node sets an internal counter "Next Segment" to indicate the first
  • to-be-downloaded segment e.g., equal to zero.
  • step S324 the remote file server node is to resume a partially completed request
  • remote file server node sets the internal counter "Next Segment” to indicate the next
  • to-be-downloaded segment following the last successfully downloaded segment e.g., equal to the bytes already successfully downloaded divided by the segment size.
  • step S326 the remote file server node transmits to the client node the file header stored for the file from which the client node has
  • the client node receives the file header and obtains the OID of the data key from the file header.
  • the client node uses the OID to retrieve the appropriate data key using the OID, including, if necessary, requesting that the remote file
  • the client node transmits a request for the appropriate data key to the remote file server node.
  • the remote file server node uses
  • the OID to identify the appropriate encrypted data key and transmits this encrypted data key to the client node.
  • the encrypted data key is retrieved from a list of encrypted data
  • step S330 the client node obtains the appropriate
  • step S332 the client node extracts the buffer size and header slot/offset information. Initially, such information is specified by the file header.
  • step S334 the client node extracts the buffer size and header slot/offset information. Initially, such information is specified by the file header.
  • the client node transmits a request to the remote file server node to download a portion of file data, of a certain amount of information (e.g., a number of bytes equal to the capacity of a
  • the remote file server begins at a specified offset from the beginning of the data file.
  • node responds to this request by retrieving the requested portion of file data from the
  • step S3366 the client node decrypts the data in the buffer using the data key
  • step S330 the client node decompresses the decrypted data
  • the client node illustratively pieces together in proper sequence the downloaded, decompressed and decrypted data segments to reproduce a replica copy of the requested file data.
  • the client node determines whether or not the all of the requested file data has been successfully downloaded. If not, then in step S342, the client node increments it's counter of the Next segment to be
  • a client node capable of allocating a new data
  • the client node For use by the client users of the group does so as follows. First, the client node generates the new data key. This data key may be used to encrypt file data transferred to the remote file server node. The client node then encrypts the new data key using is public key Puc to
  • the client node then transmits (e.g.,
  • the remote file server responds by storing the encrypted new data
  • each client user in the pre-subscribed user group maintains a complete list
  • client user's public key is transmitted to each client user in the pre-subscribed user group.
  • the client node sequentially requests (e.g., by transmitting request commands via the Internet to the remote file server node) the public key Puc', Puc",..., etc. of
  • the remote file server node responds by retrieving and transmitting to the client node via the Internet the public key of each client user Puc', Puc",..., etc. which this client user node has
  • the client node then encrypts the new data key using each of these received public
  • the client node then transmits to the remote file server node via the Internet each of
  • the remote file server node never has a clear-text, i.e., non-encrypted form
  • each data key is encrypted using the public key of a
  • node knows the respective methodology (in this case, the private key) for decrypting its
  • the remote file server node and client nodes maintain the integrity of the group of
  • a client node may continue to access the local copy of the
  • file integrity maintenance provides a very predictable outcome for file and directory modifications-either the modification is achieved as expected or not permitted at all.
  • client nodes at which such multi-user applications execute, were on the same local area
  • the remote file server node is separated from one or more of the client nodes by a wide area network, and although communication is not always possible
  • the same expected behavior is achieved as can be anticipated on a local area network which supports multi-user and shared file access.
  • a file version control is added to each file and each directory stored on the virtual storage device (i.e., both with the master copy at the remote file server
  • the file version control is used to ensure that, whenever possible, the client node only performs an access on the most up-to-date version of the file data.
  • the file version control is also used to identify conflicting modifications to files and to reconcile them. As can be appreciated, it is highly time consuming and inefficient for
  • file sharing mode and privilege access right checks can also be performed at the same times. If another client node attempts to access a file currently opened by a given client node, the remote file server node can determine that the file is currently in use by the given client
  • the remote file server node can then determine if the given client node is still in
  • the remote file server node maintains the ownership or control of the file data by the given client node including enforcing any file
  • the remote file server node can close the file on behalf of the given client node thereby relinquishing control of the
  • the client node uploads its modifications to the remote file server node.
  • the uploading of modified file data is deferred until the
  • client node closes the file. So long as a client node remains connected to the remote file
  • file server node to have granted write access permission to another client node (as described
  • FIG 10 illustrates a process executed by the client nodes and the remote file server
  • step S400 the client node determines if communications have been restored. This can occur by reason of establishment of a new connection or by reason of
  • step S404 the client node determines whether or not there is a need to access
  • access includes the operations of "read,” “modify/write,” “create,” and “delete.” If no such access is detected at the client node, the client node returns to step S400.
  • step S406 the client node determines if the requested operation is one which requires a
  • the operations of closing a file and uploading the modifications to the file data made by the client node illustratively do not require a version check. If no version check is required,
  • the client node proceeds to step S414 and attempts to perform the requested access operation.
  • step S408 the client node transmits via the
  • the request includes the version number of the respective local copy of the file data or directory information, if a local copy of such information is
  • step S410 the client node determines whether or not the client node has received any response from the
  • remote file server node If the client node fails to receive a response form the remote file
  • the client node within the time limit of the time-out timer, the client node presumes that it is out
  • step S412 the client node
  • step S414 the client
  • node attempts to perform the access operation on the file data or directory information, e.g.,
  • the client uses the operating system or application which requested the access.
  • the client uses the operating system or application which requested the access.
  • the client
  • node attempts to perform the requested access on its local copy of the file data or directory information if the client node has any. Note that if the client node does not have the requisite file data or directory information, the attempted request fails in accordance with the normal operation of the operating system, or application. In addition, if the operation is a close file
  • the client node illustratively
  • step S410 the client node received a response from the remote file server node
  • the client node determines, in step S416, whether or not the access is permitted. As will be described
  • the client node illustratively provides an appropriate abort/failure
  • step S414 the client node performs the requested access, i.e., opening a file, creating a file, deleting a file, changing a directory attribute, etc.
  • Steps S420-S430 are performed by the remote file server node in response to
  • step S420 the remote file server node checks to determine if the
  • client node has sufficient privilege access rights to perform the requested operation. For example,
  • the client node desires to open a file for writing to it, the client node lacks sufficient privilege
  • the remote file server node aborts the operation and transmits to the client node via the Internet a message indicating that the client node user lacks the requisite access privilege rights to perform the requested access
  • step S424 This message is detected by the client node in steps S410 and S416.
  • step S422 the remote file server node next checks to
  • the remote file server node aborts the operations and transmits via the Internet to the client node a message indicating that the requested access could not be performed at this time as it conflicted with a file sharing mode of the file or directory in step S424. This message is detected by the client node in steps S410 and S416.
  • step S426 the remote file server node checks the version number (if any) in the message supplied by the client node against the version number of the (master) copy of the file or directory
  • client node has the most up-to-date version of the file data and/or directory information.
  • the file server node simply transmits via the Internet to the client node a message
  • the remote file server node performs step S428.
  • step S428 the remote file server node
  • this downloaded file data and/or directory downloads to the client node the requested file data or directory information, as described in connection with FIG 8. Amongst other things, this downloaded file data and/or directory
  • a client node can obtain the latest version of file data or
  • the local copy acts as a "cached copy" in that it is much easier to access
  • the client node in the event that the client node is incapable of communicating with the remote file server node, the client node
  • a client node can specify a desire to "hoard" one or more files and/or directories.
  • a client node user can specify a desire to hoard specific files and/or directories. This results in the client node transmitting a message to the remote file server node indicating this hoarding request.
  • the remote file server node monitors each of the files or directories indicated as hoarded by each client node.
  • the remote file server node Periodically, the remote file server node performs a pass over all of the files and directories
  • the remote file server node downloads appropriate
  • the client node then updates its locally cached copy of the
  • the client node can ensure that between accesses to
  • the remote file server node is continuously updating such files and directories.
  • the client node is likely to always have the latest or most updated version of the hoarded files and directories.
  • the client node when the client node desires to access such hoarded files or directories, the client node likely can avoid any delays in accessing such hoarded files or directories incurred while the latest or most updated version of the files or
  • the client node user will have to manually reconcile a conflict.
  • the client node reduces the risk that an outdated version of
  • the file or directory will be accessed by the client node while out of communication with the
  • the communication channel is said to be closed. If a given client node closes its communication channel, or, alternatively, the remote file server node closes the communication channel with
  • the remote file server node can relinquish control of that file or directory by the given client
  • two client nodes may perform incompatible modifications to the file data or directory
  • the client node performs a reconciliation operation. During this operation, the client node performs a reconciliation operation.
  • client node first identifies each local copy of file data and directory information maintained
  • a storage device e.g., disk memory 15
  • client node checks the version of each such locally maintained copy of file data and
  • the remote file server node checks the version of the respective file data or directory information to see if the same version number is recorded in the (master) copy of the respective file data or directory information maintained by the remote file server node in
  • the client node was out of communication with the remote file server node. If a modification was made, then the version numbers will not match.
  • the specific actions taken by the client node and remote file server node depend on which modifications were made to the (master) copy of the file data or directory information maintained at the remote file server node and the
  • the client node often is required to perform some reconciliation action.
  • the remote file server node transmits appropriate sufficient messages regarding the outcome
  • FIG 11 contains a chart summarizing the reconciliation actions taken by the remote file server node and the client node in regard to reconciling changes that affect file data or files.
  • each cell of the chart is labeled with a row number RI , R2, R3, R4 and R5 and a column number Cl, C2, C3, C4 and C5.
  • the rows R1-R5 contain cells
  • the file is only presumed correct if it does not conflict with the remote file server copy. If there is a conflict that cannot be rectified, it is moved to the conflict bin of the client node.
  • the client node also makes no
  • the client node made a change to the contents of the file data, i.e.,
  • the remote file server node saves this modified file data.
  • the client node renames the file or moves it to another directory (R3, Cl)
  • the remote file server node performs the same renaming or movement action on the (master) copy of the file maintained at the remote file server node.
  • the client node deletes the file (R4, Cl) or the entire directory containing the file (R5, Cl)
  • the remote file server node deletes the
  • C2 modified or written to (C2), e.g., by another client node. If the client node did not change its local copy of the file while out of communication with the remote file server
  • the client node simply invalidates the local copy of the file. Likewise, if the client node changed its local copy of the file data (R2, C2), the local copy of the file data
  • the client node's local copy of the file data is moved to a local directory physically stored at the client node (e.g., on the client node's disk memory 15) called the "conflict bin.”
  • the conflict bin is a directory (of the disk memory 15) at the client node in
  • C3 renamed or moved (C3), e.g., by another client node. If the client node did not change its
  • the remote file server node stores the modified file data (or entire modified file)
  • the client node places a warning message in the conflict bin
  • the client node places a warning in the conflict bin indicating that the conflict bin
  • Both of these scenario classes have the same impact on the file itself. Specifically, both are acts which delete the (master) copy of the file at the remote file server
  • the client node did not change, i.e., modify or write to, its local copy of the file data
  • the client node simply deletes or invalidates its local copy of the file data.
  • the client node moves its local copy of the file data (or entire file) to the conflict bin.
  • the client node had renamed or moved the file (R3, C4 or R3, C5), then the client node moves its local copy of the file data (or entire file) to the conflict bin.
  • the client node uploads the
  • FIG 12 contains a chart summarizing the reconciliation actions taken by the remote file server node and the client node in regard to reconciling changes that affect directories.
  • each cell of the chart is labeled with a row number RI', R2', R3', R4' and
  • the rows Rl'-R5 * contain cells indicating the actions taken when the client node: makes no changes to the directory (RI'); changes, i.e., modifies, a directory attribute (e.g., the privileges of one or more users or
  • R2' groups of users
  • R3' adds a file or child/subdirectory to a directory
  • R4' renames or moves a directory
  • R5' deletes a directory
  • remote file server node (Cl').
  • the client node also has not
  • the remote file server node makes
  • the remote file server node deletes its (master) copy of the directory.
  • remote file server node was changed/modified (C2'), e.g., by another client node.
  • C2' remote file server node
  • the client node did not change/modify its local copy of the directory information (RI', C2') in which case modifications to the (master) copy of the directory information at the remote file server is downloaded to the client node and the client node stores/makes the same modifications to its local copy of the directory information. If the client node also changed/modified its local copy of the directory (R2', C2') then, the client
  • node places a warning in its conflict bin advising that the directory at the remote file server
  • client node under the same period oftime. Suppose that the client node adds one or more
  • client node contents by the client node, including prohibiting the addition of new files or child/ subdirectories. If the client node additions are compatible, they are uploaded from the client node to the remote file server node and stored in the directory. Furthermore, if compatible with the privilege access rights of the client node user as now dictated by the modified
  • the attribute modifications are downloaded to the client node and stored locally.
  • the client node made no changes/modifications to the directory (RI', C3'), then the added file and child/subdirectory entries are downloaded from the remote file server node to the client node. If the client node changed/modified one or more attributes of the directory (R2', C3'), the added file and child/subdirectory entries are nevertheless downloaded from the remote file
  • server node to the client node where they are stored locally. If the client node also added files or child/subdirectories (R3', C3'), a determination is first made to see if any are incompatible
  • An example of an incompatible entry is where both the client node and the remote file server node both
  • the client node are compatible with the additions made at the remote file server node then the
  • remote file server node are downloaded to the client node where they are stored locally.
  • the client node moves each of the client node's file or child/subdirectory
  • directories are downloaded from the remote file server to the client node and the client
  • the (master) copy of the directory at the remote file server node is renamed or moved (C4'), e.g., by another client node. If the client node made no
  • the client node in conformity with the remote file server node.
  • the client node also uploads the
  • the client node places a warning in the conflict bin indicating that the conflict bin
  • the client node downloads from the remote file sever node a
  • the (master) copy of the directory at the remote file server node is
  • C5 1 deleted (C5 1 ), e.g., by another client node. If the client node made no changes to the directory
  • node simply deletes the directory. If the client node added one or more new files or child/subdirectories to the directory (R3', C5') then the client node moves the new files and
  • the client node also deletes the locally stored copy of the directory. If the client node moved or renamed the directory (R4', C5') then the
  • client node stores a warning in the conflict bin indicating that the directory had been previously deleted at the remote file server node.
  • the directory is uploaded from the client node to the remote file server node.
  • client node also deletes the directory (R5', C5') then no action is performed.
  • remote file server nodes perform two access checks on file data and directory entries.
  • the remote file server nodes check to make sure that the client node requesting the remote file server nodes.
  • the access operation has sufficient access privilege rights to perform the requested file data or
  • the remote file server node also checks to make sure that the
  • servers are available for providing the accesses to a given file or directory on behalf of different nodes. According to this embodiment, the duties associated with access control, that
  • FIG 13 shows an illustrative environment in which this embodiment of the invention can be used, namely, a wide area network 200, such as the Internet.
  • a wide area network 200 such as the Internet.
  • r20-r23 denote routers or switches. More specifically,
  • Computer terminals h20-h25 denote client nodes on a local area network, which, with router r20, form subnetwork 120.
  • Computer terminal h26 denotes a mobile client node forming subnetwork 121.
  • Computer terminals h27 is an access control node, which, with router r21,
  • subnetworks 122-124 contain
  • remote file server nodes operated by the same virtual file service provider (although the subnetworks, themselves, can be owned by an independent access provider or ISP).
  • all of the client nodes h20-h26 are operated by client users who are part of the
  • this virtual storage device is accessible through any of the remote file server nodes h28-h33.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Storage Device Security (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention porte sur un service et un système de stockage de fichiers pour utilisateurs multiples permettant à chacun des usagers d'un groupe de pré-abonnés d'utiliser un noeud client quelconque situé en un emplacement géographique quelconque de communiquer avec un noeud serveur de fichiers (61, 62) distant via un réseau longue distance, et d'accéder aux fichiers du groupe de fichiers via le noeud client correspondant communiquant avec le noeud serveur de fichiers (61, 62) distant via le réseau longue distance. Plus d'un des usagers du groupe de pré-abonnés peut accéder simultanément au noeud serveur de fichiers (61, 62) distant. L'intégrité des fichiers du noeud serveur de fichiers (61, 62) distant est conservée du fait du contrôle de chacun des accès à chacun des fichiers dudit noeud (61, 62), du moins sur la partie de chaque fichier la plus récemment actualisée stockée dans le noeud (61, 62).
PCT/US2000/030077 1999-11-01 2000-11-01 Service de fichiers communs sur internet a acces aux pc clients originels et semantique WO2001033361A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU14509/01A AU1450901A (en) 1999-11-01 2000-11-01 Internet-based shared file service with native pc client access and semantics

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16300899P 1999-11-01 1999-11-01
US60/163,008 1999-11-01

Publications (1)

Publication Number Publication Date
WO2001033361A1 true WO2001033361A1 (fr) 2001-05-10

Family

ID=22588064

Family Applications (3)

Application Number Title Priority Date Filing Date
PCT/US2000/030077 WO2001033361A1 (fr) 1999-11-01 2000-11-01 Service de fichiers communs sur internet a acces aux pc clients originels et semantique
PCT/US2000/030201 WO2001033829A2 (fr) 1999-11-01 2000-11-01 Service de fichiers partages a base d'internet avec semantique et acces client du pc natif et controle d'acces distribue
PCT/US2000/030078 WO2001033383A1 (fr) 1999-11-01 2000-11-01 Service de fichiers partages base sur internet a semantique et acces client pc natifs et controle de version reparti

Family Applications After (2)

Application Number Title Priority Date Filing Date
PCT/US2000/030201 WO2001033829A2 (fr) 1999-11-01 2000-11-01 Service de fichiers partages a base d'internet avec semantique et acces client du pc natif et controle d'acces distribue
PCT/US2000/030078 WO2001033383A1 (fr) 1999-11-01 2000-11-01 Service de fichiers partages base sur internet a semantique et acces client pc natifs et controle de version reparti

Country Status (3)

Country Link
AU (3) AU1450901A (fr)
TW (3) TW487843B (fr)
WO (3) WO2001033361A1 (fr)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003071419A2 (fr) * 2001-12-10 2003-08-28 Incipient, Inc. Chemin rapide permettant d'effectuer des operations de donnees
DE10257819A1 (de) * 2002-12-10 2004-07-15 Web.De Ag Netzwerkbasierter Datenzugriff mit getrenntem Datenübergang und Datenübertragung
US6959373B2 (en) 2001-12-10 2005-10-25 Incipient, Inc. Dynamic and variable length extents
US6986015B2 (en) 2001-12-10 2006-01-10 Incipient, Inc. Fast path caching
US7013379B1 (en) 2001-12-10 2006-03-14 Incipient, Inc. I/O primitives
US7173929B1 (en) 2001-12-10 2007-02-06 Incipient, Inc. Fast path for performing data operations
CN106487761A (zh) * 2015-08-28 2017-03-08 华为终端（东莞）有限公司 一种消息传输方法和网络设备

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2299946A1 (fr) 2000-03-03 2001-09-03 Destiny Software Productions Inc. Methode et systeme de distribution de supports numeriques
US6715050B2 (en) * 2001-05-31 2004-03-30 Oracle International Corporation Storage access keys
US7685126B2 (en) 2001-08-03 2010-03-23 Isilon Systems, Inc. System and methods for providing a distributed file system utilizing metadata to track information about data stored throughout the system
CA2407774C (fr) 2002-07-16 2005-01-04 Musicrypt Inc. Systeme et methode de distribution de contenu
US7953794B2 (en) 2005-01-14 2011-05-31 Microsoft Corporation Method and system for transitioning between synchronous and asynchronous communication modes
US7593943B2 (en) 2005-01-14 2009-09-22 Microsoft Corporation Method and system for synchronizing multiple user revisions to a shared object
US8966080B2 (en) 2007-04-13 2015-02-24 Emc Corporation Systems and methods of managing resource utilization on a threaded computer system
US8417666B2 (en) * 2008-06-25 2013-04-09 Microsoft Corporation Structured coauthoring
TWI447584B (zh) * 2010-11-01 2014-08-01 Inst Information Industry 多人共享之網路儲存服務系統與方法
TW201315191A (zh) * 2011-09-27 2013-04-01 Jian Guo Hui 基於完整列矩陣之再加密方法
DE102012202382A1 (de) 2012-02-16 2013-08-22 Cortado Ag Verfahren und Anordnung zur Verwaltung von Daten sowie ein entsprechendes Computerprogramm und ein entsprechendes computerlesbares Speichermedium
TWI571754B (zh) * 2015-02-02 2017-02-21 群暉科技股份有限公司 用來進行檔案同步控制之方法與裝置
CN106446142A (zh) * 2016-09-21 2017-02-22 郑州云海信息技术有限公司 一种多区域间文件系统的设计方法
CN106933686A (zh) * 2017-03-10 2017-07-07 广东欧珀移动通信有限公司 一种调整广播消息队列的方法、装置及终端

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5862346A (en) * 1996-06-28 1999-01-19 Metadigm Distributed group activity data network system and corresponding method
US5864683A (en) * 1994-10-12 1999-01-26 Secure Computing Corporartion System for providing secure internetwork by connecting type enforcing secure computers to external network for limiting access to data based on user and process access rights
US5889942A (en) * 1996-12-18 1999-03-30 Orenshteyn; Alexander S. Secured system for accessing application services from a remote station

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA1337132C (fr) * 1988-07-15 1995-09-26 Robert Filepp Systeme de reception pour reseau informatique interatif et sa methode de fonctionnement
US5966715A (en) * 1995-12-29 1999-10-12 Csg Systems, Inc. Application and database security and integrity system and method
US5838910A (en) * 1996-03-14 1998-11-17 Domenikos; Steven D. Systems and methods for executing application programs from a memory device linked to a server at an internet site
US5918019A (en) * 1996-07-29 1999-06-29 Cisco Technology, Inc. Virtual dial-up protocol for network communication
US5987506A (en) * 1996-11-22 1999-11-16 Mangosoft Corporation Remote access and geographically distributed computers in a globally addressable storage environment

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5864683A (en) * 1994-10-12 1999-01-26 Secure Computing Corporartion System for providing secure internetwork by connecting type enforcing secure computers to external network for limiting access to data based on user and process access rights
US5862346A (en) * 1996-06-28 1999-01-19 Metadigm Distributed group activity data network system and corresponding method
US5889942A (en) * 1996-12-18 1999-03-30 Orenshteyn; Alexander S. Secured system for accessing application services from a remote station

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003071419A2 (fr) * 2001-12-10 2003-08-28 Incipient, Inc. Chemin rapide permettant d'effectuer des operations de donnees
WO2003071419A3 (fr) * 2001-12-10 2005-03-31 Incipient Inc Chemin rapide permettant d'effectuer des operations de donnees
US6959373B2 (en) 2001-12-10 2005-10-25 Incipient, Inc. Dynamic and variable length extents
US6986015B2 (en) 2001-12-10 2006-01-10 Incipient, Inc. Fast path caching
US7013379B1 (en) 2001-12-10 2006-03-14 Incipient, Inc. I/O primitives
US7173929B1 (en) 2001-12-10 2007-02-06 Incipient, Inc. Fast path for performing data operations
US7280536B2 (en) 2001-12-10 2007-10-09 Incipient, Inc. Fast path for performing data operations
DE10257819A1 (de) * 2002-12-10 2004-07-15 Web.De Ag Netzwerkbasierter Datenzugriff mit getrenntem Datenübergang und Datenübertragung
DE10257819B4 (de) * 2002-12-10 2005-10-13 Web.De Ag Netzwerkbasierter Datenzugriff mit getrenntem Datenübergang und Datenübertragung
CN106487761A (zh) * 2015-08-28 2017-03-08 华为终端（东莞）有限公司 一种消息传输方法和网络设备

Also Published As

Publication number Publication date
WO2001033829A3 (fr) 2002-03-28
WO2001033829A9 (fr) 2002-07-04
AU1451001A (en) 2001-05-14
AU1450901A (en) 2001-05-14
WO2001033383A9 (fr) 2002-05-16
TW498217B (en) 2002-08-11
TW561735B (en) 2003-11-11
TW487843B (en) 2002-05-21
AU2041301A (en) 2001-05-14
WO2001033383A1 (fr) 2001-05-10
WO2001033829A2 (fr) 2001-05-10

Similar Documents

Publication Publication Date Title
US7136903B1 (en) Internet-based shared file service with native PC client access and semantics and distributed access control
US20060129627A1 (en) Internet-based shared file service with native PC client access and semantics and distributed version control
WO2001033361A1 (fr) Service de fichiers communs sur internet a acces aux pc clients originels et semantique
US11863380B2 (en) Community internet drive
US8572757B1 (en) Seamless secure private collaboration across trust boundaries
US7376711B2 (en) Smart card enabled mobile personal computing environment system
US9015858B2 (en) Graphical user interface for seamless secure private collaboration
US10762229B2 (en) Secure searchable and shareable remote storage system and method
US6662198B2 (en) Method and system for asynchronous transmission, backup, distribution of data and file sharing
CN103931156B (zh) 具有用户不可知加密文件的服务器侧去重的云文件系统
US7222231B2 (en) Data security for distributed file systems
US20160011990A1 (en) System and Method for Conflict-Free Cloud Storage Encryption
KR101971225B1 (ko) 클라우드 서버의 데이터 전송 보안 시스템 및 그 제공 방법
KR101623742B1 (ko) 파일 연관 메시지 공유 방법 및 메시지 공유 시스템
JP2002140239A (ja) 情報管理システム及び情報管理方法及びシステム制御装置
JP6216673B2 (ja) データ管理方法及びデータ管理システム
TW588531B (en) Smart card enabled mobile personal computing environment system
Choudhari et al. Security and Privacy of AWS S3
Hakkala Consistency management in distributed storage systems
Lupetti et al. The Pesto Broker
EP2918039A1 (fr) Collaboration privée sécurisée transparente à travers des limites de confiance

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ 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 PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG 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 GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase