WO2003044662A1 - Augmentation ou diminution incrementielle des fonctionnalites disponibles d'un programme d'ordinateur - Google Patents

Augmentation ou diminution incrementielle des fonctionnalites disponibles d'un programme d'ordinateur Download PDF

Info

Publication number
WO2003044662A1
WO2003044662A1 PCT/US2001/042947 US0142947W WO03044662A1 WO 2003044662 A1 WO2003044662 A1 WO 2003044662A1 US 0142947 W US0142947 W US 0142947W WO 03044662 A1 WO03044662 A1 WO 03044662A1
Authority
WO
WIPO (PCT)
Prior art keywords
program
agent
user
application
menu
Prior art date
Application number
PCT/US2001/042947
Other languages
English (en)
Inventor
Ron Van Os
Original Assignee
Aladdin Knowledge Systems, Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Aladdin Knowledge Systems, Ltd. filed Critical Aladdin Knowledge Systems, Ltd.
Priority to PCT/US2001/042947 priority Critical patent/WO2003044662A1/fr
Priority to AU2002230410A priority patent/AU2002230410A1/en
Publication of WO2003044662A1 publication Critical patent/WO2003044662A1/fr

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12Protecting executable software
    • G06F21/121Restricting unauthorised execution of programs
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/62Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/629Protecting access to data via a platform, e.g. using keys or access control rules to features or functions of an application
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/61Installation

