BRPI0111802B1 - NETWORK-BASED SOFTWARE EXTENSION DISTRIBUTION METHOD - Google Patents

Description

(54) Title: NETWORK-BASED SOFTWARE EXTENSION DISTRIBUTION METHOD (73) Holder: MICROSOFT TECHNOLOGY LICENSING, LLC. Address: One Microsoft Way, Redmond, Washington, UNITED STATES OF AMERICA (US), 98052 (72) Inventor: MICHAEL C. MURRAY; PAUL R. ERICKSON; OLIVER G. FISHER; SURYANARAYANAN V. RAMAN

Validity Term: 10 (ten) years from 10/02/2018, subject to legal conditions

Issued on: 10/02/2018

Digitally signed by:

Liane Elizabeth Caldeira Lage

Director of Patents, Computer Programs and Topographies of Integrated Circuits

1/54

Invention Patent Descriptive Report for NETWORK-BASED SOFTWARE EXTENSION DISTRIBUTION METHOD.

TECHNICAL FIELD [001] The present invention relates to methods and systems for providing software over a network. More specifically, the invention relates to network-based software distribution. BACKGROUND OF THE INVENTION [002] Installing traditional PC applications requires a physical medium, such as a disk or CD-ROM, that must be physically inserted into a computer in order for the software to be loaded onto a user's computer. Typically, this process requires the user to enter configuration information that can be confusing to the user. Once the software is installed, it is typically fixed in terms of its location and functionality. When the software is updated, the user typically must purchase additional physical media and repeat the installation process so that they can use the updated software. In this model, the software is fixed in its association with the computer on which it was installed. If a user moves to another computer, he will not be able to use the specific software on his machine without repeating the installation process.

[003] As computing continues to develop within the environment of computer networks such as the Internet, it becomes clear that the traditional software distribution model described above is inadequate to meet the demands of consumers who want dynamic, flexible and adaptable software on demand. Network-based software distribution is becoming the subject of increasing focus by those who develop and distribute software. The opening of the potential in relation to the distribution of

Petition 870170015211, of 03/09/2017, p. 3/64

2/54 network-based software will require smart, innovative and dynamic solutions, especially in situations where bandwidth may be limited.

[004] Consequently, the present invention arose from the interests associated with providing new models of software distribution that are particularly well suited for network-based software distribution, for example, distribution via the Internet. SUMMARY OF THE INVENTION [005] Methods and systems for network-based software distribution are described. In one embodiment, an application program or software platform resides on a client. The program or platform is configured so that it is extensible based on the software extensions that can be distributed over a network such as the Internet. Several extensions can be developed by third-party developers for incorporation into the program or platform.

[006] In a described mode, the extension files that comprise a software extension are hosted on a network server such as an Internet server. These include descriptor files that describe aspects of the software extension. These descriptor files logically describe an extension for the program or platform and designate the location of other extension files. Extensions are incorporated into a client by browsing along a private network or Internet location through which the extensions can be accessed. The files describing the extension files are transferred by the client. These files tell the customer where, when and how the particular extension can be linked to the program or platform, as well as where to find the appropriate extension files and how to download them. The extension files are then transferred and incorporated within plaPetição 870170015211, of 03/09/2017, p. 4/64

3/54 taforma.

[007] In one embodiment, an inventive software architecture is provided to manipulate and consolidate the particular types of descriptive files associated with the various extensions. A filtering mechanism called connection points is used to create the handlers for the different descriptive types of files that define a software extension. Each of these handlers is known as a connection manager. Connection managers are provided for each type of extensible aspect. The connection managers interpret the data in the extension files that are provided by the connection points. In addition to the predefined connection managers, custom connection managers can be created using data from the connection points. When an extension extends a particular aspect type, the connection points ensure that only the appropriate connection manager is notified, so that the aspect type can be incorporated into the program or platform efficiently. BRIEF DESCRIPTION OF THE DRAWINGS [008] Fig. 1 illustrates a high level view of a system that can be used according to a described modality.

[009] Fig. 2 illustrates an illustrative computer system that can be used according to the described mode.

[0010] Fig. 3 illustrates a diagram of an illustrative EDF and PKG according to a described embodiment.

[0011] Fig. 4 shows a part of an EDF according to the described mode.

[0012] Fig. 5 shows a part of an EDF scheme according to the described mode.

[0013] Fig. 6 shows a part of a PKG according to the described mode.

Petition 870170015211, of 03/09/2017, p. 5/64

4/54 [0014] Fig. 7 presents a block diagram illustrating how hashes (invalid information) of files can be used to establish the version according to a modality.

[0015] Fig. 8 presents a block diagram that illustrates two illustrative package objects according to a modality.

[0016] Fig. 9 illustrates a flowchart that describes the steps in a method according to a described modality.

[0017] Fig. 10 illustrates a flow chart that describes the steps in a method according to a described modality.

[0018] Fig. 11 presents a block diagram that illustrates an illustrative package manifest creation tool according to a described modality.

[0019] Fig. 12 illustrates a flow chart that describes the steps in a method according to a described modality.

[0020] Fig. 13 illustrates a flow chart that describes the steps in a method according to a described modality.

[0021] Fig. 14 illustrates a flowchart of the steps in a method according to the described modality.

[0022] Fig. 15 illustrates a flow chart of the steps in a method according to the described mode.

[0023] Fig. 16 illustrates a part of an illustrative catalog structure according to the described mode.

[0024] Fig. 17 illustrates a block diagram of a software architecture according to the mode described.

[0025] Fig. 18 illustrates a flow chart of the steps in a method according to the described mode.

[0026] Fig. 19 presents a diagram that illustrates an aspect of the connection point architecture according to the described modality. [0027] Fig. 20 presents a diagram that illustrates an aspect of the architecture of Fig. 17.

Petition 870170015211, of 03/09/2017, p. 6/64

5/54

DETAILED DESCRIPTION OF THE PREFERRED MODE

Overview [0028] The methods and systems described below provide a mechanism by which functionality can be added dynamically to an application program or software platform. The functionalities or “extensions”, as will be mentioned, can be advantageously added via a network such as the Internet. Extensions, which can implement new features or add to existing features, can be added using only a network address, such as a URL, as a basis for installing the extension. That is, all files that include an extension can be kept on the network and accessed via one or more network locations.

[0029] Extensions can be described in several ways. One mode uses a hierarchical brand-based language that facilitates the manipulation and use of various extensions. In a particular implementation, a software platform is provided, which can incorporate several features. The software platform and the inventive architecture described below allow third and fourth party developers to develop extensions for the platform that can be easily and directly incorporated into the platform without having any knowledge (or relationship with) a hosting service. A third party developer is a developer who develops an extension for the platform. A fourth-party developer can be a developer who develops an extension for a third-party developer extension. Therefore, incorporating third and fourth party extensions is essentially a transparent process, until developers are interested.

[0030] Consider, for example, Fig. 1, which shows CompuPetition 870170015211, of 03/09/2017, p. 7/64

6/54 of a user 100 and several so-called extension sources 102, 104 and 106. Extension sources can comprise any entity from which a software extension can be obtained via a network. In an illustrative implementation, the network can comprise the Internet, although other networks (for example, LANs and WANs) can certainly be used. Extension sources can include, without limitation, commercial entities, such as retail stores, that can maintain a network location. In an implementation, a user can run the software on his computer that provides an application program or software platform. In this document, the terms "application program" and "software platform" will be used interchangeably. Each of the different extension sources 102 to 106 can provide software extensions that can connect within the software platform that is running on the user's machine. These extensions can be distributed via a network such as the Internet and help provide applications that can be run on the user's machine. In the described mode, the extensions are logically described in XML, which is in line with the emerging industry standards. Additionally, the use of XML helps in the ability to discover extensions in the future by promoting the properties of XML DOM on the Internet. However, it will be appreciated that any suitable format can be used to describe the extensions, for example, a binary description could be used.

[0031] Extensions can be distributed from any number of different extension sources. The inventive methods and systems provide a direct and organized way to manipulate the extensions provided. The advantageous use of XML allows the efficient manipulation of extensions from several different extension sources, without unduly taxing the software components 870170015211, from 03/09/2017, p. 8/64

