GENERALIZED APPLICATION VIRTUALIZATION METHOD FOR BUSINESS USE ON THE WEB AND THE MINI SERVER USING THIS METHOD

[0001] The invention involves a generalized application virtualization method for business use on the web and the mini server using this method. Precisely speaking, it provides network operator with a leasing method for the web user to lease digital contents, including application software, game, anime, movie, music, courseware, etc. The operator manages these with the generalized application virtualization method for business use on the web and the mini server using this method.

[0002] For the ASP operator to lease digit contents on web, there are primarily 3 successful ways: one is to collect monthly fee for the movie-watching (the video on-demand, VOD) or game-playing (the game on-demand, GOD); one is to browser-based billing controlled by server (browser/server, B/S); and the other one is client-based billing controlled by server (client/server, C/S), for example, network game. As for other methods, there is either no control over user pirated download, or massive code-embedding into individual applications or media players. None of these are successful. Even in the aforementioned second and third successful methods, it is still necessary for individual applications to modify the code, whether at the client-side or the server-side.

[0003] With the application virtualization technique, one can then provides a unified leasing method to application software, game, and other media. There is no need to modify application code; no worry about incompatibility between player and media; and no chance of content piracy. Here is the secret: it uses a pre-processing sequencing method to package application software or game one-by-one. For media such as movie or music, package the specific player and the media together. (These sequenced software or medium packages are called content hereafter.) Then place the said contents at the server for users to stream, on-demand, to their virtual client. At the virtual client, the contents need not be installed, are piracy-free, can be used anywhere/anytime, and does not disturb Windows registry and operating system files. This technique has already been provided by several vendors, although Microsoft imbedded it into its operating system and made it the standard of the application virtualization method. However, Microsoft product, SoftGrid, is matured in the intranet market only. In reality, SoftGrid has never been used for billing on the web. There are a few drawbacks to use SoftGrid as a foundation of the application virtualization method for contents leasing, described below:

[0004] (1) Maturity of the Microsoft product: In addition to delivery function, the security access and metering functions are still immature; To be specific, these are caused by the following reasons: (a) Currently, SoftGrid uses Windows Basic Authentication, which needs to work with Active Directory on the server side. Therefore, the IT operation is not simple. As for the Windows Domain Authentication, it is impossible for the consumers to be controlled from Windows domain of the server, so the authentication scheme is entirely unsuitable on the web. (b) Although the Microsoft (Softricity) U.S. Pat. No. 7,017,188 mentions that the time information for metering need not be included in the streaming protocol, the Microsoft product SoftGrid currently uses the setup and the teardown commands of RTSP transmission protocol for metering. Metering is the foundation of billing. So, if billing can't separate from RTSP protocol and operate independently, the application virtualization method is still controlled by the Microsoft product. And it is not simple to use.

[0005] (2) The actual market situation: Microsoft product and patent are not all in consideration of the user who must handle a great deal of contents on web, such as content search and selection. In addition, they are also short of buffering mechanism in case of ASP operator who uses one central server to serve centralized contents for several companies or user groups.

[0006] (3) The monopolization of Microsoft: Merely taking Microsoft product as foundation may lose the opportunity of absorbing improved techniques from other companies, and even lose future “non-Windows (e.g. cell phone)” digital content leasing market.

[0007] The purpose of the invention is to provide a generalized application virtualization method for business use on the web. Precisely speaking, it provides network operator with a leasing method for the web user to lease digital contents, including application software, game, anime, movie, music, courseware, etc. By abandoning the Microsoft Windows authentication method, the invention creates a mechanism to allow network operators to operate without Microsoft Active Directory on the web. As a result of adopting a metering method independent from the Microsoft streaming protocol, user billing is no longer monopolized by a single application virtualization technique. This new method can also imbed advertisement dynamically, remove the shortcoming of illegal game plug-in, and read game status files from the client cache. Meanwhile, the user has the ability to choose from a large amount of contents. A content server can also use a hierarchical tree structure to collect and manage massive contents. Moreover, because of content delivery and running is now separated from Microsoft transmission protocol, the invention can take advantage of the improved application virtualization technique from any vendor who improves this technique (e.g. increasing transmission speed and decreasing delay). Finally, the invention also provides for a group or organization a content buffering mechanism. It can quickly deploy contents for the group or organization.

