Patent Description:
This application claims the benefit of priority of <CIT>, entitled Software Code Optimizer,.

The invention pertains to digital data processing and more particularly, by way of non-limiting example, to the optimization of software. The invention has application in facilitating the download and execution of so-called web apps, as well as other computer programs that download and execute in source code format. Enterprises are increasingly turning to web apps to service customer and other end user needs. This is an opportunity made possible by the ubiquity of feature-rich browsers supporting JavaScript, CSS and other user interface (Ul) standards on mobile and other devices in the hands and/or on the desktops of billions of users worldwide. Whereas software distribution was once the sole province of high-tech companies with teams of dedicated developers, these feature-rich browsers now define such a large and powerful platform that enterprises of all varieties, from high-tech to low-tech, can benefit by distributing apps to them, whether for customer service, marketing or otherwise. Browser technologies have become so versatile in fact, that enterprises often rely on them for distribution of apps within the enterprise to employees - not just to customers and others on the outside.

Unfortunately, just like conventional software applications, browser apps often include code to support capabilities that most individual users do not require or cannot use. For example, browser apps typically include software supporting end users of diverse classes, even though each individual user who runs the app only falls into only one of those classes. Likewise, the apps provide code supporting user access from a variety of portals (e.g., developer portal, support portal, etc.) even though each end user is likely to access the app from only one of them.

A consequence of excess code is that web apps are large, and their downloads are slow. While end users who run a given app for hours on end may not be bothered by this on an initial download, occasional users will be - as are those who download "once and done" apps, e.g., customer service requests.

An object of the invention is to provide improved methods and apparatus for digital data processing.

A further object is to provide such methods and apparatus is to improve the download and execution of web apps and other computer programs that download and execute in source code format. <CIT> teaches a resource dependency determining method for web application which involves determining ordered lists of executing modules based on identified dependencies, and providing determined lists of executing modules in web application.

<CIT> teaches a method which involves receiving a request sent from a client device to obtain a software application. The request is processed to identify the client device. The client device profile information associated with identified client device and user profile information associated with identified user are determined. The configuration files are selected from file database. A personalized executable file is generated for requested software application. The personalized executable file of the requested software application is sent to the client device.

<CIT> teaches a method and system for executing a streamed application on a client system utilizes a virtual file system installed in the client which is configured to appear to the operating system as a local storage device containing all of the application files required by the application. Prior to streaming, the application files are broken up into streamlets corresponding generally to various portions of the application files and these streamlets are delivered to the client by the server, preferably using a predictive algorithm to determine an optimal transmission order. After an initial set of streamlets is received, the application is executed from the virtual file system. File loads issued by the operating system to the virtual file system are translated to determine which streamlets correspond to the load request and the appropriate data is returned. If a needed streamlet is not present, a streamlet request is issued to the server and the virtual file system maintains a busy status until the necessary streamlets have been provided.

A more complete understanding of the invention may be attained by reference to the drawings, in which:.

<FIG> depicts a digital data processing system <NUM> for practice of the invention, as well as a system <NUM> in which the invention may be practiced. The system <NUM> includes a server digital data processor <NUM> that is coupled to client digital data processors <NUM>, <NUM> and <NUM> via a network <NUM> comprising a combination of one or more of the Internet, a wide area network (WAN), metropolitan area network (MAN), local area network (LAN), telephone networks and/or a combination of these and other networks (wired, wireless, public, private or otherwise).

The illustrated client digital data processors <NUM> - <NUM> are conventional tablet computers, PDAs, mobile phones or other digital data apparatus (including, for example, desktop computers, workstations, minicomputers, and laptop computers) of the type that are commercially available in the marketplace and that are suitable for operation in the illustrated system as described herein and all as adapted in accord with the teachings hereof.

The digital data devices <NUM>-<NUM> each comprise central processing, memory, storage and input/output units and other constituent components (not shown) of the type conventional in the art that cooperate to execute applications 14a - 18a, each of which comprises a web application of the type commercially available in the marketplace or otherwise known in the art and operative on the respective devices <NUM> - <NUM> for, by way of example, for purposes of presenting user interfaces on the respective devices <NUM> - <NUM>, presenting data in connection therewith received from the server <NUM>, user or otherwise, accepting user input with respect to those interfaces, issuing HTTP/HTTPS (collectively, "HTTP") requests to the server <NUM> for those interfaces and/or for requesting and/or submitting information with respect thereto, and so forth, all as per convention in the art as adapted in accord with the teachings hereof. Those web apps can comprise HTML, JavaScript, cascading style sheets (CSS), and so forth, and they can execute within the context of a web browser (not shown), a WebKit, or otherwise - again, per convention in the art as adapted in accord with the teachings hereof.

The central processing, memory, storage and input/output units of client digital data processors <NUM> - <NUM> may be configured to form and/or may be supplemented by other elements of the type known in the art desirable or necessary to support applications 14a - 18a, respectively, in accord with the teachings hereof, as well as to support other operations of the digital data processor <NUM>. These can include, by way of non-limiting example, peripheral devices (such as keyboards and monitors), operating systems, and network interface cards and software, e.g., for supporting communications with server digital data processor <NUM> and other devices over network <NUM>.

Although client digital data processors <NUM> - <NUM> are depicted and described in like manner here, it will be appreciated that this is for sake of generality and convenience: in other embodiments, these devices may differ in architecture and operation from that shown and described here and/or from each other, all consistent with the teachings hereof.

Like client digital data processors <NUM> - <NUM>, server digital data processor <NUM> is a digital data processing apparatus of the type commercially available in the marketplace suitable for operation in the illustrated system as described herein, as adapted in accord with the teachings hereof. Though the server <NUM> is typically implemented in a server-class computer, such as a minicomputer, it may also be implemented in a desktop computer, workstation, laptop computer, tablet computer, PDA or other suitable apparatus (again, as adapted in accord with the teachings hereof).

