US20120089706A1

US20120089706A1 - Mobile file uploader

Info

Publication number: US20120089706A1
Application number: US13/251,540
Authority: US
Inventors: John J. Collins; Sean J. Langford
Original assignee: Nolij Corp
Current assignee: Lexmark International Technology SARL
Priority date: 2010-10-12
Filing date: 2011-10-03
Publication date: 2012-04-12
Also published as: US20120089676A1; US20120086989A1; US20120089612A1; US20120089901A1; WO2012050947A1; US9143633B2

Abstract

A mobile file uploading system is provided that includes a browser receiving a request to upload one or more selective files and issues a first message. A server receives the first message and determines whether the first message is requesting a download of a first software application, and if so, the server downloads to the user desktop the first software application where the browser executes the first software application. A file upload module is created when the browser completely executes the first software application. The file upload module manages uploading the one or more selective files from the user desktop to the server when a second message is sent by the browser. The file upload module initiates communications with the server and also issues one or more file system calls to a file system on the user desktop to retrieve the one or more selective files for uploading.

Description

PRIORITY INFORMATION

This application claims priority from provisional application Ser. No. 61/392,252 filed Oct. 12, 2010, which is incorporated herein by reference in its entirety.

BACKGROUND OF THE INVENTION

The invention is related to field of document management systems, and in particular to a mobile document retrieval using a browser.
Traditional document management, requiring extensive use of locally attached scanning devices, file servers, databases, and the like, has long been rooted in the technology of yesterday: namely, Windows-based client/server technology. A new era of computing is currently being ushered in; one that revolves around portability, cross platform support, and a new and growing installed base of mobile devices driven by Google, the resurgent Apple Inc. and others. Leveraging this new and increasingly adopted technology environment requires redesigning and, in many cases, reinventing wheels that no longer fit. Unfortunately, the enterprise document management space is largely tied to legacy client/server architecture. While most vendors offer a lightweight web client with limited functionality—to present a veneer of modernity—the bulk of the underlying technology is built on traditional Windows-based client server architecture. As Java technology continues to evolve and consume a greater percentage of development projects worldwide, more and more leading software companies are leveraging its portability and multi-platform capabilities to prepare for the next-generation Internet. The next generation Internet is one based on portability, open standards, and mobile device support. The ability to provide full document management functionality in the absence of traditional client/server technology while supporting any web browser on any platform along with a wide range of mobile devices presents a number of unique challenges.

SUMMARY OF THE INVENTION

According to one aspect of the invention, there is provided a mobile file uploading system. The mobile file uploading system includes a browser that is coupled to the Internet and being executed on a user desktop. The browser receives a user request to upload one or more selective files, the browser issues a first message. A server receives the first message and determines whether the first message is requesting a download of a first software application, if so, the server downloads to the user desktop the first software application where the browser executes the first software application. A file upload module is created when the browser completely executes the first software application. The file upload module manages uploading the one or more selective files from the user desktop to the server when a second message is sent by the browser. The file upload module initiates communications with the server and also issues one or more file system calls to a file system on the user desktop to retrieve the one or more selective files for uploading to the server.
According to another aspect of the invention, there is a method of uploading one or more selective files on a network. The method includes providing a browser that is coupled to the Internet and being executed on a user desktop. The browser receives a user request to upload one or more selective files, the browser issues a first message. Also, the method includes receiving the first message via a server and determining whether the first message is requesting a download of a first software application, if so, the server downloads to the user desktop the first software application where the browser executes the first software application. Furthermore, the method includes creating a file upload module when the browser completely executes the first software application. The file upload module manages uploading the one or more selective files from the user desktop to the server when a second message is sent by the browser. The file upload module initiates communications with the server and also issues one or more file system calls to a file system on the user desktop to retrieve the one or more selective files for uploading to the server.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic diagram illustrating the general framework of the invention;

FIG. 2 is a process flow illustrating the applet delivery used to initiate the file upload applet module used in accordance with the invention;

FIG. 3 is a process flow illustrating the steps performed by the file upload applet module to perform browser-based file uploading;

FIG. 4 is a process flow illustrating the steps performed by file upload applet module for the file uploading transmission process; and

FIG. 5 is a process flow illustrating the process 140 performed by the document capture server 20;

DETAILED DESCRIPTION OF THE INVENTION

