WO2001033383A1 - Service de fichiers partages base sur internet a semantique et acces client pc natifs et controle de version reparti - Google Patents

Service de fichiers partages base sur internet a semantique et acces client pc natifs et controle de version reparti Download PDF

Info

Publication number
WO2001033383A1
WO2001033383A1 PCT/US2000/030078 US0030078W WO0133383A1 WO 2001033383 A1 WO2001033383 A1 WO 2001033383A1 US 0030078 W US0030078 W US 0030078W WO 0133383 A1 WO0133383 A1 WO 0133383A1
Authority
WO
WIPO (PCT)
Prior art keywords
file
node
client node
thε
remote
Prior art date
Application number
PCT/US2000/030078
Other languages
English (en)
Other versions
WO2001033383A9 (fr
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 AU14510/01A priority Critical patent/AU1451001A/en
Publication of WO2001033383A1 publication Critical patent/WO2001033383A1/fr
Publication of WO2001033383A9 publication Critical patent/WO2001033383A9/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.
  • computing resources such as data, programs and applications, processing capacity, storage capacity, etc.
  • a local area network collaborates on projects remotely by exchanging computer data, programs and applications with each other via a wide area network. It is desirable to provide the same capabilities to users who remotely access computer resources as are available to users connected to a local area network. Specifically, a local area network
  • 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. However, more than one user often may be permitted to simultaneously read a file, or a portion of a file, at the same time.
  • 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
  • a third user group might have only read privileges for all files in a directory. Certain products and services are currently available for assisting users to obtain
  • remote storage device which the user can access while executing a web browser program on
  • the user uses the pointing to device to select a
  • the user selects a locally stored file for uploading (by locating the file and
  • a private network e.g., a local area network or a private wide area network link.
  • SSL secured socket layer transfers
  • SSL provides a manner whereby the server at the service encrypts information immediately before it is transmitted via the Internet to the client node (and vice versa). This tends to thwart unauthorized access by eavesdroppers to the files while in transit over the Internet.
  • the files may be subject to
  • StoragepointTM provides a WindowsTM ExplorerTM Name Space extension object. As a result, certain aspects pertaining to user file access are similar for both files
  • 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
  • X-DriveTM also allows applications and programs execuiing at the user's terminal to seamlessly access files which reside at the remote storage device as such
  • 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 does not.
  • StoragepointTM uses a secured socket layer to transfer encrypted information
  • 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
  • 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 with a remote file server node via a wide area network.
  • Each user of the user group is
  • each access to one of the files at the remote file server is performed, if at all, on a respective portion of each of the one files as most recently updated at the remote file server
  • an interface for adapting file access at a first cne of the client nodes.
  • the interface designates at the first client node each of the one
  • the interface also enables access to the designated files in a fashion which is indistinguishable, by users of,
  • 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 information of the files prior to uploading for storage at the remote file server node.
  • 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
  • the particular client node illustratively encrypts data of a file using an encryption methodology known to the client node but not known to the remote file server node.
  • the client node then uploads the encrypted data to the remote file server node.
  • the remote file server node stores the encrypted file data.
  • the remote file server node illustratively retrieves from storage the encrypted data of a particular file and transmits the encrypted data to a specific client node.
  • 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 cr remote file server of the network of
  • FIG. 1 A first figure.
  • FIG 3 shows an illustrative architecture according to an embodiment uf the oresem invention.
  • FIG 4 shows an illustrative screen displayed on a client node according to an
  • FIGs 5, 6A 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
  • 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
  • FIG 1 shows a wide area network 100 such as the Internet. This network is composed of local networks 11-16, access networks a-d and backbone networks A-C forming backbone
  • Devices rl-rl8 denote switches or routers
  • devices hl-hlO denote computer terminals
  • 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 uepicts a typical node in the form of a computer terminal 10.
  • Tbe computer 'erminal 10 typically includes a processor 1 1 or CPU, memory 12. one or more ⁇ 'O devices
  • 13-1, 13 -2...., 13-N e.g., moderns, cable mrclems, network interface cards etc.
  • di> 1 J fixed magnetic, rerno ⁇ able magnetic, optical, etc.
  • graphics accelerator and display monitor e.g., graphics accelerator and display monitor
  • An illustrative example of the computer terminal 10 is a "PC" compatible computer
  • 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 othei wide area networks.
  • Client node describes a device sucft as a computer terminal hi -ho, 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 ui remotely as
  • Remote file server node describes an apparatus, such as a file server computer h9-h!0, including a storage device, such as one or more disk drives 1 , 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
  • 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 performed in a fashion described below which maintains the integrity of these master copies of die files at the remote file server nodes.
  • each client node which "hides" the geographic remoteness of the origin of the files from bo ⁇ h the users of the client nodes and applications executing on the client nodes.
  • the files "appear,” i.e., entirely behave, and can be accessed
  • remote file server nodes are geographically remote and may be operated by
  • 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.
  • a mobile client node that can connect to a remote file server node h9 or hlO via 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 .
  • file group FI and where the users of G4 can access the file group F4 of another virtual storage device provided by the remote file server nodes.
  • user gl can freely
  • One remote file server node may contain all of the files of a given group Gl and provide all of the file access functions described below for that group.
  • 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 are geographically remote from one another. According to another embodiment, the client 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.
  • Each "volume” 42, 44 figuratively represent a different virtual storage device which is
  • given client node will depend on the particular user who is using the client node at that
  • the I/O device 13-1) with the remote file server node to obtain missing file data and directory information and to ensure the integrity of the master copy of such information at the remote
  • 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 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,
  • the public server 50 is shown as including a component labeled "volume management web pages" 54 and a component labeled rendezvous seiver" 56. Both the public server 50 and the file
  • remote file server node is implemented by suitable software executing on the processor 11 f each remote file server node.
  • the term remote file server node will be used for sake of generality,
  • 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
  • the client nodes access one or more virtual storage devices 42, 44 identified as
  • a file server can provide file access for (actually store, retrieve or
  • the client software transparently accesses locally stored information, such as URLs, for determining how to iend commands, data or other infonnation to the appropriate remote file server node providing the
  • version checks may be performed at the file level or on individual portions of a
  • the client user may only require a small data portion of the entire file.
  • 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 virtual storage devices of that customer.
  • the customer designates one or more of the client nodes as client manager nodes with the ability to provide system wide client side
  • the client manager node is provided with the ability to create
  • 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 filt
  • server nodes e.g., computer terminals h9 and hlO.
  • the public server and fil server software performs the following functions:
  • client manager nodes to delete client user accounts
  • sufficient address or contact information e.g., IP address and TCP port
  • FIG 3 shows three client
  • node software elements namely, the volume management, file system and disk subsystem. These software elements are designed to integrate with a conventional operating system/native file system 48 which may be sold with the client node.
  • the manner by which 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
  • client node software for each operating system/native file system with which the client node software is to work given the description below of what is to be achieved and other available
  • 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
  • buttons 1012 "standard button bar” 1020 with selectable “navigation buttons” 1022, “address bar” 1025, “folders” sub-window 1030 and sub-window 1040. As shown, the
  • 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 list of graphical icons representing files 1042 and folders (directories) 1044 contained on the
  • sub-window 1040 is intended to show individual files and a hierarchical organization for such files into directories and storage devices. As is well-known, the storage devices shown
  • graphically in the window 1000 can represent entile 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
  • client user may also use the DOSTM command hue interpreter to access.
  • the client node software also provides certain functionality for identifying and obtaining files and file data as the object of an action selected by one of the
  • the client node software provides such information to the operating system
  • the client node software provides sufficient integration of the functionality
  • tbe client node software performs
  • the application causes an access to another file (e.g., attempts to execute an application contained in another file or attempts to read, write, modify, etc. the data contain d in another data file). In so doing, the application generates the appropriate request to the operating system to perform the appropriate file access operations. If the file is contained in the virtual storage device, the
  • client node software intervenes and assists the operating system in identifying tbe appropriate tile and in providing the data of the file to the operating system to complete the access to the
  • the client node software does this transparently and automatically without requiring intervention by the user. This has a net effect from the
  • the virtual storage device and its contents (i.e., all of the files, directories/folders, etc. stored
  • the client node to be locally present. That is, the client node user and applications executing
  • client node software merely serves to locate and obtain valid copies of remotely stored or
  • 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 software may verify that the locally cached copy of the directory/folder infonnation or file data is still valid.
  • the client node software may download a valid copy of the directory /folder information or file data.
  • the client node software may upload the directory/fold ⁇ r information or file data to pennanently store
  • each client node has the ability to simultaneously write to a file or part of a file.
  • 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
  • the remote file server node functions as an intermediary node which performs each required access (most)
  • 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 "locking" files or portions of files to prevent access to such files or file portions according to
  • 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 en files, is achieved according to the operating system or other applications executing at the client node.
  • the client node software merely serves as a proxy for forwarding such commands and statuses between the client node
  • node software is automatic and transparent to the client node user and applications executing
  • FIG 5 shows a process for creating a virtual storage device and adding users. Assume
  • the client manager node Under control of the user of the client manager node in step SI 00, the client manager node issues a message containing a command to invite a new user, the email address of tbe 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.
  • this is achieved by the client manager node transmitting the message via the Internet to a remote file server node which manages the specific virtual drive.
  • the remote file server node which manages the specific virtual drive.
  • tile server node determines if the virtual storage device indicated by "drive id" exists but the user name 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 the client manager node via the Internet, a rejection message.
  • manager node displays a failure message to the user.
  • this prevents multiple
  • the remote file server node creates a record for the new user in step
  • the remote file server node communicates the successful completion of this step to the
  • step SI 08 the client manager node creates a one time
  • OTP is a bidirectional encryption decryption key.
  • the client manager node communicates to the new client user an invitation to join the group of user permitted to access the virtual storage device, which invitation includes the
  • 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 user node via the Internet, by addressing the email message to an Internet address of the client user.
  • 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 a data key (the purpose of which is described in greater detail below) with this OTP, to produce OTP(data key).
  • 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
  • the client user activates the join process by clicking on the email message.
  • the email message includes the URL of the remote file server node at which the client node user can join the
  • the message includes
  • the remote file server node to be contacted may be registered with a trusted third party.
  • Such authentication services are provided by companies such as Verisign 1 M , a company located in
  • the remote file server node accesses the list of records to determine if it has an entry corresponding to this new client user. If not, in step S124, 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 cliem node
  • the client node receives a message indicating that the remote file server 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
  • step SI 26 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
  • this pair of keys is randomly generated according to any combination
  • the client node permanently stores the private key Pre
  • step SI 28 the remote file server node stores the public key of the client node
  • step SI 30 the remote file server
  • 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 2 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 cliert node decrypts this twice encrypted message to obtain the data key. Then in step SI 34. the client
  • step SI 36 the remote file server node receives the encrypted
  • 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,
  • step S 164 which will be described below.
  • the remote file server validates only the user id and drive id.
  • 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 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 client node creates a drive container and generates a public
  • the client node then transmits the public key Puc to the remote file server node in rtep SI 66. As with the process of FIG 6A, the client node permanently
  • step 3168 a different, authenticated client user of the same pre-subscribed user group downloads the new client user's public key Puc and encrypts the data key Puc (data key).
  • step S 1 70 the
  • authenticated client user updates the new client user record at the server with the encrypted data key Puc (data key). At this point, the new client user may now decrypt the remote file
  • step SI 72 server drive data corresponding to the data key
  • the data key is a two-way encryption/decryption key which is used to encrypt data prior to uploading it from a client node to the remote file server node or
  • file server node have a clear-text version of the data key. Rather, the remote file server node
  • the remote file server node only has encrypted versions of the data key, namely, either OTP(data key) or Puc(data key).
  • 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 key Puc can be used to encrypt a message.
  • the public key Puc can be used to encrypt a message.
  • remote file server node maintains the public key Puc and the data key encrypted by the
  • server node to decrypt the data key.
  • 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
  • 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
  • a storage medium e.g., a floppy diskette
  • the client node user can then access the virtual storage device from each client node provided with a copy of the identity profile.
  • a copy of the separately stored identity profile e.g.,
  • FIG 7 shows ⁇ flowchart describing a process Ibi authenticating a connection between a client node and a remote file sever node. This process is performed each time the client node and remote file server node establish a connection, assuming that the client node has
  • step S200 the client node issues a connection request message via the Internet to the remote file server node.
  • the client node issues the message to a
  • the virtual storage device to be accessed by the client node.
  • step S202 the remote file server node
  • the remote file server node receives the message and first determines if the user name and virtual storage device identifier are a valid combination by consulting a list of valid, pre-subscribed user names stored at, or otherwise accessible by, the remote file server node for the respective virtual storage device
  • the remote file server node denies the connection in step S204. In denying the
  • the remote file server node may issue an appropriate rejection message to the
  • 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 transmits this encrypted random string Prs(S) and a second random string K to the client node.
  • step S210 the client node decrypts the encrypted random string Prs(S) with the public key Pus of the remote file server node in order to obtain the clear text message of the
  • step S212 the client node determines if this decryption of the received encrypted message using the servers public key. Pus(Prs(S)), yields S. If not. then the client
  • node determines that it has failed to authenticate the identity of the remote file server and breaks the connection in step S214. On the other hand, 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
  • step S2128 the remote file server node attempts to decrypt this received
  • step S220 the remote file server
  • Puc(Prc(K)) yields the second random data string K. If not, then in 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 client node. That is, the remote fiie server node determines that only the client node has the capability (most notably, the appropriate private key Pre) for encrypting the random string K
  • 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.
  • 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
  • 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 node to the remote fiie server node. Assume that the client node has file data to upload to the re ote file server node. In step S300, the client node creates a file header including d e information indicating the file size, segment size and number of segments, ⁇ t may be possible
  • the number of segments being the quotient of the file size/segment size.
  • the number of segments and the segment size need be specified.
  • the offset can, for example, be specified by the number of segments or empty
  • the file header illustratively includes an object
  • OID identifier
  • 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
  • step S304 the client node
  • step S306 the client node
  • step S308 the client node appends tbe header created in step S
  • the remote file server node receives the transmitted encrypted and compressed file data including the header. Using the offset information in the header, the
  • remote file server locates the correct storage space, within the respective (master) copy of the
  • the client node determines if the transfer of the portion of the file has
  • step S308 the client node may omit or suitably modify the client node
  • 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 S322 the remote file server node sets an internal counter "Next Segment" to indicate the first to-be-downloaded segment, e.g., equal to zero. On the other hand, if the request received at step S322, the remote file server node sets an internal counter "Next Segment" to indicate the first to-be-downloaded segment, e.g., equal to zero. On the other hand, if the request received at step S322, the remote file server node sets an internal counter "Next Segment" to indicate the first to-be-downloaded segment, e.g., equal to zero. On the other hand, if the request received at step S322, the remote file server node sets an internal counter "Next Segment" to indicate the first to-be-downloaded segment, e.g., equal to zero. On the other hand, if the request received at step S322, the remote file server node sets an internal counter "Next Segment" to indicate the first to-be-downloaded segment, e.g., equal to zero. On the other hand,
  • 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
  • step S326 the remote file server node
  • 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 tc retrieve the
  • 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
  • the client node transmits a request to the remote file server node to download a portion of file
  • the remote file server
  • 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
  • step S340 the client node determines whether or not the ail of the requested file data has been successfully downloaded. If not. then in step S342, the client node increments it' ⁇ counter of the Next segment to be downloaded and causes steps S332-S340 io be lepeaied.
  • a client node capable of allocating a new data
  • the client node generates
  • This data key may be used to encrypt file data transferred to the remote file
  • the client node then encrypts the new data key using is public key Puc to produce an encrypted new data key Puc(new data key).
  • the client node then transmits (e.g., via the Internet) the encrypted new data key Puc(new data key) to the remote file server with a
  • the remote file server responds by storing the encrypted new data
  • each client user in the pre-subscribed user group maintains a complete list
  • the complete list is accurate since every time a new client user is added, the new 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
  • 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 r , Puc",..., etc. which this client user node ' has requested.
  • the client node then encrypts the new data key using each cf 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, of any data key. Rather, all the remote file server has in its possession is multiple encrypted
  • 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 data even though the client node may be unable to communicate with the
  • 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 aiea network, and although communication is not always possible between the remote file server node and any given client (and in fact is not guaranteed or even needed between any two of the client nodes), the same expected behavior is achieved as can
  • a file version control added to ⁇ ach file and each directory stored on the virtual storage device (i.e., both with the master copy at the remote file server node and the local copy at each client node).
  • the file version control is used to ensure that,
  • 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
  • a check is performed to ensure that the directory information is up-to-date as of the time of the access.
  • file sharing mode in addition to a version check performed according to the invention, file sharing mode and
  • privilege access right checks can also be performed at the same times.
  • 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 sharing mode locking. In this latter case, the remote file server node would only permit
  • 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 server node, no version checking is needed for uploading and storing file data modifications as no other client node will be granted write access to the same file in a fashion which
  • the remote file server node will have
  • file server node to have granted write access permission to another client node (as described
  • the client node and remote file server node first perform a reconciliation process, including checking the version of the client node's locally
  • FIG 10 illustrates a process executed by the client nodes and the remote file server node:; Assume that the client node and remote fiie server node have already authenticated the connection.
  • the client node determines if communications have been restored. This can occur by reason of establishment of a new connection or by reason of restoration of communication with the remote file server node after detection of a loss of
  • step S402. This is described in greater detail below.
  • step S404 the client node determines whether or not there is a need to access
  • the client node returns to step S400. Assume now that a file or directory access must be performed at the client node.
  • step S406 the client node determines if the requested operation is one which requires a
  • the client node illustratively do not require a version check. If no version check is required,
  • step S414 attempts to perform the requested access operation. Many of the attempted requested access operations are simply performed according to the normal operation of the operating system and/or application executing at the client node
  • the upload process described above is also carried out for p poses of uploading the modifications to the file data.
  • 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
  • the client node can instead issue a request for the file
  • steps S409-S410 is continuously performed until a
  • step S410 the time-out timer expires in step S409 or the condition of step S410 is satisfied.
  • the client node determines whether or not the client node has received any response from the
  • the client node If the client node fails to receive a response form the remote file server node within the time limit of the time-out timer, the client node presumes that it is out of communication with the remote file server node. If so, then in 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
  • info ⁇ nation if the client node has any. Note that if the client node does not have the requisite
  • the client node illustratively defers uploading the modifications. As described below, the uploading of such modifications
  • 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 below, there are two circumstances in which the requested access is not permitted,
  • the client node lacks sufficient access right privileges to perform the access and/or the requested access conflicts with a file sharing mode of the file explicitly or implicitly
  • the client node illustratively provides an appropriate abort/failure message to the user indicating why the access was denied, e.g., displays the message on the
  • step S414 the client node performs the requested
  • 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
  • access rights to perform the requested access are performed using operating system software supplied with the remote file server node. If the
  • the remote file server node does not have the requisite access privilege rights
  • i 0 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 in 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 ⁇ 5 determine if the requested access adheres to implicit and explicit native file sharing modes specified by the native file application programming interface governing the file data or
  • step a Assume that the requested access does adhere to such file sharing modes.
  • 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 version number provided by the client node does not match the current version number for
  • step S428 the remote file server node 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 oi directory
  • info ⁇ nation is detected by the client node in steps S410 and S416.
  • a client node can obtain the latest version of file data or directory information and store it as a local copy in order to perform accesses. This provides
  • the local copy acts as a "cached copy" in that it is much easier to access the local copy than to perform the accesses via the Internet.
  • the local copy acts as a "cached copy" in that it is much easier to access the local copy than to perform the accesses via the Internet.
  • 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
  • a client node user can specify a desire to hoard
  • 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 client node then updates its locally cached copy of the
  • the client node can ensure that between accesses to such hoarded files or directories, the remote file server node is continuously updating such
  • 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 directory information is downloaded. Moreover, as described below, should the client node access an outdated version of a file while out of communication with the remote file server
  • 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 remote file server node closes the communication channel with the given client node, prior to closing a file or directory last accessed by the given client node,
  • the remote file server node can relinquish control of that file or directory by the given client
  • client node is enabled to access its local "cache" copy of the file or directory while out of
  • two client nodes may perform incompatible modifications to the file data or directory information.
  • an elaborate reconciliation mechanism is provided
  • client node first identifies each local copy of file data and directory information maintained locally in a storage device (e.g., disk memory 15) physically present at the client node.
  • a storage device e.g., disk memory 15
  • client node checks the version of each such locally maintained copy of file data and directory information by transmitting a message to the remote file server node.
  • the remote file server node checks the version of the respective file data
  • the client node often is required to perform some reconciliation action.
  • the client node often is required to perform some reconciliation action.
  • the remote file server node transmits appropriate sufficient messages regarding the outcome of the validity check described above for enabling the client node to perform the correct
  • FIG 11 contains a chart summarizing the reconciliation actions taken by the remote
  • each cell of ihe chart is labeled with a row number R1 , R2, R3, R4 and R5 and a column number CM , C2, C3, C4 and C5.
  • the rows Rl R5 contain cells indicating the actions taken when the client node: makes no changes to the file data (Rl );
  • the client node also makes no
  • the client node or the client node. If the client node made a change to the contents of the file data, i.e., modified or wrote to the file (R2, Cl), the modifications (or the entire modified file) are
  • the remote file server node saves this modified file data.
  • the client node lenames the file or moves it to another directory CR3, CD
  • the remote file server node performs the same renaming or movement action on the (master) copy ot the file maintained at the remote file server node.
  • the client node deletes the file (R4.
  • 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
  • the conflict bin is a directory (of the disk memory 15) at the client node in which the client node places information or file data indicative of unresolvable conflicts.
  • the (master) copy of the file at the remote file server node is renamed or moved (C3), e.g., by another client node. If the client node did not change its
  • the client node performs tbe corresponding renaming or movement actions on its local copy of the file containing the unchanged file data.
  • the client node changed the file data, i.e., modified the tile data or write to the file data (R2, C3), then the client's local copy of the file data is moved to the conflict bin.
  • the modifications to the file data are uploaded to the remote file server node.
  • the remote file server node stores the modified file data (or entire modified file) under the new name or moved location of the fiie. If the client node changed the name of the
  • 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 (Rl. C4 or Rl , C5 ⁇ the client node simply deletes or invalidates its local copy of the file data If the client node had changed, i.e.. modified or written to, its local copy of the file data (R2,
  • the client node moves its local copy of the file data (or entire file) to the conflict bin. Likewise, if the client node had renamed or moved the file (R3, C4 or R3, C5),
  • the client node moves its local copy of the file data (or entire file) to the conflict bin.
  • the client node uploads the file to the remote file server node which stores the uploaded copy under the new name or
  • FIG 12 contains a chart summarizing the reconciliation actions taken by the remote
  • each cell of the chart is labeled with a row number Rl', R2', R3', R4' and R5' and a column number Cl', C2', C3', C4' and C5'.
  • the rows Rl'-R5' contain cells
  • 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
  • R3' adds a file or child/subdirectory to a directory
  • remote file server node Cl'
  • the client node also has not changed/modified the directory (Rl', Cl') in which case no action is needed. If the client node: changed/modified one or more attributes of the directory (R2', Cl'); or added one or
  • attribute modifications e.g., changed attributes; or new file and/or child/subdirectory entries; are uploaded to the remote file server node.
  • 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
  • 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
  • the client node was modified while the remote file server node was out of communication with the client node in a fashion which was incompatible with a change/ modification made by the client node under the same period of time.
  • the client node adds one or more
  • the attribute modifications are downloaded to the client node and stored locally.
  • the client node made no changes/modifications to the directory (Rl', C3'), then the added file
  • the server node to the client node where they are stored locally. If the client node also added files or cliild/subdirec tories (R3', C3'), a determination is first made to see if any are incompatible with the added files or child subdirectories at the remote file server node.
  • An example of an incompatible entry is where both the client node and the remote, fiie ser/er node both attempted to add a file or child/subdirectory having the same name. If the additions made by
  • the client node are compatible with the additions made at the remote file server node then the file and child/subdirectory entries made by the client node are uploaded to the remote file
  • the client node moves each of the client node's file or child/subdirectory
  • server node to the client node. If the client node deleted the directory (R5', C3'), the new files and directories are downloaded from the remote file server to the client node and the client
  • node is renamed or moved (C4'), e.g., by another client node. If the client node made no
  • the client node change one or more attributes of the directory (R2', C4') then the client node nevertheless correspondingly renames or moves its local copy of the directory in conformity with the remote file server node. However, the client node also
  • the client node uploads the attribute changes to the remote file server node which stores them.
  • the client node adds one or more new files or cbiid/subdirectories (R3 1 , C4') then the client node nevertheless correspondingly renames or moves its local copy of the directory in conformity with the remote file server node.
  • the client node also uploads the
  • the client node if the client node performed an identical renaming and/or moving operation. If so, no action is taken. Otherwise, the client node places a warning in the conflict bin indicating that the
  • the client node downloads from the remote file sever node a
  • C5' deleted (C5'), 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
  • the client node also deletes the locally stored
  • the client node If the client node moved or lenam ⁇ d the directory (R4', C5') then the client node stores a warning in the conflict bin indicating that the directory had been
  • remote file server nodes perform two access checks on fiie data and director ⁇ ' entries.
  • the remote file server nodes check to make sure that the client node requesting 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
  • access control nodes other than the remote file server nodes which
  • FIG 13 shows an illustrative environment in which this embodiment of the invention
  • h20-h32 can be used, namely, a wide area network 200, such as the Internet.
  • a wide area network 200 such as the Internet.
  • h20-h32 can be used, namely, 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 netv/ork, which, with router
  • Computer terminal h26 denotes a mobile client node forming
  • Computer terminals h27 is an access control node, which, with router r21,
  • Computer terminals h28-h30 are remote file server nodes, which , with
  • Computer terminals b . -h33 are remote file server nodes
  • subnetworks 122-124 contain
  • subnetworks themselves, can be owned by an independent access provider or ISP).
  • ISP independent access provider
  • 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.
  • control node h27 For purposes of this discussion, the steps associated with version control
  • FIG 14 illustrates a process carried out according to this embodiment of the invention.
  • FIG 14 is similar to the process of FIG 10. As such, only the differences between these two
  • the client node h26 desires to access a particular file or directory
  • step S406 that a version check is necessary in step S406. Assume also initially, that the delegation of
  • step S502 the client node
  • h26 first dete ⁇ nines whether or not the client node knows of an access control node delegated to the file or directory to be accessed, if not, the client node h26 transmits to remote file server node h28 via the Internet a request to access the particular file as in step S408 and
  • step S508 the client node determines if the response was received from ⁇ 3 nuiie. other than riie remote file server node h28, which identifies itself as the access controi node (namely, the
  • the client node 3 ⁇ 2 ⁇ authenticates a connection with this other node before communicating with it. If so, the client node stores, (e.g. in
  • step S510 The client node h26 then performs the remaining steps S416, S412, S414, S418. etc.

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 concerne un service et un système de stockage de fichiers multi-utilisateur permettant à chaque utilisateur d'un groupe d'utilisateurs préalablement abonné d'utiliser un noeud client arbitraire (h20-h26) à un emplacement géographique arbitraire pour communiquer avec un noeud serveur de fichiers éloigné (h28-h30, h32-h33) par l'intermédiaire d'un réseau étendu (200) et pour accéder aux fichiers du groupe de fichiers par l'intermédiaire du noeud client respectif en communication avec le noeud serveur de fichiers éloigné par l'intermédiaire du réseau étendu. Ainsi, l'intégrité des fichiers sur le noeud serveur de fichiers éloigné est assurée par le contrôle de chaque accès à chaque fichier sur le noeud serveur de fichiers éloigné de sorte que chaque accès à des fichiers du serveur de fichiers éloigné est exécuté, le cas échéant, sur une partie respective de chaque fichier la plus récemment actualisée sur le noeud serveur de fichiers éloigné. Un contrôle de version sur un fichier particulier du groupe de fichiers peut être délégué à un noeud de contrôle de version (h31).
PCT/US2000/030078 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 WO2001033383A1 (fr)

Priority Applications (1)

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

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 (2)

Publication Number Publication Date
WO2001033383A1 true WO2001033383A1 (fr) 2001-05-10
WO2001033383A9 WO2001033383A9 (fr) 2002-05-16

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 Before (2)

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

Country Status (3)

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

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7593943B2 (en) 2005-01-14 2009-09-22 Microsoft Corporation Method and system for synchronizing multiple user revisions to a shared object
US7953794B2 (en) 2005-01-14 2011-05-31 Microsoft Corporation Method and system for transitioning between synchronous and asynchronous communication modes
US20180262358A1 (en) * 2017-03-10 2018-09-13 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Method for monitoring broadcast message and terminal

Families Citing this family (18)

* 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
US7013379B1 (en) 2001-12-10 2006-03-14 Incipient, Inc. I/O primitives
US6959373B2 (en) 2001-12-10 2005-10-25 Incipient, Inc. Dynamic and variable length extents
US7173929B1 (en) 2001-12-10 2007-02-06 Incipient, Inc. Fast path for performing data operations
AU2002366270A1 (en) * 2001-12-10 2003-09-09 Incipient, Inc. Fast path for performing data operations
US6986015B2 (en) 2001-12-10 2006-01-10 Incipient, Inc. Fast path caching
CA2407774C (fr) 2002-07-16 2005-01-04 Musicrypt Inc. Systeme et methode de distribution de contenu
DE10257819B4 (de) * 2002-12-10 2005-10-13 Web.De Ag Netzwerkbasierter Datenzugriff mit getrenntem Datenübergang und Datenübertragung
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 群暉科技股份有限公司 用來進行檔案同步控制之方法與裝置
CN106487761B (zh) * 2015-08-28 2020-03-10 华为终端有限公司 一种消息传输方法和网络设备
CN106446142A (zh) * 2016-09-21 2017-02-22 郑州云海信息技术有限公司 一种多区域间文件系统的设计方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5758072A (en) * 1988-07-15 1998-05-26 International Business Machines Corp. Interactive computer network and method of operation
US5966715A (en) * 1995-12-29 1999-10-12 Csg Systems, Inc. Application and database security and integrity system and method

Family Cites Families (6)

* 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
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
US5862346A (en) * 1996-06-28 1999-01-19 Metadigm Distributed group activity data network system and corresponding method
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
US5889942A (en) * 1996-12-18 1999-03-30 Orenshteyn; Alexander S. Secured system for accessing application services from a remote station

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5758072A (en) * 1988-07-15 1998-05-26 International Business Machines Corp. Interactive computer network and method of operation
US5966715A (en) * 1995-12-29 1999-10-12 Csg Systems, Inc. Application and database security and integrity system and method

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7593943B2 (en) 2005-01-14 2009-09-22 Microsoft Corporation Method and system for synchronizing multiple user revisions to a shared object
US7953794B2 (en) 2005-01-14 2011-05-31 Microsoft Corporation Method and system for transitioning between synchronous and asynchronous communication modes
US8150919B2 (en) 2005-01-14 2012-04-03 Microsoft Corporation Method and system for transitioning between synchronous and asynchronous communication modes
US20180262358A1 (en) * 2017-03-10 2018-09-13 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Method for monitoring broadcast message and terminal

Also Published As

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

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
WO2001033383A1 (fr) Service de fichiers partages base sur internet a semantique et acces client pc natifs et controle de version reparti
US7376711B2 (en) Smart card enabled mobile personal computing environment system
US8572757B1 (en) Seamless secure private collaboration across trust boundaries
US9015858B2 (en) Graphical user interface for seamless secure private collaboration
JP6426325B1 (ja) デジタルコンテンツアイテムのマルチプレミスホスティングのための同期プロトコル
US6662198B2 (en) Method and system for asynchronous transmission, backup, distribution of data and file sharing
US7222231B2 (en) Data security for distributed file systems
US9852147B2 (en) Selective synchronization and distributed content item block caching for multi-premises hosting of digital content items
US20190222476A1 (en) Community Internet Drive
US6981152B2 (en) Smart card security information configuration and recovery system
CN103931156B (zh) 具有用户不可知加密文件的服务器侧去重的云文件系统
US8862894B2 (en) Computerized method, program, and apparatus for limited sharing of digital content
TWI412261B (zh) 根據存取權提供服務的方法
US20190087432A1 (en) Secure searchable and shareable remote storage system and method
US20060242206A1 (en) System and method for peer to peer synchronization of files
US20130290256A1 (en) System and Method for Managing User Data in a Plurality of Storage Appliances Over a Wide Area Network for Collaboration, Protection, Publication, or Sharing
US20150199414A1 (en) Locally cached file system
KR101971225B1 (ko) 클라우드 서버의 데이터 전송 보안 시스템 및 그 제공 방법
JP2018536207A (ja) デジタルコンテンツアイテムのマルチプレミスホスティングのための同期プロトコル
JP2005536801A (ja) ピア・ツー・ピア型のデータの遠隔記憶及び共同利用
KR101623742B1 (ko) 파일 연관 메시지 공유 방법 및 메시지 공유 시스템
JP6216673B2 (ja) データ管理方法及びデータ管理システム
TW588531B (en) Smart card enabled mobile personal computing environment system

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)
AK Designated states

Kind code of ref document: C2

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: C2

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

COP Corrected version of pamphlet

Free format text: PAGES 1-71, DESCRIPTION, REPLACED BY NEW PAGES 1-71; PAGES 72-113, CLAIMS, REPLACED BY NEW PAGES 72-113; PAGES 1/14-14/14, DRAWINGS, REPLACED BY NEW PAGES 1/17-17/17; DUE TO LATE TRANSMITTAL BY THE RECEIVING OFFICE

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase