Patent Application
20060179155
Over the past decades, the Internet community has been growing at a remarkable rate. Established protocols are used to transmit large amounts of data over the Internet. Among the established protocols, File Transfer Protocol (FTP) is a prevailing method to transfer large data file information between geographically separated computers, where the size of data file is typically larger than 100 Mb. Even though a modern computer may have a built-in modem, LAN connection or wireless interface to connect to the Internet, directly connecting the computer to the Internet does not mean the computer can perform an FTP file transfer. The computer must have FTP software (client application) in order to perform an FTP transfer.
Off-the-shelf client applications, such as Microsoft Internet Explorer™, CuteFTP™, Ipswitch WS-FTP™, HyperSend, provide a user interface that FTP transfer files from one computer to anther. These applications are saved in the users' “Program Files” directories. Typically, such applications may use one of the following methods: 1) Dragging files from one window to anther window on the same computer (e.g., Microsoft Internet Explorer™). 2) Entering a remote FTP Server path, the path to save the file on your computer, user logon, password and download schedule in multiple window dialog boxes, and then select FTP download. The client software may retain this information when the application is closed and continue to FTP transfer on schedule when the client program is exited. FTP download/upload history may be provided by the client application while it is open. 3) Writing software scripts to specify FTP parameters that conform to the client application software to provide similar results as in the method 2). 4) A “Secure FTP Server” may be provided that works in conjunction with its “client” application to “enhance” FTP file transfer security.
Such conventional off-the-shelf FTP client applications have disadvantages. Every user has to purchase a licensed FTP application software that can cost $40+ per copy and install it on their computer through an operating system, such as WINDOWS XP™ or the like. Also, as the conventional software is installed on each user's personal computer, it is not typically integrated with a database and does not provide multi-user access. In addition, “Secure FTP Server” licenses can be as much as $400 per server. Thus, a typical organization needs to spend a considerable amount of expense to provide licensed FTP transfer software for its employees. “Client” users may FTP a large quantity of data files to their company hard disks and/or their PCs. Sometimes, multiple copies of identical and/or different file revisions may be scattered on many company disk drives. Typically, no one except the user who downloaded the files knows where the downloaded files are stored. If there is no organization to the downloaded files on computer disks, such duplicated storage of files can translate into a large amount of expense to purchase and operate additional disk space. An old revision file might be accessed causing data reliability issues. Thus, there is a strong need for a system to eliminate the need to purchase any FTP “client” application software and to manage the downloaded files so that the disk space can be used in an optimized manner with the latest files.
Another disadvantage of conventional applications is that each user has to go through a learning curve. Users, who are not familiar with the FTP client application, would not know what to do, and due to complex operations, it may be inefficient. Every user who FTP transfers files may be required to become an FTP application download administration expert and write a script that is specific to each computer environment. Writing scripts for FTP transfer may be essentially “programming” the FTP “client” application and require a considerable depth of knowledge in FTP as well as the operating system. In addition, even successful script programmers (or system administrators) are sometimes required to run Windows “Task Schedulers” repeatedly to run different scripts at designated times.
Yet another disadvantage of the conventional software is that filling in multiple dialog boxes open for user input may result in errors if there is no feedback mechanism to check the user input. Also, in an organization, different users may schedule to download the same file multiple times if the software cannot provide a complete view of all files scheduled for FTP download, history of the FTP downloads and schedules for updating files. Thus, there is a need for a system that allows client users to FTP transfer files, view file transfer history, schedules and upload files with a limited number of mouse clicks instead of writing FTP scripts, wherein the system preferably uses a standard Internet browser as a user interface.
Systems, methods and computer readable media are provided that allow one or more users to download files over the Internet to a predetermined master directory without purchasing FTP client application software and writing FTP scripts, wherein the users are allowed to view file transfer history, schedules and download/upload files with a limited number of mouse clicks. The users enter their ID information, such as their names and projects, into the system, referred to as the “Large File Transfer System” (LFTS) to keep track of who is requesting a download and what they are downloading, select remote FTP sites, and designate a subdirectory under the master directory to save the downloaded file. One copy of LFTS software, the database (SQL, Oracle, DBII, Microsoft Access or others), file directory structure and archive directory is installed on a Server and thousands of clients can access its capabilities via the Web. The LFTS system administrator enters parameters in the LFTS database using a web page to immediately perform FTP transfers, delete files from the database and directories, edit user inputs and change download schedules. The LFTS system communicates with a user via web pages displayed on the user's client system. Each user can upload any files downloaded into the master directory and visible in the database to his personal computer.
In one embodiment of the present invention, a server system for managing transfer of files over a public network includes: a file depository for centrally storing a plurality of files downloaded over the network; and software configured to control downloading the plurality of files via a web-based user interface and centrally organizing storage of the plurality of files on the file depository.
In another embodiment of the present invention, methods and computer readable media are provided for downloading data. In response to receiving a download request for a file, the download request is added to a download queue. Then, the file to be downloaded is compared with one or more files contained in a file depository to determine if the file already exists in the file depository. If the file is not already in the file depository, the file is downloaded into the file depository.
A user locates a remote FTP server that hosts a file to be downloaded using their web-based interface (browser). Then, the user selects the filename and submits a download request to a download queue.
In still another embodiment of the present invention, methods and computer readable media are provided for managing a database and a file depository that stores a plurality of files downloaded. A server provides information regarding the plurality of files to at least one client and receives a download request for a specific file from the at least one client if the specific file does not exist in the server. Next, the download request is added to a download queue, wherein the download queue is executed to download the specific file to the file depository. Upon competition of the file transfer, the file depository and the database containing the information are updated with file transfer details.
In yet another embodiment of the present invention, methods and computer readable media are provided for uploading files to a remote FTP server. A user locates a remote FTP server configured to receive a file to be uploaded using a web-based user interface and submit an upload request for the file to an upload queue. Subsequently, an LFTS program code executes the upload queue to upload the file into the remote FTP server. Upon completion of the file upload, the LFTS program code updates the FTP history data.
These and other advantages and features of, the invention will become apparent to those persons skilled in the art upon reading the details of the invention as more fully described below.
Before the present systems and methods are described, it is to be understood that this invention is not limited to particular data, software, hardware or method steps described, as such may, of course, vary. It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting, since the scope of the present invention will be limited only by the appended claims.
Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. Although any methods and materials similar or equivalent to those described herein can be used in the practice or testing of the present invention, the preferred methods and materials are now described. All publications mentioned herein are incorporated herein by reference to disclose and describe the methods and/or materials in connection with which the publications are cited.
It must be noted that as used herein and in the appended claims, the singular forms “a”, “an”, and “the” include plural referents unless the context clearly dictates otherwise. Thus, for example, reference to “a user” includes a plurality of such users and equivalents thereof known to those skilled in the art, and so forth.
Definitions
When one item is indicated as being “remote” from another, this is referenced that the two items are in different locations, i.e., at least in different rooms, at least in different buildings, and may be at least one mile, ten miles, or at least one hundred miles apart.
“Communicating” information references transmitting the data representing that information as signals (e.g., electrical, optical, radio, etc,) over a suitable communication channel (for example, a private or public network).
A “processor” references any hardware and/or software combination which will perform the functions required of it. For example, any processor herein may be a programmable digital microprocessor such as available in the form of a mainframe, server, or personal computer. Where the processor is programmable, suitable programming can be communicated from a remote location to the processor, or previously saved in a computer program product. For example, a magnetic or optical disk may carry the programming, and can be read by a suitable disk reader communicating with each processor at its corresponding station.
Reference to a singular item, includes the possibility that there are plural of the same items present.
“May” means optionally.
Methods recited herein may be carried out in any order of the recited events which is logically possible, as well as the recited order of events.
All patents and other references cited in this application are incorporated into this application by reference except insofar as they may conflict with those of the present application (in which case the present application prevails).
Being computer-related, it can be appreciated that the components disclosed herein may be implemented in hardware, software, or a combination of hardware and software (e.g., firmware). Software components may be in the form of computer-readable program code stored in a computer-readable storage medium, such as memory, mass storage device, or removable storage device. For example, a computer-readable storage medium may comprise computer-readable code for performing the function of a particular component. Likewise, computer memory may be configured to include one or more components, which may then be executed by a processor. Components may be implemented separately in multiple modules or together in a single module.
Referring now to
Referring now to
In system environment 200, only three companies are shown for clarity and ease of illustration. However, it should be apparent to those of ordinary skill in the art that the invention can be practiced with any number of companies. The network 114 may include the Internet or other suitable connection systems for exchanging data 208. The company A 202 can be different from company B 204, or a branch of company B 204.
Server 210 may be connected to and communicate with one or more clients 212a-n using user interface 129, wherein each client 212 (e.g., 212a, . . . , 212n) may be a server or a PC. In one embodiment, user interface 129 may include one or more web pages 218 displayed on web browsers 214a-n, such as Internet Explorer™, of clients 216a-n. Further details of web pages 218 may be given in connection with
The server 210 may receive and store data 208 in file depository 123. In existing systems, a user of one client, say 212a, may receive and store data 208 anywhere in server 210 or directory 216a. Typically, a user of another client, say 212b, may attempt to download the same data as downloaded by client 212a without knowing that server 210 already has the data, even though the user of client 212b also has a full access to the data. Such redundant file transfer is eliminated by LFTS checking all directories and subdirectories for file existence. Hereinafter, the terms directory(ies)/subdirectory(ies) and file depository may be interchangeably used. The first client to download the file becomes the winner and other clients receive a “File already exists” error. In contrast, in one embodiment of the present invention, the users of clients 212a-n may download data 208 into file depository 123 in the first step. In this step, LFTS program 128 may control the flow of file transfer through the server 210 and manage LFTS database 118 to optimize the use of the file depository 123. Also, LFTS program 128 may update FTP history 120 and download schedule 124. When server 210 receives and stores data into file depository 123, the users of clients 212a-n may share the data and/or upload a copy into their own file directories 216a-n in the next step.
As mentioned, LFTS program 128 may communicate with clients 212a-n using LFTS web pages 218 displayed on browsers 214a-n and manage LFTS database 118 based on the communication.
FTP Remote Server Information box 506 may include a display of an IP address of a remote server, a display of the current directory in the remote server, “Refresh” button 506a for refreshing the contents in FTP Remote Server Information box 506, and “Logout” button 506b to exit Create FTP Download Schedule page 500. FTP Remote Server Name 504 may be a user input field and automatically display the information of FTP Server Address/Directory 412 by default when Create FTP Download Schedule page 500 is opened.
FTP Remote Server Directory/File section 508 may display directories and files of the remote server in a hierarchical structure. Directory list 508a may display a list of directories in the remote server, while File list 508b may display a list of files in the directory selected from Directory list 508a. FTP Remote Server Path section 510 may include FTP Remote Server Path field 510a and FTP Remote File Name field 510b. The contents displayed in the fields 510a and 510b may be the same as the directory and file name selected in Directory list 508a and File list 508b, from which a user may select a directory and a file name by clicking a mouse button.
LFTS Server Path section 512 may include two input fields 512a and 512b. These two input fields 512a-b may specify the directory path where the downloaded file is to be located in file depository 123. LFTS File Information section 514 may include three or more input fields; File Owner field 514a, Project Name field 514b, and File Description field 514d. Optionally, other input fields, such as Unique names 514c, may be present on this web page. Upon completion of download, the information in LFTS Server Path section 512 may appear in File Information field 306 in
The information input to Create FTP Download Schedule page 500 may become parameters of a download request. Subsequently, the download request may be added to a download queue stored in download schedule data 124 (shown in
Optionally, the user may open a View Download Schedule page 800 to check if a download request for the file has been already submitted to a download queue in the LFTS database at step 906. If the answer to step 906 is positive, the user may wait until the file is downloaded and stored in file depository 123. As an optional step 912, the user may modify the download request in the download queue. If the answer to step 906 is negative, the user may proceed to step 904 to submit a download request. As an optional step 914, the administrator of the LFTS database may manually download the file in the download queue. Upon completion of the file download, the user may upload the file into directory 216 of client 212.
As mentioned, an administrator of the server may set the server task scheduler time of day to execute the download queue. At step 1012, the task scheduler may perform FTP transfers as required by the file parameters of the download request. To execute the download request, an LFTS program may compare a current date with a download date specified in the download request and, if the current date is earlier than the download date, the task scheduler may download the file specified in the download request. Then, the process proceeds to step 1014.
At step 1014, LFTS program determines if the file depository has a previous version of the file by comparing the file dates of the previous and current versions of the file. If the answer to step 1014 is positive, the previous version may be replaced with the current version at step 1016. Subsequently, the previous version may be sent to an archive at step 1018.
It is noted that the present invention provides systems and methods to download files using FTP. However, it should be apparent to those of ordinary skill that other types of File Transfer Protocol, such as Hypertext Transfer Protocol (HTTP), Hypertext Transfer Protocol Secure (HTTPS), Secure Socket Layer (SSL), Secure Shell (SSH), and Secure FTP, may be used without deviating from the present teachings.
FTP Remote Server section 1102 may include FTP Remote Server Name field 1102a and FTP Remote Server Path field 1102b that may be selected by a user to designate the location where the uploaded file will be transferred. Local File to Upload section 1104 may include Local File to Upload field 1104a that allows the user to select the full path of the local users' file to upload. LFTS File Information section 1106 may include three or more input fields; File Owner field 1106a, Project Name field 1106b, and File Description field 1106c. Remote File Upload Schedule section 1108 may include four or more input fields: Start Date field 1108a; Schedule Interval Unit list 1108b; Schedule Interval Type list 1108c; and End Date field 1108d.
The information input to Create FTP Upload Schedule page 1100 may become parameters of an upload request. The upload request submitted via Create FTP Upload Schedule page 1100 may be added to an upload queue (or, equivalently, upload schedule) stored in upload schedule data 125 (shown in
Optionally, the user may open a View Upload Schedule page 1300 to check if an upload request for the file has been already submitted to an upload queue in the LFTS database at step 1406. If the answer to step 1406 is positive, the user may wait until the file is uploaded. As an optional step 1410, the user may modify the upload request in the upload queue. If the answer to step 1406 is negative, the user may proceed to step 1404 to submit an upload request. As an optional step 1414, the administrator of the LFTS database may manually upload the file in the upload queue.
While the present invention has been described with reference to the specific embodiments thereof, it should be understood, of course, that the foregoing relates to preferred embodiments of the invention and that modifications may be made without departing from the spirit and scope of the invention as set forth in the following claims.