The invention involves a mobile retrieval for retrieving documents from a server using a browser. The invention allows for robust access to documents utilizing an applet that executes within a framework of a browser. The execution of the applet allows a user full access to remote document repositories and metadata while allowing a user to use file system calls initiated locally to access documents remotely, while maintaining platform independence.
The invention can be formed using any platform independent based computer language, such as Java. This computer language allows one to develop applet code that can execute when an internet browser makes a request for such a code to be downloaded from a server and be executed on a client-side computer system. The applet code or applet can execute regardless of the specific operating system being utilized by the client side computer system. Given the small size of an applet, it is desirable to use an applet conjunction with mobile platforms such as smartphones or the like having internet browsing capabilities.
FIG. 1 is a schematic diagram illustrating the general framework 2 of the invention. The framework 2 includes a user desktop 4 that is executing on a client computer system having a specific operating system, such as Windows, Linux or the like, and a native file system configuration, such as NTFS. In other embodiments of invention, a plurality of user desktops can be used. A document capture server 20 that communicates with the user desktop 4 and manages the uploading of files between the user desktop 4 and remote repositories 28, 30. The user desktop 4 executes a browser that includes a web user interface 8. When the browser 6 receives a file uploading request from a user the web user interface 8 initiate a call, the web user interface issues a request to deliver an applet to activate the file upload applet module 12. Once the document capture server 20 sends the applet, the browser initiates execution of the applet which results in the activation of the file upload applet module 12 in the browser 6. Afterwards, when a user requests to browse and upload one or more selective documents, the web interface 8 sends a message, such as a JavaScript Native Interface (JSNI), to the file upload applet module 12. The file upload applet module 12 receives the JSNI message 10 and sends a message 18 to the document capture server 20 to prepare for the upload of one or more selective files.
The file upload applet module 12 initiates file system calls to the user's file system using the browser 6 to retrieve the selective one or more documents for uploading, and uploads the one or more selective documents to a file upload handler module 22 executing on the document capture server 20. The file upload handler module 22 can be a servlet application that executes on the document capture server 20. When one or more selective files are uploaded to the document capture server 20, the upload handler module 22 manages the handling of the one or more selective documents. In particular, the upload handler module 22 can temporarily store the one or more selective documents in the document capture server's memory for later use.
The file upload handler module 22 makes assessments on how to best store the one or more selective documents on to one or more document repositories. In this case, the one or more document repositories can be a remote enterprise document repository 28, but in other embodiments of the invention, there can be a plurality of remote enterprise document repositories or even one or more local repositories on the document capture server 20. The file upload handler module 22 issues selective one or more file system calls 26 to the enterprise document repository 30 to store the one or more selective documents. Moreover, the file upload handler module 22 also determines the fashion how metadata stored when the document manage system 2 is in a hibernate state. The file upload handler module 22 send a message 24, to the metadata store 30 to upload metadata information for later retrieval.
The document capture server 20 is a server that is connected to a network 32 as well the user desktop 4. All communication between the user desktop 4 and document capture server 20 is done via the network 32.
The advantage of a Java applet is the ability to provide rich software functionality to web applications that cannot be provided by HTML alone.
FIG. 2 is a process flow of the applet delivery used to initiate the file upload applet module 12. The first step in delivering the upload applet 16 is to seat a web page with embedded logic that initiates the file upload applet download process activating the file upload applet module 12, as shown in step 41. At the start of the download process as shown in step 42, the containing browser 6 receives a session nonce—a random number uniquely identifying the current session—to be used for all subsequent communication with the deploying server. To ensure complete end to end security, the file upload applet 16 must be digitally signed. A digital signature on the applet 16 guarantees applet integrity along with point of origin and provides privileged access at the desktop; a requirement for interfacing with low level hardware devices such as local drives and network file servers. Applet downloading is far from automatic as several requirements need to be checked and verified prior to successful completion of the download process. For starters, the target platform must be checked against a list of supported platforms, as shown in step 43.
The next step is to verify the target browser and adjust the download process accordingly, as shown in step 44. Currently, only the Safari browser running under Mac OSX requires special handling. This special handling requirement results from the parallel loading capability of the Safari browser and the likelihood of premature communication with a partially downloaded applet. To ensure the applet is fully downloaded prior to any communication attempt, a ten (10) second delay is introduced during which time no communication is attempted between browser and applet, shown in step 45. The last important validation step in the applet download process is to verify the existence of the appropriate Java Runtime Environment (JRE), shown in step 46. If the minimum required JRE is present, the download process is allowed to continue to completion. If the appropriate JRE is not present, the end user is prompted to download and install the proper JRE, shown in step 47, and, if successful as shown in step 48, the applet download is allowed to continue to completion, as shown in step 49. A successful applet download confirmation is required prior to checking embedded end user permissions.
Since applets function outside the browser's cookie space, applet communication is effectively outside the established security realm. As this is a less than optimal security structure, it is necessary to extend the federated security realm to include the applet, as shown in step 50. By passing the cookie's session value explicitly from browser to applet during the applet delivery process, the applet is granted the same authentication as the browser 6. Following the extension of the federated security realm to the applet 16, it is necessary to verify that the applet download process completed successfully, as shown in step 51. If any failures are detected at this point, all web-based functionalities are disabled.
Once included in the federated security realm, the applet 16 is free to function subject to established end user rights and permissions. Specifically, an end user's permission to upload documents should be a top level check prior to unlocking the capabilities of the file upload applet, as shown in step 52. If an end user does not have permission to upload files, then an associated file upload button should be disabled, as shown in step 53. Likewise, an associated file upload button should be enabled if file uploading rights exist, as shown in step 54. Once an associated file upload button is either enabled or disabled, the applet initialization process is complete, as shown in step 55.
FIG. 3 is a process flow 75 illustrating the steps performed by the file upload applet module 12 to perform browser-based file uploading. The browser-based file uploading process cannot begin until the file uploading applet 16 is successfully downloaded and initialized. As such, the applet delivery process, as discussed for FIG. 2, must be completed, as shown in step 76. The file uploading process is initiated by end user interaction; typically in the form of an end user expanding the embedded local file system browsing window or un-hiding the local file system browsing window by selecting a menu or similar toolbar icon, as shown in step 77. The embedded local file system browsing window is only available following successful download of the file uploading applet module 12. Once the user expands or activates the local file system browsing window, the web user interface 8 or browser 6 issues a JavaScript Native Interface (JSNI) call to the file uploading applet module 12, as shown in step 78. The JSNI protocol allows the browser to invoke embedded object methods and properties such as those found in a Java applet. This, in turn, extends the functional capabilities of the browser 6 by enabling advanced functionality not generally available via standard HTML web pages.
The next step in the file uploading process is for the file upload applet module 12 to detect the local operating system and map the local root structure, as shown in step 79. The local root structure is returned to the user interface (UI) for presentation inside the local file system browsing window as shown in step 80. To simplify the information delivery to the end user, the UI displays the local system root structure as a series of root-level browsable folders using a familiar Windows folder structure paradigm, as shown in step 81. Once any of the displayed root folders are selected and expanded, that folder's contents are retrieved and displayed, as shown in step 82. Along with system file names, the file upload applet module 12 also retrieves a number of file-level metadata attributes for display including file size, path, file type, creation date and more, as shown in step 83. Armed with a full accounting of operating system level file details and attributes, an end user is well positioned to select one or more files for upload. The file system browsing window fully supports both single and multiple file selections for added simplicity.
Once the appropriate target file or files have been located and selected, as shown in step 84, the files can be dragged and dropped onto one of the non-local folders, as shown in step 85, retrieved via an embedded database search and index interface. In doing so, the end user is essentially commanding the file uploading applet to index the selected files from the local file system to the selected remote folder.
To complete the browser-based file uploading process 75, the web browser 6 or web user interface 8 issues another JSNI call to the file uploading applet module 12, as shown step 86, instructing it to begin archiving and uploading the selected files to the document capture server 20, as shown in step 87. The archiving process leverages the ZIP format (a standard data compression and archive format) and serves to aggregate all selected files into a single file bundle for cleanest transmission to the server.
The browser-based uploading process 75 as described in FIG. 3 supplies and works in parallel with the file uploading transmission process used by the invention. FIG. 4 is a process flow 110 illustrating the steps performed by file upload applet module 12 for the file uploading transmission process.
As files are selected and packaged for uploading from one or more desktops, it is necessary to securely move those images to one or more remote defined storage locations. To accomplish this, each file upload applet module 12 has the ability to initiate its own upload thread with the document capture server 20 to enable parallel uploading between all operating desktops. Data security is accomplished through the application of Secure Socket Layer (SSL) encryption on all uploaded files and associated metadata.
The file uploading transmission process 110 is initiated by the file uploading applet module 12 once one or more files have been selected for upload, so the file uploading process as described in FIG. 3 must commence, as shown in step 111. Once the list of selected files is constructed for a particular user desktop, the file uploading applet module 12 initiates an upload thread with the document capture server 20, as shown in step 112, and then begins packaging the selected files into a single zip archive bundle, as shown in step 113.
The file upload applet module 12 constantly monitors the archive build process to determine if the archive build has been completed, as shown in step 114, and if not, continues to monitor the process until the build is complete. Once a completed archive is available for transmission to the server 20, the archive is passed off to a dedicated upload thread, as shown in step 115. The newly spawned thread focuses exclusively on managing the transmission of the archive. To undertake the actual image transmission, the upload thread begins by opening a connection with the enterprise document repository 28, as shown in step 116. Specifically, the upload thread opens a connection using the same host, port, and protocol information delivered and stored with the file uploading applet module 12. To successfully connect to the document capture server 20, the upload thread must supply the same session nonce received during the file uploading applet download process. Once the correct nonce is provided to the server 20, the upload thread is able to successfully authenticate, as shown in step 117, and begin passing data.
The first data passed to the server is the archive-related indexing metadata. Prior to delivering the actual archive, the upload thread passes key metadata to the server including the target folder ID, type of files in the archive, number of files in the archive, user ID, and more, as shown in step 118. After the archive metadata is passed to the server, the upload thread begins transmitting the actual archive ZIP file in byte stream format using the HTTP put construct, as shown in step 119. To accomplish the byte stream transmission, the content type is set to binary octet-stream and the destination URL is constructed from the same origin as that used to deploy the applet. This allows the transmission process to comply with the Java ‘same origin policy’ constraint.
Since archives vary in size, the amount of bytes to be transmitted is likewise variable. To determine completion of the upload process, the byte-stream is closely monitored. At each monitoring pass, if more bytes are available, as shown in step 120, the byte-stream transmission remains in monitored mode and data continues to flow to the server via HTTP put. If no more bytes are available, the upload thread is freed up and terminated.
Once the archive byte-stream is fully delivered, the upload transmission process is terminated and details are passed to the browser, as shown in step 121. As a last step, the end user is presented with a confirmation dialog displaying the details of the file uploading transmission process, as shown in step 122.
Similar to the file uploading process, error checking is robust and embedded throughout the transmission process. If any errors are encountered, the transmission processes is halted, the hidden browser window is closed, the main browser window is returned to the foreground, and an appropriate error message is delivered to the end user describing the error.
The document capture server 20 provides a gateway to, and acts as a gatekeeper for, the backend document repository 30. The document repository 30 is the primary storage location for all scanned images and electronic documents captured via the file uploading processes 75, 110.
FIG. 5 is a process flow illustrating the process 140 performed by the document capture server 20. The document capture server lifecycle begins with installation of the designated Java servlet container on the targeted web server. Once started and configured, the document capture server 20 initiates a dedicated listener process or file upload handler 22. The file uploading document capture server process lifecycle is triggered by an inbound request 18, so the file uploading transmission process 110 as described in FIG. 4 must run, as shown in step 141.
The file upload handler module 22 constantly monitors HTTPS port 443 at a designated Uniform Resource Locator (URL) address, as shown in step 142. This URL address is specified during the servlet container (e.g. Apache Tomcat) installation and configuration process and is the location at which all captured output from the file uploading processes 75, 110 can be sent.
Files can be uploaded individually or in groups and are transmitted in a single zip archive. Each uploaded file package ultimately generates a new service request and associated processing thread on the document capture server. The document capture server continuously monitors HTTPS port 443 at the designated URL address for any inbound service request, as shown in step 143. If a valid inbound request is received, it is immediately checked for the presence of a valid nonce, as shown in step 144. All inbound requests must present a valid security nonce to be accepted into the security realm. If a valid nonce is not received, then the request is denied and an HTTP error code of 401 (unauthorized) is returned to the originating source. If a valid nonce is received, then the server 20 attempts to validate whether the submitting end user has proper permission to upload documents to the server by verifying internally established rights. If the submitting end user does not have permission to upload documents and associated metadata, then the request is denied and an HTTP error code of 401 (unauthorized) is returned to the end user. If, however, the inbound request provides a valid nonce and has permission to upload as shown in step 145, then the document capture server 20 spawns a dedicated processing thread and begins processing the service request.
The first task in processing the service request is to begin reading the inbound octet-stream. All files transmitted via the file uploading transmission process are packaged into a single zip archive file. The file uploading handler module 22 begins reading and unpacking the archive as the byte stream arrives, as shown in step 146. As the byte stream is read, the server continuously checks for a completed file, as shown in step 147, to be written to the enterprise document repository 28. If a completed file is not ready—meaning more bytes are being transmitted—then the file uploading handler module 22 continues to read and unpack the inbound octet stream until a completed file is available.
Once a completed file is retrieved from the inbound octet stream, the dedicated processing thread reads and stores the document metadata, as shown in step 148, creates the appropriate document audit trail entries in the target metadata database 30, as shown in step 149, and then creates and stores a permanent file from the inbound octet-stream, as shown in step 150. Once the permanent file is created, the processing thread checks to see if there are more files in the zip archive, as shown in step 151. If more files are detected, the thread process continues reading and unpacking the inbound octet stream, as show in step 146,—repeating the process of storing metadata, creating the audit trail, and creating the permanent file—until no more files are available. As soon as the last file is processed, the service request is fulfilled and the dedicated processing thread is terminated.
Although the present invention has been shown and described with respect to several preferred embodiments thereof, various changes, omissions and additions to the form and detail thereof, may be made therein, without departing from the spirit and scope of the invention.