Server digital data processor <NUM>, too, comprises central processing, memory, storage and input/output units and other constituent components (not shown) of the type conventional in the art that are configured in accord with the teachings hereof to form rules engine <NUM> and rules base <NUM>, transaction database <NUM>, language database <NUM> and context registry <NUM>, one or more of which may be absent in various embodiments of the invention.

Although only a single server digital data processor <NUM> is depicted and described here, it will be appreciated that other embodiments may have greater or fewer numbers of these devices. Those other servers may differ in architecture and operation from that shown and described here and/or from each other, all consistent with the teachings hereof. Still further, although server <NUM> of the illustrated embodiment is depicted as being remotely disposed from the client digital data processors <NUM> - <NUM>, in other embodiments, one or more of the client devices may be co-housed with the server.

Rules base <NUM> comprises a conventional rules base of the type known in the art (albeit configured in accord with the teachings hereof) for storing digitally encoded rules <NUM> and other application-related information in tables, database records, database objects, and so forth. Such stored rules <NUM> are likewise formatted and stored in the conventional manner known in the art (albeit configured in accord with the teachings hereof). Here, rules base <NUM> is configured and contains rules for use in business process management applications, though in other embodiments it may be configured and used for other applications. Such a rules base can be of the type described in the US patents and patent applications assigned to the assignee hereof, e.g., <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>; though, a rules base that is architected and/or operated differently may be used as well or in addition, as may be another store and/or repository of applications, apps and other software suitable for use in connection herewith.

Although shown in the illustrated embodiment as part of server <NUM>, rules base <NUM> (or other repository) may reside elsewhere, e.g., remote to server <NUM>. Moreover, some embodiments may utilize multiple rules bases, e.g., an enterprise-wide rules base <NUM> on the server <NUM> and domain-specific rules bases on one or more of client devices <NUM> - <NUM>, all by way of example. To the extent that multiple rules bases are provided in any given embodiment, they may be of like architecture and operation as one another; though, they may be disparate in these regards, as well. Utilization of multiple rules bases may be accomplished in the manner described in one or more of the above-cited U. patents and patent applications, e.g., <CIT>, entitled "Systems and Methods for Distributed Rules Processing,".

Transactional database <NUM> comprises a conventional database of the type known in the art (albeit configured in accord with the teachings hereof) for storing corporate, personal, governmental or other data that may be any of generated, stored, retrieved and otherwise processed (hereinafter, collectively referred to as "processed") by rules in rules base <NUM> and/or rules stored/executed elsewhere. The data may be financial data, customer records, personal data, run-time data related to an application, or other type of data and it may be stored in tables, database records, database objects, and so forth.

As above, some embodiments may utilize multiple transactional databases, e.g., an enterprise-wide database <NUM> on the server <NUM> and branch-office specific databases on the client devices <NUM> - <NUM>, all by way of example. To the extent that multiple transactional databases are provided in any given embodiment, they may be of like architecture and operation as one another; though, may they be disparate in these regards, as well. Utilization of multiple transactional databases may be accomplished in the manner described in <CIT>.

Language base <NUM> encodes information regarding the syntax of the language (or languages) in which user interfaces generated by server <NUM> are presented on devices <NUM> - <NUM> and, more particularly, in the illustrated embodiment, by applications 14a - 18a. That syntax can include one or more of grammar, spelling, usage, punctuation, and/or style. The language base <NUM> may comprise a language database of the variety commercially available in the marketplace - e.g., in the manner of spelling and grammar dictionaries provided with conventional word processors (which "dictionaries" often include usage-, punctuation-and/or style-related entries). Alternatively, the language syntax information may be embodied in one or more rules <NUM> of the rules base <NUM>, or otherwise.

Context registry <NUM> is a store that includes information related to the respective contexts or circumstances in which the requested user interfaces (e.g., web pages) are and/or will be communicated to and executed on the respective client devices <NUM> - <NUM>. That context or circumstance can include, by way of non-limiting example, user "properties" or business attributes (e.g., access requirements, disability settings, market segment, behavioral segment, age, locale, and so forth), client device <NUM> - <NUM> properties (e.g., processor speed, display size, keyboard capabilities, locale, and so forth), communication channel properties (e.g., the speed and type of connection between server <NUM> and the respective client devices <NUM> - <NUM>) and portal properties (e.g., download file size limits, quality-of-service requirements and so forth). That context or circumstance can further include, by way of non-limiting example, the language, country and/or other locale settings and preferences of the user of a device on which the web page is to be displayed. Still other variations in the possible range of values stored in the context registry <NUM> are possible.

Illustrated digital data processor <NUM> also includes rules engine <NUM> of the type conventionally known in the art (albeit configured in accord with the teachings hereof) for use in processing rules from a rules base in order to process data, e.g., in (and/or for storage to) a transactional database in view of a language base and/or context registry or other data sources described above, for example, in connection with events signaled to and/or detected by the engine. In the illustrated embodiment, the rules engine is of the type used for business process management applications, though in other embodiments it may be of the type used for other applications. Preferred such rules engines are of the type described in the aforementioned <CIT>, entitled "Rules Bases and Methods of Access Thereof" and <CIT>, entitled "Rules Base Systems and Methods with Circumstance Translation" and/or <CIT>, entitled "Proactive Performance Management For Multi-User Enterprise Software Systems".

