1. Field of the Invention
The present invention is a system for running and authoring internet and web applications with standardized technologies such as HTML, CSS, and a scripting language such as JavaScript offline and when a server is not available. The present invention provides details on how to deploy and manage such applications and how to manage interfaces to access local native services of the device for which there are no web language interfaces as web languages such as HTML, JavaScript, and the like run in a browser sandbox and only have programmatic interfaces to manipulate data on the server from which they are hosted.
2. Prior Art
U.S. Pat. No. 6,996,537—“System and method for providing subscribed applications on wireless devices over a wireless network”—Minear, et. al. [Qualcomm]—Describes the management of subscriptions on wireless devices but does not provide for a means for web technology based applications to run locally and does not mention how such applications which are composed of multipart file bundles can be deployed as an atomic unit and signed as an atomic unit. This patent also does not delineate how to create a connection between a local engine which contains the application and a browser for click-through connections to the world wide web in real time.
U.S. Pat. No. 6,832,253—“Viewing web pages on small screen devices using a keypad for navigation, Itavaara et. al.” [Nokia]—Describes segmenting a screen in to small units each which can be divided but does not describe how an entire web application can get stored and managed on a device. It also does not provide for an idea of page “flipping” in which local applications can serve pages quickly.
U.S. Pat. No. 6,779,042—“System, method, and computer program product for enabling on-device servers, offline forms, and dynamic ad tracking on mobile devices”, Kloba et. al. [iAnywhere]—Shows a method for caching web based content and reserving on a mobile device, even in an offline state. It also describes the reformatting or preparation of the look and feel of the content (optimization) so that it is presented in a more optimal manner. However this art does not describe how to package such information such that an entire application is synchronized so that it runs locally—rather this art describes a complex method of data caching. Also the present information separates content, including user data, as completely separate from the application code which renders the data and these items, in the present invention are treated so that the user's content and personal data can be updated without the need for updating the application itself. This allows the present invention to save bandwidth, increase responsiveness, and through an applied security model, allows the present invention to mix content from multiple servers from an application running on the local device whereas Kloba et. al does not.
U.S. Pat. No. 6,553,412—“System, method, and computer program product for web content aggregation and development, and web content delivery to clients”, Kloba et. al. [AvantGo]—This prior art describes a system of channels in which various items can be deposited and cached. However it does not delineate how to store entire bundles as single atomic units nor does it provide for a method such that web based programming methodologies such as HTML and JavaScript can be used to access native services of the device which are outside of this system. In the present invention collections of assets are made in to atomic bundles of files which can be signed and in addition the present invention allows for the use of native services, such as local operating system calls or local peripherals (such as device mounted cameras) to be used.
U.S. Pat. No. 6,421,717—“System, method, and computer program product for customizing channels, content, and data for mobile devices”, Kloba et. al. [AvantGo]—This art describes a method of serving content on regular intervals such as refreshing news stories via RSS feeds as is done with other programs on both desktop computers and mobile devices today. While the dynamic refreshing of content via polling methods is useful it does not embody client side functionality in a way in which locally running executables can access multiple sites, maintain security, or partially cache local icons and combine them with the newly acquired information to create a low bandwidth high user experience effect. The present invention not only allows for local programs written with web languages to get content but also runs a proxy, as known to those skilled in the art, to allow for secure mash-ups of information to only those apps which are securely signed or authorized.
Apple Computer makes a widget like programming environment colloquially known as Dashboard. This environment serves up mini applications called widgets using web technologies such as HTML, JavaScript, and CSS and is based on the webkit technology base. However it does not run as a server on client methodology as the present invention but instead runs effectively as a modified internet browser framework with extensions to access the host operating system through a modified HTML DOM API as known to those skilled in the art. This allows for high performance rendering in a graphical sense but does not allow for the provisioning of application bundles, subscriptions to applications, or extensible services framework in which other clients can surf to an application or have it served over a network as with the present invention. Also there is no way for plugin native services to extend the Dashboard framework, as with the present invention, except by hand modifying the source code to the underlying HTML DOM or javaScript functions. In addition the use of special functions for high performance graphics and rendering precludes its use on mobile devices such as with the present invention. Finally, the Dashboard environment does not provide automatic means for synchronizing and backing up of user data.
Another example of a small mini application is the commercial environment known as Konfabulator which is now part of the Yahoo! widget engine. This environment is based on creating small mini-applications which use a proprietary language and runtime environment to create a similar effect as what can be created using web standards. This environment allows the creation of visually mini-applications however its use of a proprietary authoring technique limits its portability across desktop operating system. Many individual widget applications must be adapted to the host operating system negating the effectiveness of the paradigm. In addition the heavy weight nature of the rendering layer which is part of the environment precludes its use on mobile devices.
Another method of provision mobile devices is via the use of the Java 2 Micro Edition (J2ME also called JME) programming environment. This environment takes programs written in the Sun Microsystems Java programming language and runs them on special virtual machine which has been created for limited CPU and limited memory environments. Since all Java programs run in a special sandbox (the Java Virtual Machine heap) access to native functionality is only available through special application programming interfaces known as JSRs (Java Specification Requests) which are agreed upon by the larger Java development community. Java programs running on the JVM do not have innate web browser like communications or rendering capabilities—the use of the network is restricted by the JVM and the only way to render web content such as HTML is through hand coding a software based renderer in the Java language itself. This restriction can somewhat be overcome by using a link to launch the on device web browser. However this causes the device to undergo a large software context switch which is not permitted under many implementations of J2ME. For those where this context switch is permitted, a large delay is induced while the browser is launched and then connectivity is established. This is greatly exacerbated by the fact if connectivity to the requested resource is not available to the browser the user is often subjected to a lengthy click—launch browser—wait for connection—delay cycle in which the end result is essentially a blank screen. Even on devices with relatively high end CPUs the best case cycle is many tens of seconds which causes users to be frustrated and update of Java to browser based click through services to be slow. The present invention leverages the local web browser as a rendering engine and hence has no such delay. In addition the present invention allows programs to run unmodified on desktop computer environments whereas the Java Mobile Environment is not supported on desktop computers—instead a different rendering architecture called the Java Standard edition classes must be used greatly limiting application portability across environments.
To overcome many of the performance deficits of the J2ME environment Qualcomm Corporation introduced a different programming paradigm to the mobile marketplace with emphasis on speed and deployment. This environment is branded BREW which stands for Binary Runtime Environment for Wireless. The BREW system is a C based programming environment which runs code directly on the microprocessor rather than on a Virtual Machine such as in Java. This results in higher performance. Also the BREW environment integrates the billing and deployment logic necessary for a wireless carrier to push an application to a mobile device and to arrange either a subscription based or one time fee based payment for the use of the application. However BREW does not offer automatic rendering and handling of web content and hence, like J2ME, the use of web content requires the either the launching of the web browser or the handcrafting, by the developer, of the necessary code to render web content such as HTML inside the BREW environment. Like Java the launching of the device native browser can create long delays as the user waits for the browser and associated connectivity to launch and then additional delays as the browser attempts to make a data connection over the wireless air interface. Also, unlike the present invention. BREW does not provide an automated method for user data to be provisioned over a network and also does not provide for compatibility with desktop computer environments.
The present invention has several advantages over existing prior art. Several of these are performance oriented in nature or reflect decreased development time for programmers whereas the second set of advantages represent new and compelling functionality which seamlessly tie mobile device and desktop experiences in a more compelling manner than previously available. In addition the present invention allows the use of web programming paradigms, such as JavaScript, HTML, CSS, and XML to write standalone applications on a mobile device or desktop computer, greatly speeding up the programming time required to create a visual content based application.
The present invention also allows the use of server side programming techniques to be combined with these client side web technologies through the use of SOAP services, XML RPC services and the like to access a database. The present invention also leverage the ability to run server side code such as PHP, Python, PERL or CGI programming environments locally, on the client computer, as part of the deployed application environment. This allows the local use of sessions and other programming paradigms all running on a client which lessons the computational load on the server and enables web based applications to run even when a main server on the internet or intranet is not available.
Another set of key advantages of the present invention is the conservation of bandwidth which is especially important for mobile device deployments. This is accomplished since many of the graphical assets of an application, such as the background images, often take more than ninety percent of the memory of application storage footprint. However the present invention allows application resources, such as background images and icons, to be stored on the client rather than being loaded over an internet connection each time the application is used. For applications running on wireless devices, this can also translate in to tremendously reduced application latency as since the resources of the application are stored locally there is no delay fetching the data over the air. For battery powered devices this has the added advantage of greatly reducing the amount of power consumption required since the radio need not be used thereby increasing battery life.
The present invention also allows the use of local services which normally would be accessed via a compiled language such as C or C++. Web languages, such as JavaScript or ECMAScript run in a sandbox and have no ability to access local resources directly. This is done for security purposes. However with the present invention local services can be brokered through SOAP, XML remote procedure calls or other means to access the local file system, database, or even device specific proprietary interfaces such as a camera in the case of a wireless phone. Since the present invention emulates an entire server software stack it enables usual web based security models and access restrictions to be enforced as is known in the art.
The present invention also allows different web applications to simultaneously have different security levels. This is further enhanced by the ability to sign web apps via the manifest mechanism noted in the description of the invention section which can then be verified by a 3rd party authentication service.
The present invention allows for truly portable code in a write once run anywhere fashion as the graphical layout and programming support are available on both mobile devices and all modern desktop computer operating systems. This is not true for Java where the graphical framework is different for server, desktop, and mobile environments. This is also not true BREW environments as this technology has no desktop equivalent. While programmer's tools such as simulators for development may run some aspects of BREW or mobile Java applications on desktops they are not available for end user's to run BREW or J2ME applications on any desktop computer.
(1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)
The present invention builds upon the basic http client server model of HTTP connections to leverage a new user experience and web application programmer model by consolidating traditional client server mode programming into a new client based programming model with extra enhancements for offline application access.
The next set of figures depicts the present invention in logical form. The present invention takes several components of the web server and compacts and expands upon them so that the entire web server and support assets can run locally on the same computer as the browser is running. In fact some implementations of the present invention are small enough that they can be run on desktop personal computers or mid price range mobile phones. Advantages of this server-on-client approach are many, but include some of the following: multiple web apps running on the same machine, low latency as content is local, access to local device services such as camera media stores or phonebooks, and ease of authoring as now the same paradigm used to author large web sites can be used to author portable client side applications. The present invention further expands on this by adding an optional synchronization engine which can sync either application assets or user data stored in a local database back to a parent server on the internet.
Since web applications are written as several files spread over a directory structure it is difficult to deploy them on to a client computer or to even move them from one server to another.
In normal operation the present invention operates several portions of an http server stack. These can be seen by the interaction of the browser through path 510 to box 560 which is a network proxy software stack which redirects incoming network traffic either to the outside world via interface 555 or towards the http server 565 via path 545. For example if a browser based application authored in XHTML and running a local scripting language (in the browser) such as JavaScript or VBScript requests a new resource, whether it is a new page or an XMLHttpRequest type data call, this request will be brokered from the browser through the proxy to the http server for handling. If the request is for a web page or similar addressable asset, the http server 565 can then pull the resource and serve it back to the browser. The http server can fetch the resource from one of several local objects which are part of the present invention. These include a locally mounted file system (as implied by http server), or the local app bundle manager 535 which is connected to the http server via path 540. If the request is a data call or a callback function to a server side scripting language such as PHP, Python, Java Enterprise Edition, servlets or Common Gateway Interface Scripts, such are known in the art, the server will hand the request off to a processing engine. In the case of a server side scripting language such as those just mentioned, the request is handed via path 570 to processing engine 575 which handles the request, provides language specific features, and maintains session management information or server side variables. If the request is via web description language interface such as SOAP, WSDL, REST, XML remote procedure call, or similar function then it can be handed off via path 585 to a specialized engine 523 which functions as previously mentioned to complete the request functionality. It is also possible to use the server side scripting engine to complete the call via path 590 to specialized services such as 523 thereby enabling either AJAX only applications (e.g. those which only have browser based code and logic) or server based code and logic to share SOAP/REST/Web services plug-ins. The present invention also can provide access to a local SQL database as shown in box 513. This is connected to the web services manager 523 via path 517. The database provides the ability to store end user data such as preferences, location, or profile information. Applications running in the browser can access the SQL database via server side scripts running in box 575 or via a direct web services software call (SOAP call) which is issued through the web services manager directly. The database also connects to a data synchronization engine 525 via path 503. More detail on the operation of the synchronization engine will be discussed in a subsequent paragraph. Application resources are stored in the database marked App Bundles 535. This is connected via path 540 to the http server directly. The App Bundles database is also connected to sync engine 525 via path 530.
The app bundle manager, box 535 manages entire web application assets such as those depicted in box 310 of
An additional functionality of the present invention is the use of the sync engine, box 525 to update the locally stored applications (box 535) and locally stored SQL database 513 via paths 530 and 513 respectively. This allows applications stored as bundles to be atomically stored on the mobile device as a single file. The sync engine can then manage the storage, updating, upgrading, and subscription status of several such applications. For example a server could store information about a subscription application which the local sync engine would enforce. When the subscription expires the application bundle would be disabled or deleted. This functionality extends the type of application storage once associated with dedicated runtimes such as Java Micro Edition to web based applications. In addition the sync engine can store, synchronize and manage application data stored in the SQL database. In a typical (server based) application user data, such as shopping cart information on an ecommerce based web store or photographs on a photo sharing website would be stored on that site's database. In the present invention the ability to utilized web based protocols to store application data locally is now available though web services calls. More over the synchronization engine can then move user data stored in the local database back to a classically running server at an internet URL. The synchronization engine in the present invention therefore allows both applications and user data to be stored on a local device and then, should that device be lost or the user acquire a newer, perhaps upgraded device, the user's applications and the application's data can be seamlessly re-provisioned to the new device. The sync engine also can access the external internet through proxy 560 by using path 520. This allows the sync engine to move code assets and user and application data stored in the either the App Bundles database 535 or App Data database 513 and maintain them in accordance with business rules for subscription or provisioning of the user's applications. The present invention, since it uses databases to store application bundles and user data, can also support different application permissions for different users allowing some to have access to more or different data than others.