Claims

1. A mobile file uploading system comprising:

a browser that is coupled to the Internet and executed on a user desktop, the browser receives a user request to upload one or more selective files and issues a first message;

a server that receives the first message and determines whether the first message is requesting a download of a first software application, and if so, the server downloads to the user desktop the first software application where the browser executes the first software application; and

a file upload module that is created when the browser completely executes the first software application, the file upload module manages uploading the one or more selective files from the user desktop to the server when a second message is sent by the browser, the file upload module initiates communications with the server and also issues one or more file system calls to a file system on the user desktop to retrieve the one or more selective files for uploading to the server.

2. The mobile file uploading system of claim 1, wherein the first application module comprises a Java applet.

3. The mobile file uploading system of claim 1, wherein the server comprises a file upload handler module that manages the one or more selective files for storage.

4. The mobile file uploading system of claim 1, wherein the file upload handler module issues file system calls to a document repository to store the one or more selective files.

5. The mobile file uploading system of claim 1, wherein the file upload handler module stores metadata associated with the one or more selective files.

6. The mobile file uploading system of claim 1, wherein the second message comprises JavaScript Native Interface.

7. The mobile file uploading system of claim 2, wherein the first software application is digitally signed to guarantee applet integrity.

8. The mobile file uploading system of claim 2, wherein the browser is verified so as to determine the fashion to deliver the first software application.