The rules engine <NUM> may be implemented in a single software program or module, or a combination of multiple software modules/programs. Moreover, it may comprise programming instructions, scripts, rules (e.g., rules stored in rules base <NUM>) and/or a combination of thereof. And, even though the rules engine <NUM> of the illustrated embodiment is depicted as executing on just server digital data processor <NUM>, in other embodiments, the engine may execute on or across multiple digital data processors (e.g., <NUM>, <NUM>, <NUM> and <NUM>). Executing the engine <NUM> over multiple digital data processors may be accomplished in the manner described in <CIT>, by way of non-limiting example.

Described below is a method of operating system <NUM> and, particularly, server <NUM> and still more particularly, by way of example, rules engine <NUM>, to optimize instantiations of a model app <NUM> for download from that device <NUM>, rules base <NUM> and/or engine <NUM> to one or more client devices <NUM> - <NUM> for execution thereon, e.g., as a web app 14a - 18a. This may be, for example, at the request of a user of one of those devices issued via a web browser executing thereon or otherwise; conversely, such download may be effected sans user request, e.g., upon boot-up of a respective one of the devices <NUM> - <NUM> or otherwise - all as per convention in the art as adapted in accord with the teachings hereof.

As used here, to "optimize" the app <NUM> means to reduce the footprint of JavaScript code and/or cascading style sheets (CSS) that make up the app <NUM> as downloaded vis-à-vis instantiations thereof to the requesting device <NUM> - <NUM>, e.g., based on the nature of that device, the access requirements (i.e., "role") of the user of that device making the request and/or on behalf of whom the request is made, and the portal (i.e., the web site or web address) to the which download request was made and/or from which the request is fulfilled. The app <NUM> is occasionally referred to herein as an app "model" because it includes rules and style sheets for all combinations of portals, requesting devices and user roles.

In the illustrated embodiment, that method is carried out by an optimization application <NUM> alone and/or in cooperation with other functionality of the server <NUM> and/or client devices <NUM> - <NUM>, as evident in the discussion below. Application <NUM> of the illustrated embodiment is implemented in rules that are stored in rules base <NUM> and executed by rules engine <NUM> upon invocation. However, other embodiments may vary in this regard. Thus, for example, application <NUM> may be embodied in other software formats, sourced from other repositories and executed other than on a rules engine.

Likewise, in the illustrated embodiment, model apps which are instantiated for download to requesting devices <NUM> - <NUM> (e.g., model app <NUM> mentioned above and discussed below) are sourced from rules base <NUM>. In such an embodiment, the app <NUM> is represented by a set of rules (e.g., from the rules base <NUM>) that combine to define the app's functions and features when executed, e.g., as an app 14a -18a within a browser or otherwise the requesting device. In other embodiments, the app <NUM> may be represented in other software formats and executed according within browsers or otherwise on the respective devices <NUM>-<NUM>.

Referring to <FIG>, in step <NUM>, the optimization application <NUM> is invoked in real-time mode or batch mode by rules engine <NUM> or other functionality executing on server <NUM>. Real-time mode refers to invocation in real-time response to a request by a client device <NUM> - <NUM> for download of an instantiation of app <NUM> to be executed on that device. Batch mode refers to invocation of the application <NUM> in advance of such a request - e.g., as where the application <NUM> is invoked to generate instantiations of the app <NUM> that are expected to meet possible future such requests. Invocation of the application <NUM>, whether implemented in rules or otherwise in real-time mode or in batch mode, is within the ken of those skilled in the art in view of the teachings hereof.

In step <NUM>, an application crawler <NUM> that forms part of optimization application <NUM> parses and/or otherwise crawls the source code of app <NUM>, that is, the rules or other source code instructions (hereinafter, collectively, "source code rules" or, simply, "rules") comprising app <NUM> to identify source code files or portions thereof, including user interface components - all, collectively, referred to herein as "components" - for use with an instantiation of app <NUM> (i) for download from a designated portal, (ii) for execution on a designated (requesting) device <NUM> - <NUM>, and/or (iii) by a user having a designated role or, put another way, for use with an instantiation of app <NUM> for download and execution in connection with a specific combination of portal, device and/or user role. In the illustrated embodiment, the source code <NUM> is JavaScript and related programming instructions/declarations, e.g., embedded scripting languages, style sheets, and the like, all as within the ken of those skilled in the art in view of the teachings hereof. In other embodiments, the source code files may include other source code programming languages, instead or in addition.

The crawler <NUM> generates, in step <NUM>, a report <NUM> referred to in the drawings as a "crawler usage report"; although, it need not be a report in the conventional sense of a human-readable document but, rather, may comprise any memorialization of identified components, e.g., in binary, XML, or otherwise, as is within the ken of those skilled in the art in view of the teachings hereof. The report can be stored in a dedicated file, as part of a database or otherwise, on server <NUM> or otherwise. Operation of the crawler <NUM> may be further appreciated in connection with <FIG> and the discussion thereof below.

In addition to the foregoing, the crawler usage report <NUM> is supplemented to include, for each listed component, names or identities of one or more JavaScript ("JS") files that implement (i.e., contain code defining) the component - or, put another way, the JS files on which the component depends. In addition, the report <NUM> can identify user interface features implemented by those files - or, put another way, the JS files on which those features depend. The crawler usage report <NUM> can, moreover, be supplemented to indicate when each JS file is preferably loaded. For example, such load order can be designated as "top," "template" or "bottom" bundle (as described further below).

The foregoing component-to-file and feature-to-file dependencies and bundle designations can be added to the report <NUM> automatically by the application crawler <NUM> and/or with the assistance of an administrator, software engineer or other human agent. Alternatively, or in addition, the crawler <NUM> can rely on a file or other listing of such dependencies and/or load order for purposes of supplementing the report <NUM>.