[0008] For the aforementioned purposes, the invention adopted a generalized application virtualization method for business use on the web. Its features include the said Initialization: to obtain parameter and read into setup file, to initialize a DDE service, to operate application monitor, and to carry on register and login; Access: The client-side SOD controller, logs into access server via access protocol; Selection of content: To input a keyword to select contents, the contents selected are provided according the content management protocol; Choosing application virtualization method: Choose one of the application virtualization methods according to bandwidth needed by the user and the resources consumed in the data center; Execution of application virtualization method: Bind the executable software for the application virtualization method and the contents selected, and carry out that executable software; Metering and billing: Calculate the start and end time of execution of application virtualization method and calculate the billing.

[0009] The invention also includes a mini server application of the generalized application virtualization method for business use on the web. In it, the client-side SOD controller, selects application virtualization method according to service level, transmits the contents within the local net with this method, and starts to meter time.

[0010] In the aforementioned scheme, the said Client Executive (a general term for “client-side SOD controller”) has to be installed by the web user at the client side. The executive controls four kinds of aforementioned steps on the client. (1) The user accesses an access server first; and the server contains user information for verification. (2) Then when the user selects contents, the billing server will check billing method and bank account funds. If passed, (3) the client executive chooses one application virtualization method, and executes that method. That application content can be immediately transmitted to the client. (4) Billing is done with the metering information and billing method.

[0011] The access server contains a database of information of legal individuals and user groups, verifies the user information which is inputted into the database during registration, and decides whether the user has the privilege to get into the leasing platform.

[0012] The content server contains hierarchical contents, sequenced, registered, and managed by network operator, thus facilitating the user to choose by keywords or drilldown categories.

[0013] The billing server contains the information of starting and ending time of application from the client executive, which calculates the billing according to the billing method chosen by user. There are different billing methods: by time length, per use, by time period, by semester and price markup in the prime-time.

[0014] The said mini server contains contents synchronized with central application virtualization server. Users authenticated on the web can use these contents on the mini server through local net. Although the invention uses four servers, the first three can be merged in any way depending on the program flexibility and hardware performance. The invention provides a generalized method that can be used for billing by the network operator. Based on the application virtualization technique, this method creates a client executive, allows user to access, select content, run application with metering and billing, avoids Microsoft product monopoly, and reaches the goal of content leasing.

[0024] In the system shown in FIG. 1, SOD client controller 10 communicates with server 12, through the protocol 11, among them, the client controller 10 is for user or user group, through multi-protocol 11, it communicates with server 12, which includes access server 15, billing server 16, content server 17, application virtualization server 18 etc. Correspondingly, it should include access protocol, executing application (with billing) protocol, the content management protocol, the web transmission protocol, transmission protocol for local net and content FTP protocol, etc. Basically, the protocols for user and user group are the same.

[0025] To implement the generalized application virtualization method for business use on web in the said invention, firstly, it is necessary to carry on management tasks of the registration of user's information on various servers, preparation of contents, and activation of charge card etc. Then the user can use the information on web to lease contents. The management tasks are done through a web page by user, or done through management console by the administrator, with a database in the backend to coordinate these tasks. The process to realize these will be introduced in details below.

[0026] FIG. 2 gives the flow chart of SOD client controller 10 and includes:

[0027] Step 201, obtain main program parameter. These main program parameters include the code, application name, second-class application name, file extension and control and other parameter etc. The client-side SOD controller 10 on client can be activated through the web page and can be also operated manually by user. The parameters used by these two ways can be different.

[0028] Step 202, read setup file, which includes setup information such as the server address and port etc.

[0029] Step 203, initialize a DDE service. When user clicks some documents at other websites, if the application generating these documents did not yet stream, with DDE service, the application would automatically stream down to the virtual Q-drive from the SoftGrid server at this time, and start running. Take the SoftGrid of Microsoft as an example. A user clicks a pdf. file. If his Acrobat Reader is not installed, the Acrobat would automatically stream down, and open that pdf. file.