7/54 tware that use specific parts of an extension or extensions. [0032] In a particular implementation, the software platform on the user's machine provides several different integrated functionalities that allow a user to perform different tasks centered on the document. An illustrative system is described in the United States Patent Application entitled “Single Window Navigation Methods and Systems”, incorporated by reference above.

ILLUSTRATIVE COMPUTER ENVIRONMENT [0033] The modality described below can be used in connection with various computer systems. A computer system, for the purposes of this document, can be considered as any computing device that includes some type of processor, that is, a microprocessor and some type of operating system. Therefore, a computer system can be constructed to include, without limitation, traditional desktop computers, more powerful servers, various handheld devices such as cell phones, pocket computer devices and the like.

[0034] Fig. 2 presents an illustrative computer system that can be used to implement the modalities described here. Computer 130 includes one or more processors or processing units 132, system memory 134 and bus 136 that couples various system components including system memory 134 with processors 132. Bus 136 represents one or more of any one of the various types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or site bus using any of a variety of bus architectures. System memory 134 includes read-only memory (ROM) 138 and random access memory (RAM) 140. An entry system Petition 870170015211, 03/09/2017, p. 9/64

8/54 da / basic output (BIOS) 142, containing the basic routines that help to transfer information between the elements inside the computer 130, such as during startup, is stored in ROM 138.

[0035] Computer 130 additionally includes a hard disk drive 144 for reading and writing next to the hard disk (not shown), a magnetic disk drive 146 for reading and writing next to a removable magnetic disk 148 and a drive optical disc 150 for reading and writing to a removable optical disc 152, such as a CD-ROM or other optical medium. Hard disk 144, magnetic disk 146 and optical disk 150 are connected to bus 136 by a SCSI interface 154 or some other appropriate interface. The units and their associated computer-readable media provide non-volatile storage of computer-readable instructions, data structures, program modules and other data for computer 130. Despite the illustrative environment described here employing a hard disk, a removable magnetic disk 148 and a removable optical disk 152, should be appreciated by those skilled in the art that other types of media that can be read by a computer that can store data that are accessible by a computer, such as cassettes Magnetic cards, flash memory cards, digital video discs, random access memories (RAMs), read-only memories (ROMs) and the like, can also be used in the illustrative operating environment.

[0036] A series of program modules can be stored on hard disk 144, magnetic disk 148, optical disk 152, ROM 138 or RAM 140, including an operating system 158, one or more application programs 160, others program modules 162 and program data 164. A user can enter commands

Petition 870170015211, of 03/09/2017, p. 10/64

9/54 and information on computer 130 via input devices such as a keyboard 166 and a pointing device 168. Other input devices (not shown) may include a microphone, joystick, gaming platform, satellite antenna, scanner, or the like. These and other input devices are connected to the processing unit 132 via an interface 170 that is coupled to the bus 136. A monitor 172 or other type of display device is also connected to the bus 136 via an interface, such as a 174 video adapter. In addition to the monitor, personal computers typically include other peripheral output devices (not shown) such as speakers and printers.

[0037] Computer 130 normally operates in a network environment using logical connections to one or more remote computers, such as a remote computer 176. Remote computer 176 can be another personal computer, a server, a router, a PC in network, a non-hierarchical network device or another common network node and typically includes several or all of the elements described above relating to computer 130, although only one memory storage device 178 has been illustrated in Fig. 2. The logical connections described in Fig. 2 include a local area network (LAN) 180 and a wide area network (WAN) 182. Such network environments are common in offices, on corporate computer networks as a whole, on intranets and on the Internet .

[0038] When used in a LAN network environment, computer 130 is connected to LAN 180 through a network interface or adapter 184. When used in a WAN network environment, computer 130 typically includes a modem 186 or another device for establishing communications over the wide area network 182, such as the Internet. Modem 186, which can be internal

Petition 870170015211, of 03/09/2017, p. 11/64

10/54 or external, is connected to bus 136 via a serial port interface 156. In a network environment, the program modules described in relation to personal computer 130, or parts of them, can be stored on the storage device of remote memory. It will be appreciated that the network connections shown are illustrative and other devices to establish a communications link between computers can be used.

[0039] Generally, the data processors of computer 130 are programmed using instructions stored at different times on the various storage media that can be read by the computer's computer. Programs and operating systems are typically distributed, for example, on floppy disks or CD-ROMs. From there, they are installed or loaded into the computer's secondary memory. Upon execution, they are loaded at least partially into the computer's primary electronic memory. The invention described here includes these and several other types of storage media that can be read by a computer when such media contains instructions or programs for implementing the steps described below in conjunction with a microprocessor or other data processor. The present invention also includes the computer itself when programmed according to the methods and techniques described below.

[0040] For purposes of illustration, programs and other executable program components such as the operating system are illustrated here as separate blocks, although it is recognized that such programs and components reside at various times in different computer storage components and run by the computer's data processors.

EXTENSIONS [0041] An “extension”, as used in this document, will be

Petition 870170015211, of 03/09/2017, p. 12/64

11/54 considered to include, without limitation, the functionality and content of the software that can be added to an application program or software platform. These additions typically provide some type of functionality that the application program may not have had before the extension was incorporated, or alter the behavior of at least one existing aspect. The extension is incorporated or integrated directly into the application program in a way that changes, to some degree, the way in which the application program behaves or operates. Extensions provide dynamically added content and can provide applications (such as an email application), helper programs to extend existing applications (such as a fax helper program for an email application), or simply web pages, to list some.

[0042] In the described mode, the extensions are described using XML, a text-based markup language, industry standard. XML highly facilitates the extensibility of software content. Specifically, several extensions can be authored by third parties and described in XML in a way that allows the extension to be readily integrated into application programs. However, it should be appreciated that XML is only an illustrative way of describing and using extensions. Other modes, of course, can be used.

ILLUSTRATIVE ORGANIZATION OF THE EXTENSION [0043] In the described mode, the extensions are organized in three separate but related parts: an Extension Definition File (EDF), a Package Manifest (PKG) and the code, components, or “bits” that constitute or define the extension. An EDF can, but need not, be associated with a URL (Universal Resource Locator), which provides a way for a customer to access

Petition 870170015211, of 03/09/2017, p. 13/64

12/54 the EDF. By convention and choice, the PKG file is located at the same URL as the EDF. It will be appreciated that each of the EDFs and PKGs described are not required for the other to be used. It turns out that in the example given in this document, the two are employed together. To this end, each of these aspects can be employed separately and independently.

[0044] EDFs describe logical links to an application program or software platform, while PKGs specify the physical files and resources that are used in an extension. There may be a one-to-one correspondence between EDFs and PKGs.

[0045] Fig. 3 shows an illustrative organization 300 that includes an EDF 302 and a corresponding package manifest (PKG) 304. In the illustrated example, EDF 302 uses XML to describe the logical links or extensions with an application program. The corresponding PKG 304 specifies the physical files and resources that are associated with a particular extension. Illustrative file types are shown to the right of PKG 304 and include, without limitation, HTM, GIF, UDO, XML, DLL and several other file types.

EXTENSION DEFINITION FILE (EDF) [0046] In the example described, an EDF is an XML file that logically describes an extension. For example, EDF can describe the HTML that constitutes a user interface (UI), objects that contain code to implement various functions and the like. EDF can also contain all or part of the functionality that comprises an extension. For example, HTML describing a toolbar could be incorporated directly into an EDF file and a toolbar link manager could read it from the EDF file, rather than from a URL. The information contained in the EDF is processed and (together with the information

Petition 870170015211, of 03/09/2017, p. 14/64

13/54 contained in the PKG) the appropriate files are automatically installed on a user's computer. This is done privately without manipulating the computer's persistent settings, as seen in the user's system registry.

[0047] An EDF, implemented in XML, contains several tags that are associated with several extensions. The various brands may correspond to:

[0048]. User interface elements. Behaviors / Components / Objects [0049]. Storage elements [0050]. User-defined objects [0051]. Or anything else that represents a point of extensibility in the application or platform.

[0052] EDFs advantageously have an “open scheme”, which means that third party developers can extend the extension mechanism and include their own extensions by creating their own brands. Additionally, the extensions can themselves be extended by other developers. EDFs can also have one or more predefined brands. Illustrative predefined XML tags for user interface elements can include tags for aspect types such as: toolbars, accelerators, menu items and themes. These types of aspects are used in the single navigable window application incorporated by reference above and defined in the table immediately below:

Aspect Type Definition Toolbars Horizontal control vessels above the document area Accelerators Keyboard shortcuts for commands Menu Items Instant or pop-up menu choices

Petition 870170015211, of 03/09/2017, p. 15/64

14/54

I think (drop-down) that third parties can add next to the so-called well-known menu on the platform Themes A data-driven way to provide overlays for well-known features of the platform, such as standard buttons or pre-established style

Table 1 [0053] Predefined XML tags for behaviors / components / objects include tags for Services. These types of appearance are used in the single navigable window application incorporated by reference above and defined in the table immediately below:

Aspect Type Definition services Services are objects that extend existing objects (such as the application, window, or document) in the Object Model of the application or platform. For example, editing functions use the Object Model Links linked with the window or with the document that maintains the document context and editing status per window. These can also include Object Model linked to the application (such as as a spelling checker dictionary object)

Table 2

Petition 870170015211, of 03/09/2017, p. 16/64

15/54 [0054] Illustrative predefined XML tags for storage elements include tags for content classes and offline data sources. These types of aspects are used in the single navigable window application incorporated by reference above and defined in the table immediately below:

Aspect Type Definition Content Classes Enables extension writers to define new types of XML documents with new schemas Outside Data Sources of line Allow extension writers to define storage replication instructions at an EDF.

Table 3 EDF SCHEME [0055] In the described mode, EDFs have a particular XML schema that is used. The scheme comprises collections of XML tags that are arranged in a hierarchical organization to facilitate the dissemination of information to software components that need certain extensions. In the modality described, the external (comprehensive brand) for EDFs is an “extension” brand. [0056] Fig. 4 shows an illustrative extension mark. The “extension” marks can include one or more of the following attributes, all of which are optional:

Attribute Definition Urn ID for the extension. It allows writers extension agents specify relative locations for content on EDFs without using relative paths or fixed URLs. It also allows

Petition 870170015211, of 03/09/2017, p. 17/64

16/54

hosting administrators to move around extensions on servers without interrupting any links. Name Name that can be used in a bar status or message display Version Vendor-determined version number for the extension Last update Date / Time the EDF was modified by last time description Brief description of the extension.

Table 4 [0057] Within the external “extension” brand are one or more child brands, also referred to as “higher level brands”. These top-level marks are each associated with a type of appearance that can be added by a particular extension. Illustrative aspect types are discussed in connection with Tables 1 to 3 above. Below each top level tag there may be one or more child tags that are individually associated with a particular aspect of the type of aspect that is to be added by a particular extension.

[0058] Fig. 5 presents an organization of the illustrative XML schema according to this modality. For each top-level brand in an EDF, there is an associated link manager that is a software component that receives data associated with the brand so that the data can be used to incorporate the extension into the platform or application program. Different link managers can interpret the data from the tag in different ways to provide different types of extensibility, so that different higher-level tags will contain different types of data in different structures. This will become

Petition 870170015211, of 03/09/2017, p. 18/64

17/54 more evident in the “Architecture” section below. Note that the “edf:” namespace qualifier allows support for an open scheme where extensions can provide their own brands and the corresponding liaison managers. The marks within the edf space name are used by the connection managers embedded in the application or software platform. Tags in other namespaces are used by third parties to provide additional extensibility points.

PACKAGE MANIFEST (PKG FILE) [0059] Package manifests (PKGs) help organize the transfer of software in the form of multiple files over a network such as the Internet. PKGs are advantageously employed, in the example given in this document, with EDFs. As noted above, however, the techniques discussed in connection with PKGs can be deployed independently of EDFs and in any suitable scenario where it is desirable to distribute software over a network such as the Internet. While EDFs describe the logical connection of extensions within an application program or platform, the role of the package manifest is to assist in one or more of: organized distribution, validation and / or updating of the files associated with the various extensions that can be proportionate.

[0060] When designing a distribution mechanism for network-assisted distribution of software content or files, several considerations are of interest.

[0061] Whenever possible, it is desirable to reduce the size of the transfers required during the update and installation operations. To address this consideration, the content of the software is broken into several packages. Each package contains a group of one or more files that implement common functionality or

Petition 870170015211, of 03/09/2017, p. 19/64

18/54 defined. By breaking the content into individual packages, the download size required during installation and upgrade can be minimized. Each package is then described by a package manifest (PKG) that includes information about the file such as file locations and values of invalid information that can be used for validation or security and versioning. [0062] It is also desirable to provide the end user with a Network-like experience. To do this, the extensions are loaded in a way that gives a user the impression that he is loading a web page, rather than the traditional software packages where the user has to wait until the entire package is loaded before he can interact with it. In the described mode, the user is given a network-like experience by continuously streaming (streaming) extension files to the client so that a user starts interacting with an application program much earlier than if he had to wait for the entire software application program is loaded. For example, if there are user interface (UI) image files flowing continuously to the client, the user can see the UI as the files flow. Consider, for example, the single application program having the various different functionalities that is described in the patent application incorporated by reference above. A user can navigate to an email functionality and transfer the files that are needed to interact with the email functionality. The files that are associated with another different functionality would then be transferred after the files associated with the email functionality. In this way, the user can start operating within a particular functionality without having to wait for all files associated with all other functionality.

[0063] Another consideration of interest is related to efficiency with

Petition 870170015211, of 03/09/2017, p. 20/64

19/54 to which the extension files or “bits” are distributed to the client. To address this consideration, the modality described uses a couple of different approaches: a controlled transfer and a background transfer. Controlled transfer leads to transfer operations while taking into account the available bandwidth and the type of media over which files are being transferred. Any suitable controlled transfer process can be employed and will be understood by those skilled in the art. Background transfer is carried out while the user is working within the application program and is implemented by allocating a background chain, so that the user can continue his work. An optimization that is used is that packages are prioritized and distributed according to what a user may be working on.

[0064] Another consideration is associated with the optimization of the user's computing experience. Here, the user experience is optimized by making the most common scenarios available to the user. This is effectively aimed at providing the user with the functionality he wants first and then, through the background transfer process, providing the code that implements functionality that the user can use in the future. To determine which features a user wants to have first, an automated scenario-based packaging process is provided, which works against the file usage records of the documented scenarios.

[0065] All of these considerations and inventive solutions aimed at addressing the considerations are discussed in detail in the section below.

DEFINITION OF THE PACKAGE MANIFESTO [0066] In the described mode, a package manifest (file

Petition 870170015211, of 03/09/2017, p. 21/64

20/54

PKG) comprises a list of files that are used in a package. The list is advantageously something compacted and digitally signed. Each package manifest can contain a list of one or more files, each of which can include an associated hash, as well as transfer policies that control the capture of the files. Once an extension is authorized, a software tool can be used to generate the package manifest.

[0067] In addition, the package manifest can specify several other pieces of information.

FILE GROUP [0068] All files in an extension can be labeled according to a series of predefined file groups. The filegroup of a private file determines when the private file was transferred, where it is stored on the client, and how it was packaged. In the described mode, four groups of predefined files are provided and are listed and described in the table immediately below:

Name of Group When was it Transferred Where is it stored in client Packaging to Content Required Downloaded before any other files in the extension Cache package NetDocs All required files to an extent are empha- quoted together as a CAB file * DLLs included so that a user will not have to wait for a prolonged period

Petition 870170015211, of 03/09/2017, p. 22/64

21/54

cattle of time before to click an element UI Offline Files out lines start to be transferred as soon as required are transferred. As long as users stay connected for time enough, all of these files will be transferred and posteriorly will be available to the offline use. cache of package NetDocs File is transferred individually Majority of UI files Under sends Only transferred when they are required for the first time cache of package NetDocs Files are transferred individually To avoid use a lot space in disk on the client, features

Petition 870170015211, of 03/09/2017, p. 23/64

22/54

advanced features can be placed in this category Only Online Transferred on demand. The content just stay available when the user is logged in. Wi- cache nlnet Files are transferred individually Content that is not to be provided offline. Examples include help pages and other content that can consume a large amount of disk space.

* CAB stands for CABinet technology that the Internet