As used above and elsewhere herein, a portal designation can be with respect to a specific portal address (or portion of such address) from which the instantiation is to be downloaded (or, as used synonymously therewith herein, to which a request for download is made), or with respect to a role served by such portal (e.g., a portal that serves production code vs test code, etc.), and so forth, as is within the ken of those skilled in the art in view of the teachings hereof. Likewise, above and elsewhere a device designation can be with respect to a specific device address (e.g., as specified by MAC address, or other unique identifier) or device type (e.g., as specified by operating system, browser or webkit type, processor class, memory or other storage capacity, display type/size, data communication speed and type, and so forth), or otherwise, as is within the ken of those skilled in the art in view of the teachings hereof. Furthermore, above and elsewhere a user role designation can be with respect to a specific role, e.g., end user, developer, administrator and so forth, as reflected in an active directory, user name requirement codes or otherwise, as is within the ken of those skilled in the art in view of the teachings hereof. In some embodiments, the user role designation/identification can extend to a level of granularity of individual users in which case the designation/identification can be by user name, ID or other unique identifier.

In step <NUM>, a JavaScript optimizer <NUM> that forms part of optimization application <NUM> generates for the components identified in Step <NUM> and reflected in the report <NUM> (i.e., the components identified as being for use with an instantiation of app <NUM> for download and execution in connection with a specific combination of portal, device and/or user role) a dependency-ordered stack of source code files containing the components so identified. In step <NUM>, the JavaScript optimizer combines the dependency-ordered stacks generated in step <NUM> into a single dependency-ordered stack. In step <NUM>, the JavaScript optimizer <NUM> prepares for transfer to and loading on a requesting client device <NUM>-<NUM> (and, particularly, for example, within the environment of a browser or webkit of such device) the source code files identified in the dependency-ordered stack generated in step <NUM>. The optimizer <NUM> prepares for such transfer in an order that is based on the dependency order specified in that stack. In the illustrated embodiment, in which the steps <NUM> - <NUM> are executed in real-time mode, the optimizer <NUM>, alone or in cooperation with other elements of server <NUM>, proceed with transfer of those files in that order, via HTML stream or otherwise, as is within the ken of those skilled in the art in view of the teachings hereof. Where, on the other hand, steps <NUM> - <NUM> are executed in batch mode the optimizer can delay such transfer until such a corresponding request is received. Operation of the optimizer <NUM> as per steps <NUM> - <NUM> may be further appreciated in connection with <FIG> and the discussion thereof below.

In the illustrated embodiment, the optimizer <NUM> transfers (or prepares for transfer) the source code files to the requesting client <NUM> - <NUM> in multiple bundles, including (i) a top bundle <NUM> comprising source code loaded as soon as page is visible upon execution of the app on the client digital data device by the user, (ii) a template bundle <NUM> comprising source code loaded before control rendering begins upon execution of the app on the client digital data device by the user, and (iii) a bottom bundle <NUM> comprising source code loaded at an end of an initial page load upon execution of the app on the client digital data device by the user. In each instance, the bundles are transferred in accord with the dependency order specified in the single dependency-ordered stack. In other embodiments, the JavaScript optimizer <NUM> may transfer the source code files in greater, fewer and/or different bundles. The segregation of files into such bundles and their transfer to the client devices <NUM> - <NUM> is within the ken of those skilled in the art in view of the teachings hereof.

As discussed above, in step <NUM>, the application crawler <NUM> can parse/crawl rules comprising app <NUM> to identify components for use with an instantiation of app <NUM> for download and execution in connection with a specific combination of portal, device and/or user role. In step <NUM> of some embodiments, the crawler <NUM> can, alternatively or in addition, identify the cascading style sheets (hereinafter, simply, "style sheets") used by the app <NUM>, a set of user interface components, features of those user interface components, and formats of those user interface components or features - all, collectively, referred to herein as a set of "style features" - for use with instantiations of app <NUM> downloaded from a plurality of different portals for execution on a plurality of different (requesting) devices <NUM> - <NUM>, and/or by a plurality of users having different role. The crawler can, furthermore, identify a subset of those style features that are not for use with an instantiation of app <NUM> (i) for download from a designated portal, (ii) for execution of a designated (requesting) device <NUM> - <NUM>, and/or (iii) by a user having a designated role or, put another way, that are not for use with an instantiation of app <NUM> for download and execution in connection with a specific combination of portal, device and/or user role. In embodiments where step <NUM> includes identifying style features, step <NUM> can include generating the report <NUM> to include such style features as fall within the aforesaid set, along with those that fall in the aforesaid subset.

Moreover, in such embodiments, a CSS optimizer <NUM> that forms part of optimization application <NUM> can, in step <NUM>, prepare for transfer to and loading and execution on the client device <NUM> - <NUM> (and, particularly, for example, the browser of such a device) files that define style sheets that are in the aforesaid set but that are not in the aforesaid subset. In embodiments in which the steps <NUM> - <NUM> and <NUM> are executed in real-time mode, the optimizer <NUM> can, alone or in cooperation with other elements of server <NUM>, proceed with the file transfer via HTML stream or otherwise, as is within the ken of those skilled in the art in view of the teachings hereof. Where, on the other hand, those steps are executed in batch mode the optimizer can delay such transfer until such a corresponding request is received.

Operation of the CSS optimizer <NUM> may be further appreciated in connection with <FIG> and the discussion thereof below.

<FIG> depicts operation of an application crawler <NUM> according to one practice of the invention. As noted above, the crawler parses/crawls a set of rules defining an app model <NUM> to identify components used in execution of an instantiation of that model for a specific combination of portal, device and/or user role.