[0030] Step 204, with a monitor, the SOD client controller can determine whether there is line-broken trouble for communication. In addition to basic monitoring of the socket, the monitor has also capability to monitor timeout: Once the line breaks, it can be detected immediately. As a result, one can apply a relevant billing policy at that moment. For example, one can notify a user about a service pause, until recovering the line. (1) Monitoring line break, so-called “heartbeat” among IT fields, is important operation for monitor. At fixed time, the client sends a message to the server and receives response. If it did not receive a response in a certain time, then it determines for line break or server crash, and vice versa. (2) A line break billing policy for that content did not stream 100%: Whether this time's contents are free for user or to succeed a continuous charge after recovering. (3) A line break billing policy for that content did already stream 100%: One feature of application virtualization method is that usually an application can operate as long as streaming 20%. If line breaks, it will report error immediately. However, if the content already streams 100% to the client, the fact is that the content can still be used after line break and will not report error; the server however can not get any billing information from the client. Under such circumstance, a different policy is required to decide billing, e.g. to calculate the billing on local client temporarily.

[0031] Step 205, determine if a user already completed registration or not. If user has already registered, turn into step 207; otherwise, go to step 206 then can proceed to step 207.

[0032] Step 206, if the user did not registered and user is requested to register. The user can get into step 207 after registering.

[0033] Step 207, the user is requested to login. The user then can proceed to step 208 after login.

[0034] Step 208, perform input protocol in FIG. 3.

[0035] Step 209, verify whether the user login with password is successful. If successful, proceed to step 210, otherwise return to step 207.

[0036] Step 210, determine whether one is activated by the web page. If yes, proceed to step 213, otherwise, has to go to step 211 and 212, then proceed to step 213.

[0037] Step 211, display SOD client.

[0038] Step 212, after displaying SOD client, the user can immediately select content by inputting keyword into the graphical interface. After preparing by the administrator using content management protocol in FIG. 4, the user can select and use the content. As a common user (rather than an administrator), (s)he uses only step 413 in FIG. 4. In the search results from the content server (steps 414 in FIG. 4), the name and category of contents are returned. This provided step 214 with the dynamic information to make decision.

[0039] Step 213, if an advertisement (also a virtualized content) is to be inserted, this insertion must comply with the industry standard of the frequency to display advertisement, or, determine even whether to advertise. Regardless how the application is activated, enacting advertisement is shown before applying or after applying the content.

[0040] Step 214, activate an application virtualization method according to the different virtualization platforms. Next, decide to choose which application virtualization method. For example, Microsoft SoftGrid and RTSP protocol pairing is one candidate of several virtualization methods. As a matter of fact, it can be that the application virtualization method candidates are already written in the client software in advance as an optimized selection. This is called static decision. For example, two selected candidates each have their own respective special features in using bandwidth, so at start when the client is installed, the parameters of both candidate methods are already in the setup files (step 202). The dynamic decision in this step is nothing but to differentiate content types: the application virtualization method may provide of different Level of Service, LOS, for different content types. (The LOS is closed related to user's communication bandwidth. The real-time game has to have the highest Level of Service, because no game player can tolerate the runtime delay resulted from a non-100% streaming of game. Movie or music perhaps can have the intermittence, especially those free videos. In general, non-real time business application needs no high bandwidth, because the interaction between user and machine has more delay than the delay caused by communication.) Again from the example above, two candidates of application virtualization methods are setup. The first is Microsoft SoftGrid, of which the RTSP currently used did not have the latest transmission technology. The second application virtualization candidate uses the latest transmission technology, so the real time game completes the streaming in a blink under the common bandwidth. Therefore, if content-type parameter is game, the second application virtualization method will be prepared. However, if the user just watches free movie, then SoftGrid RTSP of the Microsoft can be used to deliver contents. Moreover, the higher the LOS, the more resources of the data center is used. Thus, this step dynamically decides the policy of application virtualization method: the LOS is high and the resource consumed in the data center is little.

[0041] Step 215, execute application protocol (include metering and billing) in the FIG. 5.

[0042] Step 216, execute “start.exe”. In the process of running start.exe, (1) After sequencing, the necessary formats (i.e. SFT and OSD files) of all types of contents sequences are unified; (2) After the format of all the virtualized contents are set, the virtualized package can be delivered in many ways including streaming, normal downloading, P2P communication, and FTP transfer (first to the mini server then) to the SOD client controller, without worrying about content piracy; (3) Preparing execution parameters, decoding and verifying the virtualized package to be delivered to the user. Application then begins running. (4) If we sequence a game and its companion program, which examines virtual drive game status, together into a virtualized package, the virtualized package can be used by the game player, or used for in-game advertisement when the game changes status. The Start.exe is a special executable program for the said invention, not public software. In fact, this step is the detailed explanation of step 513 “usage application” in the FIG. 5. This step has a core code:

[0043] sfttray appName parameterlist

[0044] It looks very simple, albeit it has already experienced a lot of preparing actions before going to this step. This means:

[0045] The Generalization of the Application Virtualization Method: sfttray is an executable for SoftGrid client, if SOD client decides to use another application virtualization method, according to step 214 dynamic decisions, then the other executable (e.g. the Appstream or Citrix Tarpon executable in client) will replace sfttray. (The order of sequence for parameter in the parameter list may be different due to different virtualization method.)

[0046] The Unification of Different Contents: The appName represents for contents that was prepared. In the content preparation process, in addition to the explanation of the unified management process in the FIG. 4, there is also a virtualization application sequencing process. Regardless they are a game, video or business app, different types of content are unified in sequencing and management process. They can then be delivered uniformly to the client.

[0047] The Content Dispersion: Digital supermarket server site is not the only location the contents can reside and deliver from. As long as the selected application virtualization method has an “import” function at the client side, the contents may also be delivered through common download, P2Ps, and through the FTP (first to the mini server and then) to import to the client-side SOD controller at the client side. Therefore the content residence can be outside of the server site. Of course, a user still needs to go through access protocol for authentication before using the contents, so that there is no worry about that contents being too widely spread and used illegally.

[0048] The Prevention of the Illegal Game Plug-in: Because at the client, the game is protected in the virtual (disk) drive, where no plug-in can get into. Therefore after the game is streamed, the illegal game plug-in can not be installed.

[0049] Portability of Game Status File: The gamer plays games in the different places and often needs to take game status file with him or her, in order to continue from the existing status. This is usually what game development company connived. Since the game can't get into the protected virtual drive, the solution is to first write a secondary application that can copy the game status files in the virtual drive to some place outside the drive, then sequence this program together with the game into one virtual package.

[0050] In-game advertisement: With the permission and cooperation from the game vendor, one may sequence a game together with a secondary, checking-status-file program into the same virtualized package. Then an advertisement can be shown when the game changes status.

[0051] Step 217, the user terminates the running of virtualized application. This step and step 218, in fact, are a summarized statement of detailed steps in FIG. 6. The key point is the billing process at the end of application execution. Please refer to the notes of the detailed steps in FIG. 6.

[0052] Step 218, send out information of application-ending to billing server.

[0053] The above said process involves three different protocols. Detailed introduction will be given below, with the FIG. 3-6 respectively.

[0054] FIG. 3 gives the processing flowchart between client-side SOD controller (so-called “SOD client controller” or “SOD controller” hereafter) and the access server with a access protocol.

[0055] Step 301, first, an access request is send to server 12 from SOD controller 10;

[0056] Step 302, server 12 immediately builds a GUID number for the user and to transmit it to the SOD controller 10;

[0057] Step 303, the SOD controller 10 sends out a client-side public key to server 12;

[0058] Step 304, the server 12 receives the client-side public key and sends out a TDES key to he SOD controller 10;

[0059] Step 305, the SOD controller 10 receives a TDES key, and sends out symmetric vector TDESIV to server 12;

[0060] Step 306, the server 12 receives TDESIV, and sends out request for checking CRC to the SOD controller 10;

[0061] Step 307, the SOD controller 10 sends out client CRC information to the server 12;

[0062] Step 308, after checking the CRC, the server 12 sends out user-number request to the SOD controller 10;

[0063] Step 309, the SOD controller 10 sends out a user number to the server 12;

[0064] Step 310, the server 12 receives user number and sends out a password request to the SOD controller 10;

[0065] Step 311, the SOD controller 10 sends out a user password to the server 12;

[0066] Step 312, the server 12 sends out the password-verifying information to the SOD controller 10;

[0067] Step 313, the SOD controller 10 receives the password-verifying information. If the access is allowed, then send a notification to server 12, server 12 then establishes that user's software object; if the access is denied, then no notification to server 12, but to report a login failure message on the client.

[0068] In aforementioned access protocol process, it was not only to verify a password, but also to exchange an secret key, that secret key is not only used in access, but also used in two other protocols for the content management and application execution. The reasons are: (1) such a security mechanism prevents the protocol info being intercepted and billing system destroyed. (2) Because our metering instruction is independent from the RTSP of Microsoft, we have to have our own security mechanism. (3) In fact, the RTSP secure protocol is a RTSPS, but RTSPS, the Microsoft product, is very unstable when it is used on web.

[0069] FIG. 4 is the processing flow chart between the SOD controller at the client and access server, which performs content management protocol.

[0070] Step 401, the SOD controller 10 sends a request to server 12 to add company, department, product, and self-defined node;

[0071] Step 402, server 12 builds the node immediately for the administrator and sends the SOD controller 10 the information saying that the node is built up already;

[0072] Step 403, the SOD controller 10 sends out to server 12 an instruction to modify node;

[0073] Step 404, server 12 modifies that node immediately for the administrator and sends the SOD controller 10 the information saying that the node is modified already;

[0074] Step 405, the SOD controller 10 sends out an instruction to server 12 to delete node;

[0075] Step 406, server 12 deletes that node immediately for the administrator and sends the SOD controller 10 the information saying that the node is deleted already;

[0076] Step 407, the SOD controller 10 send an instruction to the server 12 to obtain node;

[0077] Step 408, server 12 transmits immediately the information of the node and pathname to the SOD controller 10;

[0078] Step 409, the SOD controller 10 sends to server 12 an instruction of displaying application configuration data;

[0079] Step 410, server 12 delivers immediately to the SOD controller 10 the information of application configuration data;

[0080] Step 411, the SOD controller 10 sends to server 12 the information of displaying node billing;

[0081] Step 412, server 12 transmits immediately to the SOD controller 10 the information of node billing;

[0082] Step 413, the SOD controller 10 sends content search instruction to the server 12;

[0083] Step 414, server 12 transmits search result to the SOD controller 10 immediately.

[0084] In the aforementioned step, similarly to a normal user, a content administrator logins, goes through access protocol process, and completes secret key exchange. From here on, each time the SOD controller converses with content server the secret key will be used to prevent security breach as a lower-layer communication.

[0085] FIG. 5 is the processing flow chart between the SOD controller 10 at the client and the access server, which performs metering and billing protocol.

[0086] Step 501, the SOD controller 10 sends to billing server 16 the instruction to obtain application configuration data;

[0087] Step 502, the billing server sends immediately to the SOD controller 10 the information of application configuration, such as content pathname and location on SoftGrid server;

[0088] Step 503, the SOD controller 10 sends out instruction to obtain user information;

[0089] Step 504, the billing server sends immediately to the SOD controller 10 the user information of user object built up in server during the operation of access protocol in FIG. 3, in addition to user name and password, the information also includes user contact information provided during registration, for example, sex, email address, cell phone, telephone, address, etc.

[0090] Step 505, the SOD controller 10 sends to billing server 16 the instruction to obtain application icon;

[0091] Step 506, the billing server sends immediately to the SOD controller 10 the application icon;

[0092] Step 507, in order to process secondary applications related to main application, e.g. PowerPoint and Excel as secondary to package together with Word in Microsoft Office Suite, the SOD controller 10 sends to the server the instruction to obtain secondary applications;

[0093] Step 508, the billing server immediately delivers the secondary application names to the SOD controller;

[0094] Step 509, the SOD controller sends out to the billing server the instruction of choosing application billing method and signing contract; first, the SOD controller determines what billing method is used by that user, to pay first and use after or to use first and pay after?

[0095] Step 510, the billing server sets the application billing method selected by that user and notifies the SOD controller setting completed;

[0096] Step 511, the SOD controller sends out to the billing server an instruction to open application;

[0097] Step 512, the billing server immediately puts that application into the user object, and notifies the SOD controller that an application has already opened;

[0098] Next step 513, the SOD controller commands that the content be delivered according to the virtualization method chosen by the user in step 214 of FIG. 2. For example, if Microsoft SoftGrid and RTSP protocol are selected, through SoftGrid client 52 one may ask the SoftGrid server 54 to send application contents. The SOD controller starts to meter at this time;

[0099] Step 514, the SoftGrid server delivers application to a SoftGrid user through RTSP protocol. This is a major function of the Microsoft product SoftGrid.

[0100] In summary, what FIG. 5 essentially completed is the first-half, preparation task for metering and billing.

[0101] FIG. 6, as a second-half task, metering is completed through timeout detection.

[0102] In the step 509, SOD controller has already determined which billing method is adopted by user, pay after use or pay then to use?

[0103] Step 515, the SOD controller sends to the billing server an instruction to verify if the usage of application is timed out according to the application billing rule and start time;

[0104] Step 516, the billing server immediately transmits the verification result to the SOD controller. If the user's billing method is use-after-pay and the fund is insufficient, the SOD controller can forbid a user to continue to use at the client side. At this time, if the user decides to continue to pay, the SOD controller, with the step 517, sends to the billing server the instruction of continued payment;

[0105] Step 518, the billing server checks immediately the user's account status, and will transmit to the SOD controller the result of setting the continued payment;

[0106] When the user completes the contents application, the SOD controller performs step 519. The SOD controller stops metering, and sends to the billing server an instruction to close application;

[0107] Step 520, the billing server immediately transmits the result of closing application to the SOD controller;

[0108] Step 521, the SOD controller sends to the billing server an instruction to obtain user product billing information;

[0109] Step 522, the billing server delivers immediately the user's product billing information to the SOD controller, in order to calculate expenses;

[0110] Step 523, the SOD controller sends to the billing server an instruction to report user's application information, including total usage time and total expenses;

[0111] Step 524, the billing server immediately records usage time and total expenses information reported by the user into the database, and notifies the result to the SOD controller.

[0112] At any time, the user can send to the billing server an instruction of deleting application with instruction 525;

[0113] Step 526, the billing server immediately deletes the application from the user's object, and notifies the SOD controller that an application already is deleted;

[0114] Likewise, the user can also send to the billing server an instruction to suspend application at any time with a step 527;

[0115] Step 528, the billing server immediately suspends that application in the user's object, and notifies the SOD controller that an application is already suspended.

[0116] What to be explained is the flow charts in FIG. 3-6 are modified Figures from the so-called “communication protocol Figures” as commonly known in the engineering community. The process arrowheads in the modified Figures usually can be regarded as especial case, rather than mandatory step. Furthermore, the step of odd number can be the request that the SOD controller at client sends to server; the step of even number can be the response that the server delivers to the SOD controller at client. FIG. 7 is the flowchart figure of billing server or contents server in response to said billing or content management process. The software structures of the two servers are very similar, except in the step 710 with 711, where the communication protocol to SOD controller is different. As to the specific billing protocol and content management protocol, the descriptions in the aforementioned FIGS. 5, 6 and 4 may be referred to.

[0117] Step 701, two threads are spawned by the server, first thread is executed in step 702, second thread is executed in step 703 and the steps after it.

[0118] Step 702, the server carries out stop, pause, or continue commands every 10 seconds according to the management console status. Management console is the managing software of the server. It is used for insuring the load balance and fault tolerance of the server;

[0119] Step 703, the server starts a socket monitor and monitors whether the client crashes and whether there is anything transmitted in;

[0120] Step 704, the server performs the initialization of the service information;

[0121] Step 705, the server establishes “events” and also gets into the steps 706-712 of an infinite loop;

[0122] Step 706, the server determines whether there is any input from the client (i.e. the SOD controller) or not. If yes, perform step 707. Otherwise, continue to wait for;

[0123] Step 707, the server builds up client processing software component;

[0124] Step 708, the server connects SOD client controller through the access protocol with the security key in the database;

[0125] Step 709, the server checks to see if it itself is a content management server. If yes then perform step 710. Otherwise it is a billing server, execute step 711;

[0126] Step 710, the server manages the content according to the content management protocol shown in FIG. 4. There is the information of each node in the database.

[0127] Step 711, the server proceeds application running (include metering and billing) protocol in the FIG. 5 and 6.

[0128] When either of step 710 or 711 completes the protocol instruction, the server performs step 712.

[0129] Step 712, the server uses “callback” to handle events. Possible events are: error in sending, error in receiving, error when establishing user, successful login, server socket closeout, service denial, server pause, and server stop. When the events finish handling, the server probably returns to step 706, or terminates server operation according to the seriousness of the situation.

[0130] FIG. 8 gives a structure sketch of mini server. The said mini server is a server, which applies the method on FIG. 2. The SOD controller 83 is used by the group user rather than individual user. In the frame figure, key points are following: (a) the FTP synchronous protocol 21 between SoftGrid server 81 and mini server 82, and (b) the local net transmission protocol 31 between the SoftGrid client 84 and the mini server 82. Both of the FTP synchronous protocol 21 and the local Ethernet transmit protocol 31 can use international standard protocol. As for the dialogue protocol between the SOD controller 83 and the content server or the billing server 85, it is described in detail in the FIG. 3-6 respectively. Although in the above description, we use the Microsoft product SoftGrid as an example, a different virtualization method can replace SoftGrid, whichever application virtualization product is selected by the user. The only thing is: the selected product has to have the “import” function. It is necessary to explain: the “import” function is one of the characteristics of the Microsoft product SoftGrid. “Import” means that the virtualized application need not go through streaming. What is needed is to “add” the OSD file resulted from sequencing to the client. Then, “import” the SFT file to the client. That is all.

[0131] Refer to FIG. 8. First, the SoftGrid server 81, with FTP synchronous protocol 21, sends the content file synchronizing requests to the mini server 82 (as a buffering child server) in the user group;

[0132] Afterwards, the mini server 82, with the FTP synchronous protocol 21, completes the content file transmission. Thereafter, when the group user accesses the contents server or the billing server 85, it chooses content and opened application according to the content protocol or the billing protocol 11;

[0133] At this time, the SOD controller 83 sends the request of “importing” the content file to mini server 82. Then, mini server 82, using the local Ethernet transmission protocol, sends the content file to the SoftGrid client 84. This completes the “import” function of the SoftGrid and starts application running. Afterward, it gets into logics in FIG. 6, closes application and completes metering and billing function.

[0134] In the real networking environment, it is entirely possible to combine the function of the access server into the billing server in one physically machine. Similarly, this applies to the logics of access server into the contents management server. In regards to the said invention: this kind of combination can apply to both situations of individual user and the group user, so that the access/authentication process can proceed in two separate physical machines (i.e. billing server and content management server).

[0135] According to the description of aforementioned process, we can get the results for adopting above leasing method of the digital contents: On one hand, to individual user, network operator need not use the Active Directory of Microsoft on the web. By adopting a metering method that is independent of Microsoft streaming protocol, user billing is not constrained by a single application virtualization technique. Furthermore it can also add dynamic advertisement operating, get rid of illegal game plug-in and read the game status files from the virtual drive in the client. Meanwhile, the user has the ability to choose from a great deal of contents. The contents server can also use the tree structure to collect and manage a vast amount of contents. On the other hand, to the group user, because of usage of the intra-net transmission, application-running process is accelerated. Also, services can be provided for multiple groups from a single server. These services include the centralized content management, and quick, on-demand deployment across geographically-spread regions.

[0136] In summary, the said invention combines application virtualization technique, web communication technique and application computer technique. It provides a digital content leasing method for the individual and group users of public web.

[0137] Any technical personnel can use the said invention with the description of better-applied examples given above. The various modifications of these examples are obvious to the technical personnel in this field and the basic principle can be applied to the other examples without extra creation. As a result, the said invention won't limit the shown practical examples here, but should include most extended scope according to the principle and the new characteristics revealed here.