Explorer uses to package bits for transfer. CAB files range from 2 to 3: 1 compression and are optimized for rapid expansion. CAB files have the added security benefit by which they are easily signed.

FILE TRANSFER PRIORITY [0069] The files in each group are listed according to the order in which they are to be transferred. This transfer order is implicit in the ordering of files in the package manifest,

Petition 870170015211, of 03/09/2017, p. 24/64

23/54 whose example is shown in Fig. 6.

HASH VALUE FOR SECURITY / VERSION ESTABLISHMENT [0070] Individual files in the package manifest may have an associated hash value. Each hash value is generated by running the file through an encryption algorithm. An illustrative encryption algorithm is Microsoft's CryptoAPI. In the illustrated example, each file can be listed with a base 64 encoded hash value, so the file can be validated once the content arrives at the client. Specifically, the package manifest is sent to the client in a secure manner (that is, it is digitally signed). The package manifest contains the hash values for the individual files. When the individual files are received by the client, each file can be executed using the same CryptoAPI that was used to provide the hash values in the package manifest. If the hash values for a particular file compare favorably, then the file has not been changed and is safe.

[0071] When a file is updated, hash values can serve a useful purpose when identifying files that have not been changed between different versions of an extension. For example, consider Fig. 7. There, an old directory 700 in a client package cache contains package A which includes two files - file 1 with hash = x and file 2 with hash = y. Assume that this package is associated with an older version of an extension. When an updated version is produced, your package manifest is distributed to the customer. The version of the updated extension is represented in a source directory of a code or 704 network server. The package manifest includes hash values for all files in the new version of the extension. A new 702 client destination directory is defined for all files in the new extension. If any of the vaPetition 870170015211, of 03/09/2017, p. 25/64

24/54 hash files for files in the new extension is the same as the hash values of files in old directory 700, so files can be copied directly from old directory 700 to the new destination directory 702. In this example, the hash value of file 1 is the same as the hash value for file 1 in the source directory 704, so it can be copied into the new destination directory 702. The hash value of file 2, however, is different from the hash value for file 2 in the source directory, so it is not copied from the old 700 directory. Instead, file 2 is transferred from the code server. A new file 3 has been added and is also downloaded from the code server. Consequently, in this example, a new version of an extension resulted in a transfer of less than all files in the extension version. This is because the hash values for each of the files in the old version of the extension were able to be compared to the hash values of the files in the new version of the extension. These hash values that are the same indicate that the files have not been changed between versions.

[0072] Using hash values for versioning has two important advantages over traditional versioning schemes. First, the update process is automatic. That is, with an explicit version number, it is possible to forget to update the version number when dispatching a new version of a file. Using hash values avoids this problem. Second, versioning does not rely on file types. Specifically, traditional versioning schemes usually embed version information within files; however, not all files (for example, GIF files) support the built-in version information. In the present example, the use of hash values to establish the version does not depend on whether a particular file type supports or

Petition 870170015211, of 03/09/2017, p. 26/64

25/54 does not support information about the embedded version. In addition, the version information can be stored separately from the file itself. Therefore, access to the actual file to determine whether it is current is not required.

TOTAL PACKAGE STORAGE SIZE [0073] The total storage size of a package is useful at the time of transfer to verify that the user has sufficient disk space.

CLASS IDS FOR DLLs [0074] Listing the Class IDs for each DLL is necessary to allow script writers to create undocumented classes in relation to OM. In addition, this allows a determination of which package contains the code for a particular class. DLL LOAD DEPENDENCE [0075] The reason for the dependency sections is to allow legacy code that is expected to be transferred due to being in the search path of some other dll. In this case we have to make sure that the dependency dll is in the package cache directory before the dependent dll is loaded. Fig. 6 presents an illustrative package manifest 600 that is defined in a hierarchical brand-based language. Advantageously, the brand-based language comprises XML that is desirably extensible and flexible. In this example, a series of marks are provided in a hierarchical arrangement. The “package” tag contains information about the size of the package. The “files” tag is a child of the “package” tag and contains information about the file groups that are contained in this particular package. The "file" tag is a child of the "group" tag and contains information about specific files that comprise the extension, that is, the file name and hash value. A “dependency” brand is provided as a child of

Petition 870170015211, of 03/09/2017, p. 27/64

26/54 marks “file” and lists any dependencies as discussed above. A “COMCIass” tag is also provided as a child of the “file” tag and contains the IDs as mentioned above. The ordering of filegroups in this scheme implicitly defines the order in which files are transferred.

PACKAGE DISTRIBUTION [0076] To optimize package distribution, two different distribution schemes are used. First, a regulated transfer approach is used using known regulated transfer techniques. Here, considerations such as available bandwidth and the medium over which the extensions are being provided are considered.

[0077] Second, a way of approaching background transfer is used. Background transfer allows a user to continue working within an application program while the content is being transferred. Foreground transfers are used when the user explicitly requested a file / extension by clicking, for example, on an extension link, or requested an action, for example, by clicking on the “Compose” mail button, which requires transferring files that are not available locally.

[0078] Along with background transfers, an aspect of queue management is provided. Specifically, when an extension must be installed or updated, a package manager, which is essentially a software component that manages packages, is provided with the following information:

[0079]. URL for the package manifest information on a code server [0080]. URN for the package destination directory in the package cache on the client

Petition 870170015211, of 03/09/2017, p. 28/64

27/54 [0081]. (Optional) URN for the old package directory (if one exists) in the package cache [0082] From this information, the package manager creates a package object and adds the package object to a transfer queue. The transfer queue is designed for easy reordering of a package transfer order. Consider, for example, Fig. 8, which presents a part of a transfer queue 800 that contains two packet objects - the packet object 802 (corresponding to packet A) and the packet object 804 (corresponding to packet B). Package objects maintain a list of which files in a corresponding package have been downloaded or installed. In the present example, files 1 and 2 in package A were installed while file 3 was not installed; and files 1, 2 and 3 were not installed from package B. The transfer queue can be laid out again based on what the user is doing. That is, based on the actions a user takes, the priority of the files that are to be transferred can be changed. In this example, the package manager is designed to process the first file not installed in the package in the transfer queue header. If, however, the user starts using a file in an extension that is different from the extension whose files are in the transfer queue header, the corresponding package for the file that the user started using can be moved to the queue header transfer. Because a file package is specified by its URN, the file package can be quickly identified and located in the transfer queue. For example and considering Fig. 8, if one of the files in package B is requested before the package manager has started installing the third file in package A, then package B will be moved to the transfer queue header.

[0083] Fig. 9 illustrates a flow chart that describes the steps in

Petition 870170015211, of 03/09/2017, p. 29/64

28/54 a transfer queue management method according to the example described. The method can be implemented on any appropriate hardware, software, firmware or combination thereof. In the present example, the method is implemented in software.

[0084] Step 900 receives one or more requests for an extension. Requests can be generated in any suitable way. Step 902 creates a package object that corresponds to each extension package that must be transferred. Step 904 arranges the package objects in a transfer queue. Step 906 then transfers the files corresponding to the package objects in the transfer queue. This step can be implemented, for example, by starting at the header of the transfer queue and transferring the files until all files for a package object have been transferred and then moving to the next package object. Step 908 checks whether a user action requires a file that is not described in the current package object. If the user action does not require a file not described by the current package object, then the method branches back to step 906 and continues to transfer files associated with the current package object. If, on the other hand, the user's action requires a file that is not described in the current package object, then step 910 moves the package object associated with the required file to the transfer queue header and begins to transfer the files associated with the most recently repositioned package object. This step can be implemented by checking which package object is associated with the file required by checking the URN associated with the file. This URN specifies the file package so that its package object can be quickly located and moved to the front of the transfer queue.

PACKAGE CREATION [0085] One of the innovative aspects of the described mode is its

Petition 870170015211, of 03/09/2017, p. 30/64

29/54 extensibility. That is, a software platform is provided in the form of an application program that can be extended by several extensions defined by third-party users. These extensions are distributed via the Network and are integrated directly within the software platform. In order to provide an organized distribution process, packages must be created in a uniform manner so that they can be manipulated in a predictable way and integrated within the software platform.