9. The mobile file uploading system of claim 1, wherein the file uploading module detects the local operating system of the user desktop.

10. The mobile file uploading system of claim 1, wherein the browser comprises a browsing window to view files on the user desktop.

11. A method of uploading one or more selective files on a network comprising:

providing a browser that is coupled to the Internet and executed on a user desktop, the browser receives a user request to upload one or more selective files and issues a first message;

receiving the first message via a server and determining whether the first message is requesting a download of a first software application, and if so, the server downloads to the user desktop the first software application where the browser executes the first software application; and

creating a file upload module when the browser completely executes the first software application, the file upload module manages uploading the one or more selective files from the user desktop to the server when a second message is sent by the browser, the file upload module initiates communications with the server and also issues one or more file system calls to a file system on the user desktop to retrieve the one or more selective files for uploading to the server.

12. The method of claim 11, wherein the first application module comprises a Java applet.

13. The method of claim 11, wherein the server comprises a file upload handler module that manages the one or more selective files for storage.

14. The method of claim 11, wherein the file upload handler module issues file system calls to a document repository to store the one or more selective files.

15. The method of claim 11, wherein the file upload handler module stores metadata associated with the one or more selective files.

16. The method of claim 11, wherein the second message comprises JavaScript Native Interface.

17. The method of claim 12, wherein the first software application is digitally signed to guarantee applet integrity.

18. The method of claim 12, wherein the browser is verified so as to determine the fashion to deliver the first software application

19. The method of claim 11, wherein the file uploading module detects the local operating system of the user desktop.

20. The method of claim 11, wherein the browser comprises a browsing window to view files on the user desktop.