WO2001004752A2 - A method and system of allowing prospective users to test and use software via a computer network - Google Patents

A method and system of allowing prospective users to test and use software via a computer network Download PDF

Info

Publication number
WO2001004752A2
WO2001004752A2 PCT/US2000/018814 US0018814W WO0104752A2 WO 2001004752 A2 WO2001004752 A2 WO 2001004752A2 US 0018814 W US0018814 W US 0018814W WO 0104752 A2 WO0104752 A2 WO 0104752A2
Authority
WO
WIPO (PCT)
Prior art keywords
server
client
software
test software
test
Prior art date
Application number
PCT/US2000/018814
Other languages
French (fr)
Other versions
WO2001004752A3 (en
Inventor
Robert Coates
Christopher Reed
Original Assignee
Robert Coates
Christopher Reed
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 Robert Coates, Christopher Reed filed Critical Robert Coates
Priority to AU60842/00A priority Critical patent/AU6084200A/en
Publication of WO2001004752A2 publication Critical patent/WO2001004752A2/en
Publication of WO2001004752A3 publication Critical patent/WO2001004752A3/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/451Execution arrangements for user interfaces

Definitions

  • the present invention relates to a system and method for computer software distribution through the testing and using of computer software over a computer network.
  • a potential user of a software package must receive the software package via some medium.
  • the prospective user must also install the software on to his or her home computer. Installation takes up hard drive space. If the current hard drive space on the potential user's system is insufficient, then he or she will have to delete files or procure a larger or additional hard drive so the test software package may be installed. Installation also normally requires the prospective user to end all other programs that might be running so that process conflicts, which may create fault block errors or other processing errors, do not occur. This is required so that the installation will be successful. Often, a prospective user will have to reboot his or her home computer after installation.
  • a prospective user may also find himself or herself in the position of having to configure the test software and local computer prior to and or after the test software has been installed.
  • the difficulty of configuration can range from trivial, such as selection of file and folder names and/or locations, to serious, such as where batch files must be edited or device drivers installed.
  • Configuration is often required to allow test software to interact properly with a particular operating system, other program modules, and/or peripherals. Configuration is also usually needed in order for the test software to run optimally. Further, after the prospective user is done testing the software, he or she will normally want to uninstall and remove the test software package. Not only may the test software program files need to be deleted, but whatever steps were undertaken during configuration of that test software package may need to be undone as well.
  • a software vendor may provide a magnetic or optical disk(s) containing single or multiple test software packages.
  • One method of allowing customers to test software is disclosed in US Patent No. 5,689,560, which is hereby incorporated by reference.
  • Software vendors may also install test software packages on computer hard drives prior to purchase of the computer.
  • Recently, software vendors have began to distribute test software packages online, including distribution over the Internet.
  • One such method of online software distribution is disclosed in U.S. Patent No. 5,883,955, which is hereby incorporated by reference.
  • Web pages are files that contain instructions written in Hypertext Markup Language (“HTML”), as well as text contained in standard ASCII format. HTML files are normally sent over the Internet using Hypertext Transfer Protocol ("HTTP") on top of Transmission Control Protocol Internet Protocol (“TCP/IP"). Web browsers, such as Netscape Navigator, Microsoft Internet Explorer, and others, translate HTML into a graphical display containing text, images, sound, and hyperlinks. Hyperlinks are interactive text or images that, when selected, will execute any command associated with that link. Such commands include, but are not limited to, loading another web page in a browser, downloading a file(s), or starting another process on either a remote or local machine.
  • the '835 patent allows any command to be passed to the remote server. This presents a grave security risk should an unauthorized individual gain access.
  • the '835 patent attempts to limit this risk through the authentication of a user ID and password.
  • utilizing user IDs and passwords takes up administrative resources ,through such tasks as setting up user accounts, mamtaining user accounts, checking log files for unauthorized connection attempts, protecting against fraudulent connections, and other system administration tasks, that could be dedicated elsewhere.
  • user ID and password authentication takes up additional system resources that can lengthen the time required to make a connection and can slow down processing time that can be dedicated to other functions.
  • the maintenance of a web page by software vendors allows customers who have access to the Internet to retrieve and peruse desired information at any time from virtually any location.
  • test software packages can place those test software packages in a location from where they may be accessed and downloaded through the web server. These download locations could be listed as hyperlinks that a potential user of the software package can select and thereby initiate a download of the test version directly from a vendor's Internet site via File Transfer Protocol ("FTP"), or other file transfer method.
  • FTP File Transfer Protocol
  • a prospective user wishing to test Netscape Communicator 4.51 for Windows 95, English Version, Complete Install would have to download a one hundred and twenty million bit file. At fifty-three thousand bits per second, this download would take almost thirty-eight minutes. If the prospective user has a slower connection, this time could be greatly increased. Downloading also requires the prospective user to allocate sufficient hard drive space to accommodate the test software file(s). If sufficient hard drive space is unavailable, the prospective user will have to delete other files, or acquire a larger or second hard drive, to make room for the test software package.
  • test software package may be installed.
  • a prospective user may also need to configure the test software and local computer prior to and/or after it has been installed. The prospective may also need to remove the test software package after completing the test.
  • the principle object of the present invention is to allow a prospective purchaser of a software package to test the software prior to purchase without having to download, install, configure, or remove the test software package.
  • Another object of the present invention is to allow a prospective user of freeware to test the freeware prior to procurement without having to download, install, configure, or remove the freeware.
  • these objectives are achieved by the present invention through the use of custom server-client layers that deliver, receive, and process datagrams. These datagrams are transmitted over a computer network using certain communication protocols.
  • FIG. 1 is a diagram of components for a preferred system for testing software over a computer network.
  • FIG. 2 is a flow chart of a preferred web based test software server-client system.
  • FIG.3 is a conceptual flow chart of a preferred method of filtering and eliminating extraneous test software session output.
  • FIG. 4 is a conceptual flow chart of a preferred method of filtering and eliminating extraneous visual test software session output.
  • FIG. 5 is a flow chart of a preferred non-web based test software server-client system.
  • This method allows a customer to test a software package prior to purchase or procurement without having to download, install, configure, or remove the software on their local computer.
  • a customer When a customer is looking for software, he calls up the web site of the software vendor.
  • the web site normally consists of HTML commands, dynamic and static images, sounds, streamed video and audio, common gateway interface ("CGI") script, and applets.
  • CGI common gateway interface
  • the software vendor is likely serving up its web pages using an HTTP web server.
  • the customer is likely using a standard HTML browser, such as Netscape NavigatorTM, Microsoft Internet ExplorerTM, or any other browser that is or may be developed.
  • the present invention's system consists of 100 server computer(s) and 112 customer's local computer connected over a 110 network.
  • the term computer refers to a general purpose digital computer.
  • General purpose digital computers are comprised essentially of a data processing unit, memory storage devices, input devices, and display devices.
  • a data processing unit manipulates data bits according to an instruction set provided to it.
  • the data processing unit then outputs the resulting data bits. Both input data bits and output data bits, as well as the manipulative instruction set, are stored by a memory storage device.
  • Memory storage devices include random access memory for temporary storage and use by the data processing unit, read-only memory for permanent storage and use by the data processing unit, and a mass storage device for storing large numbers of data bits for eventual use by the data processing unit.
  • Mass storage devices are capable of containing large numbers (>10 8 ) of data bits, and include floppy magnetic disks, hard magnetic disks, and optical disks.
  • Input devices allow a computer user to provide data bits for processing by the data processing unit. Input devices include keyboards, disk drive controllers, track-balls and mice, digital cameras, and sound recording devices. Another input device necessary for the present invention is, referring to FIG. 1, 106, 116, a network interface device.
  • a network interface device such as a modem or network interface card, allows a computer to be connected to a computer network.
  • Computers with network interface devices can transfer data bits to other computers connected to the same computer network.
  • Display devices allow a computer user to see and hear, or otherwise utilize the output of the computer, and include monitors and speakers.
  • the preferred network is the Internet.
  • the server computer(s) contain 102 test software server, 104 test software package(s), 106 network interface device, and, in embodiments described herein that are web-based, 108 web server. 100
  • test software server 104 test software package(s), 106 network interface device, and, in embodiments described herein that are web-based, 108 web server.
  • One reason multiple server computers are possible is because it is not necessary that the computer containing the software vendor's test software server and test software package(s) be the same computer as that containing the vendor's web server, so long as a network connection exists between the server computers containing those packages.
  • the test software server software is a program that, after receiving a command, starts a process, that being an instance of the desired software package to be tested, sends a command to the customer's local computer to start a client process, filters and eliminates any output not associated with the test session process, encodes the remaining output for transmission, transmits any visual or other output of the test software session to the test software client, receives command datagrams from the test software client, translates the received datagrams into binary code usable by the test software session program, may filter and eliminate any commands not directed to the test software session process or associated processes, and passes the remaining commands to the test software session process or associated processes.
  • the test software server may be comprised of a wholly custom program or a combination of custom and off-the-shelf programs. Multiple processes of the same or different software packages can be running on the server at any one time.
  • the web server 108 can be any off-the-shelf product that allows a server computer to spawn a process upon an HTTP, HOP, or other request sent to the web server.
  • Such web servers include APACHETM, Microsoft IISTM, Netscape
  • the operating system of the web server computer can be any operating system that will run a required web server, including: Apple MacOSTM, Microsoft Windows 9XTM, Microsoft Windows NTTM Server 3.0 and above, Microsoft Windows NT WorkstationTM, and any flavor of UNIXTM (i.e. SolarisTM 2.x and above, HPUXTM, LinuxTM, AIXTM, etc.).
  • a conventional computer could be used as the web server computer, but as the amount of connections increase, so to will the system requirements. If the web server computer is going to also be the test software server computer hosting the software package sessions then the system requirements increase.
  • the preferable minimum data processing unit requirements is a Pentium ⁇ TM 400 MHz processor, or comparable CyrixTM or AMDTM processors.
  • test software server computer can be the same computer as the web server computer, or may be a separate computer.
  • the minimum system requirements for a separate test software server computer are the same as that of the web server computer. In order to host the program sessions, the test software server computer either runs or emulates the native operating system of the software (i.e. Apple MacOSTM, Microsoft WindowsTM 9x or NTTM, etc.).
  • the customer's computer contains 114 test software client, 116 network interface device, and, in embodiments described herein that are web-based, 118 web browser.
  • the test software client (“client program”) 114 is a program which interacts with the test software server to provide the customer with the appearance of a real-time, or near real-time, interactive program window of the selected test software package.
  • the client program includes a client window through which the customer interacts with the software session running on the server.
  • the customer interacts with the client program window through keyboard strokes, mouse scrolls and clicks, and other device input normally associated with the operation of application software.
  • the client receives datagrams ("packets") from the server and translates those datagrams into binary code useable by the customer's local computer.
  • These packets contain the visual and aural elements of the software interface, as well as other output of the test software session.
  • the packets are rendered on the local computer, after decoding by the client program, to give the user the appearance of the software interface.
  • the client may filter and eliminate commands not directed to the test software session, encodes the commands, and transmits the encoded commands to the test software server.
  • the client program window can be a window on top of the locarcbmputer's operating system. As described below, with this invention different types of clients using different protocols are possible.
  • the customer's computer can be any computer that will run the required client program, and web browser for the web based embodiments, and support 116 network interface device.
  • a customer viewing a software vendor's web site wishes to test a software package he views through the software vendor's or other web site. She sends a command 203, via hyperlink or other method, from her local computer to the vendor's web site or test software server. This command is received 205, directly if sent to the test software server or indirectly if sent to the web site, by the test software server on the test software server computer.
  • the web server contains a function for passing the received datagrams to the test software server. This function may be supplied by a CGI script.
  • the server After the customer sends a request to the test software server to test the software, 207 the server sends a command to the test software server computer's data processing unit to start an instance of the desired test software package.
  • the test software server also 209 sends a command back to the customer's computer to start an instance of the test software client.
  • the test software server receives a code indicating that the client has connected.
  • the test software server 217 copies the video, audio " and other output of the test software server computer, and 219 filters and eliminates any output not associated with the corresponding test software session.
  • the test software server 221 then encodes the output remaining into packets and transmits these packets to the customer's computer, which then directs these packets to the client program.
  • the client program 223 decodes the packets received and directs the decoded output to the rendering engine or video RAM of the customer's computer for normal processing. After normal processing of the video, sound and other output, 225 the client program displays the rendered output through their associated devices.
  • Visual output is displayed on the customer's monitor in the form of a window on top of the customer's computer's desktop, aural output is displayed through speakers connected to the associated sound or multimedia card.
  • This process of copying output, filtering and eliminating extraneous output, transmitting to the client program, decoding the packets received, directing the decoded output to the proper device processor, and display on the appropriate devices is described in greater detail, with respect to FIG.3, below.
  • Another method of filtering and eliminating extraneous video output only is described in greater detail, with respect to FIG. 4, below.
  • the customer interacts 227 with the client program window, the client 229 translates those commands from the local computer directed to the client program window into packets to be sent to the server.
  • the test software server 231 decodes the packets received from the client program and may filter and eliminate any commands not associated with the test software session. Through this filtration and elimination only commands that are directed at interaction with the test software session are allowed to pass from the client program window, through the client, to the test software server, and on to the test software session. These commands are those that allow the user to use the software, such as manipulating data, typing text, performing calculations, and the like. These commands will normally be keyboard strokes and mouse scrolls and clicks. With proper filtration and elimination, commands directed at the test software server computer's operating system or any other process not related to the software package process that is properly eliminated and filtrated are not processed.
  • test software server be the system component that performs the filtration and elimination of commands not directed to or associated with the test software session. This is because the test software client, unlike the test software server, will be distributed to the public, and therefore could be altered so that any commands could passed to the test software server computer for execution. This security risk is eliminated when the test software server filters and eliminates commands not associated with the test software session, as the public will not have access to the test software server program.
  • the test software server 233 After filtration and elimination of commands not directed to interaction with the test software session, the test software server 233 passes the remaining commands to the test software session. If 235 those commands passed to the test software session include a command to terminate the test software session, then 237 the test software session terminates and the connection between the test software client and test software server is severed. If the commands passed to the test software session do not include a command to terminate the test software session, then 215 the test software session executes the commands received. At this point, steps 217 - 235 are repeated until an end session command is received and the test software session terminates and the connection between test software client and test software server is severed.
  • HOP Internet Inter-ORB Protocol
  • CORBA Common Object Request Brokerage Architecture
  • ORB Object Request Broker
  • CORBA uses HOP to make communications over the Internet.
  • the HOP embodiment is the preferred embodiment due to its scalability.
  • a customer perusing a software vendor web site list of available test software packages 203 selects a software package to test.
  • the test software server 205 receives the customer's request and 207 executes a test software package process.
  • the test software server 209 sends a command to the customer's computer to start the test software client.
  • the customer must have the HOP client in order to use this embodiment. If the customer does not have the HOP client resident on his local computer, then 239 he will be directed to a web location where the client may be downloaded.
  • the customer 241 downloads, installs and configures the client program and then repeats steps 203 - 209.
  • the HOP client program 213 executes and connects to the test software server.
  • the test software server 217 copies the output of the test software server computer and 219 filters and eliminates any output not associated with the corresponding test software session.
  • the test software server 221 encodes the remaining output using the CORBA standard, and sends HOP packets containing the encoded output of the software session to the HOP client on the customer's computer. These packets are 223 translated by the HOP client into a format compatible with the native operating system on the customer's computer.
  • the packets are 225 rendered into aural, visual and other elements through the appropriate rendering engines and devices. 227
  • the customer interacts with the window session through mouse clicks, mouse scrolls, and keyboard strokes.
  • These commands are then 229 encoded by the HOP client into CORBA standard packets and sent back to the software session being hosted on the test software server.
  • the test software server 231 translates the packets received into a format compatible with the native operating system of the test software server computer and usable by the software program being tested, and filters and eliminates extraneous commands.
  • the remaining commands contained in the decoded packets are 233 sent to the test software session. These commands are 215 executed by the test software session. Steps 217 - 233 are repeated until the customer 235 sends a termination command 237 ending the test software session.
  • ActiveXTM is a set of MicrosoftTM object-oriented program technologies. Its main technology is the Component Object Model ("COM").
  • COM When used in a client- server environment, COM allows interoperability of program objects on different platforms and/or written in different languages. Its function is the same as that of CORBA, providing interoperability between program objects written in different languages and residing on different platforms.
  • This embodiment operates the same as that detailed in the HOP/CORB A embodiment detailed above, but that instead of ⁇ OP/CORBA being used, ActiveX uses COM as the standard for transport on top of TCPIP.
  • 201 a customer perusing a software vendor web ,site list of available test software packages 203 selects a software package to test.
  • the test software server 205 receives the customer's request and 207 executes a test software package process.
  • the test software server 209 sends a command to the customer's computer to start the test software client. 211
  • the customer must have the ActiveX client in order to use this embodiment. If the customer does not have the ActiveX chent resident on his local computer, then 239 he will be directed to a location where the client may be downloaded.
  • the customer 241 downloads, installs and configures the chent program and then repeats steps 203 - 209. 213
  • the ActiveX client program executes and connects to the test software server.
  • the test software server 217 copies the output of the test software server computer and 219 filters and eliminates any output not associated with the corresponding test software session.
  • the test software server 221 encodes the remaining output using the COM standard and sends ActiveX packets containing the encoded output of the software session to the ActiveXTM client on the customer's computer. These packets are 223 translated by the ActiveXTM client into a format compatible with the native operating system on the customer's computer. The packets are 225 rendered into aural, visual and other elements through the appropriate rendering engines and devices. 227 The customer interacts with the window session through mouse clicks, mouse scrolls, and keyboard strokes. These commands are then 229 encoded by the ActiveXTM client into COM standard packets and sent back to the test software session being hosted on the test software server.
  • the test software server 231 translates the packets received into a format compatible with the native operating system of the test software server computer and usable by the software program being tested and filters and eliminates extraneous commands.
  • the remaining commands contained in the decoded packets are 233 sent to the test software session. These commands are 215 executed by the test software session. Steps 217 - 233 are repeated until the customer 235 sends a termination command 237 ending the test software session.
  • JavaTM is a Sun MicrosystemsTM technology that allows the creation of JavaTM applets.
  • JavaTM applets are programs which, when run on a computer that contains a JavaTM virtual machine, are platform independent.
  • a JavaTM applet can be written for any platform and then compiled into bytecode.
  • the JavaTM virtual machine (which comes standard with most HTTP browsers, i.e. recent versions of Netscape NavigatorTM and Microsoft Internet ExplorerTM) then dynamically translates the bytecode into binary code executable on the computer that contains the JavaTM virtual machine.
  • the JavaTM applet will then run on the local computer and serve as the test software chent.
  • JavaTM applets require a web based embodiment of the present invention.
  • a customer viewing a software vendor's web site 203 selects an appropriate hyperlink or other command requesting to test a software package.
  • the test software server 205 receives the customer's request and 207 executes the selected test software package.
  • the test software server then sends a 209 JavaTM applet package to the customer's computer.
  • the browser the customer is using is JavaTM enabled, then the JavaTM applet 213 loads into the JavaTM virtual machine and is translated into the platform-appropriate binary code and is executed.
  • the JavaTM applet connects to the test software server. If the customer's browser is 239 not JavaTM enabled, then the customer is prompted to procure a browser that supports JavaTM- technologies.
  • test software server 217 copies the output of the test software server computer and 219 filters and eliminates any output not associated with the corresponding test software session.
  • the test software server 221 encodes the remaining output and sends the TCP/IP packets containing the encoded output of the software session to the JavaTM applet on the customer's computer. These packets are 223 translated by the JavaTM applet into a format compatible with the native operating system on the customer's computer.
  • the packets are 225 rendered into audio, visual and other elements through the appropriate rendering engines and devices.
  • the customer interacts with the test software session through the applet window with mouse clicks, mouse scrolls, and keyboard commands. These commands are then 229 encoded by the applet into standard TCP/IP packets and sent back to the test software server.
  • the test software server 231 translates the packets received into a format compatible with the native operating system of the test software server computer and usable by the software program being tested, and filters and eliminates extraneous commands.
  • the remaining commands contained in the decoded packets are 233 sent to the test software session. These commands are 215 executed by the test software session. Steps 217 - 233 are repeated until the customer 235 sends a termination command 237 ending the test software session.
  • Plug-ins are programs which have their functions integrated into an HTML file through a HTTP browser. Accordingly, this embodiment will be web based.
  • plug-in programs are platform dependent. This means that a plug-in containing the functionality needed for the present invention has to be written and compiled for each platform.
  • the plug-in is a chent program running through a web browser that interfaces with the server program to allow the testing of software packages.
  • 201 when a customer desires to test a software package, 203 he selects a test hyperlink on the vendor's web site. Selecting this test hyperlink directs the test software server to 207 execute an instance of the desired test software package.
  • the test software server then 209 sends a command to customer's computer to start the appropriate plug-in that will interface with the test software server. If 211 the customer's computer does not contain the appropriate plug-in, 239 the customer is prompted to download and install the plug-in in order to test the software package. 241 The customer then downloads, installs and configures the plug-in.
  • the test software server copies the video and other output of the test software server computer, 219 filters and eliminates any output not associated with that test software session, and 221 encodes and transmits the remaining output to the plug-in.
  • the plug-in receives and 223 decodes the encoded packets and directs the decoded output to the appropriate processing devices, such as video RAM and sound card.
  • the rendered output 225 of the processing devices is displayed through the customer's momtor, speakers, etc.
  • the customer 227 interacts with the test software session through the browser/plug-in window.
  • the customer's commands are 229 encoded by the plug-in and are transmitted to the test software server.
  • the test software server 231 decodes the received commands and filters and eliminates any commands not directed to the test software session.
  • the test software server 233 sends the remaining commands to the test software session.
  • the test software session 215 executes the commands received. Steps 217 - 233 are repeated until the customer 235 sends an end session command and 237 terminates the testing session, or until the connection between the test software server and plug-in is lost and times-out.
  • Virtual Network ComputingTM (“VNC”) is an AT&T software package that allows a local computer to display and interact with the desktop of a remote computer. The remote computer must be running the VNC server , and the local computer must be running the VNC chent. Current commercial versions of VNC use the TCP/IP transport layer, although other transport protocols have and could be developed.
  • VNC client session When a person using VNC wishes to view and interact with a remote computer, they start a VNC client session. If the user fails to specify a host name (which must be resolvable into a fully-qualified domain name or numerical IP address) for the VNC server at runtime, then the VNC viewer session will request one. It is necessary to supply the VNC viewer with the location of the remote host machine (through a host name, fully-qualified domain name or IP address) in order for the viewer to know where to establish a connection. In this embodiment, the test software server will supply its IP address to the customer's VNC client. After the remote host computer containing the VNC server is located, a connection is established between the VNC server and the VNC viewer.
  • the VNC server and a custom server layer comprise the test software server.
  • the custom server layer contains functions for filtering and eliminating output not associated with a test software session, and filtering and eliminating commands not associated with a test software session.
  • a customer perusing a software vendor's web site 203 selects a software package to test.
  • the test software server 205 receives the customer's request and 207 executes a test software package process.
  • the test software server 209 sends a command, including the IP address of the test software server, to the customer's computer to start the VNC client.
  • an error code is returned to the test software server and the customer is prompted to download the VNC client.
  • the VNC client 213 executes and connects to the test software server.
  • the test software server 217 copies the output of the test software session and 219 filters and eliminates any output not associated with the corresponding test software session.
  • the test software server 221 encodes the remaining output and sends the packets containing the encoded output of the software session to the VNC client on the customers computer. These packets are 223 translated by the VNC client into a format compatible with the native operating system on the customer's computer and directed to the appropriate processing devices. The packets are 225 rendered into aural, visual and other elements through the appropriate rendering engines and devices. 227
  • the customer interacts with the test software session through mouse clicks, mouse scrolls, and keyboard strokes via the client window. These commands are then 229 encoded by the VNC client into packets and sent back to the software session being hosted on the test software server.
  • the test software server 231 translates the packets received into a format compatible with the native operating system of the test software server computer and usable by the software program being tested, and filters and eliminates extraneous commands.
  • the remaining commands contained in the decoded packets are 233 sent to the test software session.
  • the test software 215 session executes the commands received. Steps 217 - 233 are repeated until the customer 235 sends a termination command to the test software session and the test software session 237 terminates.
  • the VNC server contains a small web server that can serve Java classes needed to make a browser connection. If this function of the VNC server is used, the customer, after deciding to test the software package, selects the hyperlink for testing. Thisiiyperlink points to the URL and port number where the VNC server is listening. The VNC server listens to sets of port numbers (e.g. 5800 and above) for connection requests. When the customer selects the hyperlink, the VNC server accepts the connection and sends the desktop display to the customer through an applet. The customer may then interact with the desktop through the applet. The session operates like the Java applet embodiment detailed above.
  • PC AnywhereTM is a software package marketed by Symantec CorporationTM that allows a user to connect to a remote computer via modem, Internet, and other remote connection services.
  • PC AnywhereTM allows a user to operate a remote computer as if the individual were sitting at a local terminal. It is much like VNC in its capabilities.
  • PC Anywhere server software must be installed on the remote computer the user wishes to connect to, and the PC Anywhere client software must be installed on the local computer the user wishes to connect from.
  • a custom software layer runs on top of the server, and both the PC Anywhere server and the custom server layer comprise the test software server.
  • the custom server layer contains functions for filtering and eliminating output not associated with a test software session, and filtering and eliminating commands not associated with a test software session.
  • a customer perusing a software vendor's web site 203 selects a software package to test.
  • the test software server 205 receives the customer's request and 207 executes a test software package process.
  • the test software server 209 sends a command to the customer's computer to start the PC AnywhereTM client.
  • the test software server 209 sends a command to the customer's computer to start the PC AnywhereTM client.
  • 211 If the PC AnywhereTM client is not installed on the customer's local computer 239 an error code is returned to the test software server and the customer is prompted to download the PC AnywhereTM client.
  • the PC AnywhereTM client 213 executes and connects to the test software server.
  • the test software server 217 copies the output of the test software server computer and 219 filters and eliminates any output not associated with the corresponding test software session.
  • the test software server 221 encodes the remaining output and sends the packets containing the encoded output of the software session to the PC AnywhereTM client on the customer's computer.
  • These packets are 223 translated by the PC AnywhereTM client into a format compatible with the native operating system on the customer's computer and directed to the appropriate processing devices.
  • the packets are 225 rendered into audio, visual and other elements through the appropriate rendering engines and devices. 227
  • the customer interacts with the test software session through mouse clicks, mouse scrolls, and keyboard strokes via the client window.
  • These commands are then 229 encoded by the PC AnywhereTM client into packets and sent back to the test software session being hosted on the test software server.
  • the test software server 231 translates the packets received into a format compatible with the native operating system of the test software server computer and usable by the software program being tested, and filters and eliminates extraneous commands.
  • the remaining commands contained in the decoded packets are 233 sent to the software session.
  • the test software 215 session executes the commands received. Steps 217 - 233 are repeated until the customer 235 sends a termination command to the test software session and the test software session 237 terminates.
  • a non-web based embodiment of the present invention is also possible.
  • the customers does not need a web browser to utilize the system.
  • a custom test software client program is required to test any software packages.
  • This client program would contain all the functionality of the web based client necessary to the present invention, including functions for decoding transmissions from the test software server, passing commands to the appropriate processing devices, receiving commands from the customer, and encoding and transmitting commands received back to the test software server, but would also include other functions unique to a non-web based embodiment.
  • the client would have a function for locating the software server, a function for listing what test software packages are available, and a function for calling up desired test package.
  • the custom test software client must be downloaded and installed on the customer's computer prior to any utilization of this embodiment.
  • a customer 501 starts the custom test software client and connects to a test software server. Data on what test programs were available for testing is transmitted directly to the client from a test software server. This list of test programs is sent to the client, via TCP/IP or other protocols, in the form of an ASCII delimited text file. The list of test programs available are then displayed to the customer through the client window. The customer 503 selects which test program is desired from the client window via mouse click or keyboard stroke. The test software server 505 receives the test session request. The session now proceeds much like the web-based embodiment. The test software server 507 starts up a test software session and 511 copies the video, audio and other output of the test software server computer.
  • the test software server then 513 filters and eliminates any extraneous output.
  • the remaining video, audio and other output 515 is converted into packets and transmitted to the test software client running on the customer's local computer.
  • the test software client 517 decodes the packets into native format and directs the decoded output to the appropriate processing devices.
  • the rendered output 519 is then displayed via monitor, speaker, and other output devices.
  • the customer 521 interacts with the test software session through the chent window via mouse scrolls, mouse clicks, and keyboard strokes.
  • the client 523 encodes these commands into packets and transmits those packets to the test software server.
  • the test software server 525 decodes the packets and filters and eliminates commands not associated with the test software session.
  • This filtering and ehminating of commands can also be accomplished by the test software client prior to encoding and transmission of the commands to the test software server. However, it is preferred that the test software server do the filtering and eliminating of extraneous commands.
  • the server After converting the command packets and filtrating and eliminating extraneous commands, 527 the server passes the commands to the associated test software session.
  • the test software 509 session processes the commands. Steps 511 - 527 are repeated until 529 an end session command is sent by the customer to the test software session. When an end session command is received 531 the test software session terminates. The customer may then 501 peruse the list of available test software packages and 503 select a new package to test. This can continue until the connection between the test software server and test software client is lost.
  • test software server computer which is not related to the test software session is filtered out and eliminated. This is necessary so that only output from the test software session is transmitted to the customer. Without a method of filtering and eliminating output extraneous to the test software session, the entire desktop of the server machine, including any programs running on top of the desktop, would-be displayed to the customer. Further, any other output from device drivers resident on the test software server computer could be passed to the client program, providing output to the customer not associated with the test software session. This would make testing the software package difficult.
  • the entire visual and other output of the server computer 300 is passed to 302 the server computer's rendering engines.
  • the rendering engine is the graphics rendering engine.
  • the rendering engine is the device drivers associated with certain devices, such as a sound card or multimedia card. The rendering engines translate the binary output into a form capable of processing by 312 the display and other device drivers.
  • the output of 302 the rendering engines is grabbed by 304 the test software server and duplicated by 306 a copying module.
  • One copy of the rendering engine output 305 is directed to 312 the video RAM and other device hardware components, such as a sound card, of the test software server computer for normal processing and transmission to 314 the test software server computer's monitor and other devices.
  • the other copy is directed to 308 a program module that filters out and eliminates any output not associated with the test software session.
  • the resulting output stream 311 is directed to 310 a program module for converting video and other output into packets for transmission to the customer's computer. These packets, 313, are sent first to 316 the server computer's network interface device and then out to 315 the Internet or other computer network.
  • These packets are routed to 318 the customer's computer's network interface device, and then directed to 320 the test software client.
  • 322 The chent program's conversion module converts the received packets into native output usable by the customer's local computer. This output is then directed to 324 video RAM and other device hardware components for normal processing and transmission to 326 the customer's monitor and other output devices. This method of filtering and eliminating output not associated with the test software session is repeated for every transmission of the test software session's output to the client on the customer's computer.
  • FIG. 4 what is illustrated is another method of filtering and eliminating visual output not associated with the test software session.
  • This method is operable for transmissions between the server computer and the customer's computer where both are running Microsoft Windows 95TM, 98TM, or NTTM operating systems, or other operating systems compatible with these MicrosoftTM operating systems.
  • the entire visual output of the server computer 400 including the desktop and windows from the test software session and other programs, is passed directly to 402 the test software server.
  • the visual output of the server computer, 401 consists of information in Windows MetafileTM format (“WMF") or enhanced MetafileTM 1 format (“EMF").
  • a WMF or EMF file contains graphical-device-interface function calls that enable the visual output of the associated program session to be displayed as a graphic image on a monitor.
  • the copying module of the test software server duplicates the visual output.
  • One copy of the visual output, 407 is sent to 410 the server computer's rendering engine for normal processing.
  • the other copy, 403 is directed to 406 a program module that filters and eliminates any visual output not associated with the test software session. After the extraneous output has been filtered and eliminated, the remaining output, 405, is converted by 408 the test software server's conversion module into packets for transport over the Internet or other computer network to the customer's computer.
  • the packets, 413 are sent first to 416 the server computer's network interface device and then out to 415 the Internet or other computer network.
  • the packets are routed to the customer's computer and received 417 by the customer's computer's 418 network interface device.
  • the packets 419 are directed to 420 the test software client.
  • the test software chent's 422 conversion module converts the packets back into metafiles and 421 directs them to the customer's computer's 424 rendering engine for normal processing.
  • the resulting output 423 is then directed to 426 video RAM for normal processing and transmission to 428 the customer's monitor. This method of filtering and eliminating extraneous audio and video output of the server computer is repeated for each transmission of audio and video output of the test software session to the customer's local computer.

Abstract

The present invention is a computer network-based method for allowing prospective users to test software programs. The method provides for a potential user of software programs to request a test session from a test software server. The test software server resides on a server computer maintained by the software vendor or third-party. The test software server causes the selected software package to be executed. The test software server checks to ensure that the potential user has the appropriate test software client. The test software client resides on the potential user's local computer. A network connection is established between the test software server computer and test software client computer. The test software server gets the output of the tests software session, filters and eliminates any output not associated with that test software session, encodes the output for network transmission, and passes the encoded output to the test software client.

Description

A METHOD AND SYSTEM OF ALLOWING PROSPECTIVE USERS TO TEST AND USE SOFTWARE VIA A COMPUTER NETWORK
BACKGROUND OF THE INVENTION
FIELD OF THE INVENTION
The present invention relates to a system and method for computer software distribution through the testing and using of computer software over a computer network.
DESCRIPTION OF THE PRIOR ART The sale of computer software is a multibillion-dollar industry. Many millions of dollars each year are spent on advertisements for software packages. The best advertisements impart the most information to a potential user of the software advertised. Potential users of computer software want information on the computer software prior to purchase or installation of the software. Information has been typically gathered through pamphlets, periodicals, and other literature describing the software. Certain televisions programs that demonstrate and review software have been directed at the computer software consumer. These television shows are another way potential users of software can gather information on software package. Software development companies and software vendors also provide information on computer software on the software packaging. However, the literature often cannot adequately describe all the features of a software package. Certainly, a written description cannot impart the total look and feel of the software package to a potential user. On account of these limitations of written descriptions of a software package, potential users often desire to test the software package prior to its procurement. In response to this customer desire, the software distribution industry has developed numerous methods to allow a potential user of software to test a software package prior to its procurement. Software vendors often set up computers with various software packages at vendor locations. These software packages can then be tested by potential users who use a test computer containing the desired software package. However, this method of allowing software testing prior to procurement requires that a prospective user travel to the vendor location. Further, the number of test computers is often limited, so that a potential user may have to wait for a test computer to become available.
Software vendors also distribute demonstration versions of software packages. These-demonstration versions are stripped-down versions of the software package, and do not contain the full functionality of the software package. Demonstration versions impart to a potential user of the software package the look and feel of the software package. However, demonstration versions, because of their lack of full functionality, do not provide a potential user with a complete experience of the software package. Software vendors have also provided fully functional software packages to potential users for testing purposes. These software packages usually contain some method of security whereby the software package can only be used a limited number of times or for a limited period. These software packages also normally contain some form of security that restricts copying or alteration of the test software package so that a potential user cannot transform the test software package into a software package without restrictions, and thereby obtain a free copy of the software package. One method of distributing test software with such security is disclosed in U.S. Patent No. 5,689,560, which is hereby incorporated by reference.
Several drawbacks exist with both demonstration and fully functional test versions of software packages. First, a potential user of a software package must receive the software package via some medium. The prospective user must also install the software on to his or her home computer. Installation takes up hard drive space. If the current hard drive space on the potential user's system is insufficient, then he or she will have to delete files or procure a larger or additional hard drive so the test software package may be installed. Installation also normally requires the prospective user to end all other programs that might be running so that process conflicts, which may create fault block errors or other processing errors, do not occur. This is required so that the installation will be successful. Often, a prospective user will have to reboot his or her home computer after installation. A prospective user may also find himself or herself in the position of having to configure the test software and local computer prior to and or after the test software has been installed. The difficulty of configuration can range from trivial, such as selection of file and folder names and/or locations, to serious, such as where batch files must be edited or device drivers installed. Configuration is often required to allow test software to interact properly with a particular operating system, other program modules, and/or peripherals. Configuration is also usually needed in order for the test software to run optimally. Further, after the prospective user is done testing the software, he or she will normally want to uninstall and remove the test software package. Not only may the test software program files need to be deleted, but whatever steps were undertaken during configuration of that test software package may need to be undone as well. Software vendors have employed various means of distributing both demonstration and fully functional test versions of software packages. A software vendor may provide a magnetic or optical disk(s) containing single or multiple test software packages. One method of allowing customers to test software is disclosed in US Patent No. 5,689,560, which is hereby incorporated by reference. Software vendors may also install test software packages on computer hard drives prior to purchase of the computer. Recently, software vendors have began to distribute test software packages online, including distribution over the Internet. One such method of online software distribution is disclosed in U.S. Patent No. 5,883,955, which is hereby incorporated by reference.
As computer users increasingly gain access to the Internet, Internet distribution of software is rapidly becoming the method of choice for software distribution. Software vendors typically maintain web sites that contain information on various software packages. The main benefit of Internet distribution over traditional distribution channels is the convenience with which potential users can receive information on and procure a software package. A potential user of software does not need to leave their home or office in order to receive information on and procure software. Further, the World Wide Web is a central resource for information on software packages, making it easy for a potential user of software to quickly gather information on many different types and makes of software.
Information about software packages can be maintained online in several different forms. Modem-accessible bulletin boards are one example. Another example is an anonymous File Transfer Protocol ("FTP") site. Currently, the preferred method of maintaining and distributing information online is through the use of World Wide Web pages ("web pages"). Web pages are files that contain instructions written in Hypertext Markup Language ("HTML"), as well as text contained in standard ASCII format. HTML files are normally sent over the Internet using Hypertext Transfer Protocol ("HTTP") on top of Transmission Control Protocol Internet Protocol ("TCP/IP"). Web browsers, such as Netscape Navigator, Microsoft Internet Explorer, and others, translate HTML into a graphical display containing text, images, sound, and hyperlinks. Hyperlinks are interactive text or images that, when selected, will execute any command associated with that link. Such commands include, but are not limited to, loading another web page in a browser, downloading a file(s), or starting another process on either a remote or local machine.
One method of remotely executing a command via web pages is disclosed in U.S. Patent No. 5,898,835 (hereinafter, "the '835 patent"), which is hereby incorporated by reference. However, the '835 patent only discloses a method whereby the output of the remotely executed command is returned to the remote user via an HTML encoded web page. This method of returning the result of a user's request is limited by the nature of HTML web pages in that input via HTML web pages is limited to selecting hyperlinks and filling in form fields. HTML web pages are also limited in that their layout is inherently restricted by HTML code and its interpretation by a browser; the same HTML web page can vary in appearance from web browser to web browser and from platform to platform. Further, the '835 patent allows any command to be passed to the remote server. This presents a grave security risk should an unauthorized individual gain access. The '835 patent attempts to limit this risk through the authentication of a user ID and password. However, utilizing user IDs and passwords takes up administrative resources ,through such tasks as setting up user accounts, mamtaining user accounts, checking log files for unauthorized connection attempts, protecting against fraudulent connections, and other system administration tasks, that could be dedicated elsewhere. Further, user ID and password authentication takes up additional system resources that can lengthen the time required to make a connection and can slow down processing time that can be dedicated to other functions. The maintenance of a web page by software vendors allows customers who have access to the Internet to retrieve and peruse desired information at any time from virtually any location. Further, if a software vendor wishes to provide test software packages, the vendor can place those test software packages in a location from where they may be accessed and downloaded through the web server. These download locations could be listed as hyperlinks that a potential user of the software package can select and thereby initiate a download of the test version directly from a vendor's Internet site via File Transfer Protocol ("FTP"), or other file transfer method.
— However, several difficulties present themselves with methods that require a prospective software user to download a test software package. The prospective user must wait while the test software is being downloaded. Depending on the file size of the test software and the speed of the potential user's connection to the Internet or Internet service provider ("ISP"), download times can range from short to substantial, sometimes taking up to several hours to complete. Most individuals using the Internet from home have a modem connection to an ISP. These modem connections use analog phone lines to transmit information between the individual's computer and the ISP. Currently, the maximum download speed using such a system is fifty-three thousand bits per second. To provide an example of download times, a prospective user wishing to test Netscape Communicator 4.51 for Windows 95, English Version, Complete Install would have to download a one hundred and twenty million bit file. At fifty-three thousand bits per second, this download would take almost thirty-eight minutes. If the prospective user has a slower connection, this time could be greatly increased. Downloading also requires the prospective user to allocate sufficient hard drive space to accommodate the test software file(s). If sufficient hard drive space is unavailable, the prospective user will have to delete other files, or acquire a larger or second hard drive, to make room for the test software package.
The same difficulties that exist with respect to traditional distribution of test software also exists with respect to Internet . A prospective user must install the software on his or her local machine. Again, if current hard drive space is insufficient, a prospective user will have to delete files or procure a large or additional hard drive so the test software package may be installed. A prospective user may also need to configure the test software and local computer prior to and/or after it has been installed. The prospective may also need to remove the test software package after completing the test.
All of the above mentioned task that may have to be performed prior to a prospective user being able to use any test software can detract from the marketing of the software package. A prospective user who is uncomfortable with performing these operations, or unknowledgeable about how these operations may be undertaken, may forego testing the software. This, in turn, leads to a decreased likelihood that the prospective user will become an actual user of the software package.
SUMMARY OF THE INVENTION The principle object of the present invention is to allow a prospective purchaser of a software package to test the software prior to purchase without having to download, install, configure, or remove the test software package.
Another object of the present invention is to allow a prospective user of freeware to test the freeware prior to procurement without having to download, install, configure, or remove the freeware. Briefly, these objectives are achieved by the present invention through the use of custom server-client layers that deliver, receive, and process datagrams. These datagrams are transmitted over a computer network using certain communication protocols.
BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a diagram of components for a preferred system for testing software over a computer network. FIG. 2 is a flow chart of a preferred web based test software server-client system.
FIG.3 is a conceptual flow chart of a preferred method of filtering and eliminating extraneous test software session output.
FIG. 4 is a conceptual flow chart of a preferred method of filtering and eliminating extraneous visual test software session output.
FIG. 5 is a flow chart of a preferred non-web based test software server-client system.
DETAILED DESCRIPTION OF PREFFERED EMBODIMENT OF INVENTION
This method allows a customer to test a software package prior to purchase or procurement without having to download, install, configure, or remove the software on their local computer. When a customer is looking for software, he calls up the web site of the software vendor. The web site normally consists of HTML commands, dynamic and static images, sounds, streamed video and audio, common gateway interface ("CGI") script, and applets. The software vendor is likely serving up its web pages using an HTTP web server. The customer is likely using a standard HTML browser, such as Netscape Navigator™, Microsoft Internet Explorer™, or any other browser that is or may be developed. However, should a new markup language be developed (example, virtual-reality markup language, "VRML") and come into common use, these web servers, browsers and associated transfer protocols may be used as well. Alternatively, a non-web based embodiment is contemplated where web sites and HTML pages are not necessary to the present invention. The non-web based embodiment is described in detail below.
Referring now to FIG. 1, the present invention's system consists of 100 server computer(s) and 112 customer's local computer connected over a 110 network. For the purposes of this description of the preferred embodiment, the term computer refers to a general purpose digital computer. General purpose digital computers are comprised essentially of a data processing unit, memory storage devices, input devices, and display devices. A data processing unit manipulates data bits according to an instruction set provided to it. The data processing unit then outputs the resulting data bits. Both input data bits and output data bits, as well as the manipulative instruction set, are stored by a memory storage device. Memory storage devices include random access memory for temporary storage and use by the data processing unit, read-only memory for permanent storage and use by the data processing unit, and a mass storage device for storing large numbers of data bits for eventual use by the data processing unit. Mass storage devices are capable of containing large numbers (>108) of data bits, and include floppy magnetic disks, hard magnetic disks, and optical disks. Input devices allow a computer user to provide data bits for processing by the data processing unit. Input devices include keyboards, disk drive controllers, track-balls and mice, digital cameras, and sound recording devices. Another input device necessary for the present invention is, referring to FIG. 1, 106, 116, a network interface device. A network interface device, such as a modem or network interface card, allows a computer to be connected to a computer network. Computers with network interface devices can transfer data bits to other computers connected to the same computer network. Display devices allow a computer user to see and hear, or otherwise utilize the output of the computer, and include monitors and speakers. 110 The preferred network is the Internet.
100 The server computer(s) contain 102 test software server, 104 test software package(s), 106 network interface device, and, in embodiments described herein that are web-based, 108 web server. 100 One reason multiple server computers are possible is because it is not necessary that the computer containing the software vendor's test software server and test software package(s) be the same computer as that containing the vendor's web server, so long as a network connection exists between the server computers containing those packages. 102 The test software server software is a program that, after receiving a command, starts a process, that being an instance of the desired software package to be tested, sends a command to the customer's local computer to start a client process, filters and eliminates any output not associated with the test session process, encodes the remaining output for transmission, transmits any visual or other output of the test software session to the test software client, receives command datagrams from the test software client, translates the received datagrams into binary code usable by the test software session program, may filter and eliminate any commands not directed to the test software session process or associated processes, and passes the remaining commands to the test software session process or associated processes. The test software server may be comprised of a wholly custom program or a combination of custom and off-the-shelf programs. Multiple processes of the same or different software packages can be running on the server at any one time.
The web server 108 can be any off-the-shelf product that allows a server computer to spawn a process upon an HTTP, HOP, or other request sent to the web server. Such web servers include APACHE™, Microsoft IIS™, Netscape
Enterprise™, and most other commercially available web servers. The operating system of the web server computer can be any operating system that will run a required web server, including: Apple MacOS™, Microsoft Windows 9X™, Microsoft Windows NT™ Server 3.0 and above, Microsoft Windows NT Workstation™, and any flavor of UNIX™ (i.e. Solaris™ 2.x and above, HPUX™, Linux™, AIX™, etc.). A conventional computer could be used as the web server computer, but as the amount of connections increase, so to will the system requirements. If the web server computer is going to also be the test software server computer hosting the software package sessions then the system requirements increase. The preferable minimum data processing unit requirements is a Pentium π™ 400 MHz processor, or comparable Cyrix™ or AMD™ processors. For non-x86 architecture chips (those chips not running Microsoft Windows™ 9x or NT™ operating systems), equivalent processors include the Motorola 120 MHz PowerPC 604™"or the Sun Microsystems™ 167 MHz UltraSPARC-I™ chips. The preferable rriinimum RAM requirement is 64 megabytes. The preferable mass storage requirement is 1 gigabyte, which can be tape, magnetic disk, optical disk, or any other storage medium. Input devices, such as a keyboard and mouse, as well as a network interface device are preferred. The test software server computer, as mentioned above, can be the same computer as the web server computer, or may be a separate computer. The minimum system requirements for a separate test software server computer are the same as that of the web server computer. In order to host the program sessions, the test software server computer either runs or emulates the native operating system of the software (i.e. Apple MacOS™, Microsoft Windows™ 9x or NT™, etc.).
Still referring to FIG. 1, 112, the customer's computer contains 114 test software client, 116 network interface device, and, in embodiments described herein that are web-based, 118 web browser. The test software client ("client program") 114 is a program which interacts with the test software server to provide the customer with the appearance of a real-time, or near real-time, interactive program window of the selected test software package. The client program includes a client window through which the customer interacts with the software session running on the server. The customer interacts with the client program window through keyboard strokes, mouse scrolls and clicks, and other device input normally associated with the operation of application software. The client receives datagrams ("packets") from the server and translates those datagrams into binary code useable by the customer's local computer. These packets contain the visual and aural elements of the software interface, as well as other output of the test software session. The packets are rendered on the local computer, after decoding by the client program, to give the user the appearance of the software interface. After the customer has enter commands through the client program window the client: may filter and eliminate commands not directed to the test software session, encodes the commands, and transmits the encoded commands to the test software server. The client program window can be a window on top of the locarcbmputer's operating system. As described below, with this invention different types of clients using different protocols are possible. The customer's computer can be any computer that will run the required client program, and web browser for the web based embodiments, and support 116 network interface device.
Referring now to FIG. 2, what is depicted is the preferred web based method of practicing the present invention. 201 A customer viewing a software vendor's web site wishes to test a software package he views through the software vendor's or other web site. She sends a command 203, via hyperlink or other method, from her local computer to the vendor's web site or test software server. This command is received 205, directly if sent to the test software server or indirectly if sent to the web site, by the test software server on the test software server computer. For indirect transmission, the web server contains a function for passing the received datagrams to the test software server. This function may be supplied by a CGI script. After the customer sends a request to the test software server to test the software, 207 the server sends a command to the test software server computer's data processing unit to start an instance of the desired test software package. The test software server also 209 sends a command back to the customer's computer to start an instance of the test software client.
Still referring to FIG. 2, 211 at this point, two possibilities exist. If the customer's computer has the proper client program resident, 213 the client is executed and connects to the test software server. However, if the customer's computer does not have the proper client program resident 239 an error code is returned to the test software server. Upon receiving this error code, the test software server transmits a prompt requesting that the customer download the appropriate client software. Upon selecting this download prompt the client program is downloaded to the customer's computer. The customer 241 installs and configures the client program. At this point the customer is able to utilize the test software server and returns to the vendor's web site, 203, and selects the software package. Steps 205, 207, 209, and 211 are repeated. Once the proper client program is started, the test software server receives a code indicating that the client has connected. The test software server 217 copies the video, audio" and other output of the test software server computer, and 219 filters and eliminates any output not associated with the corresponding test software session. The test software server 221 then encodes the output remaining into packets and transmits these packets to the customer's computer, which then directs these packets to the client program. The client program 223 decodes the packets received and directs the decoded output to the rendering engine or video RAM of the customer's computer for normal processing. After normal processing of the video, sound and other output, 225 the client program displays the rendered output through their associated devices. Visual output is displayed on the customer's monitor in the form of a window on top of the customer's computer's desktop, aural output is displayed through speakers connected to the associated sound or multimedia card. This process of copying output, filtering and eliminating extraneous output, transmitting to the client program, decoding the packets received, directing the decoded output to the proper device processor, and display on the appropriate devices is described in greater detail, with respect to FIG.3, below. Another method of filtering and eliminating extraneous video output only is described in greater detail, with respect to FIG. 4, below. The customer interacts 227 with the client program window, the client 229 translates those commands from the local computer directed to the client program window into packets to be sent to the server. The test software server 231 decodes the packets received from the client program and may filter and eliminate any commands not associated with the test software session. Through this filtration and elimination only commands that are directed at interaction with the test software session are allowed to pass from the client program window, through the client, to the test software server, and on to the test software session. These commands are those that allow the user to use the software, such as manipulating data, typing text, performing calculations, and the like. These commands will normally be keyboard strokes and mouse scrolls and clicks. With proper filtration and elimination, commands directed at the test software server computer's operating system or any other process not related to the software package process that is properly eliminated and filtrated are not processed. It is preferred that the test software server be the system component that performs the filtration and elimination of commands not directed to or associated with the test software session. This is because the test software client, unlike the test software server, will be distributed to the public, and therefore could be altered so that any commands could passed to the test software server computer for execution. This security risk is eliminated when the test software server filters and eliminates commands not associated with the test software session, as the public will not have access to the test software server program.
After filtration and elimination of commands not directed to interaction with the test software session, the test software server 233 passes the remaining commands to the test software session. If 235 those commands passed to the test software session include a command to terminate the test software session, then 237 the test software session terminates and the connection between the test software client and test software server is severed. If the commands passed to the test software session do not include a command to terminate the test software session, then 215 the test software session executes the commands received. At this point, steps 217 - 235 are repeated until an end session command is received and the test software session terminates and the connection between test software client and test software server is severed.
This system lends itself well to high bandwidth download/low bandwidth upload connections such as satellite down/modem back, cable modems, and the like. Any high bandwidth connection, such as Tl, T3, ISDN, etc., is more than sufficient for this system.
There are a number of embodiments for the present invention, varying in the type of server-client software that is to be used as well as the type of communication protocol that is used. These specific embodiments include: HOP over TCP/IP using CORBA, ActiveX, Java applets, plug-ins for a browser, Virtual Network Computing with a custom client layer, PC Anywhere with a custom client layer, and a non-web based custom server-client software package. πOP (Internet Inter-ORB Protocol) is an object-oriented protocol that allows programs written in different languages to communicate over the Internet. CORBA (Common Object Request Brokerage Architecture) is an architecture and specification for creating, distributing, and managing programs in a computer network. It allows programs written in different languages to communicate in a computer network through an interface broker, the Object Request Broker ("ORB"). ORB allows client programs (on computers in a client-server environment) to make requests of other programs without having to know the location or proprietary interface of the server program. CORBA uses HOP to make communications over the Internet. The HOP embodiment is the preferred embodiment due to its scalability. In this embodiment, referring to FIG. 2, 201 a customer perusing a software vendor web site list of available test software packages 203 selects a software package to test. The test software server 205 receives the customer's request and 207 executes a test software package process. The test software server 209 sends a command to the customer's computer to start the test software client. 211 The customer must have the HOP client in order to use this embodiment. If the customer does not have the HOP client resident on his local computer, then 239 he will be directed to a web location where the client may be downloaded. The customer 241 downloads, installs and configures the client program and then repeats steps 203 - 209. The HOP client program 213 executes and connects to the test software server.
The test software server 217 copies the output of the test software server computer and 219 filters and eliminates any output not associated with the corresponding test software session. The test software server 221 encodes the remaining output using the CORBA standard, and sends HOP packets containing the encoded output of the software session to the HOP client on the customer's computer. These packets are 223 translated by the HOP client into a format compatible with the native operating system on the customer's computer. The packets are 225 rendered into aural, visual and other elements through the appropriate rendering engines and devices. 227 The customer interacts with the window session through mouse clicks, mouse scrolls, and keyboard strokes. These commands are then 229 encoded by the HOP client into CORBA standard packets and sent back to the software session being hosted on the test software server. The test software server 231 translates the packets received into a format compatible with the native operating system of the test software server computer and usable by the software program being tested, and filters and eliminates extraneous commands. The remaining commands contained in the decoded packets are 233 sent to the test software session. These commands are 215 executed by the test software session. Steps 217 - 233 are repeated until the customer 235 sends a termination command 237 ending the test software session. ActiveX™ is a set of Microsoft™ object-oriented program technologies. Its main technology is the Component Object Model ("COM"). When used in a client- server environment, COM allows interoperability of program objects on different platforms and/or written in different languages. Its function is the same as that of CORBA, providing interoperability between program objects written in different languages and residing on different platforms. This embodiment operates the same as that detailed in the HOP/CORB A embodiment detailed above, but that instead of πOP/CORBA being used, ActiveX uses COM as the standard for transport on top of TCPIP. In this embodiment, referring to FIG. 2, 201 a customer perusing a software vendor web ,site list of available test software packages 203 selects a software package to test. The test software server 205 receives the customer's request and 207 executes a test software package process. The test software server 209 sends a command to the customer's computer to start the test software client. 211 The customer must have the ActiveX client in order to use this embodiment. If the customer does not have the ActiveX chent resident on his local computer, then 239 he will be directed to a location where the client may be downloaded. The customer 241 downloads, installs and configures the chent program and then repeats steps 203 - 209. 213 The ActiveX client program executes and connects to the test software server. The test software server 217 copies the output of the test software server computer and 219 filters and eliminates any output not associated with the corresponding test software session. The test software server 221 encodes the remaining output using the COM standard and sends ActiveX packets containing the encoded output of the software session to the ActiveX™ client on the customer's computer. These packets are 223 translated by the ActiveX™ client into a format compatible with the native operating system on the customer's computer. The packets are 225 rendered into aural, visual and other elements through the appropriate rendering engines and devices. 227 The customer interacts with the window session through mouse clicks, mouse scrolls, and keyboard strokes. These commands are then 229 encoded by the ActiveX™ client into COM standard packets and sent back to the test software session being hosted on the test software server. The test software server 231 translates the packets received into a format compatible with the native operating system of the test software server computer and usable by the software program being tested and filters and eliminates extraneous commands. The remaining commands contained in the decoded packets are 233 sent to the test software session. These commands are 215 executed by the test software session. Steps 217 - 233 are repeated until the customer 235 sends a termination command 237 ending the test software session.
Java™ is a Sun Microsystems™ technology that allows the creation of Java™ applets. Java™ applets are programs which, when run on a computer that contains a Java™ virtual machine, are platform independent. A Java™ applet can be written for any platform and then compiled into bytecode. The Java™ virtual machine (which comes standard with most HTTP browsers, i.e. recent versions of Netscape Navigator™ and Microsoft Internet Explorer™) then dynamically translates the bytecode into binary code executable on the computer that contains the Java™ virtual machine. The Java™ applet will then run on the local computer and serve as the test software chent. Java™ applets require a web based embodiment of the present invention.
Referring to FIG. 2, using the Java™ applets and a Java™ enabled HTTP browser, 201 a customer viewing a software vendor's web site 203 selects an appropriate hyperlink or other command requesting to test a software package. The test software server 205 receives the customer's request and 207 executes the selected test software package. The test software server then sends a 209 Java™ applet package to the customer's computer. 211 If the browser the customer is using is Java™ enabled, then the Java™ applet 213 loads into the Java™ virtual machine and is translated into the platform-appropriate binary code and is executed. The Java™ applet connects to the test software server. If the customer's browser is 239 not Java™ enabled, then the customer is prompted to procure a browser that supports Java™- technologies. 241 After the client procures, installs and configures a Java™ enabled browser, the customer repeats steps 201 - 209 and proceeds to step 213. The test software server 217 copies the output of the test software server computer and 219 filters and eliminates any output not associated with the corresponding test software session. The test software server 221 encodes the remaining output and sends the TCP/IP packets containing the encoded output of the software session to the Java™ applet on the customer's computer. These packets are 223 translated by the Java™ applet into a format compatible with the native operating system on the customer's computer. The packets are 225 rendered into audio, visual and other elements through the appropriate rendering engines and devices. 227 The customer interacts with the test software session through the applet window with mouse clicks, mouse scrolls, and keyboard commands. These commands are then 229 encoded by the applet into standard TCP/IP packets and sent back to the test software server. The test software server 231 translates the packets received into a format compatible with the native operating system of the test software server computer and usable by the software program being tested, and filters and eliminates extraneous commands. The remaining commands contained in the decoded packets are 233 sent to the test software session. These commands are 215 executed by the test software session. Steps 217 - 233 are repeated until the customer 235 sends a termination command 237 ending the test software session.
Plug-ins are programs which have their functions integrated into an HTML file through a HTTP browser. Accordingly, this embodiment will be web based.
Unlike the web based embodiment incorporating Java™ applets, plug-in programs are platform dependent. This means that a plug-in containing the functionality needed for the present invention has to be written and compiled for each platform. In this embodiment, the plug-in is a chent program running through a web browser that interfaces with the server program to allow the testing of software packages.
Referring to -FIG. 2, 201 when a customer desires to test a software package, 203 he selects a test hyperlink on the vendor's web site. Selecting this test hyperlink directs the test software server to 207 execute an instance of the desired test software package. The test software server then 209 sends a command to customer's computer to start the appropriate plug-in that will interface with the test software server. If 211 the customer's computer does not contain the appropriate plug-in, 239 the customer is prompted to download and install the plug-in in order to test the software package. 241 The customer then downloads, installs and configures the plug-in. 211 Once the proper plug-in is 213 executed and connects to the test software server, 217 the test software server copies the video and other output of the test software server computer, 219 filters and eliminates any output not associated with that test software session, and 221 encodes and transmits the remaining output to the plug-in. The plug-in receives and 223 decodes the encoded packets and directs the decoded output to the appropriate processing devices, such as video RAM and sound card. The rendered output 225 of the processing devices is displayed through the customer's momtor, speakers, etc. The customer 227 interacts with the test software session through the browser/plug-in window. The customer's commands are 229 encoded by the plug-in and are transmitted to the test software server. The test software server 231 decodes the received commands and filters and eliminates any commands not directed to the test software session. The test software server 233 sends the remaining commands to the test software session. The test software session 215 executes the commands received. Steps 217 - 233 are repeated until the customer 235 sends an end session command and 237 terminates the testing session, or until the connection between the test software server and plug-in is lost and times-out. Virtual Network Computing™ ("VNC") is an AT&T software package that allows a local computer to display and interact with the desktop of a remote computer. The remote computer must be running the VNC server , and the local computer must be running the VNC chent. Current commercial versions of VNC use the TCP/IP transport layer, although other transport protocols have and could be developed. When a person using VNC wishes to view and interact with a remote computer, they start a VNC client session. If the user fails to specify a host name (which must be resolvable into a fully-qualified domain name or numerical IP address) for the VNC server at runtime, then the VNC viewer session will request one. It is necessary to supply the VNC viewer with the location of the remote host machine (through a host name, fully-qualified domain name or IP address) in order for the viewer to know where to establish a connection. In this embodiment, the test software server will supply its IP address to the customer's VNC client. After the remote host computer containing the VNC server is located, a connection is established between the VNC server and the VNC viewer. In this embodiment, the VNC server and a custom server layer comprise the test software server. The custom server layer contains functions for filtering and eliminating output not associated with a test software session, and filtering and eliminating commands not associated with a test software session.
Referring to FIG. 2, 201 a customer perusing a software vendor's web site 203 selects a software package to test. The test software server 205 receives the customer's request and 207 executes a test software package process. The test software server 209 sends a command, including the IP address of the test software server, to the customer's computer to start the VNC client. 211 If the VNC client is not installed on the customer's local computer 239 an error code is returned to the test software server and the customer is prompted to download the VNC client. Once the customer 241 downloads, installs and configures the VNC client, he then repeats steps 203 - 209. The VNC client 213 executes and connects to the test software server.
The test software server 217 copies the output of the test software session and 219 filters and eliminates any output not associated with the corresponding test software session. The test software server 221 encodes the remaining output and sends the packets containing the encoded output of the software session to the VNC client on the customers computer. These packets are 223 translated by the VNC client into a format compatible with the native operating system on the customer's computer and directed to the appropriate processing devices. The packets are 225 rendered into aural, visual and other elements through the appropriate rendering engines and devices. 227 The customer interacts with the test software session through mouse clicks, mouse scrolls, and keyboard strokes via the client window. These commands are then 229 encoded by the VNC client into packets and sent back to the software session being hosted on the test software server. The test software server 231 translates the packets received into a format compatible with the native operating system of the test software server computer and usable by the software program being tested, and filters and eliminates extraneous commands. The remaining commands contained in the decoded packets are 233 sent to the test software session. The test software 215 session executes the commands received. Steps 217 - 233 are repeated until the customer 235 sends a termination command to the test software session and the test software session 237 terminates.
The VNC server contains a small web server that can serve Java classes needed to make a browser connection. If this function of the VNC server is used, the customer, after deciding to test the software package, selects the hyperlink for testing. Thisiiyperlink points to the URL and port number where the VNC server is listening. The VNC server listens to sets of port numbers (e.g. 5800 and above) for connection requests. When the customer selects the hyperlink, the VNC server accepts the connection and sends the desktop display to the customer through an applet. The customer may then interact with the desktop through the applet. The session operates like the Java applet embodiment detailed above. PC Anywhere™ is a software package marketed by Symantec Corporation™ that allows a user to connect to a remote computer via modem, Internet, and other remote connection services. PC Anywhere™ allows a user to operate a remote computer as if the individual were sitting at a local terminal. It is much like VNC in its capabilities. PC Anywhere server software must be installed on the remote computer the user wishes to connect to, and the PC Anywhere client software must be installed on the local computer the user wishes to connect from. In this embodiment, like the VNC embodiment, a custom software layer runs on top of the server, and both the PC Anywhere server and the custom server layer comprise the test software server. The custom server layer contains functions for filtering and eliminating output not associated with a test software session, and filtering and eliminating commands not associated with a test software session.
Referring to FIG. 2, in this embodiment, 201 a customer perusing a software vendor's web site 203 selects a software package to test. The test software server 205 receives the customer's request and 207 executes a test software package process. The test software server 209 sends a command to the customer's computer to start the PC Anywhere™ client. 211 If the PC Anywhere™ client is not installed on the customer's local computer 239 an error code is returned to the test software server and the customer is prompted to download the PC Anywhere™ client. Once the customer 241 downloads, installs and configures the PC Anywhere™ client, he then repeats steps 203 - 209. The PC Anywhere™ client 213 executes and connects to the test software server.
The test software server 217 copies the output of the test software server computer and 219 filters and eliminates any output not associated with the corresponding test software session. The test software server 221 encodes the remaining output and sends the packets containing the encoded output of the software session to the PC Anywhere™ client on the customer's computer. These packets are 223 translated by the PC Anywhere™ client into a format compatible with the native operating system on the customer's computer and directed to the appropriate processing devices. The packets are 225 rendered into audio, visual and other elements through the appropriate rendering engines and devices. 227 The customer interacts with the test software session through mouse clicks, mouse scrolls, and keyboard strokes via the client window. These commands are then 229 encoded by the PC Anywhere™ client into packets and sent back to the test software session being hosted on the test software server. The test software server 231 translates the packets received into a format compatible with the native operating system of the test software server computer and usable by the software program being tested, and filters and eliminates extraneous commands. The remaining commands contained in the decoded packets are 233 sent to the software session. The test software 215 session executes the commands received. Steps 217 - 233 are repeated until the customer 235 sends a termination command to the test software session and the test software session 237 terminates.
A non-web based embodiment of the present invention is also possible. In this embodiment, the customers does not need a web browser to utilize the system. However, a custom test software client program is required to test any software packages. This client program would contain all the functionality of the web based client necessary to the present invention, including functions for decoding transmissions from the test software server, passing commands to the appropriate processing devices, receiving commands from the customer, and encoding and transmitting commands received back to the test software server, but would also include other functions unique to a non-web based embodiment. The client would have a function for locating the software server, a function for listing what test software packages are available, and a function for calling up desired test package. The custom test software client must be downloaded and installed on the customer's computer prior to any utilization of this embodiment.
Referring to FIG. 5, a customer 501 starts the custom test software client and connects to a test software server. Data on what test programs were available for testing is transmitted directly to the client from a test software server. This list of test programs is sent to the client, via TCP/IP or other protocols, in the form of an ASCII delimited text file. The list of test programs available are then displayed to the customer through the client window. The customer 503 selects which test program is desired from the client window via mouse click or keyboard stroke. The test software server 505 receives the test session request. The session now proceeds much like the web-based embodiment. The test software server 507 starts up a test software session and 511 copies the video, audio and other output of the test software server computer. The test software server then 513 filters and eliminates any extraneous output. The remaining video, audio and other output 515 is converted into packets and transmitted to the test software client running on the customer's local computer. The test software client 517 decodes the packets into native format and directs the decoded output to the appropriate processing devices. The rendered output 519 is then displayed via monitor, speaker, and other output devices. The customer 521 interacts with the test software session through the chent window via mouse scrolls, mouse clicks, and keyboard strokes. The client 523 encodes these commands into packets and transmits those packets to the test software server. The test software server 525 decodes the packets and filters and eliminates commands not associated with the test software session. This filtering and ehminating of commands can also be accomplished by the test software client prior to encoding and transmission of the commands to the test software server. However, it is preferred that the test software server do the filtering and eliminating of extraneous commands. After converting the command packets and filtrating and eliminating extraneous commands, 527 the server passes the commands to the associated test software session. The test software 509 session processes the commands. Steps 511 - 527 are repeated until 529 an end session command is sent by the customer to the test software session. When an end session command is received 531 the test software session terminates. The customer may then 501 peruse the list of available test software packages and 503 select a new package to test. This can continue until the connection between the test software server and test software client is lost.
The embodiments detailed above require a method whereby the visual, aural and other output of the test software server computer which is not related to the test software session is filtered out and eliminated. This is necessary so that only output from the test software session is transmitted to the customer. Without a method of filtering and eliminating output extraneous to the test software session, the entire desktop of the server machine, including any programs running on top of the desktop, would-be displayed to the customer. Further, any other output from device drivers resident on the test software server computer could be passed to the client program, providing output to the customer not associated with the test software session. This would make testing the software package difficult.
Referring now to FIG. 3, what is illustrated is one way of filtering and eliminating extraneous visual and other output from the server computer. Once a customer's command is processed by the test software session, the entire visual and other output of the server computer 300, including the desktop and windows from the test software session and other programs and any output related or directed to device drivers, is passed to 302 the server computer's rendering engines. In the case of visual output, the rendering engine is the graphics rendering engine. In the case of non- visual output, the rendering engine is the device drivers associated with certain devices, such as a sound card or multimedia card. The rendering engines translate the binary output into a form capable of processing by 312 the display and other device drivers. The output of 302 the rendering engines is grabbed by 304 the test software server and duplicated by 306 a copying module. One copy of the rendering engine output 305 is directed to 312 the video RAM and other device hardware components, such as a sound card, of the test software server computer for normal processing and transmission to 314 the test software server computer's monitor and other devices. The other copy is directed to 308 a program module that filters out and eliminates any output not associated with the test software session. The resulting output stream 311 is directed to 310 a program module for converting video and other output into packets for transmission to the customer's computer. These packets, 313, are sent first to 316 the server computer's network interface device and then out to 315 the Internet or other computer network. These packets are routed to 318 the customer's computer's network interface device, and then directed to 320 the test software client. 322 The chent program's conversion module converts the received packets into native output usable by the customer's local computer. This output is then directed to 324 video RAM and other device hardware components for normal processing and transmission to 326 the customer's monitor and other output devices. This method of filtering and eliminating output not associated with the test software session is repeated for every transmission of the test software session's output to the client on the customer's computer.
Referring now to FIG. 4, what is illustrated is another method of filtering and eliminating visual output not associated with the test software session. This method is operable for transmissions between the server computer and the customer's computer where both are running Microsoft Windows 95™, 98™, or NT™ operating systems, or other operating systems compatible with these Microsoft™ operating systems. In this embodiment, once a customer's command is processed by the test software session, the entire visual output of the server computer 400, including the desktop and windows from the test software session and other programs, is passed directly to 402 the test software server. The visual output of the server computer, 401, consists of information in Windows Metafile™ format ("WMF") or enhanced Metafile™1 format ("EMF"). A WMF or EMF file contains graphical-device-interface function calls that enable the visual output of the associated program session to be displayed as a graphic image on a monitor. 404 the copying module of the test software server duplicates the visual output. One copy of the visual output, 407, is sent to 410 the server computer's rendering engine for normal processing. The other copy, 403, is directed to 406 a program module that filters and eliminates any visual output not associated with the test software session. After the extraneous output has been filtered and eliminated, the remaining output, 405, is converted by 408 the test software server's conversion module into packets for transport over the Internet or other computer network to the customer's computer. The packets, 413, are sent first to 416 the server computer's network interface device and then out to 415 the Internet or other computer network. The packets are routed to the customer's computer and received 417 by the customer's computer's 418 network interface device. The packets 419 are directed to 420 the test software client. The test software chent's 422 conversion module converts the packets back into metafiles and 421 directs them to the customer's computer's 424 rendering engine for normal processing. The resulting output 423 is then directed to 426 video RAM for normal processing and transmission to 428 the customer's monitor. This method of filtering and eliminating extraneous audio and video output of the server computer is repeated for each transmission of audio and video output of the test software session to the customer's local computer.
The invention now being fully described, it will be apparent to one of ordinary skill in the art that many changes and modifications can be made thereto without departing from the spirit or scope of the appended claims.

Claims

We claim:
1. A method of testing software over a computer network prior to procurement comprising:
(a) server means for starting a software session, for sending a command to start a client program, for receiving commands from a remote computer, for filtering and eliminating commands not directed to a software session, for passing commands to a test software session, for copying output of the a test software server computer, for filtering and eliminating output not associated with a test software session, for encoding remaining output into datagrams, and for transmitting datagrams to a remote computer; and
(b) client means for receiving datagrams from server means, for decoding datagrams into output, for directing output to appropriate rendering engine, for receiving commands from user input, for translating commands received into datagrams, and for transmitting datagrams to server means.
2. The method of claim 1, wherein the server means initiates a software session after receiving a command from the client means.
3. The method of claim 1, wherein the server means initiates a software session after receiving a command from a web server.
4. The method of claim 1, wherein the server means and client means utilize HOP and CORBA standard.
5. The method of claim 1, wherein the server means and client means utilize ActiveX™ and the COM standard.
6. The method of claim 1, wherein the client means comprises a web browser plug-in.
7. The method of claim 1, wherein the client means comprises a Java™ applet.
8. — The method of claim 1, wherein the client means comprises a Virtual Network Computing™ client, and the server means comprises a Virtual Network Computing™ server plus a custom server layer.
9. The method of claim 1, wherein the client means comprises a PC Anywhere™ client, and the server means consists of a PC Anywhere™ server plus a custom server layer.
10. A method of using software over a computer network comprising:
(a) server means for starting a software session, for sending a command to start a client program, for receiving commands from a remote computer, for passing commands to a test software session, for copying output of the a test software server computer, for filtering and eliminating output not associated with a test software session, for encoding remaining output into datagrams, and for transmitting datagrams to a remote computer; and
(b) client means for receiving datagrams from server means, for decoding datagrams into output, for directing output to appropriate rendering engine, for receiving commands from user input, for filtering and eliminating commands not directed to a software session, for translating commands received into datagrams, and for transmitting datagrams to server means.
11. The method of claim 10, wherein the server means initiates a software session after receiving a command from the client means.
12. The method of claim 10, wherein the server means initiates a software session after-receiving a command from a web server.
13. The method of claim 10, wherein the server means and chent means utilize πOP and CORBA standard.
14. The method of claim 10, wherein the server means and chent means utilize ActiveX™ and the COM standard.
15. The method of claim 10, wherein the client means comprises a web browser plug-in.
16. The method of claim 10, wherein the client means comprises of a Java™ applet.
17. The method of claim 10, wherein the client means consists of a Virtual Network Computing™ client and a custom client layer, and the server means consists of a Virtual Network Computing™ server plus a custom server layer.
18. The method of claim 10, wherein the client means consists of a PC Anywhere™ client and a custom client layer, and the server means consists of a PC Anywhere™ server plus a custom server layer.
PCT/US2000/018814 1999-07-13 2000-07-11 A method and system of allowing prospective users to test and use software via a computer network WO2001004752A2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU60842/00A AU6084200A (en) 1999-07-13 2000-07-11 A method and system of allowing prospective users to test and use software via acomputer network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US35246399A 1999-07-13 1999-07-13
US09/352,463 1999-07-13

Publications (2)

Publication Number Publication Date
WO2001004752A2 true WO2001004752A2 (en) 2001-01-18
WO2001004752A3 WO2001004752A3 (en) 2001-07-12

Family

ID=23385231

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/018814 WO2001004752A2 (en) 1999-07-13 2000-07-11 A method and system of allowing prospective users to test and use software via a computer network

Country Status (2)

Country Link
AU (1) AU6084200A (en)
WO (1) WO2001004752A2 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9895386B2 (en) 2005-09-29 2018-02-20 Bayer Intellectual Property Gmbh Antibiotic formulations, unit doses, kits, and methods
US11748246B2 (en) 2021-04-28 2023-09-05 International Business Machines Corporation Crowd-sourced QA with trusted compute model

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5757925A (en) * 1996-07-23 1998-05-26 Faybishenko; Yaroslav Secure platform independent cross-platform remote execution computer system and method
US5881236A (en) * 1996-04-26 1999-03-09 Hewlett-Packard Company System for installation of software on a remote computer system over a network using checksums and password protection
US5883955A (en) * 1995-06-07 1999-03-16 Digital River, Inc. On-line try before you buy software distribution system
US5909545A (en) * 1996-01-19 1999-06-01 Tridia Corporation Method and system for on demand downloading of module to enable remote control of an application program over a network

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5883955A (en) * 1995-06-07 1999-03-16 Digital River, Inc. On-line try before you buy software distribution system
US5909545A (en) * 1996-01-19 1999-06-01 Tridia Corporation Method and system for on demand downloading of module to enable remote control of an application program over a network
US5881236A (en) * 1996-04-26 1999-03-09 Hewlett-Packard Company System for installation of software on a remote computer system over a network using checksums and password protection
US5757925A (en) * 1996-07-23 1998-05-26 Faybishenko; Yaroslav Secure platform independent cross-platform remote execution computer system and method

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9895386B2 (en) 2005-09-29 2018-02-20 Bayer Intellectual Property Gmbh Antibiotic formulations, unit doses, kits, and methods
US11748246B2 (en) 2021-04-28 2023-09-05 International Business Machines Corporation Crowd-sourced QA with trusted compute model

Also Published As

Publication number Publication date
AU6084200A (en) 2001-01-30
WO2001004752A3 (en) 2001-07-12

Similar Documents

Publication Publication Date Title
US6065051A (en) Apparatus and method for communication between multiple browsers
US6138150A (en) Method for remotely controlling computer resources via the internet with a web browser
US6029245A (en) Dynamic assignment of security parameters to web pages
US7739327B2 (en) Distributed link processing system for delivering application and multi-media content on the internet
US6654784B1 (en) Computing architecture
US6477550B1 (en) Method and system for processing events related to a first type of browser from a second type of browser
KR100264535B1 (en) Computer apparatus and method for communicating between software applications and computers on the world-wide web
US6427149B1 (en) Remote access of archived compressed data files
EP0981885B1 (en) Apparatus and method for identifying clients accessing network sites
US6292827B1 (en) Information transfer systems and method with dynamic distribution of data, control and management of information
US5734831A (en) System for configuring and remotely administering a unix computer over a network
US5945989A (en) Method and apparatus for adding and altering content on websites
US6286003B1 (en) Remote controlling method a network server remote controlled by a terminal and a memory storage medium for HTML files
US6654785B1 (en) System for providing a synchronized display of information slides on a plurality of computer workstations over a computer network
US6144990A (en) Computer apparatus and method for communicating between software applications and computers on the world-wide web using universal variable handling
US9171049B2 (en) Offline simulation of online session between client and server
US20010016873A1 (en) Method for acquiring content information, and software product, collaboration system and collaboration server for acquiring content information
WO1999004357A1 (en) Integrated electronic commerce system and method
JP2002351829A (en) Providing computing service through online network computer environment
JP2000057113A (en) Computer system for improving performance of java program operating on server
US6223224B1 (en) Method and apparatus for multiple file download via single aggregate file serving
WO2001039046A1 (en) Web browser plug-in interface system
CA2437273C (en) Network conduit for providing access to data services
JPWO2003038634A1 (en) Method, system, and computer program for collaborating between multiple computers on a network
WO2001054369A2 (en) System and method for computer network uploading

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ 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 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: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG 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 BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
AK Designated states

Kind code of ref document: A3

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ 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 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: A3

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG 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 BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase in:

Ref country code: JP