[0086] According to the described mode, each package must correspond to an end user aspect. For example, in the patent application incorporated by reference above, separate packages are provided for each of the email, contact, document authoring and planner functionality. If packages that do not depend on each other share a dependency, then this shared dependency must become its own package. For example, there is no reason why e-mail and document authoring functionality should depend on each other, even though both require the ability to publish content. By separating the publishing functionality into its own package, a certain amount of flexibility in the transfer order is preserved. Depending on what the user starts to work on, files corresponding to the email or document authoring functionality can be transferred first.

[0087] Fig. 10 illustrates a flow chart that describes the steps in a package creation method according to the example described. The method can be implemented on any appropriate hardware, software, firmware or combinations thereof. Parts of the method, however, can be implemented manually.

[0088] Step 1000 identifies the aspects of the end user that are to be provided as extensions. Step 1002 identifies

Petition 870170015211, of 03/09/2017, p. 31/64

30/54 any dependencies shared between the end user aspects. Step 1004 creates individual packages for the end-user aspects. Step 1006 creates individual packages for any dependencies shared between aspects of the end user.

AUTOMATED PACKAGE MANIFESTO CREATION TOOL [0089] Advantageously and according to an implementation, an automated package manifest tool is provided and takes various input parameters and automatically creates a package manifest. The tool may be available to third parties to assist them in creating a package manifest.

[0090] Fig. 11 presents an illustrative package manifest creation tool 1100 that is desirably implemented in software. In this specific example, the tool can take the following input parameters (some of which are optional): [0091]. Extension Directory [0092]. Information about the file group and DLL load dependency (Optional) [0093]. File usage statistics from the scenario's operations (Optional) [0094] The directory input parameter of the extension specifies the directory containing all files that will be described by the package manifest. If this is the only parameter, then the 1100 tool will generate a manifest in which the EDF and the DLLs in the directory are listed in the “Required” parameter and all other content is “Offline”. [0095] Information about the file group and the load dependency parameter is optional. If an extension author has an idea of the categories in which their files should be placed, the categories should be specified here. For example, the author of the model manifest presented below knows that he wants his maPetition 870170015211, of 03/09/2017, p. 32/64

31/54 GIF error nipulation is included in the required parameter of the package. Your choices here will always be respected in the final manifest. Additionally, if the author of the extension knows of any DLL load dependencies, they must also be specified here.

<? xml version = ”1.0”?>

<Package>

<Files>

<Group Name = “required”>

<File Name = “bar.dll” />

<File Name = “foo.dll” />

<Dependencies>

<File Name = “bar.dll” />

</Dependencies>

</File>

<File Name = “myextension.edf 7>

<File Name = “errorhandling.gif *>

</Group> ...

</Files>

</Package>

[0096] File usage statistics from the scenario's operating parameter is an optional parameter. This parameter allows the file transfer priority to be determined based on the execution of the scenario. A scenario is a task script that the average user typically follows when using a product during a particular part of using the product. For example, a scenario should be related to the tasks involved when sending an e-mail message (for example, clicking the “new e-mail” button, typing correctly in “TO”, typing correctly in “Subject”, etc.) . In the described mode, the statistics of the use of the file from the operations of the scenario are collected from the IIS records of functioning in the various scenarios. Different scenarios are designed to ensure, with some degree of probability support, that the file transfer order reflects, in some way, the files that are likely to be used by the user first.

Petition 870170015211, of 03/09/2017, p. 33/64

32/54 [0097] It will be appreciated that file usage statistics can be provided dynamically by building a knowledge base that describes the real tasks that people typically perform. The information that is maintained in the knowledge base can then be used to generate and adapt the transfer scenarios that actually conform to standards that are established through the user base.

[0098] If extension writers wish to pass this information to the 1100 package manifest creation tool, they need to specify the registry directory, as well as the start and end dates of the registry section that the tool should analyze. For third parties, the order of priority of the transfer within a group will be the order in which the files of the group were requested in the records across all scenarios.

[0099] In an implementation, the approach is a little more sophisticated. Additional information (in addition to the steps described) is stored in the I IS records and includes the priority and checkpoints of the scenario. The scenario priority is a priority that is assigned to each scenario. So, for example, if a scenario is ten times more important than another scenario, this information can be maintained. The priority (for example, a rating between 1 and 100, with 100 being the highest priority) should equal a better guess as to the percentage of time that users will walk through the scenario, assuming that they in no way use the extension. Checkpoints provide a way to separate one scenario from another. For example, checkpoints designated as “Off-Line” and “Off” can be automatically added at the beginning and end of the scenarios, respectively, so that there may be a difference between the executions of the scenario in the activity log. Additionally, script authors can

Petition 870170015211, of 03/09/2017, p. 34/64

33/54 optionally use the average checkpoint scenario to indicate a change in group priority, for example, part of a scenario script could be labeled as an “On Demand” aspect and another part could be labeled “Off- Line ”.

[00100] Fig. 12 illustrates a flow chart that describes steps in a method of creating a package manifest according to the example described. The method can be implemented on any appropriate hardware, software, firmware or in combination. In the example described, several steps of the method are implemented by a manifest creation tool that is implemented in software.

[00101] Step 1200 provides a package manifest creation tool. This tool can be a software tool that resides on an extension author's machine. Step 1202 receives information about an extension directory as a first input parameter. The step determines whether there is any information about the file group or information about load dependency provided by the author of the extension. If it exists, step 1206 receives the information as an input parameter. Step 1208 determines whether there is any information on file usage statistics. Such information can be provided, in a modality, through the use of scenario executions as described above. If such information is provided, then step 1210 receives the information as an input parameter. Step 1212 then uses all the information provided as input parameters to automatically generate a manifest.

ILLUSTRATIVE FILE ORDINATION HEURISTICS BASED ON FILE USE STATISTICS [00102] Fig. 13 illustrates a flowchart that describes an orderPetition 870170015211, from 03/09/2017, p. 35/64

34/54 illustrative or heuristic file classification according to the described mode. It should be understood that this specific example is just a way of ordering files for transfer. Consequently, other heuristics can be used without departing from the spirit and scope of the claimed subject.

[00103] Step 1300 classifies files by file group. Remember that in the example illustrated above, files can be grouped into one of four possible groups: Required, Offline, On Demand and only On-Line. A filing group is determined first by the manifest and if it does not provide any group information, then by the highest priority group it uses, according to the checkpoint information in the activity log. The files in the “Required” set should not be considered because their order is already known. If no group information is included about a file, then an assumption is made that the EDF and all DLLs are "Required" files and all other files in the directory are "Offline".

[00104] Consider, for example, the following initial file usage information for three different scenarios:

[00105] Use of file of scenario 1: 1) FileA.gif, 2) FileB.xml, 3) FileE.dll [00106] Use of file of scenario 2: 1) FileC.xml, 2) FileA.gif [00107 ] Use of scenario 3 file: 1) File.js, 2) FileA.gif [00108] Scenario 1 = priority 80 [00109] Scenario 2 = priority 80 [00110] Scenario 3 = priority 40

Petition 870170015211, of 03/09/2017, p. 36/64

35/54 [00111] In this example, there are three scenarios that have files associated with them. Each scenario has a priority with which it is associated. The files are first classified by group (step 1300). Remember that in this sorting heuristic, DLLs are "Required" and all other files are considered "Off-Line". This provides the following classified files:

REQUIRED FILES

File E

OFF-LINE FILES [00112] File A, File B, File C, File D [00113] Step 1302 classifies files based on scenario priorities (from highest to lowest). The highest priority files are ordered so that they are transferred first. This step provides the following classified files:

Required Files

Archive E Offline Files [00114] Priority group 80: files used by Scenarios 1 and 2 = File A, File B and File C [00115] Priority group 40: files used by Scenario 3 (which are not already listed) = File D.

[00116] Step 1304 then sorts the files in the order in which they are used within a scenario execution. For each priority grouping with more than one file, the files are classified according to the average order in which they were transferred within the scenarios of their labeled priority. Scenarios with a lower average usage order will be transferred first. Loops are broken based on the order in which the scenarios appear in the input file. As an example, consider the following:

Petition 870170015211, of 03/09/2017, p. 37/64

36/54 [00117] File A: average order = (Order of Scenario 1 + order of Scenario 2) 12 = (1 + 2) / 2 = 1.5.

