Source: http://www.google.com/patents/US8103631?dq=7,441,219
Timestamp: 2016-12-04 15:21:23
Document Index: 624388696

Matched Legal Cases: ['art1', 'art1', 'art1', 'art0', 'art1', 'art2', 'art3', 'art1', 'art1', 'art1', 'art2', 'art2', 'art2', 'art1', 'art1', 'art2', 'art2', 'art3', 'art3', 'art2', 'art2', 'art1', 'art2', 'art1', 'art1']

Patent US8103631 - Merging files on storage and retrieve - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsA client designates and transfers a file to a server in distinct chunks. The number of data chunks equals the number of communication sessions that are required to complete the transfer of the designated file to the server, that number being dependent on the number of times the communication session...http://www.google.com/patents/US8103631?utm_source=gb-gplus-sharePatent US8103631 - Merging files on storage and retrieveAdvanced Patent SearchTry the new Google Patents, with machine-classified Google Scholar results, and Japanese and South Korean patents.Publication numberUS8103631 B2Publication typeGrantApplication numberUS 12/274,145Publication dateJan 24, 2012Filing dateNov 19, 2008Priority dateNov 19, 2008Fee statusPaidAlso published asUS20100125591Publication number12274145, 274145, US 8103631 B2, US 8103631B2, US-B2-8103631, US8103631 B2, US8103631B2InventorsYaakov Ben Tsvi, Ittai Golde, Judah Gamliel HahnOriginal AssigneeSandisk Il LtdExport CitationBiBTeX, EndNote, RefManPatent Citations (18), Referenced by (4), Classifications (8), Legal Events (2) External Links: USPTO, USPTO Assignment, EspacenetMerging files on storage and retrieve
US 8103631 B2Abstract
The present invention generally relates to data transfers between a client and a server and more specifically to a client capable of transferring a large file to a server in an efficient way.
In online backup systems a client may concatenate many files into a single archive file and then upload the archive file as a whole to a remote backup server. In computers, an “archive file” might be a file that contains several compressed files, and a “client” might be an application or computer system that accesses a remote service on another computer system, known as a server, by using some communication network (e.g., the Internet).
A popular and simple way to transfer files, such as an archive file, from clients to backup servers is by using the Hypertext Transfer Protocol (“HTTP”). HTTP is a request/response communication standard that facilitates data transfers between a client and a server on the Internet. In the Internet environment a client is the end-user and the server is a website.
While every server used for backing up archive files supports standard HTTP/WebDAV commands such as “GET”, “PUT” and “LIST”, many servers do not support the byte-range feature that is required to resume failed data transfers. Thus, if a file (e.g., an archive file) transmitted from the client to the server is very large (e.g., at least in the order of megabytes) and the communication connection between the client and the server is interrupted or cut off during transmission, the entire file must be retransmitted at the next available opportunity, rather than transmitting only the portion of the file that has not yet been received by the server. This impedes using simple hosted web services as servers for online backup because sending a large file takes a considerable amount of time and requires computing resources. Therefore, the traditional requirement to retransmit the entire file only exacerbates this problem.
It would, therefore, be beneficial to back up files in a server in a way that it will not be necessary to retransmit the files if the communication connection is interrupted in the middle of a file transfer. Various embodiments are designed to implement such capability, examples of which are provided herein. Various embodiments are designed to implement such files management, examples of which are provided herein. The following exemplary embodiments and aspects thereof are described and illustrated but are not intended to be exclusive or limiting in scope.
To address the foregoing, a file, which may include, contain, or be associated with one or more client files, is transferred from a client to a server using a communication session. If the communication session is interrupted before the file transfer is completed, the file is transferred to the server using additional one or more communication sessions, where each communication session is used to transfer a different chunk of the file. A “communication session”, as used herein, necessitates establishing a communication channel between the client and the server and performing handshaking. In telecommunications “handshaking” is an automated process of negotiation that sets parameters of a communications channel that is established between two computer devices before normal communication over the channel begins. It follows the physical establishment of the channel and precedes normal information transfer. By “interruption” is meant herein any communication phenomenon that entails a new communication session.
By “designating a file for transfer” is meant a process by which one or more files (designated herein below as files f1, f2, . . . , fk) are transferred from a client to a server using a randomly changing number of files (also referred to herein below as “chunks”) that are name-wise related because their file names share a common part which is referred to herein as a “common file name”. The number of name-wise related files required to transfer the one or more files f1, f2, . . . , fk changes because each communication interruption causes an End-of-File (“EoF”) to be generated and entails the generation of a new such file. The number of the name-wise related files is random because communication interruptions occur randomly. The name-wise related files are collectively called “designated file” because their file names are variants of a common file name. Transferring a designated file, therefore, means transferring the name-wise related files, or chunks. The file or files to be transferred from the client to the server (i.e., files f1, f2, . . . , fk) may be transferred by using one or more chunks. That is, if a communication session is long enough the file or files f1, f2, . . . , fk can be transferred to the server as one chunk.
The unique variant of the file name may include, for example, a unique suffix (e.g., “, . . . , part1”), a unique prefix (e.g., “part1, . . . ,”), or a file extension (e.g., “.part1”) to the file name. The unique variant of the file name may include a unique sequential identifier. The unique sequential identifier may include an alphabetical, numeric, or alphanumeric index whose value is incremented for each time the latter two steps (i.e., the steps of establishing a communication session between the client and the server, and transferring the file to the server by using a unique variant of a file name of the file) are repeated, where, for each repetition, the client uses a different (i.e., unique) variant of the file name to transfer the rest or another chunk of the file to the server.
The information may include a size of each chunk of the file that is transferred to the server during one of the communication sessions, and the offset may be derived from the sizes of the transferred chunks. The offset may be the sum of all the sizes of the transferred chunks or the sum of the sizes of the transferred chunks excluding the size of the chunk that was transferred to the server during a previous communication session. By “previous communication session” is meant a communication session preceding an interrupted communication session.
The method may further include assigning to a flag a repeating value (e.g., “1” or “REPEAT”) or a non-repeating value (e.g., “0” or “NO_REPEAT”) to respectively indicate to a retrieving client whether transferring the file to the server has been completed or not. The retrieving client may be the client or some other client. The flag may be assigned the repeating value before or during the first communication session and the non-repeating value after transfer of the file to the server is completed.
In another embodiment the method may include designating by the client k data objects for transfer to the server; associating a common file name (e.g., F) to the designated k data objects; establishing a communication session between the client and the server; and, while the communication session is uninterrupted, sequentially transferring data objects to the server, one data object after another, by using a unique variant of the file name (e.g., “F.part0”). If the communication session is interrupted, the method may include reestablishing the communication session and continuing to transfer untransferred data objects to the server by using, during each reestablished communication session, a different unique variant of the file name F. The process of reestablishing the communication session and continuing to transfer untransferred data objects is repeated until the last untransferred data object is transferred to the server. A data object may be or include one or more files f1, f2, . . . , fk, and/or data, and metadata related to one or more of files f1, f2, . . . , fk.
The designated file or k files may be transferred from the client to the server and retrieved from the server by using, for example, Hypertext Transfer Protocol (“HTTP”).
Files f1, f2, . . . , fk may be of the same type (e.g., multimedia file). For example, one or more files may be multimedia files, other files may be WORD files, picture files or MP3 files, etc. After processor 130, or a user of client 100, selects the k files for transfer to server 150, processor 130 associates a common file name F with the k selected files. The associated common file name may be chosen arbitrarily, provided that the chosen file name is not already used by the pertinent file system. For example, it can be “myfile” (i.e., F=myfile), “transfer_file” (i.e., F=transfer_file), “exchang_file” (i.e., F=exchang_file), or any other name.
Notating the common file name can be implemented in various ways. For example, if the common file name assigned to, or associated with, the k selected files is “myfile”, the file name myfile can be uniquely notated by adding to it some differentiating text or index (e.g., “myfile—1”, “myfile—2”, myfile—3”, and so on) or some file extension (e.g., “myfile.part1”, “myfile.part2”, myfile.part3”, and so on). Even though each file name is unique because of its differentiating index or extension, the file names all share a common file part: the assigned common file name (in this example “myfile”). The common file part is used by client 100 as a filter: (1) to retrieve from server 150 information pertaining to transferred files in order to identify the point in memory 110 from which to resume transfer of other files, and, after all the files have been transferred to server 150, (2) to retrieve the files from server 150.
FIG. 1B is a block diagram of a device 200 with a client according to an example embodiment. Device 200 may have all the physical components (e.g., a memory device 210, a storage controller 220, a processor 230 and a communication interface 240) necessary for it to function in a similar way as client 100 of FIG. 1A. Memory 210, storage controller 220, processor 230 and communication interface 240 may respectively be function-wise similar to memory 110, storage controller 120, processor 130 and communication interface 140 of FIG. 1A. Physical components of device 200 may operatively interact with processor 230 and be configured to perform the steps, procedures and method described above, for example in connection with FIG. 1A. In one example, memory device 210 may store a client software application (e.g., “client application” 215) or firmware and be operatively linked to/with processor 230 to cause processor 230 to execute instructions of the client software application to (i) designate a file for transfer to server 150; (ii) establish a communication session between processor 230 and server 150; (iii) transfer the designated file to server 150 by using a unique variant of a file name of the designated file; and (iv) if the communication session between processor 230 and server 150 is interrupted before transfer of the designated file to server 150 is completed, to repeat steps (ii) and (iii) (i.e., establishing a communication session between processor 230 and server 150, and transferring the designated file to server 150 by using a unique variant of a file name of the designated file) as many times as required for processor 230 to complete the file transfer to server 150. The client may be implemented as a special-purpose processor that replaces processor 230.
FIG. 2 demonstrates transferring a designated file from a client to a server according to one example embodiment. A file f1 with an exemplary file name DayTrip, which is stored in memory 200, is to be transferred (i.e., it is designated for transfer) from a client to a server. In order to transfer file f1 to the server, a communication session is established between the client and the server and a unique variant of the file name DayTrip (e.g., “DayTrip_P1”) is used to transfer file f1. After a first chunk 210 of file f1 is transferred to the server the communication session is assumed to be interrupted. Because file f1 has not been completely transferred to the server, a second communication session is established (or the first/original communication session may be thought of as being reestablished) and a different variant of the file name DayTrip (e.g., “DayTrip_P2”) is used to transfer the untransferred part of file f1 to the server.
After a second chunk 220 of file f1 is transferred to the server the communication session is assumed to be interrupted. Because file f1 still has another part that should be transferred to the server, a third communication session is established (or the first/original communication session may be thought of as being reestablished) and a different variant of the file name DayTrip (e.g., “DayTrip_P3”) is used to transfer the untransferred part of file f1 to the server. It is assumed that transferring file f1 requires three communication sessions, which results in the designated file f1 being transferred to the server in three chunks (i.e., chunks 210, 220, and 230).
As explained above, the number of chunks that are transferred to the server equals to the number of the communication sessions required for a complete transfer of the involved file, and the size of each chunk depends on the duration of the associated communication session. The (common) file name used to transfer file f1 to the server can be the original file name (e.g., “DayTrip”) of filed f1. Alternatively, file f1 may be transferred to the server by using a file name other than the file's original name. For example, the file name “TransFile” may be used instead of the file's original name DayTrip. The file name used to transfer the designated file to the server may be chosen randomly.
FIG. 3 demonstrates transferring a designated file from a client to a server according to another example embodiment. Files f1, f2, . . . , f3 and f4, which are stored in memory 300, are to be transferred from a client to a server. In order to transfer files f1, f2, f3, f4 to the server a common file name (e.g., “myfile”, shown at 302) is assigned to them (i.e., a file called myfile is designated for transfer). By “assigned to them” is meant that different variants of the common file name myfile will be used to transfer different chunks of the designated file myfile, where the number of variants of the common file name matches the number of chunks which depends on the number of communication interruptions. After the common file name myfile is assigned to files f1, f2, f3, f4, the files f1, f2, f3, f4 are transferred to the server, one file after another, by using unique variants of the common file name myfile, as described below.
In order to transfer files f1, f2, f3, f4 to the server, a first communication session is established between the client and the server and the files f1, f2, f3, f4 are started to be transferred to the server, on file after another, by using a unique variant of the designated file myfile is (e.g., “myfile.Chunk1”). After a first chunk 310 of the designated file myfile is transferred to the server the communication session is assumed to be interrupted. It is assumed that the first two files f1, f2 were completely transferred to the server within or as part of chunk 310 and that files f3, f4 still need to be transferred. Therefore, a second communication session is established (or the first/original communication session may be thought of as being reestablished) and a different variant of the file name myfile (e.g., “myfile Chunk2”) is used to transfer the rest of the files (i.e., files f3, f4) to the server.
After a second chunk 320 of the designated file myfile is transferred to the server the communication session is assumed to be interrupted. It is assumed that the file f3 was completely transferred to the server within or as part of chunk 330 and that file f4 still needs to be transferred. Therefore, a third communication session is established and a different variant of the file name myfile (e.g., “myfile Chunk3”) is used to transfer file f4 to the server.
After a third chunk 330 of the designated file myfile is transferred to the server the communication session is assumed to be interrupted. It is assumed that the communication interruption occurred during transfer of file f4, which means that chunk 330 includes only part of file f4. Therefore, a fourth communication session is established and a different variant of the file name myfile (e.g., “myfile Chunk4”) is used to transfer the rest of file f4 to the server. Alternatively, in order to ensure error-free communication of a particular file that was partly transferred to the server, the entire particular file, whose transfer to the server was interrupted, may be sent to the server. Referring to FIG. 3, the entire file f4 may be transferred to the server as part of chunk 340 or only the part thereof which was not transferred as part of any of the previous chunks 310, 320 and 330.
At step 450 processor 130 checks whether the current communication session is interrupted. If the current communication session is not interrupted (shown as “N” at step 450), then at step 460 processor 130 checks whether transferring the designated file to server 150 is completed. If transfer of the designated file is not completed (shown as “N” at step 460), transfer of the designated file continues in a regular manner as long as the current communication session is uninterrupted. If transfer of the designated file to server 150 is completed (shown as “Y” at step 460) without any communication interruptions in the current communication session, processor 130 terminates the file transfer process after using only one communication session. However, if the current communication session is interrupted before transfer of the designated file is completed (shown as “Y” at step 450), processor 130 establishes, at step 420, a second communication session and iterates steps 430, 440, 450 and 460 until transfer of the designated file to server is completed.
FIG. 5 is a method for transferring files from a client to a server according to another example embodiment. FIG. 5 will be described in association with FIG. 1A. At step 510, processor 130 selects k files f1, f2, . . . , fk for transfer to server 150. At step 520 processor 130 associates, or assigns, a common file name, for example “archive_file”, to the k selected files f1, f2, . . . , fk. At step 530, processor 130 establishes a communication session with server 150.
At step 540, processor 130 uniquely notates the common file name archive_file and prepares to transfer to server 150 files f1, f2, . . . , fk. At this stage the communication session established between processor 130 and server 150 is the first communication session and processor 130 notates the common file name archive_file by adding, for example, the file extension “part1” to the common file name. If the first communication session is not interrupted at least until all files f1, f2, . . . , fk are transferred to server 150, the files' transfer process requires one communication sessions. If, however, the communication session is interrupted before all files f1, f2, . . . , fk are transferred to server 150, an additional communication session would be required during which transfer of files f1, f2, . . . , fk will continue substantially from the point where the first communication session was interrupted. If, for example, the i (e.g., first) communication session was interrupted in the middle of the transfer of file f3, the transfer of the files will continue during the i+1 (e.g., second) communication session by completing the transfer of file f3, and then by transferring the rest of the files.
At step 550 processor 130 notifies server 150 of the first notated file name (e.g., archive_file.part1). Responsive to receiving the first notated file name server 150 (i) prepares for storing whatever files processor 130 intends to transfer to server 150, and (ii) acknowledges to processor 130 receipt of the first notated file name. Responsive to receiving the acknowledgement from server 150, processor 130 uses the first notated file name archive_file.part1 to transfer to server 150 as many files among files f1, f2, . . . , fk as possible. As long as the first communication session is free of interruptions (shown as “N” at step 560) and the last file has not yet been transferred (shown as “N” at step 570), processor 130 continues to transfer to server 150 one file after another during the first communication session. If the first communication session is long enough, processor 130 transfers to server 150 all the files f1, f2, . . . , fk in the first (and only) communication session. However, if the first communication session is interrupted (shown as “Y” at step 560) before all the files f1, f2, . . . , fk are transferred to server 150, then at step 530 processor 130 establishes a second communication session.
At step 540, processor 130 uniquely notates the common file name archive_file and prepares to transfer to server 150 the rest of the files f1, f2, . . . , fk. At this stage the communication session established between processor 130 and server 150 is the second communication session. Therefore, processor 130 may notate the common file name archive_file by adding, for example, the file extension “part2” to the common file name archive_file.
At step 550 processor 130 notifies server 150 of the second notated file name (e.g., archive_file.part2). Responsive to receiving the second notated file name server 150 (i) prepares for storing whatever file(s) processor 130 intends to send to server 150, and (ii) acknowledges to processor 130 receipt of the second notated file name. Responsive to receiving the acknowledgement from server 150 processor 130 uses the second notated file name archive_file.part2 to transfer to server 150 as many untransferred files among files f1, f2, . . . , fk as possible (i.e., until the communication session is interrupted). As long as the second communication session is free of interruptions (shown as “N” at step 560) and the last file has not yet been transferred (shown as “N” at step 570), processor 130 continues to transfer to server 150 one untransferred file after another during the second communication session. If the second communication session is long enough, processor 130 transfers to server 150 all the rest of the untrenasferred files among files f1, f2, . . . , fk in the second communication session. However, if the second communication session is interrupted (shown as “Y” at step 560) before all the rest of the untransferred files are transferred to server 150, then at step 530 processor 130 establishes a third communication session. During the third communication session processor 130 transfers additional untransferred files to server 150 and if transfer of the untransferred files is interrupted one or more times processor 130 may use additional one or more communication sessions to transfer more files by repeating steps 530 through 570.
If a communication session is not interrupted (shown as “N” at step 560), processor 130 checks, at step 570, whether the file currently transferred to server 150 is the last file to be transferred. If it is the last file to be transferred file, processor 130 completes its transfer and terminates the files' transfer process. However, if the file currently transferred to server 150 is not the last file to be transferred, processor 130 continues to transfer that file and, for as long as the current communication session is still intact, also the other files.
As explained above, a communication session may be interrupted before processor 130 completes the transfer of a particular file. For example, the communication session may be interrupted during the transfer of file f1 or after processor 130 transfers the first three files (e.g., f1, f3, f8) to server 150. Processor 130 “knows” which files are yet to be transferred to server 150 (i) by receiving, from server 150, information pertaining to files (e.g., file names and file sizes) that have already been transferred to server 150, or (ii) by maintaining the information in lookup table 115 in client 100.
As explained above, the steps of reestablishing a communication session and transferring more files during the reestablished communication sessions may need to be repeated. For file(s) transferring purpose client 100 may use a flag to indicate to a retrieving client whether or not all the files f1, f2, . . . , fk have been transferred to server 150. For example, a flag called “FLAG” may be set to some repeating value (e.g., “1” or “Transfer”) before the first file of the files f1, f2, . . . , fk is transferred to server 150, and to some non-repeating value (e.g., “0” or “End-of-Transfer”) after the last file of the files f1, f2, . . . , fk is transferred to server 150. The “retrieving client” may be client 100 or any other client, for example remote client 190. Client 100 may send a corresponding URL link to remote client 190 and remote client 190 may use that link to retrieve file f1, f2, . . . , fk from server 150.
FIG. 6 is a method for retrieving files from a server according to an example embodiment. It is assumed that a server stored files that are name-wise related (i.e., their file names are unique variants of a common file name). At step 610 a retrieving client sends the common file name to the server. At step 620 the server uses the common file name to seek search for the name-wise related files associated with the common file name. At step 630 it is checked whether such name-wise related files exist. If the server does not find such files (shown as “N” at step 630) the file-retrieving process is terminated. If the server finds such files (shown as “Y” at step 630) the server transfers the files that it found to the retrieving (i.e., requesting) client.
FIG. 7 demonstrates exchanging data between a client 702 and a server 704 according to an example embodiment. Client 702 and server 704 operate in a similar manner as client 100 and server 150 of FIG. 1A, respectively. Client 702 has ten files f1, f2, . . . , f10 (shown at 706) that have to be transferred to server 704. Client 702 will use the common file name “myfile” (shown at 708) to transfer files f1, f2, . . . , f10 to server 704 in the way described below. As explained above, it may be said that file “myfile” is designated by client 702 for transfer to server 704.
In order for client 702 to send ten files 706 to server 704, client 702 uniquely notates the common file name myfile (i.e., it prepares a unique variant of the common file name) by using a first notation “part1” 712. Client 702, then, sends the file name myfile.part1 (shown at 714) to server 704. Then, while first communication session 710 continues uninterruptedly, client 702 starts transferring files 706 one file after another. In this example client 702 has transferred to server 704 during first communication session 710 three files f1, f2, f3 (shown at 716), after which first communication session 710 was interrupted (the interruption being symbolically shown at 71.8). Because files f4 through f10 have not been transferred to server 704 during first communication session 710 client 702 establishes a second communication session 720 with server 704.
In order for client 702 to send the rest of files 706 to server 704 during second communication session 720, client 702 uniquely notates common file name myfile 708 by using a second notation “part2” 722. Client 702, then, sends the second notated file name myfile.part2 (shown at 724) to server 704. Then, while second communication session 720 continues uninterruptedly, client 702 resumes transferring the rest of the files 706 to server 704, one file after another. In this example client 702 has successfully transferred to server 704, during second communication session 720, files f4 and f5 (shown at 726), after which second communication session 720 was interrupted.
In order for client 702 to send the rest of files 706 to server 704 during third communication session 730, client 702 uniquely notates common file name myfile 708 by using a third notation “part3” 732. Client 702, then, sends the notated file name myfile.Part3 (shown at 734) to server 704. Then, while third communication session 730 continues uninterruptedly, client 702 resumes transferring the rest of files 706 to server 704 one file after another. In this example client 702 has managed to transfer to server 704, during third communication session 730, files f6 through f10 (shown at 736), after which communication session 730 may be terminated by client 702 in an orderly fashion if there is nothing else that needs to be communicated from client 702 to server 704 or from server 704 to client 702. As explained above, instead of requesting from server 704 the information that pertains to transferred files, client 702 may hold the information, for example, in a lookup table similar to lookup table 115 of FIG. 1A.
While files 706 are stored in server 704, a user of client 702 can manually request the file myfile from a different client, for example by using a Uniform Resource Locator (“URL”). For example, the user can use the HTTP command “PUT” to send, for example, a file http://www.myserver.com/myfile.xyz to server 704, and then send a link (e.g., “Get_this_file”) to this URL to a second user. Then the second user can use the same URL (i.e., “Get_this_file”) from anywhere to retrieve every file that was send to server 704 by using the common file name myfile (i.e., by using the designated file myfile).
FIG. 8 is a method of using the HTTP protocol to transfer files from a client to a server according to an example embodiment. FIG. 8 will be described in association with FIG. 7. With respect to the HTTP protocol, “GET” is a command requesting a representation of a specified resource; “PUT” is a command for uploading a representation of the specified resource, and “LIST” is a command used to obtain a list of file names based on some filter value. In the context of the present disclosure the LIST command may include a common file name as a filter value (i.e., as an argument) “grep” is a command triggering a searching mechanism for searching for a specific string of characters or a specific text pattern in a file or in a file name. “grep” is a POSIX command, an equivalent of which is found in typical server operating systems. “POSIX”, which stands for “Portable Operating System Interface”, is a collective name of a family of standards specified by the IEEE to define the application programming interface (API). Depending on the degree of compliance with the standards, operating systems can be fully or partly POSIX compatible.
At step 810, client 702 notifies server 704 that it intends to store a file f in server 704. File ‘f’ is a common file name of a file designated for transfer to the server. At step 820, client 702 sends a “LIST” command with file name f as a filter value to server 704 in order to know whether files are stored in server 704 which are name-wise related to the filter value, which, in this example, is the common file name f.
At step 830 client 702 applies a grep command on the output of the LIST command to identify the files currently present in server 704 whose file names match the file f.p pattern, where ‘f’ designates the common file name used to store the files in server 704 and ‘p’ designates a template extension used to denote the various files (e.g., myfile.1, myfile.2, etc.). In other words, by using the grep command client 702 receives the names of all the files in server 704 whose file name includes the common file name f and, in addition, the size of each of these files.
At step 840 client 702 uses the file sizes it receives from server 704 to calculate the total size T of these files. Client 702 uses, at step 850, the value of T as an offset value by which client 702 seeks (e.g., in its memory) the next “chain” of files that are yet to be sent to server 704, or the point in the memory of or associated with client 702 from which client 702 should resume transferring the rest of the file(s).
At step 860 client 702 PUTs the rest of the files in server 704, starting from the offset point T onwards. The PUT process is orderly terminated with the conclusion of the PUT command, but if the PUT command fails in the middle, the PUT process may be restarted. At step 870 it is checked whether the last file was transferred from client 702 to server 704. If the last file to be transferred to server 704 has not been transferred (shown as “N” at step 870), a new communication session is commenced, during which communication session steps 820 through 860 are repeated. After the last file is transferred to server 704 (shown as “Y” at step 870), the PUT process is terminated.
At step 970 it is checked whether there are more notated files f.parti (i>1) that should likewise be retrieved. If there is at least one more such file (i.e., file f.parti) (shown as “N” at step 970), then at step 980 index i is incremented by one, and, at step 950, client 702 GETs the second notated file f.part2, which includes other files that were stored in server 704 by client 702 during a corresponding PUT process. Then, at step 960 client 702 concatenates the second notated file f.part2 to file f, which, after the second concatenation, contains two notated files: f.part1 and f.part2. Assuming there are n notated files (i.e., files f.part1 through f.partn), steps 950 and 960 are repeated until client 702 GETs the last notated file f.partn. As explained above, each notated file f.parti that client 702 receives from server 704 contains one or more files that client 702 transferred to server 704 during the corresponding communication session (i.e., during the corresponding PUT process). By retrieving all the n notated files (i.e., files f.part1, f.parti, . . . , f.partn) client 702 receives from server 704 every file that was transferred to server 704 by using a common file name. As explained above, files may be stored in a server by one client and retrieved from the server by the same client or another client.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS5517892 *Jun 6, 1995May 21, 1996Yamaha CorporationElectonic musical instrument having memory for storing tone waveform and its file nameUS5961600 *Nov 21, 1996Oct 5, 1999Nec CorporationMethod and apparatus for controlling data transferUS6810405 *Oct 4, 2000Oct 26, 2004Starfish Software, Inc.System and methods for synchronizing data between multiple datasetsUS7275140Mar 9, 2006Sep 25, 2007Sandisk Il Ltd.Flash memory management method that is resistant to data corruption by power lossUS7349976 *Oct 4, 2001Mar 25, 2008Realnetworks, Inc.Audio-on-demand communication systemUS7917719Dec 4, 2006Mar 29, 2011Sandisk CorporationPortable module interface with timeout prevention by dummy blocksUS7925781 *May 29, 2007Apr 12, 2011The Hong Kong University Of Science And TechnologyDistributed storage to support user interactivity in peer-to-peer video streamingUS7930585Jan 3, 2008Apr 19, 2011Sandisk Il LtdRecovery of a failed file transfer between a host and a data storage deviceUS7945759Oct 9, 2008May 17, 2011Sandisk CorporationNon-volatile memory and method with phased program failure handlingUS20020093582 *Jan 7, 2002Jul 18, 2002Taizou AokiData communication terminal and cameraUS20020184224 *Jun 13, 2002Dec 5, 2002Hyperspace Communications, Inc.File transfer systemUS20040003103 *Jun 28, 2002Jan 1, 2004Microsoft CorporationMethod and system for managing image filesUS20040049515 *Sep 9, 2003Mar 11, 2004Hyperspace Communications, Inc.Third party authentication of files in digital systemsUS20050131961 *Oct 14, 2004Jun 16, 2005Margolus Norman H.Data repository and method for promoting network storage of dataUS20070299930 *Sep 5, 2006Dec 27, 2007Sony Ericsson Mobile Communications AbContinued transfer or streaming of a data file after loss of a local connectionUS20080134163Nov 26, 2007Jun 5, 2008Sandisk Il Ltd.Incremental transparent file updatingUS20080307109 *Jun 28, 2007Dec 11, 2008Galloway Curtis CFile protocol for transaction based communicationUS20090024749 *Jul 2, 2008Jan 22, 2009Mediacast, Inc.Adaptive file delivery with transparency capability system and method* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS8874777 *Sep 15, 2011Oct 28, 2014Telefonaktiebolaget Lm Ericsson (Publ)Method and system for efficient streaming video dynamic rate adaptationUS8874778 *Sep 15, 2011Oct 28, 2014Telefonkatiebolaget Lm Ericsson (Publ)Live streaming media delivery for mobile audiencesUS20120005365 *Sep 15, 2011Jan 5, 2012Azuki Systems, Inc.Method and system for efficient streaming video dynamic rate adaptationUS20120011267 *Sep 15, 2011Jan 12, 2012Azuki Systems, Inc.Live streaming media delivery for mobile audiences* Cited by examinerClassifications U.S. Classification707/640, 709/231, 707/661, 709/203International ClassificationG06F7/00, G06F17/00Cooperative ClassificationG06F17/30067European ClassificationG06F17/30FLegal EventsDateCodeEventDescriptionNov 25, 2008ASAssignmentOwner name: SANDISK IL LTD.,ISRAELFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:TSVI, YAAKOV BEN;GOLDE, ITTAI;HAHN, JUDAH GAMLIEL;REEL/FRAME:021886/0850Effective date: 20081118Owner name: SANDISK IL LTD., ISRAELFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:TSVI, YAAKOV BEN;GOLDE, ITTAI;HAHN, JUDAH GAMLIEL;REEL/FRAME:021886/0850Effective date: 20081118Jul 8, 2015FPAYFee paymentYear of fee payment: 4RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services