Definitions

  • the present invention relates to software distribution and particularly to electronic software distribution (ESD).
  • ESD electronic software distribution
  • Application software has become increasingly sophisticated and feature-laden. Many application programs are now aptly described by the proverbial 80/20 rule— 80% of program usage is confined to 20% of the program features; the remaining 80% of program features account for only about 20% of program use. Custom installation capabilities have been developed in view of this phenomenon. That is, the user may choose to install only a subset of the program that the user expects to actually use, saving disk space on the user's machine. Nevertheless, the user is generally required to purchase the entire application program at one time. To draw an analogy, the user is required to purchase an entire seven-course meal when all the user may really have wanted is a good dessert.
  • the present invention allows for incremental distribution of a computer program through a two-way automated exchange of information between a user's machine and a server machine via a wide area computer network, e.g., the Internet.
  • the user initially purchases the core program.
  • the core program may be distributed electronically.
  • the menu structure of the core program may include menu items relating to capabilities that are not part of the core program.
  • a dialog is displayed asking the user whether the user wishes to download a program module corresponding to the selected menu item, either immediately or in the background at the next available opportunity.
  • the program module may be distributed on either a "Buy/Try” or “Try/Buy” basis, Try /Buy being preferred such that the user is afforded an opportunity to use the new program feature for a period of time before committing to buy the additional program module.
  • the menu structure of the program may also be dynamically updated to include menu items relating to capabilities developed after distribution of the core program. Program modules implementing these capabilities may be downloaded and purchased in the same manner.
  • a program can not only be increased but might also be decreased incrementally.
  • a software publisher may be afforded the ability to remotely control the availability of one or more features of an application. Enablement/disablement is achieved by intercepting key operating system messages and only permitting authorized activities to complete within the target application. No source code changes are required.
  • the Internet may be used for remote control of the application.
  • the foregoing capabilities may be implemented by a software agent installed on the user's machine.
  • the agent may be distributed and installed together with the core program, for example. Except as the user may direct, communication between the agent and the server is optimized to be unobtrusive or transparent, using spare bandwidth of intermittent Internet connections, for example.
  • the agent is software non-specific and may be instructed to operate with respect to any arbitrary software program, and may further be instructed at various times to operate with respect to various different software programs, including multiple different software programs on a single machine.
  • Figure 1 is a generalized block diagram of a system with which the present invention may be used;
  • FIG. 2 is a more detailed block diagram of the agent of Figure 1;
  • Figure 3 is a diagram illustrating a distributed server architecture that may be used in the system
  • Figure 4 is an illustration of a screen display in which the time and place of message delivery is controlled
  • FIG. 5 is a flowchart showing a general sequence of execution events
  • Figure 6 is an illustration of a screen display showing an example pull-down menu-
  • Figure 7 is an illustration of a screen display showing the pull-down menu of Figure 6 modified to disable a menu item
  • Figure 8 is an illustration of a screen display showing an Enhanced Feature dialog displayed upon selection of an added menu item within the pull-down menu of Figure 6;
  • Figure 9 is an illustration of a screen display showing another example pull-down menu
  • Figure 10 is an illustration of a screen display showing the pull-down menu of Figure 9 modified to add menu items.
  • a persistent client architecture that may be used to implement incremental software distribution will first be described, followed by a description of the application of the persistent client architecture to incremental software distribution.
  • a user machine 101 is assumed to include a run-time environment 103, provided by an operating system, a Web browser or the like, and to be running one or more computer programs 105.
  • the computer programs may be software applications, system software or embedded computer programs. Individualized, interactive program execution flow is made possible by equipping the user machine with a persistent client, or persistent agent 107, that engages in two-way communication with a server 109.
  • the agent may be installed concurrently with an application, may be pre-loaded on the user's machine, may be separately installed from a disk or download, etc.
  • the connection between the agent and the server may be a virtual connection, i.e., a connection that time-shares a physical communications channel with other communications.
  • the virtual connection uses spare bandwidth of Internet connections, continuous or intermittent, to communicate with the server.
  • the agent can and typically does interact with the application without a concurrent Internet connection.
  • Communications between the agent and the server are preferably two-way.
  • the agent communicates control, configuration and usage information (and in some embodiments, registration information, survey information, etc.).
  • the server communicates non-executable content, executable content, or both, including control information, agent updates, etc.
  • Separate servers may be responsible for delivering non-executable content and executable content, as described more fully hereinafter. Note that non-executable content may nevertheless be active, i.e., contain HTTP links enabling the user to "click through" to related Web sites.
  • Executable content may relate to the application or to the agent or both. Executable content related to the application may include updates, bug fixes, additional code modules, etc. Executable content related to the agent allows the agent to be transparently upgraded with new capabilities in the field, avoiding the potential problem of agent obsolescence.
  • An agent process 201 therefore includes a resident agent 203 and various plug-ins that interface to the resident agent through a plug-in API.
  • the plug-ins include a command processor plug-in 205, a message plug-in 207, a survey plug-in 209, an Inet plug-in 211 that handles virtual connections to the Internet, and a hook plug-in 213.
  • the message plug-in, survey plug-in, and possibly other plug-ins are capable of taking actions within the process and User Interface (UI) space of the client applications.
  • Other plug-ins may be included with the agent or added to the agent by download.
  • Persistent storage 215 is provided for the plug-ins as well as for the resident agent, e.g., within the registry file system.
  • the modularity resulting from plug-in architecture of the agent is important from the standpoint of allowing for user-transparent operation.
  • the core agent and the plug-ins are all small modules that are easily downloadable. The time needed to download a module is typically only a few seconds.
  • Core tasks of the agent include the following:
  • Maintain state (e.g., the current command file) to survive system crashes and restarts.
  • the operating system registry may be used for persistent storage of state information including the configurations of the plug-ins, the status of events and the registered client applications'.
  • the agent is capable of interacting with software applications in all respects without modification of the application itself.
  • a small system hook 217 e.g., a linkable code module
  • the system hook determines if any relevant actions are happening within a monitored application and if so, passes this information off asynchronously to the hook plug-in 213.
  • the system hook is designed to not degrade the user's system performance or application performance. More particularly, in an exemplary embodiment, the agent when it first launches loads the hook plug-in 213, which starts execution of a separate thread. This thread interacts with the system hook 217 and is responsible for selecting messages of interest. The separate thread ensures that processing of the messages of the client application are not noticeably slowed down. Note that, to prevent recursion in the message processing, the system hook ignores any messages related to the agent itself.
  • the Inet plug-in 211 is responsible for handling all Internet traffic. In an exemplary embodiment, it supports various types of Internet transactions, including registering an agent with the server and obtaining a user ID, retrieving a command file using the user ID, uploading data to the server, and downloading resources from the server/ Data may be exchanged using POST and GET commands, for example, as in the HTTPl.l or higher protocol.
  • the Inet plug-in is designed to gracefully fail if any transaction is not completed across the Internet.
  • the command processor plug-in 205 is responsible for converting the command file into tangible actions. For example, it scans the command file and schedules all resource downloads required by the command file, expands any macros, and generates a clean version of the command file.
  • An agent control panel applet 219 may be provided to enable user interaction with the agent to control prospective operation of the agent, although typically the user will not have occasion to use the control panel. For purposes of the present application, the agent control panel applet is assumed to be inactive.
  • the resident agent includes a scheduler/manager 221, a remote dialup monitor 223, and a command file pre-processor 225.
  • the resident agent also includes a client map 227, an event map 229 and a plug-in map 231.
  • the resident agent is responsible for dynamically maintaining the configuration and status of active plug-ins, the registered client applications and the events working on the client applications.
  • a command queue contains actual event information and is processed upon each agent start.
  • the agent is started by a machine start table within the registry of the operating system.
  • the scheduler/manager 221 is responsible for establishing periodic Internet connections with the server, through the Inet plug-in 211. If a connection becomes available, each client object is allowed bandwidth to service the client's needs. Subsequently, all pending POST operations are processed.
  • the scheduler/manager can be invoked either via an event driven method, in the case of dialup Internet access, or at periodic intervals in the case of direct (or proxied) LAN-based Internet access. In the case of dialup access, different dialup access methods may be used depending on the software configuration of the user machine.
  • the remote dialup monitor 223 determines which dialup access method is used and establishment of an Internet connection is detected accordingly.
  • the client map 227, event map 229 and plug-in map 231 together operate to establish "client channels" though which interaction between the clients and the server occurs.
  • the client map consists of one or more client objects.
  • a privileged client object is present that is allowed to add clients to and remove agents from the client map and to add agents to and remove agents from the plug-in map. All other client channels can only be used to schedule events and direct the agent to download content from a server.
  • a client object within the client map has a corresponding event object within the event map and a corresponding plug-in object within the plug-in map.
  • the event map in combination with the client map causes user interactions in the client applications UI space.
  • a client object contains information that allows the system hook to recognize events from a particular application.
  • the agent 107 checks in with the server 109 when a check-in interval for the application has elapsed.
  • the agent may receive back a command file from the server, which the agent then interprets.
  • the interpretation of the command file may cause the agent to fetch resources from the server and/or place information back onto it.
  • the agent may also be instructed to check-in for another command file.
  • the privileged client is also considered an application for the agent. Therefore the agent checks in with the appropriate server on a check-in interval separate from the check-in intervals of other applications. Also, an application's command file may cause the privileged client to check in, or vice versa.
  • the agent 107 When the agent 107 has acquired the resources and commands from the server 109 to actually do some work, it can be instructed to immediately display appropriate messages to the user, or (more commonly) to wait until the target application is running, and work in the context of the application.
  • the agent converts system event data into tangible actions events for the attached plug-ins, with messages appearing to the user as coming from the vendor, within the application's screen window and only while the application is running. Referring again to Figure 2, a typical sequence of events is as follows: 1.
  • the system hook 217 determines that a new application has launched or obtained the user's focus.
  • the resident agent 203 queries its client objects to see if the application is a client. If it is not a client, the agent remains dormant.
  • a valid client with user input will cause the resident agent 203 to instruct the system hook 217 to start detailed monitoring of the application and route selected application messages through the hook plug-in 213. 4.
  • the hook plug-in 213 will reflect the message asynchronously to the resident agent 203, which will catalog the events under the current user's name. 5.
  • the resident agent 203 queries its client/event map 227, 229 to look for a match. 6. If a match exists, the event is executed, which could include invoking a plug-in to undertake action in the application's UI space. If visible content is shown in the application's UI space, the client application is temporarily disabled and cannot receive user focus.
  • the agent returns to Step 4 above until the client application loses focus.
  • the agent transfers any client application-related data to persistent storage, at which point the agent reverts to Step 1 above.
  • the agent 107 were to somehow be disabled and hence unable to intercept UI messages, then the user would be able to access functionality intended to be disabled and would be unable to access added functionality.
  • the program can be "injected" with or otherwise have added to it a code stub in a manner described, for example, in the previously-referenced U.S. patent application. A call is made by the code stub from within the injected software program to the agent to verify that the agent is in fact operation before the user is allowed to begin using the software program or before all of the functionality of the application will be unlocked and made available to the end user.
  • the application components are injected at the time that the final application installer is built ("early binding").
  • the application installer is combined with the agent installer which, during installation on the end user machine, will inject code into the appropriate application modules to ensure that the agent is running.
  • the essential job of the server 109 is the delivery of an appropriate command file to particular agent.
  • the command files in the agent determine the action that the agent is going to take— which of the various kinds of activities it will carry out, at what time, with respect to what user operation, etc.
  • the server maintains a record for every single user of an application.
  • the agent working for one of its user's connects to the server, it consults a table of rules that determines which, if any, of the potential command files that the server has for that application are appropriate for that agent. Those rules are predicates that are based on all the data in a database 111 relative to that user.
  • An example of a rule might be "If installation of this application took place 60 or more days ago, send Command File A,” which causes the agent to perform some action, "and if installation took place less than 60 days ago, send Command File B,” which takes some other action.
  • the two actions would differ with respect to the degree of experience that particular user has with the program. For example, in the case where an upgrade has become available, a publisher may choose to send one upgrade message to experienced users, more appropriate to their experience level, and another upgrade message to less experienced users, more appropriate to their experience level.
  • the determination of experience level may be based, for example, on the time elapsed since installation.
  • the server uses a rules engine 111 to apply rales that have been created in a table sequentially to determine which if any of those rales are true for a particular agent that is querying the server at a particular point in time. Upon discovering that one or more of those rales "fires," i.e. is true, then the corresponding one or more command files are downloaded to the agent. The publisher therefore enjoys very "fine-grain" control of the activities of an agent based on the attributes of that agent. Very sharp targeting results in which particular information is sent to particular agent based its characteristics and its history. As may be appreciated from the foregoing description, the server has two different types of responsibilities. One function of the server is to maintain the agent. Operations to maintain the agent occur through the control channel described previously.
  • Another function of the server is to provide customer support for specific client applications. These two distinct functions can be combined on one physical server machine or on multiple physical server machines. More preferably, these two functions are separated, with agent maintenance being handled by a technology provider server and customer support being handled by a collection of software vendor servers.
  • executable content is provided from the technology provider server 301 across the control channel and non-executable content is exchanged with software vendor servers 303a - 303n across other channels as shown in Figure 3. In this manner, executable content may be assured to be virus-free.
  • private vendor-customer information may be passed directly to the vendor without being passed through a third party.
  • the privileged client periodically connects to the technology provider server and informs it of activities of the agent on behalf of various client applications.
  • Identifiers are allocated to support the foregoing separation of functions.
  • the agent when it is first activated seeks a connection opportunity and, when a connection is established, obtains an agent ID 305 from the technology provider server through the control channel.
  • the agent receives from the server a command file instructing the agent to look for a particular application. If that application is found installed on the user's system, a client ID 307 is obtained for that copy of the application.
  • Only the technology provider server need be aware of the correspondence between agent IDs and client IDs. Transactions between the agent and the vendor server use only the client ID.
  • a Database Management System maintains a per-client-copy database of information uploaded from various instances of an application.
  • the agent collects numerical counts for each menu bar item in a client application.
  • the vendor may determine from the database how often the file:print command has been used, for example.
  • the DBMS includes a rales engine. Business rules are established governing the actions to be taken in relation to a particular copy of the application depending upon the data stored for that application. When action is to be taken, a command file is prepared and transferred to the agent.
  • the system has the ability to precisely target the moment a message dialog appears in a client application.
  • the vendor can pick an operation from among a menu hierarchy of the application, a time delay, and a number of times to repeat the operation until it is completed with a click-through or other affirmative response.
  • the system also has the ability to determine who among the vendors installed base will see a particular message. Criteria can be based on demographics, responses to past offers, responses to past surveys, usage information, time since the application was installed, even random selection. Any information in the database can be used to determine who gets a particular message. For example, a particular rule might send all users a message before or after use of a particular feature after that feature has been used a specified number of times ( Figure 4) .
  • a Web-based administration tool is provided to allow business rules to be set up and changed through a familiar Web-form interface.
  • the described agent technology is able to attach itself into the main window of the target application.
  • This attachment allows direct access to all of the window objects that the target application generates for constructing the user interface. Some of these elements are the actual menu bar and menu items.
  • These window objects can be dynamically updated by code added at runtime to the target application to accomplish: 1) removal of a menu item constructed by the target application; 2) addition of a menu item and installation of a command handler to add functionality; 3) disabling a menu item, by graying it out; 4) rerouting a menu command handler such that the attached code gets the first chance to handle the user command.
  • the latter feature allows for display to the user of a message informing the user that the feature is for sale. A combination of these capabilities allows the agent to tailor a legacy application for incremental deployment.
  • menu commands are accessible either through a mouse click or a keyboard shortcut.
  • the OS will formulate the correct windows message to send the menu object to invoke a command.
  • This higher-level message is intercepted to handle the menu object interaction in the manner specified for the particular application.
  • the agent can either: 1) Remove the menu item from the application at runtime, to make the feature unavailable to the user; or 2) Intercept the user interaction before it reaches the application and substitute a dialog alerting the user of what steps to take to acquire the functionality.
  • the steps could allow for a Try /Buy scenario.
  • it may be necessary to for the technology provided run a test setup in which a copy of the target application is run. A test person performs each UI action to be disabled while a separate computer program (which may be the agent previously described) monitors and records the corresponding messages.
  • the agent performs the following steps: 1) Insert a menu item into the application at rantime, to make the feature available to the user; and 2) Handle the user interaction with this new menu item and invoke the acquired functionality.
  • Any operating system (OS) that provides a Graphical User Interface (GUI) handles the keyboard and pointing device input from the user and converts them into a format (messages) suitable for processing by applications using the GUI services.
  • the agent can insert itself between the GUI and the application, thereby monitoring and controlling the user input received by the application.
  • the agent can generate additional GUI messages to control the UI of the application.
  • the OS detects that the user has clicked a mouse button, it will determine which application has the user focus and should receive a message describing this event. Once this message is received by the application, it can execute some feature. Being able to monitor and control the flow of messages between the OS and the application enables the agent to alter the application behavior at rantime.
  • the application UI is constructed by issuing requests to the OS for generating and displaying UI elements on the end user's monitor. Examples are a window with a title bar, a button, an edit text box, and so forth.
  • the agent can add or remove UI elements from the application's UI.
  • WIN32 API calls are used for this purpose.
  • the application constructs memory objects that represent the various objects rendered on the screen. These objects are called windows (window ohjects), well-known in the art. All of the UI elements are managed by the OS on behalf of the program and become part of the desktop.
  • any other application can query the system for what is on the desktop. Once an object of interest is found, it can be injected with a small hook code module which will execute in the context of the target application. Once part of the application, it can perform various functions, e.g., adding/removing UI elements (menus), filtering the messages received by the OS, etc.
  • an applications menu structure can be altered at runtime by sending the appropriate messages. Once menu items have been added to an application to extend its feature set, the user is able to select them. If the user selects the item, the persistent client can intercept the corresponding message and execute the appropriate code.
  • This code can be part of the original application or new functionality that become available after the application had already been released.
  • the persistent client can display a dialog asking the user if she or he wants to download the new feature corresponding to the new menu item, either immediately or in the background.
  • an execution example is shown leading to the user being asked to add a new feature to a product.
  • the OS Once the OS has handled a user action, in this case the selection of a menu item, it formats a message describing this event and would normally send it to the application.
  • the message is intercepted by the agent and compared against a list of dynamically added menu items (501). If the message did not originate from a dynamically added menu item, the message is passed to the application and processed as usual (503). If the message did originate from a dynamically added menu item, the persistent client will check to see if the user has already downloaded (or unlocked) the associated feature code (505). If the feature code is in place, the client will execute the code (507). If the feature has not been downloaded yet, a dialog is presented to the user informing the user of the feature availability and steps to acquire it (509).
  • the program module may be distributed on either a "Buy/Try” or “Try /Buy” basis, Try/Buy being preferred such that the user is afforded an opportunity to use the new program feature for a period of time before committing to buy the additional program module. Try /Buy self- wrapping of software programs is described in U.S. Patent Application Serial No. 08/921,394 entitled MULTI-TIER ELECTRONIC SOFTWARE DISTRIBUTION, filed August 29, 1997, incorporated herein by reference.
  • the menu structure of the program may also be dynamically updated to include menu items relating to capabilities developed after distribution of the core program. Program modules implementing these capabilities may be downloaded and purchased in the same manner.
  • FIG. 6 an example is shown of a native target application's SEARCH menu.
  • the agent is able to disable a menu item in the target application, as shown in Figure 7.
  • the "Find Next F3" item has been dynamically disabled, preventing the user from selecting " this menu item.
  • the menu item selection can be rerouted and handled by the agent.
  • a dialog can be shown to allow the user to acquire the requested feature, as shown in Figure 8. If the user decides not to acquire the feature, it can be disabled as in Figure 7.
  • Steps performed by the agent to allow it to modify the attributes of the menu items of the target application include identifying the target application, injecting a small hook into the message processing loop, and retrieving a handle to the target application frame.
  • a code example illustrating this processing is provided as Appendix A. Special care needs to be taken to ensure that a disabled menu item is no longer accessible using short cuts.
  • the injected code in the message processing loop can selectively suppress windows messages passed from the operating system to the target application. This mechanism ensures that disabled items are no longer available to the target application.
  • this mechanism allows the agent to redirect messages intended for the target application to itself and handle the message, e.g., by displaying to the user that the particular item is disabled and can be purchased as a separate module.
  • An example procedure for filtering messages in this manner is provided as Appendix B.
  • the agent also provides for the dynamic addition of menu items at rantime.
  • the native target application's FILE menu may appear as shown in Figure 9.
  • An example of a corresponding runtime-modified menu is shown in Figure 10, in which two additional items have been added to allow the user to either email or fax the document to a recipient.
  • Steps performed by the agent to allow it to modify the attributes of the menu items of the target application include identifying the target application, injecting a small hook into the message processing loop, and retrieving a handle to the target application frame.
  • a code example illustrating this processing for the addition of menu items is provided as Appendix C.
  • the added command is handled by the injected code which monitors the windows messages received by the target application frame.
  • the corresponding code can either execute inside the context of the target application or out of process.
  • the injected code handles the message: HandlelnProcessMenuCommand specified.
  • the message is forwarded to the agent using PosfMessage defined.
  • Appendix D A code example illustrating these steps is provided as Appendix D.
  • CMenu*pClien HelpMenu pClientTopMenu->GetSubMenu(2); if ⁇ ClientFileMenu) //Search menu
  • CMenu*pClientHelpMenu pClientTopMenu->GetSubMenu(0); if(pClientFileMenu) //File menu
  • PostMessage (ghwndlnjectRelay, WM_FORWARD_UNWINDING_WND, (WPARAM) hwnd, (LPARAM) GetCurrentProcessIdO);
  • PostMessage (ghwndlnjectRelay, WM_HOOKCLIENTCOMMAND, (WPARAM) uiMessage, (LPARAM) hwnd) ; • ⁇ ⁇ > return TRUE;