[00118] File B: average order = (Scenario Order 1) / 1 = (2) / 1 = 2 [00119] File C: average order = (Scenario Order 2) / 1 = (1) / 1 =

1.

[00120] Here, file A was used first for scenario 1 and second for scenario 2 for an average of 1.5 and so on. The C file has the lowest order number so that, of the Offline files, it is sent first. The final file order is shown below:

Required Files

File E Offline Files [00121] File C, File A, File B, File D Code, Components and “bits” [00122] The following files and resources may, but need not, be included with an extension. This list is not exclusive, as other features can certainly be incorporated within an extension.

[00123]. Custom UI and keyboard shortcuts [00124]. Components and Behaviors [00125]. XML navigation and editing components (including XSL and business logic objects) [00126]. Static Pages or other resources [00127]. Custom content defined by third parties [00128] Users install extensions by browsing to a network location for the extension. In an Internet implementation, the user navigates to an appropriate URL for the extension. Hosting administrators can also “push” extensions for

Petition 870170015211, of 03/09/2017, p. 38/64

37/54 so that users can automatically receive them by adding an entry within the “Preferences” settings of users.

PLATFORM CONFIGURATION AND EXTENSION INSTALLATION [00129] Fig. 14 illustrates a flow chart that describes illustrative steps in an extension configuration and installation process according to the described mode. This example describes an example based on the Internet. In the illustrated example, several extensions are maintained or accessible through various locations on the Internet. Extensions can be distributed via the Internet to a customer. It will be appreciated that the computer division illustrated may not necessarily exist. For example, all functionality incorporated by computers can reside on one machine, or the extension can be local, or the platform and extensions can be on the same machine, etc.

[00130] The flowchart, in this example, is illustrated in connection with three separate "zones", one of which represents a client, one of which represents a "platform" Internet server and one of which represents a third party Internet server. The actions that are described in connection with the different zones are performed, in this example, by the entities designated for the zone. In some configurations, one or more of these three zones can overlap. For example, the platform server can be the same device as the extension server.

[00131] Step 1400 navigates a user to a particular location on the Internet that is associated with the software platform that should be used as the foundation for the extension installation described below. In step 1402, the user clicks an “install” button that sends a message to the software platform server that indicates

Petition 870170015211, of 03/09/2017, p. 39/64

38/54 that a user wants to install the software platform. This step can be an optional step. Steps 1404 and 1405 then transfer the software associated with the software platform to the customer. In the illustrated example, step 1404 transfers the package file to the single navigable window application and based on the contents of this file, step 1405 transfers other components and files to the user's computer. Step 1406 installs the software code on the client machine and can create local directories for the application cache, local storage and preferences. However, it will be appreciated that local directories or preference are not necessarily necessary. Step 1408 activates the software platform.

[00132] The steps described immediately above constitute steps associated with an initial configuration in which the software code for the single navigable window application is distributed and installed on a client machine. The steps described immediately below are associated with the extension installation.

[00133] Step 1410 uses a link that is associated with an extension to access the extension. This step can be implemented by a user using his browser to a particular location on the Internet through which one or more extensions can be accessed. Alternatively, a reference to the link can be placed in the user's preferences or the preference of a computing group with which the user is associated (for example, the system administrator can place a reference in a group's preferences). The link can advantageously be associated with an Internet server or a third party's Internet location. Step 1412 transfers the extension files according to the PKG associated with an EDF. The files are distributed to the client and step 1414 places the extension files in local storage, as specified by the PKG specification. At this point, an extension is required. 870170015211, of 03/09/2017, p. 40/64

39/54 and the user can use the functionality provided by the extension. Step 1416 determines whether updates to the extension are available. This can be done by periodically searching a catalog of extensions (discussed in a "Catalog of Extensions" section discussed below) to check if there are any updates with the various extensions. Alternatively, notifications can be automatically sent to the customer so that the customer is aware of the updates or any other method can be used to determine whether updates are available. If updates are available, step 1418 branches to step 1412 which transfers the extension files associated with the update and installs them on the client.

DEVELOPING EXTENSIONS [00134] Developing extensions for the software platform is a fairly straightforward process. A developer develops the content of the extension using a tool such as Notepad or other tools such as Visual Studio. The extension is then described in an EDF and a PKG and the PKG is digitally signed and then optionally compressed. The extension can then be hosted on a private server on the network.

[00135] Fig. 15 illustrates a flow chart that describes steps in an extension development method according to the described modality. One or more of these steps can be performed by a software developer or organization that creates a particular extension. Some of the steps are implemented in software. Step 1500 develops an extension. Any suitable tools can be used to develop the extension. Step 1502 then creates an extension definition (EDF) file for the extension. EDF, in this example, is defined using XML as discussed above. Other formats can obviously be used paPetição 870170015211, from 03/09/2017, p. 41/64

40/54 to describe the EDF. Step 1504 creates a package manifest (PKG) for the extension. The PKG, in this example, is defined using XML as discussed above. Step 1506 then hosts the EDF and PKG on a network server such as an Internet server. In addition, the associated extension files that are described in the PKG can also be hosted by the network or Internet server (step 1508). Having accomplished the above, users can now navigate to an EDF directly (using, for example, the associated URL or some other network address), which then installs the extension by capturing any required files locally and by placing a reference to extension in user preferences.

[00136] Specifically, step 1510 distributes the EDF and PKG files to a customer. This step can be implemented by a user browsing to a particular location on the Internet where the appropriate files are hosted and then transferring the files. Step 1512 distributes the extension files that are associated with the EDF and PKG files to the client, after which they can be installed and used.

EXTENSION CATALOG [00137] An optimization, discussed briefly in connection with Fig. 14, is a catalog of extensions or EDFs that provides an additional level of indirect procedure for EDF. An EDF catalog allows organizations close to group extensions and provides a unique place to determine when an extension changes. The desired extension can be automatically selected from the catalog by the software platform based on user parameters. The catalog can be consulted to determine which extension is most appropriate for the user.

[00138] In the described mode, a catalog is an XML file that

Petition 870170015211, of 03/09/2017, p. 42/64

41/54 contains mappings of the extension's URNs to one or more package URNs based on language, version, or other attributes. However, catalogs can be defined using any suitable format. Catalogs can provide:

[00139]. The ability of a hosting organization to update version information for one or more extensions hosted in a single location [00140]. Optional automatic indirect procedure for the corrected version based on user parameters for different languages. For example, a catalog may list several versions of an extension for different language. The catalog file can be processed to find the version of the extension that matches the user's language parameters, [00141]. Optional automatic update for new versions of extensions as they become available.

[00142] Like EDFs, catalogs can be compressed and digitally signed to prevent counterfeiting. By subscribing to a catalog in order to detect changes to one or more hosted extensions, a series of server pings (protocol to check if computer is connected) from the client (or notifications to the client) in order to discover updates from extension can be reduced.

[00143] Fig. 16 presents an illustrative structure of the XML catalog. Catalog entries can be structured as follows:

Attribute Type Required description Extension URN uri Yes Identifier for an extension. There may be more than one entry for a given URN from extension in a single catalog

Petition 870170015211, of 03/09/2017, p. 43/64

42/54

representing different versions, languages, etc. Name Jail Not Friendly name for an extension Package URN uri Yes URN required for the package. THE Package URN corresponds to a discrete set of bits. He is different from the extension's URN: For each user, the extension URN (name) corresponds to a specific set of files based on language and version preferences. This means that, for shared machines, different users may have different URNs of different extension for URN maps of package based on your preferences. Package URL uri Yes The URL of the compressed file digitally signed containing the PKG file is required. Language Jail Not Language is a specifier optional language Version Jail Not Version is a specifier of optional version Language Standard Jail Not Standard language is an attribute optional specifying the package standard language. For given version of an extension,

Petition 870170015211, of 03/09/2017, p. 44/64

43/54

there must be only one entry with the Language attribute Standard. Standard Version Jail Not Standard Version is an optional attribute specifying the version pre-established for an extension. For a given extension URN and a given language attribute there must be only an entry with the Default Language attribute.

[00144] In this particular example:

[00145]. The standard language of netdoc-planner is the English version.