In step <NUM>, the crawler <NUM> discerns the portal in connection with which the components of app <NUM> are to be identified. In real-time mode, the crawler <NUM> can determine the portal of a just-received request from the identity of a function or page from which it (the crawler <NUM>) is invoked, from the identity of a server <NUM> upon which the crawler <NUM> is executing, or as otherwise within the ken of those skilled in the art in view of the teachings hereof. In batch mode, the portal associated with a possible future request can be passed as a parameter to the crawler <NUM>, e.g., by the rules engine <NUM> or other functionality executing on server <NUM> that iterates through portal/device/user-role combinations for purposes of generating such instantiations in advance, or otherwise, as is within the ken of those skilled in the art in view of the teachings hereof.

In step <NUM>, the crawler <NUM> discerns the user role (or "access group") in connection with which the components of app <NUM> are to be identified. In real-time mode, the crawler <NUM> can determine the role/access group of a user from a cookie maintained on that user's device, from a parameter passed by a function or page from which the crawler <NUM> is invoked, or as otherwise within the ken of those skilled in the art in view of the teachings hereof. The crawler <NUM> can likewise determine the role/access group associated with at possible future request, i.e., in batch mode, from a parameter passed by the functionality that iterates through portal/device/user-role combinations, or otherwise, as is within the ken of those skilled in the art in view of the teachings hereof.

In step <NUM>, the crawler <NUM> discerns the device in connection with which the components of app <NUM> are to be identified. In real-time mode, the crawler <NUM> can determine the role/access group of a user by querying the browser, webkit or other functionality executing on the user device <NUM> - <NUM> from which the download request was initiated, from a parameter passed by a function or page from which the crawler <NUM> is invoked, or as otherwise within the ken of those skilled in the art in view of the teachings hereof. The crawler <NUM> can likewise determine the device associated with at possible future request, i.e., in batch mode, from a parameter passed by the functionality that iterates through portal/device/user-role combinations, or otherwise, as is within the ken of those skilled in the art in view of the teachings hereof.

Although <FIG> illustrates determination by crawler <NUM> of each of the portal, user role and device for purposes of identifying components used in execution of an instantiation of app model <NUM>, other embodiments may use only one or two of those determinants - e.g., user role and portal, by way of non-limiting example - and, hence, in the discussion that follows they are connected by the grammatical conjunction "and/or.

In step <NUM>, the crawler <NUM> recursively iterates, in both depth and breadth, through rules contained in app model <NUM> beginning at the execution entry point for the specified combination of portal, device and/or user role. In the illustrated embodiment, the crawler <NUM> iterates through the rules on a file-by-file basis, as reflected by the source code files depicted as elements <NUM> in the drawing. As used here, "entry point" (or "app root") refers to the programming instruction and, more generally, the component at which execution of the instantiated app will begin, upon user request or otherwise, following download. The identification of that entry point, as typically, based on requirements associated with one or more of the designated portal, user role and/or device, is within the ken of those skilled in the art in view of the teachings hereof.

Such recursive iteration can be effected by executing the following steps, beginning at the entry point: (i) iterating (or stepping) through each instruction (or "rule," as used herein synonymously therewith) of source code in a component and (ii) identifying each further component (if any) that instruction references which further component is available and suitable for execution in view of the designated combination of portal, user role and/or device - and, repeating those steps (i) and (ii), in turn (i.e., recursively), for each such referenced component. As each component available and suitable for execution in view of the designated combination of portal, user role and device is identified through this iterative recursion, the crawler <NUM> stores the component's name or other identification to report <NUM>. Such instruction-by-instruction iteration can be effected through a line-by-line examination of the source code. Alternatively, it can be effected using information in a source code model that represents each source code file, e.g., with metadata that includes component dependencies (as defined by an administrator, software engineer, automated analysis or otherwise). A benefit of this latter approach is avoidance of line-by-line parsing of the source code concurrently with execution of optimization application <NUM>.

In addition to identifying component dependencies during recursive iteration of the app model <NUM>, the crawler <NUM> also identifies user interface features that depend on the examined source code files. For example, a source code file may be marked (in the aforesaid source code model) with metadata indicating that file is used for a button component that is formatted (i.e., displayed) as a text link. Another file may be marked by such metadata that indicates the same button component is formatted as an image. By storing those file-based UI feature dependencies, e.g., to report <NUM>, the crawler <NUM> makes possible the building of bundles that avoid inclusion of unnecessary source code, as discussed further below.

In some embodiments, in step <NUM>, the crawler <NUM> recursively iterates through all rules that are available and suitable for execution for the designated combination of portal, user role and/or device, as described above. In other embodiments, the crawler <NUM> skips (i.e., does not perform aforesaid steps (i) and (ii)) on components that are marked as "blacklisted", e.g., as indicated by the black triangle superimposed over one of the files <NUM> in the drawing. A listing of files to be skipped in this regard can be reflected in a store (not shown) associated with the crawler <NUM>, the engine <NUM>, the server <NUM> or otherwise, as per convention in the art as adapted in accord with the teachings hereof. Such components can be identified in such a store by file name, line range, rule name or id, and/or via other convention within the ken of those skilled in the art as adapted in accord with the teachings hereof. As a consequence, components on which blacklisted ones depend (e.g., components that are themselves specified within a blacklisted component and that, therefore, are necessary for the blacklisted component to execute) will not be identified as necessary for execution - unless those depended-upon components are crawled during processing of other, non-blacklisted components of the app <NUM>.

Conversely, in other embodiments, the crawler <NUM> can, in step <NUM>, recursively iterate through all rules that make up components that are "whitelisted," e.g., regardless of whether those components are available and suitable for execution in view of the designated combination of portal, user role and/or device. As above, such whitelisted components can be identified in such a store by file name, line range, rule name or id, and/or via other convention within the ken of those skilled in the art as adapted in accord with the teachings hereof.