Abstract

De manière générale, la présente invention permet d'effectuer la distribution incrémentielle d'un programme d'ordinateur par un échange bidirectionnel automatisé d'information entre une machine d'utilisateur et une machine serveur via un réseau informatique de zone étendue, par exemple, l'Internet. L'utilisateur achète au départ le programme résidant en mémoire centrale. Ce programme résidant en mémoire centrale peut être distribué par la voie électronique. La structure de menu du programme résidant en mémoire centrale peut comprendre des commandes de menu se rapportant à des capacités qui ne font pas partie du programme résidant en mémoire centrale. Lorsque l'utilisateur sélectionne des commandes de menu qui ne sont pas assurées directement par le programme résidant en mémoire centrale, un dialogue est présenté à l'utilisateur, ce dialogue lui demandant s'il souhaite télécharger un module de programme correspondant à la commande de menu sélectionnée, soit immédiatement soit plus tard au moment de l'opportunité disponible suivante. Le module de programme peut être distribué sur une base 'acheter/essayer'' ou bien sur une base 'essayer/acheter'', l'essai suivi de l'achat étant préféré étant donné que l'utilisateur a ainsi l'opportunité d'utiliser la nouvelle caractéristique du programme pendant un certain temps avant de s'engager à acheter le module de programme supplémentaire. La structure de menu du programme peut également être dynamiquement actualisée pour inclure des commandes de menu correspondant à des capacités développées après la distribution du programme résidant en mémoire centrale. Des modules de programme de mise en oeuvre de ces capacités peuvent être téléchargés et achetés de la même manière.
PCT/US2001/042947 2001-11-15 2001-11-15 Augmentation ou diminution incrementielle des fonctionnalites disponibles d'un programme d'ordinateur WO2003044662A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/US2001/042947 WO2003044662A1 (fr) 2001-11-15 2001-11-15 Augmentation ou diminution incrementielle des fonctionnalites disponibles d'un programme d'ordinateur
AU2002230410A AU2002230410A1 (en) 2001-11-15 2001-11-15 Incrementally increasing or decreasing the available functionalities of a computer program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2001/042947 WO2003044662A1 (fr) 2001-11-15 2001-11-15 Augmentation ou diminution incrementielle des fonctionnalites disponibles d'un programme d'ordinateur