[00146]. The standard English version is 1.1. The standard French version is 1.0. If there is no version available in the user's specified language on the platform, it will take the English version 1.1 by pre-established parameter.

[00147]. The English version of netdoc-planner has been updated from V1 to V1.1.

[00148]. There is also a French version. The extension's URN is the same as the English version. There is no release 1.1 for French yet, so 1.0 is the current version for French speaking users.

[00149]. A query with the catalog returns only the lines where the language matches the user's language preferences. The query would also return all lines where the language is the user's language or the default = "yes" and rejects duplicates for the same name.

ARCHITECTURE

Petition 870170015211, of 03/09/2017, p. 45/64

44/54 [00150] In the described mode, one of the aspects that provides desirable utility is the extensibility of the software platform. That is, third and fourth party developers are free to develop their own extensions that can then be used within the framework of the software platform. Extensions are integrated directly into the software so that the functionality of the platform is modified by the extensions. Remember that in order to provide an extension, the developer simply creates the extension, describes its extension in an EDF and PKG, and then hosts the EDF, PKG and associated files on a network server. [00151] The EDF, as highlighted above, can be defined in an XML schema that includes a root node (ie, “extension” tag) and one or more child nodes. In this particular example, the child nodes generally correspond to the future types of the individual extension that are desired for incorporation within the software platform. For example, remember that Tables 1 to 3 above describe several illustrative predefined appearance types that can be added via an extension using the predefined XML schema.

[00152] Now consider that a developer wants to add two menus and a toolbar to the software platform. The menus and the toolbar can be associated with a retail store that maintains a Web site for its customers. The retail store may want a customer who visits its Web site to be presented with a UI that is unique to the retail store and provides services that are specifically built for the store. To do this, the developer develops two different menus, one of which can be associated with the display of the most recent specials and the other can be associated with providing a search engine through which the user can search for specific products. The toolbar can

Petition 870170015211, of 03/09/2017, p. 46/64

45/54 contain specific buttons that are unique to the retail store. A simplified EDF called “retail.edf” for the retail store extension is shown directly below:

<edf: extension name = “retail extension” um = “extension.retail.com”> <edf: menus>

<edf: menu url = “uri 1 .htm” />

<edf: menu url = “url2.htm” />

</ edf: menus>

<edf: toolbars>

<edf: toolbar url = “url3.htm” />

</ edf: toolbars>

</ edf: / extension>

[00153] Here, the external tag “extension” designates this XML file as an extension. The internal “menu” and “toolbar” tags are top-level tags that designate the information between these tags relative to the menus and toolbars respectively that correspond to the extensions that the developer has added. The bold "menu" and "toolbar" tags describe data relating to the actual extension and contain a URL that is associated with each extension as described above. The above EDF logically describes the extensions being provided as including two menus and a toolbar.

[00154] Also consider that the EDF above can constitute only one of several EDFs that are loaded into the system. Each EDF can contain one or more top-level tags, each of which is associated with one or more specific extensions that must be added to the software platform.

[00155] Fig. 17 illustrates a block diagram of an illustrative software architecture that is configured to process several different EDFs so that the software components that are responsible for incorporating each particular extension into the software platform 870170015211, dc 09 / 03/2017, p. 47/64

46/54 tware receives the appropriate information that is specific to its extension. This example is specific to the XML implementation that is discussed throughout this document. It should be understood that other architectures, similar in functionality to the one discussed below, can be used in other implementations without departing from the spirit and scope of the claimed subject.

[00156] Utility objects, here referred to as connection points, are used to process information from several EDFs. A connection point is simply a collection of objects that triggers events for registered listeners as objects as objects are added to or removed from the collection. Several types of connection points can be created, but all take data from a source (often another connection point), process it (dynamically or statically) and display the results of its processing. Some of the simplest connection points include: [00157]. An XML connection point, which loads an XML file and exposes the topmost XML nodes as objects in your collection.

[00158]. A filter connection point, which connects to another connection point and exposes only those objects of the same that meet some criteria.

[00159]. A joint connection point, which connects with one or more other connection points and exposes all its objects as a collection of joined objects.

[00160] In the illustrated example, the architecture includes a collection of one or more connection points, including a funnel structure known as EDFHub 1700, a connection point manager 1702 and several connection managers 1704. The EDFHub 1700 receives all EDFs and merges them together and exposes them as a single list. Other individual connection points provide mecca Petition 870170015211, of 03/09/2017, p. 48/64

47/54 nisms that manipulate (including filtering, merging and expanding) the unique list that is exposed by the EDFHub 1700. Whenever a new extension or EDF is added or removed from the EDFHub 1700, the various connection points will see with the same if the appropriate connection manager is notified. This is done by triggering events to the appropriate call managers. The connection point manager 1702 creates, destroys and manages the various connection points in the system and allows easy reuse of identical connection points.

[00161] For each top-level brand (ie "menu" and "toolbar" brands), there is a corresponding connection manager 1704 that uses the data provided by the connection points to incorporate a particular type of aspect within the platform software. Each connection manager requests a set of connection points from connection point manager 1702. These manipulate the data exposed by the EDFHub 1700. In the illustrated example, connection points can be requested as a presumed chain that the point manager of connection uses to create and build a set of connection points that operates on the data exposed by the EDFHub 1700.

[00162] Fig. 18 illustrates a flowchart that describes steps in a method according to the described mode. The method is implemented in software and, in this example, by the software components of Fig. 17.

[00163] Step 1800 receives several EDFs. These files can be received in any suitable way. For example, a user can specify in their preferences particular extensions that they want to be loaded when they are online. Alternatively, a user can browse using a link to a particular location on the Internet that recognizes that the user is running a software platform that is configured to dynamically add 870170015211, from 03/09/2017, pg. 49/64

48/54 operate the extensions. The EDFs, in this example, are tapered on the EDFHub 1700 which uses connection points to combine the EDFs (step 1802). In this example, EDFs are defined as XML files and the nodes are combined into a single XML list. Step 1804 exposes the combined EDFs. In this particular example, the EDFs are combined into a single XML list that is exposed to several other connection points that then further manipulate this data (step 1806). A goal of the connection points is to avoid having the 1704 connection managers to query the entire system again each time an extension is added or removed from the system. Thus, if an extension is added or removed, the connection points ensure that only the appropriate connection manager 1704 is notified of the extension's specific additions or deletions. For example, if an EDF indicates the addition of a menu, then only the link manager associated with menus is notified. Consequently, step 1808 notifies the appropriate connection manager of any new data that matches the requirements of the connection managers.

CONNECTION POINTS AND POINT MANAGER

CONNECTION [00164] Connection points are objects that expose collections of ordered objects and activation notifications when new objects are inserted or deleted. In the illustrative system, the objects are XML nodes, but they could be any type of object. Although there are several types of connection points, they all follow a similar process:

1) Initially connect to one or more data sources. These could be files or, normally, other connection points.

2) Process the data based on some logic.

Petition 870170015211, of 03/09/2017, p. 50/64

49/54

Usually the logic is very simple and could involve something like filtering objects based on some criteria.

) Display the results of processing step 2 in a new collection of objects.

4) Trigger events to indicate how the exposed object collection has changed (Onlnserted (lndex, count) or OnRemoved (index, count)).

5) Optionally, continue to listen for changes in the data sources and repeat steps 2 to 4 when changes occur.

[00165] Alone, each connection point is very simple, but when different types of connection points are combined to form "chains", where a connection point processes data from a second connection point, the processing can be very powerful. This is especially true if the connection points only process the data changed in step 2, since they only do a small amount of simple work at any time. In the illustrative system, this incremental processing means that the entire system does not have to be consulted again when a new extension is installed or when an existing extension is removed. In addition, each connection manager in the illustrative system uses a specific chain of connection points and is thus only informed of changes that impact its area of extensibility.

[00166] The connection point manager performs two important functions when building chains of connection points. First, it allows chains to be described as presupposed chains. The hotspot manager interprets these chains and builds the required hotspot chain. Second, it allows the new use of identical connection points, which makes the system 870170015211, of 03/09/2017, p. 51/64

50/54 more efficient theme. As the hotspot manager creates each chain of hotspots, it follows which assumed chain corresponds to which hotspot. If this presumed chain is subsequently requested again, it simply reuses the existing connection point without creating a new one.