Application crawler <NUM> stores to the usage report <NUM> a report of rules and, more generally, components used in execution of an instantiation of app model <NUM> for the specific combination of portal, device and/or user role. It can supplement that with dependencies and load-order pertaining to each component, as discussed above.

<FIG> depict operation of the CSS optimizer <NUM> according to one practice of the invention in regard to building optimization representations from the usage report <NUM>. <FIG> depicts the first part of that process resulting in identification of CSS generation elements required for an instantiation of model app <NUM> for a specific combination of portal, device and/or user role. <FIG> depicts the second part of that process, resulting in a listing of a subset of CSS style feature-related files not necessary for that particular instantiation, which subset is defined with respect to the set of all CSS style feature-related files used by the app <NUM> independent of portal, device and user role.

In step <NUM>, the optimizer <NUM> maps (i) cascading style sheets (CSS) for buttons, check boxes and other user interface widgets (collectively, referred to here as "generation elements" or "Gen El") used in the model <NUM> as a whole to (ii) components identified as used in execution of an instantiation of the model <NUM> for a specific combination of portal, device and/or user role. The components are reflected in the crawler usage report <NUM>, which is generated as discussed above in connection with <FIG>. The CSS for generation elements is reflected in a map <NUM>, which is generated from an application rule <NUM> that describes the complete set of CSS Generated Elements and formats that may be used by an application model <NUM>. In the illustrated embodiment, the mapping by the optimizer in step <NUM>, that is, the mapping of CSS generation elements to components is <NUM> to m, where m is an integer greater than or equal to one.

The mapping of generation elements to components or other values, as reflected in step <NUM> and elsewhere herein, is within the ken of those skilled in the art in view of the teachings hereof. Such mappings can be reflected in tables, arrays, linked lists or otherwise, whether stored in binary, text or otherwise, as is within the ken of those skilled in the art in view of the teachings hereof.

In step <NUM>, the optimizer <NUM> maps each CSS generation element used in the model <NUM> as a whole to a Boolean value (e.g., true or false) reflecting whether that element appears in the mapping generated in step <NUM>. Put another way, the optimizer <NUM> in step <NUM> assigns each CSS Gen El used in model <NUM> as a whole a value of true or false, depending on whether that CSS Gen El is used in a component that appears in the usage report <NUM>. In addition to assigning a value of false to each CSS Gen El not used in a component in that report <NUM>, the optimizer assigns a value of false to each generation element that is blacklisted, e.g., as reflected in the store referred to above in connection with step <NUM> or otherwise. See step <NUM>. By this mechanism, embodiments can prevent the download of CSS generation elements that have been deprecated.

Although Boolean values are mentioned above and elsewhere herein, it will be appreciated that other values may be used instead or in addition. Moreover, it will be appreciated that in lieu of mapping CSS Gen El to Boolean (or other) values, alternative techniques within the ken of those skilled in the art for reflecting the same information may be used instead or in addition.

In step <NUM>, the optimizer <NUM> stores the resultant mapping of CSS generation elements - i.e., the mapping of CSS Gen El to true or false values reflecting whether (or not) those elements are used by components in the report <NUM> or, regardless, whether they have been deprecated or otherwise blacklisted - as a so-called component usage map <NUM>. As noted above, this can be represented in tables, arrays, linked lists or otherwise; moreover, it can be stored internal to the optimizer <NUM>, the engine <NUM>, the server <NUM> or otherwise. In embodiments operating in real-time mode, it can be stored to the requesting client device <NUM>- <NUM>, in addition or instead.

In step <NUM>, the optimizer <NUM> maps each CSS generation element identified in step <NUM> as used by a component in the usage report to one or more formats available to that element. This allows the comparison of formats that are possibly used (i.e., as defined in the "Skin" rule mentioned above) with the formats that crawler had seen as being used, skipping the generation of CSS for any Formats that aren't used.

As used above and throughout, a "format" is a collection of CSS styles that are used together to provide a particular look (e.g., a "bold button" definition that calls for boldface text and a rounded rectangle outline with a <NUM> px border). In the illustrated embodiment, the mapping by the optimizer in step <NUM> of CSS to Gen El to formats is <NUM> to m, where m is an integer greater than or equal to one.

In step <NUM>, the optimizer <NUM> supplements the mapping generated in step <NUM> to include synonyms of the formats generated by that prior step. Such synonyms can be obtained from definition files (not shown here), entered by an administrator or otherwise. Additional formats required for a given implementation, e.g., formats for standard fonts and colors used by a given enterprise, website or otherwise, can likewise be added in step <NUM>.

In step <NUM>, the optimizer <NUM> stores the resultant mapping of CSS generation elements - i.e., the mapping of CSS Gen El to formats, their synonyms and required formats- as a so-called format usage map <NUM>. As noted above, this can be represented in tables, arrays, linked lists or otherwise; moreover, it can be stored internal to the optimizer <NUM>, the engine <NUM>, the server <NUM> or otherwise. In embodiments operating in real-time mode, it can be stored to the requesting client device <NUM> -<NUM>, in addition or instead.

<FIG> depicts further operation of the CSS optimizer <NUM> according to one practice of the invention; here, in regard to generating a listing <NUM> of the subset of CSS style feature-related files not necessary for instantiation of the model app <NUM> for given combination of portal, device and/or user role.