Publications (1)

Publication Number Publication Date
WO2003044662A1 true WO2003044662A1 (fr) 2003-05-30

Family

ID=21742980

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/042947 WO2003044662A1 (fr) 2001-11-15 2001-11-15 Augmentation ou diminution incrementielle des fonctionnalites disponibles d'un programme d'ordinateur

Country Status (2)

Country Link
AU (1) AU2002230410A1 (fr)
WO (1) WO2003044662A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005045562A2 (fr) 2003-10-23 2005-05-19 Microsoft Corporation Systeme, procede et api servant a installer progressivement une application logicielle
EP1643339A1 (fr) * 2004-09-29 2006-04-05 Sysmex Corporation Méthode et système pour restreindre l'usage d'un programme applicatif
US8218529B2 (en) 2006-07-07 2012-07-10 Avaya Canada Corp. Device for and method of terminating a VoIP call
US8468131B2 (en) 2006-06-29 2013-06-18 Avaya Canada Corp. Connecting devices in a peer-to-peer network with a service provider
US8856361B2 (en) 2009-01-13 2014-10-07 Microsoft Corporation Incrementally changing the availability of a feature

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0778512A2 (fr) * 1995-12-08 1997-06-11 Sun Microsystems, Inc. Système et méthode de gestion d'utilisation de logiciels d'application du type essai et achat
WO1998058306A1 (fr) * 1997-06-17 1998-12-23 Shopnow.Com Inc. Procede et system permettant d'introduire sans risque des informations electroniques dans une application d'achat en direct
US6243692B1 (en) * 1998-05-22 2001-06-05 Preview Software Secure electronic software packaging using setup-external unlocking module

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0778512A2 (fr) * 1995-12-08 1997-06-11 Sun Microsystems, Inc. Système et méthode de gestion d'utilisation de logiciels d'application du type essai et achat
WO1998058306A1 (fr) * 1997-06-17 1998-12-23 Shopnow.Com Inc. Procede et system permettant d'introduire sans risque des informations electroniques dans une application d'achat en direct
US6243692B1 (en) * 1998-05-22 2001-06-05 Preview Software Secure electronic software packaging using setup-external unlocking module

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "Privilege User's Guide - Version 2.0", ALADDIN SOFTWARE DOCUMENTATION, June 2001 (2001-06-01), pages c,ix - xii,1-9,11-29,47-75,85-99,101-121,219-233, XP002209452, Retrieved from the Internet <URL:ftp://ftp.ealaddin.com/pub/privilege/doc/privilegeusersguide.zip> [retrieved on 20020808] *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005045562A2 (fr) 2003-10-23 2005-05-19 Microsoft Corporation Systeme, procede et api servant a installer progressivement une application logicielle
EP1597654A2 (fr) * 2003-10-23 2005-11-23 Microsoft Corporation Systeme, procede et api servant a installer progressivement une application logicielle
EP1597654A4 (fr) * 2003-10-23 2008-12-24 Microsoft Corp Systeme, procede et api servant a installer progressivement une application logicielle
EP1643339A1 (fr) * 2004-09-29 2006-04-05 Sysmex Corporation Méthode et système pour restreindre l'usage d'un programme applicatif
US8468131B2 (en) 2006-06-29 2013-06-18 Avaya Canada Corp. Connecting devices in a peer-to-peer network with a service provider
US8218529B2 (en) 2006-07-07 2012-07-10 Avaya Canada Corp. Device for and method of terminating a VoIP call
US8856361B2 (en) 2009-01-13 2014-10-07 Microsoft Corporation Incrementally changing the availability of a feature
US9313204B2 (en) 2009-01-13 2016-04-12 Microsoft Technology Licensing, Llc Incrementally changing the availability of a feature