[00167] As an example, consider that the connection manager associated with menus requested the following assumed chain of connection points using the retail.edf file above: (Note: this example does not assume the presence of an EDFHub connection point) .

Explode (Filter (“menus”, Explode (URL (“retail.edf”)))) [00168] This string represents all the menus in the retail.edf file. The XML file located at retail.edf is loaded by the URL connection point that exposes the root node of the XML file as the only object in its collection. The internal Explode connection point uses the URL connection point as its data source and exposes all children of objects in this source collection. In this case, the children of the root nodes are the top level XML tags "menu" and "toolbar". The Filter connection point uses the Explode connection point as its data source and filters the exposed objects by looking only at the nodes that are “menus”. The external Explode connection point uses the Filter connection point as its data source and exposes all children of the filtered menu nodes to provide a list containing the two menus that are added by the extension. Once this particular XML file contains menus that have been identified by the link points associated with the menu link manager, this link manager is then notified that two menus have been added by an extension.

[00169] This process is illustrated diagrammatically in Fig. 19, which shows the connection points 1900, 1902, 1904 and 1906. Each

Petition 870170015211, of 03/09/2017, p. 52/64

51/54 connection point exposes a list of XML nodes. The 1900 1900 connection point takes input (a URL to an XML file - for example, retail.edf) and exposes a list of XML nodes. This list contains only the root node “<edf: extension>”. The Explode 1902 connection point takes connection point 1900 as an input and exposes a list of XML nodes that are children of the source XML nodes. In this example, the list of XML nodes exposed by connection point 1902 are “<menus>” nodes and “<toolbar>” nodes. The Filter 1904 connection point uses connection point 1902 as an input and filters “menus”. It then exposes an XML list having only the “<menus>” nodes in it. The connection point explodes 1906 uses the connection point 1904 as an entry and displays a list of the XML nodes that are contained in the “<menus>” nodes - here, both “<menus>” nodes.

[00170] Additionally consider that the toolbar connection manager would request an assumed chain of connection points that would also use the URL connection point, an Explode connection point and a Filter 1904 connection point that filters in "toolbar". Thus, the connection point explodes corresponding 1906 would expose an XML list containing only the node “<toolbar>”. But, the connection point manager would detect the community of the URL connection point and the internal Explode connection point, so that it would reuse the same connection points that it created for the menu connection manager. The Filter connection points used by the toolbar connection manager and the menu connection manager would use the same Explode connection point as their data sources but would expose different collections of nodes, because they were filtered based on different criteria.

[00171] Consider Fig. 20, which incorporates an EDFHub 2000 connection point. This connection point receives all EDFs and, as discussed above, combines them into a single XML list. O

Petition 870170015211, of 03/09/2017, p. 53/64

52/54

EDFHub then exposes the root nodes of all EDFs. The connection point explodes 2002 then exposes an XML list that contains all the top level nodes for all EDFs. As an example, there may be several EDFs, each of which contains top-level menu nodes, toolbar nodes, accelerator nodes and the like. The Explode 2002 connection point exposes an XML list that contains all of these top-level nodes for all EDFs. The Filter 2004 connection point can then filter the XML list exposed by the Explode 2002 connection point according to any suitable parameters (that is, filter or menu nodes, toolbar nodes, accelerator nodes and the like). The final Explode 2006 connection point then exposes a list of individual child nodes from the list exposed by the Filter 2004 connection point. This list describes all the specific aspects (of the particular type that has been filtered) that have been added by all EDFs.

[00172] The Table below lists a series of different connection points that can be used according to this described mode but several others could easily be created.

Connecting Point Purpose URL Loads the URL and exposes the XML node for highest level as a member of collection Context For each member, he gets the attribute “Expression” and links with it. If the expression evaluates to true, then the member is exposed. EDF The same as the URL connection point, but it also exposes a member manufactured with data to create an APP

Petition 870170015211, of 03/09/2017, p. 54/64

53/54

based on URL and URN (Which exist in the XML DOM). Merge Takes zero or more connection points (of any kind) and fuses the same together. The order and continuity of original collections will be maintained. Filter Monitors a single connection point and it only exposes these nodes that match the specified name. The order of the original collection will be maintained. Duplicate Monitors a single connection point and filters out any duplicates. A duplicate is defined as having the same URN attribute. If none URN attribute is present, then the knot is exposed. Collection order original will be kept. Explodes Monitors a single Connection Point and for each exposed member it exposes the this member's children as its members. The order of the original collection will be maintained as well as the order of the children inside the nodes. Link Monitors a single Connection Point and for each member looks for a URL attribute and creates an AP URL and merges the same within himself. If the included optional Content is established for true, it will also fuse the original collection.

Petition 870170015211, of 03/09/2017, p. 55/64

54/54

Order Monitors a single Connection Point. For each member, he takes three attributes: id, before and after. Based on this information, he reorders members as specified. If none ordering information is provided, the order of the original collection will be maintained. EDFHub This Connection Point is the central merger representing all EDF points.

CONCLUSION [00173] The modalities described above provide a platform solution that provides optimization and extensibility through a consistent and logical extensibility mechanism and an object model that can be easily understood by third party developers. Internet-based transfers can be performed without a large amount of user intervention and without manipulating any persistent user settings. Extensions can be provided for a software platform or application program dynamically based on the user's computing context.

[00174] Although the invention has been described in specific language for structural aspects and / or methodological steps, it should be understood that the invention defined in the attached claims is not necessarily limited to the specific aspects or steps described. Instead, specific aspects and steps are revealed as preferred ways to implement the claimed invention.

Petition 870170015211, of 03/09/2017, p. 56/64

1/3

Claims (16)

1. Method of software distribution over the network comprising the steps of: describe (1502) one or more software extensions using descriptions, the software extensions being configured for incorporation into a software platform running on a client (100,300); and distribute (1510) descriptions of one or more extension files to the client over a network, the descriptions being configured for use when transferring software extensions over the network; characterized by the fact that it still comprises the steps of: generate one or more packages, each package including at least one software extension file, a download queue, the download queue defining an order in which the packages are downloaded; and transferring (1412,1512) the software extension files associated with one of the multiple different functionalities for the customer, comprising downloading the packages in the defined order and reorganizing the download queue depending on an action that a user performs. 2. Method, according to claim 1, characterized by the fact that the network consists of the Internet. 3. Method, according to claim 1, characterized by the fact that the descriptions comprise a hierarchical language based on marks. 4. Method, according to claim 1, characterized by the fact that the descriptions consist of XML descriptions. 5. Method, according to claim 1, characterized by the fact that: Petition 870170043459, of 06/23/2017, p. 6/12 2/3 the network consists of the Internet; and the descriptions consist of XML descriptions. 6. Method, according to claim 1, characterized by the fact that the software extensions are configured to make context-based changes in the operation of the software platform, the context-based changes being associated with a user's computing context . 7. Method, according to claim 1, characterized by the fact that the software platform is configured to provide a single application program having several different functionalities that can allow a user to perform several different tasks. 8. Method, according to claim 7, characterized by the fact that the software extensions are configured to make changes based on the context in the operation of one or more of the multiple different functionalities that change the way in which a user can perform a task associated with a particular feature. 9. Method, according to claim 1, characterized by the fact that the software extensions provide elements of user interface. 10. Method, according to claim 1, characterized by the fact that software extensions provide behaviors, components or objects. 11. Method according to claim 1, characterized by the fact that the software extensions provide storage elements. 12. Method, according to claim 1, characterized by the fact that the software extensions provide elements defined by the user. Petition 870170043459, of 06/23/2017, p. 7/12 3/3 13. Method according to claim 1, characterized by the fact that the software extensions provide one or more of the following: user interface elements; behaviors, components or objects; storage elements; and user-defined elements. 14. Method according to claim 1, characterized by the fact that at least one software extension provides an ability to add new points of extensibility. 15. Method according to claim 1, characterized by the fact that the description of one or more software extensions comprises the step of describing the extensions using an extension description file (EDF) comprising an XML file that describes a link logic with the software platform. 16. Method according to claim 1, characterized by the fact that one or more of the descriptions contains an implementation of all or part of the functionality of an extension. Petition 870170043459, of 06/23/2017, p. 12/8 THE