The listing is generated from the crawler usage report <NUM> and the usage maps <NUM>, <NUM>. Significantly, it is also generated from a base listing <NUM> of the set of files containing CSS source code associated with model app <NUM> for all combinations of portal, device and user role. That base listing is referred to, here, as the pzBase. The listing <NUM> may be generated automatically, e.g., by a integrated development environment, or by an administrator or other person, and/or by a combination of the foregoing, and it may be a text file, binary or otherwise, all as is within the ken or those skilled in the art in view of the teachings hereof.

In step <NUM>, the optimizer <NUM> stores to the file containing listing <NUM> (which file may be a text file, binary or otherwise, as is within the ken of those skilled in the art in view of the teachings hereof) the names or other identifiers of files listed in the pzBase file <NUM> which are blacklisted, e.g., as reflected in the store discussed above in connection with step <NUM>.

In step <NUM>, the optimizer <NUM> stores to the file containing listing <NUM> the names or other identifiers of files listed in the pzBase file <NUM> which contain CSS generation elements that are not necessary for instantiation of the model app <NUM> for a given combination of portal, device and/or user role, e.g., as evident from the report <NUM> and/or maps <NUM> and <NUM>.

In step <NUM>, the optimizer <NUM> stores to the file containing listing <NUM> the names or other identifiers of files listed in the pzBase file <NUM> which reflect formats that are not used for CSS generation elements for instantiation of the model app <NUM> for a given combination of portal, device and/or user role, e.g., as evident from the report <NUM> and/or maps <NUM> and <NUM>.

In step <NUM>, the optimizer <NUM> stores to the file containing listing <NUM> the names or other identifiers of files listed in the pzBase file <NUM> which are associated with user interface components that are not necessary for instantiation of the model app <NUM> for a given combination of portal, device and/or user role, e.g., as evident from the report <NUM> and/or maps <NUM> and <NUM>.

In step <NUM>, the optimizer <NUM> stores to the file containing listing <NUM> the names or other identifiers of files listed in the pzBase file <NUM> which contain CSS generation elements and user interface components that are not necessary for instantiation of the model app <NUM> for a given combination of portal, device and/or user role, e.g., as evident from the report <NUM> and/or maps <NUM> and <NUM>.

In step <NUM>, the optimizer <NUM> stores to the file containing listing <NUM> the names or other identifiers of files listed in the pzBase fiel <NUM> associated with user interface components for which formats are not necessary for instantiation of the model app <NUM> for a given combination of portal, device and/or user role, e.g., as evident from the report <NUM> and/or maps <NUM> and <NUM>.

In step <NUM>, the optimizer <NUM> stores to the file containing listing <NUM> the names or other identifiers of files listed in the pzBase file <NUM> associated with user interface components for which features are not necessary for instantiation of the model app <NUM> for a given combination of portal, device and/or user role, e.g., as evident from the report <NUM> and/or maps <NUM> and <NUM>.

Steps <NUM> - <NUM> can be run in parallel or in serial in order to generate the listing <NUM>, which may be internal to the optimizer <NUM>, the engine <NUM>, the server <NUM> or otherwise. In embodiments operating in real-time mode, it can be stored to the requesting client device <NUM> - <NUM>, in addition or instead.

<FIG> depicts generation of a style sheet bundle <NUM> ("CSS Bundle" or "static content"), i.e., a collection of style feature-related files, for instantiation of the model app <NUM> for given specific combination of portal, device and/or user role. In the illustrated embodiment, this is done in three phases: a first phase <NUM> that includes selected files from the pzBase listing in file <NUM>; a second phase <NUM> that includes selected CSS generation elements; and a third phase <NUM> that includes additional files selected from the pzBase listing <NUM>. Other embodiments may utilize a greater or lesser number of phases.

In phase <NUM>, the optimizer <NUM> prepares for download to the requesting device as part of the CSS Bundle <NUM> the set of files in base listing <NUM> (<FIG>) that are not in the listing <NUM> of the subset of files not necessary for instantiation of the model app <NUM> for a specific portal, device and/or user role combination. In some embodiments, the set can be the entirety of the files in base listing <NUM>; however, in the illustrated embodiment, it is just those files that are designated for initial download. Typically, these are file associated with style sheets corresponding to JavaScript that will be loaded as soon as a page (or other screen) of the instantiation of app <NUM> begins execution on the requesting client device.

In phase <NUM>, the optimizer <NUM> iterates over CSS generation elements contained in store <NUM> (<FIG>), skipping over any listed in listing <NUM> and/or marked in format usage map <NUM> as unused for the specific portal, device, and/or user role combination. For each used (i.e., not skipped) generation element, the optimizer <NUM> iterates over each format potentially used by that element (e.g., as reflected in store <NUM> or otherwise) skipping over any formats listed in listing <NUM> and/or marked in component usage map <NUM> as unused for the specific portal, device, and/or user role combination. For each used (i.e., not skipped) format, the optimizer generates a cascading style sheet (or entry) for that format and prepares it for download as part of the CSS Bundle <NUM>.

In phase <NUM>, the optimizer <NUM> prepares for download to the requesting device as part of the CSS Bundle <NUM> remaining files in the set of in base listing <NUM> (<FIG>) that are not in the listing <NUM> of the subset of files not necessary for instantiation of the model app <NUM> for a specific portal, device and/or user role combination. In the set comprises those in listing <NUM> that are designated for final download. Typically, these are file associated with style sheets loaded at the ends of a page (or other screen) of the instantiation of app <NUM> after it begins execution on the target client device.

In embodiments operating in real-time mode, the bundle <NUM> can be downloaded to a target client device <NUM> - <NUM> at the time of its request and in connection with the download of JavaScript files to those devices. In embodiments operating in batch mode, the CSS bundle can be generated for download at a later time, or its generation and download can be deferred until corresponding requests are received, or otherwise, all as is within the ken of those skilled in the art in view of the teachings hereof.

<FIG> depicts generation of JavaScript source code files for download and execution in connection with a specific combination of portal, device and/or user role as discussed above in connection with steps <NUM> - <NUM>; here, shown as steps <NUM> - <NUM>.

As shown in the drawing, the crawler usage report <NUM> provides an input to the illustrated processing sequence. That report <NUM> contains, as evident in the discussion above, a list of components used/unused in an instantiation of model <NUM> for download to the specific portal, device and/or user role. In addition, for each component that is marked as used, the report <NUM> includes a listing of features of that component, with each of them marked as used/unused, as well.

For each component in the report <NUM> marked as used by the specific portal/device/user-role combination, the JS optimizer <NUM> performs the recursive step(s) below and illustrated in the drawing:
Step <NUM>: Create a "stack" of JS file dependencies for the component and store it for further processing. For each JS file in that stack, the JS optimizer <NUM> performs the step(s) of:
Step <NUM>: Create a "stack" of JS file dependencies for the component and store it for further processing. For each JS file in that stack, the JS optimizer <NUM> performs the step(s) of:
Create a "stack" of JS file dependencies for the component and store it for further processing.

The depth-and-breadth recursive descent stops when one of the recursive processing steps <NUM>, <NUM>, etc.:.

Stacks built as a result of recursive processing steps <NUM>, <NUM>, etc., can be illustrated by the following example, which assumes that the report contains records identifying user interface components U1 through U3 and JavaScript components A through I as used for a specific portal/device/user-role combination, with the following dependencies (where "->" means "depends on"), including a circular dependency, reflected above, to wit, A->B->C->A.

As a result of the processing in steps <NUM>, <NUM>, etc., a stack is built for each JavaScript component or JS file encountered in the report <NUM>. Specifically, when a component or JS file is encountered, a dependency stack is created for that component file (if one doesn't exist). Then, its dependencies are opened in the order they appear (which can cause creation of that component/file dependency stack, etc.). Then, as the recursion is "unwound", the "child" dependencies are read and pushed onto the "dependent's" stack.

In the illustrated embodiment, UI components themselves are not placed in a stack; only the JS components they are dependent upon are. Moreover, UI components do not depend upon other UI components; they are only dependent on JS components. However, in the illustrated embodiment JS components can be dependent upon other JS components and therefore can create circular references, e.g., as illustrated below.

For the specific example above, the annotations below show the order of the stacks being created, added to, etc. Further explanation is provided parenthetically.

U1 triggers a stack for A and subsequently B and C, as follows:.

U2 triggers a stack for D and subsequently E, as follows:.

U3 triggers for stack A (already done previously) and a stack G, as follows:.

As a result of the foregoing, the following stacks are built:.

Combining U1, U2 and U3 dependency stacks produces the following:.

The final contents of the new (combined) stack is read as file needing to be loaded in reverse order. In the example, this means load I, then load H, then G, etc. This also means C will be loaded before B which will be loaded before A, as the dependency indicates. These data representations also allow the optimizer <NUM> to note that a cyclic dependency remains (A needs to be loaded before C and C needs to be loaded before B which loads before A) indicating work that needs to be resolved in the code, e.g., by generating a warning message to an administrator or other. As a consequence, the optimizer <NUM> is able to generate a single dependency stack (reverse order-which is the desired load order). In this example, that would be I, H, G, C, B, A, F, E, D.

In step <NUM>, the JavaScript optimizer <NUM> prepares for transfer to and loading on a requesting client device <NUM> - <NUM> the source code files identified in the dependency-ordered stack generated in step <NUM>. The optimizer <NUM> prepares for such transfer in an order that is based on the dependency order specified in that stack. In embodiments, in which the steps <NUM> - <NUM> are executed in real-time mode, the optimizer <NUM> can, alone or in cooperation with other elements of server <NUM>, proceed with transfer of those files in that order, via HTML stream or otherwise, as is within the ken of those skilled in the art in view of the teachings hereof. Where, on the other hand, steps <NUM> - <NUM> are executed in batch mode the optimizer can delay such transfer until such a corresponding request is received. In either case, the transfer of files can be effected in a conventional manner known in the art, e.g., via a compiler (e.g., GCC) or otherwise.

Claim 1:
A method of optimizing an app for any of download to, and execution, on a client digital data device, comprising
- Step A-identifying a plurality of source code files or portions thereof, including user interface components, used in execution of an app on a client digital data device by a user who at least one of -i-has a designated access group, role, and -ii-requests download of the app from a designated portal,
- Step B- for each component identified in Step A: identifying source code files on which execution of that component in connection with execution of the app by the user depends, and generating for that component a dependency-ordered stack of the source code files so identified, where the step of identifying source code files includes crawling the app source code starting at an entry point specific to the user role and designated portal, and recursively descending in both depth and breadth to identify the components used in execution of the app on the client digital data device by such user in view of that role and portal,
- Step C- combining the dependency-ordered stacks generated in step B into a single dependency-ordered stack,
- Step D-transferring to the client digital data device for loading and execution thereon the source code files identified in the single dependency-ordered stack, where the source code files are transferred based on the dependency order specified in that stack,
wherein step D comprises transferring the source code files to the client digital data device in multiple bundles, where the source code files transferred in each bundle is based on the dependency order specified in the single dependency-ordered stack, and wherein the multiple bundles includes at least two of:
- i-a top bundle comprising source code loaded as soon as page is visible upon execution of the app on the client digital data device by the user,
- ii-a template bundle comprising source code loaded before control rendering begins upon execution of the app on the client digital data device by the user, and
- iii-a bottom bundle comprising source code loaded at an end of an initial page load upon execution of the app on the client digital data device by the user.