Also Published As

Publication number Publication date
AU2002230410A1 (en) 2003-06-10

Similar Documents

Publication Publication Date Title
US6434532B2 (en) Interactive customer support for computer programs using network connection of user machine
US6073163A (en) Method and apparatus for enabling web-based execution of an application
US9262245B2 (en) Computing system and method for processing user input in a world wide web application
US6513158B1 (en) Method and apparatus for running multiple java applications simultaneously
US6901595B2 (en) Method, apparatus, and system for implementing a framework to support a web-based application
AU769099B2 (en) System and method for delivering remotely stored applications and information
US6907451B1 (en) Method, apparatus, and system for immediate posting of changes in a client server environment
CA2605120C (fr) Procede et systeme pour heberger et executer une application a composants
US7577700B2 (en) Method and apparatus for a portable information agent
US20020019844A1 (en) Method and system for network-distributed computing
US7461119B2 (en) Method, apparatus, and system for managing status of requests in a client server environment
US20020183051A1 (en) System and method for remote application management of a wireless device
US20070214463A1 (en) Method, apparatus, and system for implementing view caching in a framework to support web-based applications
US7107315B1 (en) Method for web-based delivery of use-restricted programs to handle mail attachments
US7870492B2 (en) Method, apparatus, and system for managing commands in a client server environment
US7716684B2 (en) Software configuration methods and common presentation layer
WO2003044662A1 (fr) Augmentation ou diminution incrementielle des fonctionnalites disponibles d&#39;un programme d&#39;ordinateur
US20030023752A1 (en) Pluggable URL providers in a J2EE server
US10073689B2 (en) Managing application lifecycles within a federation of distributed software applications
US7885996B2 (en) Method, apparatus, and system for implementing notifications in a framework to support web-based applications
WO2001055876A1 (fr) Dispositif web
Revett et al. Network computing: a tutorial review
WO2000014617A2 (fr) Systeme et procede d&#39;echange d&#39;information relatives a une application client cible
KR20010081239A (ko) 응용 소프트웨어를 이용한 인터넷 광고방법
WO2001063421A1 (fr) Procede et appareil destines au partage des ressources d&#39;application

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP