JP3711162B2 - Software price settlement system and method - Google Patents

Description

[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a service for installing software on a terminal device of a user via a communication line, and relates to a software price decision system and a method for deciding the price of software.
[0002]
[Prior art]
With the recent development of personal computer communication and the like, there is a user's desire to obtain software via a communication line, but a full-scale system for automatically delivering such software has not been realized. In order to perform automatic software distribution, first, the software desired by the user is notified from the terminal device at home to the distribution center, and the distribution center that receives the notification from the user sends the requested software to the user terminal device via the communication line. A form of transmission is conceivable.
[0003]
In order to realize such automatic delivery of software, the “remote installation system and method” (Japanese Patent Application No. 7-1797) of the prior application has been devised. Hereinafter, the prior art will be described with reference to the drawings.
[0004]
FIG. 28 is a configuration diagram of the remote installation system of the prior application. The remote installation system of FIG. 28 includes a host computer 21 in a software distribution center, a user terminal 23, and a communication line 22 connecting them. The terminal 23 is, for example, a personal computer at the user's home far away from the distribution center, and the communication line 22 is, for example, a network line for personal computer communication.
[0005]
The host computer 21 includes a software group 35 including a plurality of software that can be distributed in a storage area (not shown), a first key table 32 that holds a list of keywords used when selecting specific software from the software group 35, and A second key table 33 is stored.
[0006]
When the user requests a list of keywords from the terminal 23 to the host computer 21, the host computer 21 sequentially transmits the first key table 32 and the second key table 33, and the keywords contained therein are displayed on the display device 24 of the terminal 23. Display on the screen. The user selects one corresponding to the desired software from the displayed keywords, and notifies the host computer 21 of it.
[0007]
The host computer 21 displays a menu including names of some software corresponding to the notified keyword on the screen of the display device 24, and the user selects desired software from the menu and notifies the host computer 21 of the selected software. Then, the host computer 21 extracts the content (file) of the software selected by the user from the software group 35 and stores it in the delivery (home delivery or distribution) directory D: ¥ SOUKO set in the hard disk 25 of the terminal 23. .
[0008]
At this time, an icon 37 for starting the delivered software is automatically registered and displayed on the screen of the display device 24 in the warehouse window 36 provided corresponding to the directory D: \ SOUKO. For example, when the terminal 23 is equipped with WINDOWS, the delivered software is registered in the WINDOWS program manager. Thereafter, the user can use the delivered software by simply clicking the icon 37 using an input device such as a mouse.
[0009]
An environment file 31 describing the operating environment such as hardware and software tools installed in the terminal 23 is generated in the terminal 23 and sent to the host computer 21 when the host computer 21 is accessed. The host computer 21 holds the received environment file 31 for each user and uses it to check whether the software selected by the user is operable.
[0010]
The host computer 21 prepares an individual setting file 34 for each user, and describes a set of files necessary for the operation of the software selected by the user and a storage location thereof. Then, the setting file 34 can be sent to the terminal 23 together with the set of files so that the terminal 23 can automatically install the software.
[0011]
Next, an operation flow of software delivery by the remote installation system of FIG. 28 will be described with reference to FIGS.
In FIG. 29, the terminal 23 of the user A acquires operating environment information when installing the terminal software for communication, and creates an environment file 38 in which the acquired information is set (step S1). At this time, information that takes time to acquire the model of the user's terminal and the storage location SOUKO used for home delivery, or information that must be inquired to the user in some cases is acquired.
[0012]
In determining the storage location SOUKO, the terminal 23 checks whether there is a free area of a predetermined capacity or more in the hard disk 25, and if there is a free area, creates a directory for home delivery in the route. At this time, the directory name and the like are automatically generated by the terminal 23, and the user A performs only the operation of confirming it. Therefore, user A does not need to input a directory name or the like.
[0013]
Here, it is written in the environment file 38 that the model of the user A is TOWNS and the directory of SOUKO is D: ¥ SOUKO (directory SOUKO of drive D). User A can change D: ¥ SOUKO to another directory if necessary.
[0014]
If there is no free space of a predetermined capacity in the already set partition, a place where the free space of another partition is the largest is searched and a home delivery directory is created there. Specifically, if the directory D: ¥ SOUKO is full, the terminal 23 displays a message such as “D: ¥ SOUKO is full. It is displayed on the screen of the device 24. If the user A approves this, F: ¥ SOUKO becomes a new SOUKO directory. If there is no free space of the specified capacity on any hard disk, a message such as "Unfortunately there is not enough disk space. Please add a disk."
[0015]
Next, when the terminal software is activated (when accessing the host computer 21), information that may have changed after installation, such as the status of the hard disk or memory, is acquired (step S2). Here, it is written in the environment file 38 that the hard disk of the user A is in the drive D and the free capacity is 300 Mbytes. The contents of the environment file 38 created in this way are stored in the command RIS when the user A accesses (connects) the host computer 21. It is transmitted to the host computer 21 by SENDENV (step S3).
[0016]
The host computer 21 holds the received information as a user A environment file 39. In addition to the model, hard disk information HD, and storage location SOUKO, the user A environment file 39 describes the OS (operating system) being used and its storage location. Here, it can be seen that the OS of the terminal 23 of the user A is WINDOWS, and the storage location WINDIR is D: ¥ WINDOWS.
[0017]
Command RIS from host computer 21 RIS as a response to SENDENV Upon receiving SENDENV * RESP OK, the terminal 23 sends the command RIS. A first key list is requested by KEYLIST (step S4). In response to this, the host computer 21 changes the contents of the first key table 32 to RIS. Send back with KEYLIST * RESP. Here, the first key table 32 stores OS / basic software, development support, a game,... As keywords corresponding to the key numbers 1, 2, 3,.
[0018]
When these keywords are displayed on the screen of the display device 24 as the first key list (step S5), the user A selects the first keyword from them and inputs it to the terminal 23 (step S6). Then, the terminal 23 sends a command RIS requesting the second key list together with the key number of the first keyword selected by the user A. KEYLIST is sent to the host computer 21 (step S7). Here, the user A selects a game as the first keyword, and the corresponding key number 3 is sent to the host computer 21.
[0019]
The host computer 21 requested for the second key list obtains the corresponding second key table 33 using the pointer stored in the first key table 32 corresponding to the received key number, and stores the contents thereof. RIS Send back with KEYLIST * RESP. Here, RPG, action, puzzle / quiz,... Are stored in the second key table 33 as keywords corresponding to the key numbers 51, 52, 53,.
[0020]
A plurality of second key tables are generally provided corresponding to the keywords in the first key table 32, and the number thereof is the same as or less than the number of keywords in the first key table 32. In the latter case, two or more keywords in the first key table 32 indicate the same second key table.
[0021]
When the keywords in the second key table are displayed on the screen of the display device 24 as the second key list (step S8), the user A selects the second keyword from them and inputs it to the terminal 23 (FIG. 30, step). S9). Then, the terminal 23 issues a command RIS requesting a list of software corresponding to both the first and second keywords together with the key numbers of the first and second keywords selected by the user A. The LIST is sent to the host computer 21 (step S10). Here, the user A selects an action as the second keyword, and the corresponding key number 52 is sent to the host computer 21.
[0022]
The host computer 21 requested for the software list searches the software group 35 for software having two key numbers of the first and second keywords. At this time, the search is performed flat without distinguishing the first keyword and the second keyword as the search condition. Also, the model and OS type are handled as default keys, and these are taken into account for the search. Thereby, for example, software dedicated to a model other than TOWNS is prevented from being searched.
[0023]
Then, a list of corresponding software names and numbers is displayed in RIS. It is sent to the terminal 23 together with LIST * RESP. Here, software such as Tetris and Pachinko having key numbers 3 and 52 corresponds to the software, and the names thereof are sent to the terminal 23 together with the software numbers 5 and 30.
[0024]
When a list of software is displayed on the screen of the display device 24 (step S11), the user A selects desired software from them and inputs it to the terminal 23 (step S12). Then, the terminal 23, together with the number of the software selected by the user A, a command RIS that requests checking whether the environment of the user A is suitable for the operation of the software. CHKENV is sent to the host computer 21 (step S13). Here, the user A selects Tetris and the corresponding software number 5 is sent to the host computer 21.
[0025]
Upon receiving the software number selected by the user A, the host computer 21 prepares a check script 40 for checking the consistency between the operating environment of the software corresponding to the number and the environment of the terminal 23 of the user A. I do. Since this check is automatically performed by the exchange between the execution program of the check script 40 and the terminal software of the terminal 23, the user A does not necessarily need to be aware that the environment check is being performed (step S14). . The host computer 21 makes an inquiry only when it is necessary to make an inquiry to the user A.
[0026]
Here, as the operating environment of the Tetris selected by the user A, the OS is WINDOWS, the model is TOWNS, the PC 98, and the like, and the recommended directory (DIR) name is TET. On the other hand, in the user A environment file 39, the model is described as TOWNS and the OS is WINDOWS, and it can be seen that the model and the OS are compatible by comparing the two.
[0027]
Next, when the Tetris check script 40 is viewed, VBRJP 200. Since there is a command “ST4 @ WINDIR @ VBRJP200.DLL” for investigating whether there is a file called DLL (MQ1), the host computer 21 recognizes this as RIS. It is sent to the terminal 23 together with CHKENV * RESP. At this time, the host computer 21 refers to the user A environment file 39 and sends @ WINDIR @ to D: ¥ WINDOWS. Here, @ represents a wild card. Also, the file VBRJP200. DLL is one of the files necessary for Tetris operation.
[0028]
Receiving this command, the terminal 23 stores the file VBRJP200.V in the directory WINDOWS of the drive D. It is checked whether there is a DLL, and the result is sent back to the host computer 21 as an ANS. Here, since there is no corresponding file, ANS = OFF is sent back.
[0029]
The file VBRJP200. The host computer 21 that knows that there is no DLL sends an inquiry “Can I copy the VBRJP 200?” To the terminal 23 according to the check script 40 (MQ2), and this inquiry is displayed on the screen of the display device 24. . User A inputs an answer to the displayed inquiry, and terminal 23 sends the answer back to host computer 21. Here, ANS = Yes is sent back, and the host computer 21 accepts the remote installation according to the check script 40 (RIS = OK), and VBRJP200. The flag F2 for instructing the DLL copy is turned ON (MA2).
[0030]
If the file VBRJP200. If the DLL is in the designated directory of the terminal 23, ANS = ON is sent back, so that RIS = OK at that time (MA1).
[0031]
By automatically performing the environment check in this way, it is possible to prevent software that does not match the environment of user A from being delivered. For example, after purchasing a certain package software via the communication line 22, an accident such as knowing that it does not operate without a specific driver is prevented.
[0032]
When RIS = OK, the host computer 21 finishes the environment check, and sends the delivery destination directory SOUKODIR together with the determination result (JUDGE = OK) to the terminal 23. This SOUKODIR is specified in a format in which TET, which is a recommended Tetris directory, is added as a subdirectory under D: \ SOUKO, which is a SOUKO directory stored in the user A environment file.
[0033]
At the same time, whether or not installation is possible (RIS), whether or not an icon of the installation program (installer) is registered (ICON), and whether or not download is possible (DLOAD) is sent to the terminal 23. Based on these flags RIS, ICON, and DLOAD, the host computer 21 notifies the terminal 23 which of installation, installer icon registration, and download is possible.
[0034]
The installation means that the software selected by the user A is registered in the system of the terminal 23, for example, WINDOWS, and can be used on the terminal 23. Therefore, in this case, the process includes the operation of registering the execution file of the software on WINDOWS. On the other hand, the icon registration of the installer means that the program for executing the installation is registered on the terminal 23 as an icon.
[0035]
Here, a condition is presented that installation and download are permitted (RIS = OK, DLOAD = OK), and installer icon registration is not performed (ICON = NG). In the case of software having a complicated installation program, it is indicated that the icon registration of the installer is necessary instead of permitting the installation. Also, when an application for TOS (TOWNS OS) is requested from a terminal equipped with WINDOWS, only downloading is permitted.
[0036]
Next, the terminal software of the terminal 23 assigns priorities in the order of installation, icon registration of the installer, and download, sets a higher priority as a default, and displays it on the screen of the display device 24. Here, of the installation and download permitted by the host computer 21, the installation with the higher priority is set as a default and displayed in the installation method selection window.
[0037]
FIG. 32 shows a display example of the installation method selection window. In FIG. 32, “system registration” corresponds to installation, which is selected by default.
[0038]
User A confirms the displayed installation method and inputs the confirmation (step S15). User A can also change the settings displayed here. For example, if it is desired to register an installer icon, “installer icon registration” in the installation method selection window of FIG. 32 is selected and input.
[0039]
Basically, user A selects “system registration” if he / she wants to perform a clean installation without any hassle, and selects “installer icon registration” if he / she wants to make detailed installation settings himself. Select "Download" if you want to change the location later (you want to install it on another model of device). If “Download” is selected, it is possible to obtain software for a model different from the model of the terminal 23 and test whether it operates.
[0040]
Next, the terminal 23 automatically generates a home delivery subdirectory D: \ SOUKO \ TET instructed by the host computer 21 in the hard disk 25 (step S16). Here, if the subdirectory D: \ SOUKO \ TET already exists in the terminal 23, for example, a subdirectory D: \ SOUKO \ TET 001 is created, and if this already exists, D: \ Create a subdirectory called SOUKO \ TET 002.
[0041]
The Tetris file body 41 is a file TET1. LZH (F1) and VBRJP200. DLL (F2) and TET1. LZH has four files TETRIS. EXE, TOWNS. DRV, PC98. DRV, and MAC. It is made by compressing DRC. TET1. When LZH is expanded (decompressed) to the state before compression, it is divided into these four files. LZH decompression is performed after delivery from the host computer 21 to the terminal 23.
[0042]
The terminal 23 that has generated the sub-directory for delivery uses a command RIS that requests the start of remote installation. INSTALL is sent to the host computer 21 together with the number of the selected software (FIG. 31, step S17). In response to this, the host computer 21 starts remote installation of software corresponding to the sent number. The remote installation is automatically performed by the exchange between the host computer 21 and the terminal 23 in accordance with the Tetris installation script 42 created by the host computer 21 (step S18).
[0043]
The installation script 42 first includes files TET1. There is a description instructing to download LZH to the storage location @ SOUKO @ on the user A side. Therefore, the host computer 21 replaces @ SOUKO @ with SOUKODIR = D: \ SOUKO \ TET, and replaces TET1. Download LZH.
[0044]
When the download completion (OK) is notified from the terminal 23, the host computer 21 then replaces @ WINDIR @ with D: \ WINDOWS, and changes the VBRJP200.com to the directory D: \ WINDOWS of the hard disk 25. Download the DLL.
[0045]
When the completion of downloading (OK) is notified from the terminal 23, the host computer 21 next downloads the TET1..TET downloaded to the storage location @ SOUKO @ (D: \ SOUKO \ TET). Instruction to decompress LZH, LHA X D: ¥ SOUKO ¥ TET ¥ TET1. Send LZH. In response to this, the terminal 23 receives TET1. The four files TETRIS. EXE, TOWNS. DRV, PC98. DRV, and MAC. Thaw to DRC. These four files are TET1. It is held in the same subdirectory D: \ SOUKO \ TET as LZH.
[0046]
When the completion of decompression (OK) is notified from the terminal 23, the host computer 21 next sends the model @. At the storage location @ SOUKO @ (D: \ SOUKO \ TET). Move the file named DRV to the storage location @ WINDIR @ (D: ¥ WINDOWS) and rename the file to FONT. Instruction to change to DRV, MOVE D: ¥ SOUKO ¥ TET ¥ TOWNS. DRV D: ¥ WINDOWS ¥ FONT. Send DRV. At this time, the host computer 21 refers to the user A environment file 39 and sends the model @ replaced with TOWNS. In response to this, the terminal 23 receives the file TOWNS. Of the subdirectory D: \ SOUKO \ TET. Move DRV to directory D: \ WINDOWS (file move), FONT. Change the file name to DRV (Rename).
[0047]
When notified of the completion of file movement and renaming (OK) from the terminal 23, the host computer 21 next sends the file TETRIS. Instruction to register EXE icon, ICON TETRIS. Send EXE. In response to this, the terminal 23 receives the file TETRIS. In the subdirectory D: \ SOUKO \ TET. EXE is converted into an icon and registered in the terminal 23. As a result, in the warehouse window 36 displayed on the screen of the display device 24, for example, TETRIS. An icon 37 for starting EXE is displayed. When the icon 37 is clicked, Tetris starts its operation.
[0048]
When the completion of icon registration (OK) is notified from the terminal 23, the host computer 21 sends back RETURN to notify the terminal 23 of the end of the remote installation, and ends a series of installation operations. The terminal 23 notified of the end of the remote installation performs the selection of the next software and the remote installation according to the instruction of the user A, or ends the process (step S19).
[0049]
At the time of installation in step S18, if the software to be installed is larger than the free space in the download destination storage location, the storage location is changed and downloaded.
[0050]
Next, an example of a remote installation protocol and display examples of the first and second keywords will be described with reference to FIGS.
FIG. 33 shows an example of a protocol by which the terminal 23 sends environment information when the terminal 23 accesses the host computer 21 in step S3. In the protocol of FIG. 33, machine information (Machine :) related to the terminal 23 is described following the request ID (RID), the machine ID (MID) for specifying the terminal, and the date and time (TIME).
[0051]
The drive information (DRV :) in MACHINE: describes information related to the hard disk 25 such as capacity and drive name. For example, CAPACITY in PARTINF: indicates the capacity of the partition, VACANT indicates the free capacity of the partition, and DRVNAME indicates the drive name corresponding to the partition.
[0052]
Subsequent to DRV :, a warehouse directory SOUKODIR, which is a storage location for home delivery, and a directory WINDIR, which is a storage location of the OS (WINDOWS), are described. Here, SOUKODIR = D: ¥ RIS ¥ SOUKO and WINDIR = D: ¥ WINDOWS. Next, there is information about memory (MEM :). By designating this SOUKODIR, the terminal 23 notifies the host computer 21 of the delivery destination.
[0053]
Subsequently to MACHINE :, a machine password (MPSWD) of the terminal 23 is described.
FIG. 34 shows an example of a protocol in which the host computer 21 adds a subdirectory to SOUKODIR and sends it back at the end of the environment check in step S14. In the protocol of FIG. 34, information (STRPLACE :) relating to the delivery destination is described following the RID and environmental check determination result (JUDGE).
[0054]
“SOFT” in STRPLACE: represents the number of the software selected by the user in step S12, “WORKDIR” represents the work area, and “SOUKODIR” represents the delivery destination designated by the host computer 21. Here, WORKDIR is the same as SOUKODIR in FIG. 33, and SOUKODIR has a subdirectory name FM added to SOUKODIR in FIG.
[0055]
Subsequent to STRPLACE :, the work area size WORKSIZ and the delivery destination size SOUKOSIZ are described.
FIG. 35 shows an example of a protocol in which the host computer 21 sends the first and second key lists to the terminal 23 and the terminal 23 sends back the key number of the keyword selected by the user A in steps S4 to S9. In the protocol of FIG. 35, the terminal 23 sends a command RIS. When the first key list is requested by KEYLIST, the host computer 21 returns RIS as a response. The contents KEYLIST: of the first key table are sent back together with KEYLIST * RESP. In this KEYLIST :, keywords NAME = “OS / basic software”, “development support”, “game”,... Are described corresponding to the key numbers KEY = 1, 2, 3,. Yes.
[0056]
Next, the terminal 23 receives the command RIS. When the key number 3 of the first keyword “game” selected by the user A is sent together with KEYLIST, the host computer 21 responds as RIS. Along with KEYLIST * RESP, the contents KEYLIST: of the second key table corresponding to key number 3 are sent back. In this KEYLIST: In the key numbers KEY = 51, 52, 53, 54, 55,..., The keywords NAME = “RPG”, “action”, “puzzle / quiz”, “simulate”, "Joke", ... is described.
[0057]
The terminal 23 then sends a command RIS Along with the LIST, the key numbers 52 and 55 of the second keyword “action” and “joke” selected by the user A are sent to the host computer 21 to request a list of software having three key numbers 3, 52 and 55. Here, since the host computer 21 stores the key number 3 of the first keyword that has already been sent, only the key numbers 52 and 55 of the second keyword are sent.
[0058]
FIG. 36 shows a display example of the first and second keywords. The first and second keywords in FIG. 36 are different from those in FIG. For example, a first keyword such as an image or a game is displayed on the screen of the display device 24 viewed by the user A. When the user A selects the first keyword, a tool, text, DOS, WIN, image, sound, and the like are next displayed. A second keyword such as a game is displayed. Some of the second keywords overlap with the first keyword, such as images and games.
[0059]
User A can select any of the displayed keywords. For example, an image is selected as the first keyword, and a tool, DOS, game, or the like is selected as the second keyword, or a game is selected as the first keyword, and DOS, WIN, image, audio, or the like is selected as the second keyword. In addition, the user A can simultaneously select two or more keywords as the second keyword.
[0060]
In general, since there are many keywords for selecting desired software from the software group 35, it is difficult to view all of them at once, and those that are not necessary at all are also displayed. Therefore, if this is displayed as a simple tree-structured menu, the keyword to be selected first plays an important role, and if the selection is made incorrectly, the desired software cannot be obtained.
[0061]
Therefore, as shown in FIG. 36, by allowing duplication and displaying keywords in two layers, the user can more flexibly select necessary ones from a large number of keywords. Note that the keyword hierarchy is not limited to two, and may be displayed in more hierarchy.
[0062]
The contents of each software in the software group 35 are stored in association with some keywords in advance. For example, in FIG. 36, software A has three keywords of game, image, and DOS, and software B has four keywords of image, tool, WIN, and game. Therefore, when the user A selects two keywords of image and game, a list including these two softwares is sent from the host computer 21 and displayed on the screen.
[0063]
FIG. 37 shows another example of a transmission protocol for environment information sent from the terminal 23 to the host computer 21 during host access in step S3. In the protocol of FIG. 37, MODEL in the machine information MACHINE: is information acquired at the time of installation of the terminal software in step S1, and represents the model TOWNS of the terminal 23. VACANT in PARTINF: is information acquired before the access to the host computer 21 in step S3 (step S2), and represents the free capacity of the corresponding partition.
[0064]
FIG. 38 shows an example of an environment check in step S14 and a subsequent installation start protocol in step S17. In the protocol of FIG. 38, the terminal 23 first sends a command RIS. Software number selected by user A along with CHKENV (soft code) SOFT = 5 as host computer
21 to request an environmental check.
[0065]
First, the host computer 21 executes VBRJP200. An instruction CHKEXE: for examining whether a file called DLL exists in the system directory of the terminal 23, a response RIS It is sent to the terminal 23 together with CHKENV * RESP. In CHKEXE: TAG = "VBRJP200.DLL", command CMD = "ST4 D: \ WINDOWS \ SYSTEM \ VBRJP200.DLL", work directory specification WORKDIR = "D: \ RIS \ KOBUTA", home delivery directory SOUKODIR = "D: \ RIS \ KOBUTA" etc. are described.
[0066]
The terminal 23 stores the file VBRJP200.V in the directory WINDOWS \ SYSTEM of the drive D. Whether there is a DLL is checked, and the result is sent back to the host computer 21 as RESULT :. In RESULT :, the investigation result VAL = “OFF” is described together with the corresponding TAG = “VBRJP200.DLL”. This is the file VBRJP200. This means that the DLL was not in the system directory.
[0067]
Therefore, the host computer 21 sends an instruction ASKCHK: for inquiring the user whether or not the selected software can be installed, and the response RIS. It is sent to the terminal 23 together with CHKENV * RESP. ASKCHK: describes TAG = “Q1”, a question sentence to be displayed QUERY = “Are you sure you want to install this software?”, And an answer format ANS :.
[0068]
The terminal 23 sets the response input by the user A as RESULT: and uses the command RIS. It is sent back to the host computer 21 together with CHKENV. In RESULT :, the response result VAL = “OK” is described together with the corresponding TAG = “Q1”. This means that software may be installed.
[0069]
Therefore, if there is no other failure in the operating environment, the host computer 21 returns the response RIS. The environment check result JUDGE = “OK” is sent to the terminal 23 together with CHKENV * RESP. This is the file VBRJP200. Except that there is no DLL, it means that the operating environment of software No. 5 is prepared and can be installed.
[0070]
Since the result of the environmental check is “OK”, the terminal 23 executes the command RIS. Along with INSTALL, the type of installation method TYPE = “RIS”, delivery destination designation STRPLACE: etc. are sent to the host computer 21 to request installation. STRPLACE: describes a working directory WORKDIR and a home delivery destination directory SOUKODIR, along with a software code SOFT of software to be installed.
[0071]
Thereafter, the host computer 21 installs software by a designated method. At the time of installation, for example, as described in step S18 of FIG. 31, the terminal 23 performs a sequential operation of decompressing the file, copying it, and registering it in the system by a command sent from the host computer 21. Since the terminal 23 sequentially sends back whether or not these operations are completed, the host computer 21 can monitor the progress of the installation operation to the end.
[0072]
However, in this method, since the terminal 23 must frequently communicate with the host computer 21, the communication efficiency is deteriorated. Therefore, a method is conceivable in which the host computer 21 prepares a setting file in which an installation work command is described, and passes this to the terminal 23 to perform automatic installation.
[0073]
FIG. 39 is a flowchart of automatic installation using a setting file. The installation work of FIG. 39 is performed after the generation of the subdirectory in step S16 of FIG.
[0074]
The terminal 23 first sends a command RIS INSTALL is sent to the host computer 21 together with the software number (step S21). In response to this, the host computer 21 starts remote installation of software corresponding to the sent number. The remote installation is automatically performed by the exchange between the host computer 21 and the terminal 23 in accordance with the Tetris installation script 43 created by the host computer 21 (step S22).
[0075]
First, the host computer 21 replaces @ SOUKO @ with SOUKODIR = D: \ SOUKO \ TET, and subtracts the file TET1. Download LZH.
[0076]
When the download completion (OK) is notified from the terminal 23, the host computer 21 then replaces @ WINDIR @ with D: \ WINDOWS, and changes the VBRJP200.com to the directory D: \ WINDOWS of the hard disk 25. Download the DLL.
[0077]
When the completion of download (OK) is notified from the terminal 23, the host computer 21 next replaces @ SOUKO @ with SOUKO = D: ¥ SOUKO and describes the command of the work to be performed by the terminal 23 for user A Download the setting file 44 (SETUP.INF) to the directory D: \ SOUKO on the hard disk 25. At this time, the host computer 21 refers to the user A environment file 39 in the same manner as in step S18 and sets the setting file SETUP. Information such as the model, SOUKO, WINDIR, etc. included in the INF is rewritten to information for the user A and sent. Setting file SETUP. INF contains files TET1. Unzip LZH, file TOWNS. Move and rename the DRV, file TETRIS. A series of operations for registering EXE in the system is described.
[0078]
When the completion of download (OK) is notified from the terminal 23, the host computer 21 next sends the setting file SETUP. Instructions for performing automatic installation according to the description of INF INSTALL D: ¥ SOUKO ¥ SETUP. INF is sent to the terminal 23.
[0079]
In response to this, the terminal 23 receives the setting file SETUP. Automatic installation is performed according to the description of INF. The terminal 23 first disconnects the line with the host computer 21 by the command LOG OFF. Thereafter, the communication line 22 is not used, so no communication fee is charged. Next, the command LHA X D: \ SOUKO \ TET \ TET1. With LZH, files TET1. The four files TETRIS. EXE, TOWNS. DRV, PC98. DRV, and MAC. Thaw to DRC.
[0080]
Next, the terminal 23 sends the command MOVE D: \ SOUKO \ TET \ TOWNS. DRV D: ¥ WINDOWS ¥ FONT. With DRV, the file TOWNS. DRV is moved from the directory D: \ SOUKO \ TET to D: \ WINDOWS, and the file name is changed to FONT. Change to DRV. Next, the command ICON TETRIS. By EXE, the file TETRIS. EXE is converted into an icon and registered in the terminal 23. Then, the power is turned off by the command POFF, and the installation work is finished.
[0081]
In the automatic installation using the setting file, the host computer 21 cannot make a final confirmation of the end of the work, but the use efficiency of the communication line 22 can be increased by reducing the number of communications. In addition, the installation conditions such as the model are solved before purchasing the software, and then the installation is automatically performed.
[0082]
FIG. 40 shows an example of a setting file of another format. In the setting file of FIG. 40, [DstDirs] is a list of file storage destinations, and [Files] is a list of files to be stored. Here, the software execution file Soft2 .. Exe is stored in the directory D: \ RIS \ KOBUTA, and TOWNS. The name of DRV is FONT. It is described that it is changed to DRV and stored in the directory D: \ WINDOWS \ SYSTEM.
[0083]
When the setting file is generated, [DstDirs] is described as 1 = SOUKODIR, 2 = WINDIR, but when the host computer 21 obtains actual information of SOUKODIR and WINDIR, 1 = D: ¥ RIS ¥ KOBUTA, 2 = D: Rewritten as \ WINDOWS \ SYSTEM. Thus, the setting conditions in the setting file can be changed dynamically or selectively.
[0084]
As described above, according to the prior application, software desired by the user can be automatically installed on the terminal device from the distribution center via the communication line. Using this, it becomes possible to sell the software to the user via the communication line.
[0085]
At this time, since the delivered software is stored in a dedicated directory, the maintainability is good, and the user does not need to input a character string specifying a delivery destination directory or the like.
[0086]
The user can efficiently select the desired software on the screen of the terminal device, and can also select the installation method. Further, it is not necessary for the user to check the operating environment of the software, and the environment is automatically checked.
[0087]
Furthermore, it is possible to minimize the use of communication lines when installing software.
[0088]
[Problems to be solved by the invention]
However, the above-described remote installation system has the following problems.
[0089]
There are various types of software currently distributed by personal computer communication. For example, what is called freeware is basically distributed free of charge, and what is called shareware is temporarily sent free of charge with a function restriction, and then the function restriction is lifted if a predetermined fee is sent. It has become. Moreover, what is sold as a product is basically sent in exchange for the price.
[0090]
When a distribution center uses a remote installation function to provide a service for selling software to a user, a mechanism is required to ensure that the price is received according to such various sales forms. Especially in the case of shareware, the problem is how to process the receipt of the price and the release of the function restriction.
[0091]
SUMMARY OF THE INVENTION An object of the present invention is to provide a software price settlement system and method for automatically deciding the price of delivered software in a service for selling software via a communication line.
[0092]
[Means for Solving the Problems]
FIG. 1 is a diagram showing the principle of a software fee settlement system according to the present invention. The software price settlement system of FIG. 1 is provided in an information processing system that delivers software to a user terminal device via a communication network, and includes software information storage means 51, price information storage means 52, processing means 53, and accounting means 54. Is provided.
[0093]
The software information storage means 51 stores software information including a registered software main body file and management information.
The price information storage means 52 stores price information regarding the sales form and price of the registered software.
[0094]
When the processing unit 53 receives a delivery request for the registered software from the first user, the processing unit 53 determines the price of the registered software based on the price information stored in the price information storage unit 52, and according to the sales form. Perform the delivery process.
[0095]
The price information describes the sales form and price of registered software such as freeware and shareware, and the processing means 53 refers to this price information to determine the price of the software that received the delivery request, Appropriate delivery processing can be performed. For example, if the registered software is freeware, it is installed free of charge on the first user's terminal, and if it is a product, it is installed in exchange for the specified price. In the case of shareware, processing necessary for releasing the function restriction is performed in exchange for a predetermined price. In this way, the price for the software is automatically approved.
[0096]
The processing means 53 receives the software information and price information from the terminal of the second user who performs software registration, for example, via the network in advance, and registers them in the software information storage means 51 and the price information storage means 52, respectively. .
[0097]
The charging unit 54 automatically charges the first user with the price determined by the processing unit 53. This makes it possible for the distribution center or the second user to reliably receive the paid software fee.
[0098]
For example, the software information storage means 51 and the price information storage means 52 in FIG. 1 correspond to a storage device associated with the host computer 63 in FIG. 2 of the embodiment, and the processing means 53 and the charging means 54 are the CPU of the host computer 63. (Central processing unit).
[0099]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.
FIG. 2 is a configuration diagram of the remote installation system according to the embodiment. In the system of FIG. 2, N terminals 61-1,..., 61 -N are coupled to the host computer 63 via the communication network 62. Terminals 61-1,..., 61-N are terminal devices of respective users to be serviced, and the host computer 63 is on the distribution center side. Although the host computer 63 appears to be one when viewed from the network 62, in practice, distributed processing by a plurality of computers is possible. First, a method for registering software (content) in the host computer 63 via the network 62 will be described. The software author needs to upload information necessary for registration together with the created main body file. At this time, the information to be uploaded is standardized. As a specific method for uploading software information, a standardized and classified information is sent with a TAG indicating its contents. By standardizing information, registration work and check work can be automated. Also, by dividing the information and uploading it, it is possible to retransmit only the necessary part at the time of finding a bug and shorten the time required for re-uploading. Upload information is roughly classified into the following five types.
[1] CFG file (configuration file): Basic information (essential information) for registering software in the system, including the following.
○ Information to register in the database
Content name
Previous version of content, current version (not required)
Sales form (freeware / shareware / commercial product)
price
Operable hardware
Operating OS
Search keyword
○ Information about the main process of installation
Content compression method
How to install
○ Pre-processing and post-processing information during installation
Pre-treatment presence and method
Existence and method of post-processing
[2] Explanation file: Explanation describing the outline of the software (essential information)
[3] Main body file: Compressed files required for execution and combined into one (essential information)
[4] CHK file (check file): A file written in a special language and requiring only environment-dependent software is necessary to qualify remote installation by examining the environmental conditions under which the software operates. Commonly used ones are provided by the system, while special ones are optionally created by the user. The CHK file includes the following information, for example.
[0100]
CHKEXE: Execution program for an optional environment check
VERSION: Created when version information of DLL (dynamic link library) needs to be checked as an option.
[0101]
Information such as the check script 40 in FIG. 30 can be described in the CHK file.
[5] Installation-related file: An actual procedure for remote installation is written and includes the following information.
[0102]
INSTALL: Actual installation procedure (not required if the procedure is standardized)
The standardized installation process is as follows, and most software can be installed within this range.
[0103]
1. If specified, perform preprocessing.
2. Download the compressed main body to the work area of the terminal.
3. Extract the main body and copy the file to an appropriate directory.
[0104]
4). Change file attributes if specified.
5. If specified, register menus and icons.
6). If specified, perform post-processing.
[0105]
ICON: Information for registering software in what is called a menu or manager
FIRST: A pre-process that is performed prior to the standard installation process when INSTALL is standardized. For example, in the upgrade process, it indicates an old version backup process.
[0106]
LAST: When INSTALL is standardized, post-processing performed after the standard installation, for example, environment variable file CONFIG. This refers to SYS rewrite processing and the like.
Next, a specific example of a file will be described with reference to FIGS. FIGS. 3 to 6 show examples of CFG files, and FIGS. 7, 8, 9, and 10 show examples of explanation files, main body files, CHK files, and installation-related files, respectively.
[0107]
In the CFG files of FIGS. 3, 4, 5, and 6, a line beginning with; represents a comment sentence. In FIG. 3, [name] represents the name for software search, [version] represents the version, and [old version] represents the old version. [Type] represents a sales form, and [price] represents a price. Here, [type] is SHARE, indicating shareware. [Machine] represents operable hardware, and here, four models of TOWNS, FMR, PC98, and PC-AT are listed.
[0108]
In FIG. 4, [os] represents an operable OS, and only WIN31J is listed here. [Key] represents a keyword for search, and “Chinese” is described as a keyword here. [Compression] represents the compression format of the main body, and is described as the LHA method here. [Intype] represents a possible remote installation method. “RIS icon.def” performs a normal remote installation and performs icon file icon. INSTALL represents a method for registering an icon for the installer (INSTALL.EXE) itself, and “DLOAD” represents a method for downloading. Here, any of these methods is possible.
[0109]
In FIG. 5, [suko] represents a recommended directory for storing software at the time of installation. Here, two directories P1 and P2 are described.
[0110]
[Source] represents information of the compressed main body file (archive file), and here, information of two archive files S1 and S2 is described.
The file name of S1 is NEWWP. In LZH, the storage directory after expansion (after decompression) is @ P1 @, the mode during expansion is M, the file capacity is 800000 bytes, and the minimum required capacity after expansion is 2000000 bytes. The file name of S2 is NEWWWPLIB. In LZH, the expanded storage directory is @ P2 @, the expanded mode is F, the file capacity is 7000 bytes, the minimum required capacity after expansion is 13000 bytes, and the target file name for duplication check is GSDLL. DLL.
[0111]
Here, if the mode M is designated, the expansion destination directory can be changed on the terminal side, and if the mode F is designated, it cannot be changed. In addition, GSWDLL. DLL is an archive file NEWWWLIB. One of the files compressed and stored in the LZH, and is written to check whether there is a duplicate file name on the terminal.
[0112]
[Destination] represents a special deployment destination directory, and here, @ WINSYSTEM @ is written as D1. [Copy] represents information such as a file to be moved at the time of installation, and here, as C1, the file GSWDLL. Included in the archive file specified in S2 is displayed. It is described that the DLL is moved to the directory specified by D1 with the same file name.
N in the Attr column indicates that the attribute remains unchanged after movement.
[0113]
In FIG. 6, [first] represents preprocessing information, and describes a command to be executed before downloading an archive file at the time of installation. [Last] represents post-processing information, and describes a command to be executed after execution of the icon registration command at the time of installation.
[0114]
The explanation file in FIG. 7 is information for explaining to the user an outline of the software called the new word processor-A2 described in the CFG files in FIGS. 3 to 6, and the main body file in FIG. Show. Archive file NEWWP. LZH has three files WP. EXE, NEWWP. ICO, README. DOC and archive file NEWWWPLIB. LZH is one file GSWDLL. It can be seen that only DLL is included.
[0115]
The CHK file in FIG. 9 corresponds to a check script for an environment check at the time of installation. Here, WP. A check for whether or not a file named EXE exists in the user's terminal, a check for whether or not the file is the latest version, and a process according to each check result are described.
[0116]
FIG. 10 shows an ICON file that is a type of installation-related file. In the ICON file of FIG. 10, information such as an execution file of the new word processor-A2, a current working directory, and an icon registration file are described. This ICON file is used for system registration at the time of remote installation.
[0117]
By uploading such a CFG file, description file, main body file, CHK file, and installation-related file from the terminal to the host computer 63, the new word processor-A2 is automatically registered. The registered software is delivered to the terminal for a fee or free of charge according to a request from the user.
[0118]
By the way, when selling software by a remote installation system, a special procedure for charging or a change in price may be required depending on the type of software, the user's past purchase history, or the like. Therefore, in order to perform charging according to the type of software to be delivered, a file defining a procedure related to charging is uploaded at the time of software registration.
[0119]
FIG. 11 shows an example of a file group created on the terminal 61-i (i = 1, 2,..., N). In FIG. 11, in addition to the CFG file 72, the explanation file 73, the main body file 74, the CHK file 75, and the installation related file 76, a definition file 77 and a rewrite file 78 are created in the memory 71. These file groups are uploaded to the host computer 63.
[0120]
Here, consider a case where the creator of shareware software registers it in the host computer 63. In the case of shareware, the author describes shareware remittance procedures in the definition file 77. The definition file 77 describes the software name, software code, remittance destination, remittance amount, remittance type, and user system update method.
[0121]
FIG. 12 shows an example of the definition file 77 for shareware. The definition file AAAS. In CFG, [name] represents the name of the shareware “AAA scheduler”, and [type] describes a remittance procedure. Here, FJOKI is written as the remittance destination ID for the soft code 555. AAA represents a designated serial number label, and here means “AAA scheduler”. [Price] represents a price, [machine] and [os] represent an operable model and OS, respectively, and [key] represents a search keyword.
[0122]
[Intype] describes the type of remittance, and here, a process for canceling the function restriction on the spot when a remittance is requested is described. [Last] describes user file update processing as post-installation processing. Here, using the command CHGINI, the file INI. A process for rewriting the user's file in accordance with the contents described in DEF is described.
[0123]
Note that the difference in remittance procedure between normal software and shareware is identified in the [type] section.
The CHK file 75 is also used as one of option files relating to the remittance procedure, and describes the contents that the user and the host computer 63 interact with at the time of installation. FIG. 13 shows an example of such a CHK file 75. The CHK file AAAS. CHK contains the file AAA. A process for checking whether the INI exists in the user system and confirming the storage location with the user is described. AAA. INI is a file for setting the function of shareware. If correct information is not written in the [UserInfo] section, the shareware does not operate completely.
[0124]
The rewrite file 78 is an option file that defines the rewrite method of the user system. FIG. 14 shows an example of the rewrite file 78. The rewrite file INI. DEF includes a file AAA. A process of rewriting the value of the License in the [UserInfo] section in the INI to AA123AAA is described. License = AA123AAA plays the role of an encryption code for releasing the function restriction of shareware.
[0125]
FIG. 15 shows an example of upload processing of the file group shown in FIG. In FIG. 15, the shareware author first has a CFG file 72 (AAA.CFG), an explanation file 73 (AAA.TXT), an installation-related file 76 (here, an icon file ICON.DEF), and a main body as main body registration files. Upload file 74 (AAA.LZH) from your terminal. The host computer 63 registers these upload information in the content database 81. Here, the software code, name, type (TYPE), main body file name, description file name, icon file name, and the like of the uploaded software “AAA scheduler” are registered as management information. SHARE in the type column indicates that the software type is shareware. The content database 81 is provided, for example, in the host computer 63 or in an external disk device.
[0126]
Next, the author uploads a definition file 77 (AAAS.CFG), a CHK file 75 (AAAS.CHK), and a rewrite file 78 (INI.DEF) as remittance procedure files. As a result, the software code, name, type, CHK file name, post-processing file name, etc. of the remittance procedure file AAAS are registered in the content database 81. Here, as a file for post-processing, the file name INI. DEF is written. Also, SOKIN # RIS in the type column indicates that the type of software is a shareware remittance procedure file, and AAAS. This corresponds to the information of [intype] of CFG.
[0127]
Next, the shareware remittance procedure using the uploaded file group will be described with reference to FIGS. 16 to 20. In the shareware procedure, in addition to the remote installation procedure of the previous application, a remittance flag is set on the protocol. Then, by setting this flag from the terminal and requesting a software search, the shareware procedure can be selected. In addition, a menu for turning ON / OFF the remittance flag is displayed on the terminal screen.
[0128]
16, 17, 18 and 19 show the remittance procedure of the shareware “AAA scheduler”. However, before the remittance procedure, it is assumed that the shareware “AAA scheduler” is installed in the user system with function restrictions. When the user intends to purchase this software, a command / response is exchanged between the host computer 63 and the terminal as shown in the figure.
[0129]
In FIG. 16, the terminal first transmits the user environment to the host computer 63 (step S31), and upon receiving this, the host computer 63 returns a response (step S32). Next, when the user requests a keyword list for software search (step S33), the host computer 63 returns the keyword list (step S34).
[0130]
At this time, as shown in FIG. 17, an option procedure menu 82 is displayed on the screen of the terminal, and the user designates “send money” from the menu and selects a keyword from the keyword list. Thereby, the remittance flag SOKIN is set (turned on), and an instruction to start searching for shareware is sent to the host computer 63 (step S35). The host computer 63 searches the content database 81 with the specified keyword, and returns the name of the software whose type starts with SOKIN and the software code of the remittance procedure file (remittance software) (step S36). Here, names such as “AAA scheduler” and “BBB scheduler” and software codes 4000 and 4001 of remittance software are returned.
[0131]
The terminal lists only the remittance software, and the user designates the specific remittance software in the listing (step S37). Here, the soft code 4000 is designated. The host computer 63 negotiates with the terminal side according to the conditions of the remittance software with the soft code 4000 (step S38). Here, first, AAA. Instruct the terminal to check the location of the INI. In response, the terminal receives AAA. The location of the INI is checked, and the host computer 63 is notified that the location is E: ¥ AAA (step S39). It is assumed that the command ST4 is provided in advance on the terminal side.
[0132]
Next, in FIG. 18, the host computer 63 displays a dialog box 83 on the terminal screen, and AAA. The user confirms whether the position of INI can be E: ¥ AAA (step S40). If the directory displayed in the dialog box 83 is correct, the user returns the directory as it is (step S41), and the host computer 63 determines that the directory path of the file to be rewritten in the user system is E: \ AAA \ AAA. Confirm INI. If the displayed directory is not correct, the user enters the correct directory name. For example, if G: ¥ GGG is entered, the terminal will receive a directory path G: ¥ GGG ¥ AAA. INI is returned to the host computer 63. AAA. Since the storage location of the INI has been determined, the host computer 63 notifies the terminal that shareware remittance is possible (step S42).
[0133]
Next, in FIG. 19, the user requests release of the function restriction (step S43). In response to this, the host computer 63 refers to [intype] in the definition file of FIG. The rewrite file INI. Send DEF. Further, a post-processing command CHGINI is sent with reference to [last] of the definition file, and INI. The terminal is instructed to rewrite according to the DEF procedure.
[0134]
In response, the terminal receives the downloaded INI. With reference to DEF, as shown in FIG. Rewrite INI. In FIG. 20, it can be seen that AA123AAA is written in the [UserInfo] License after rewriting. As a result, the function restriction of the shareware “AAA scheduler” is released, and the shareware “AAA scheduler” operates completely on the user system.
[0135]
Thereafter, the host computer 63 receives the INI. DEF is deleted from the terminal, and the process ends.
In the definition file of FIG. 12, the information that the restriction is released on the spot was written in the [intype] section, so the function restriction of the shareware was released at the same time as the payment was withdrawn. However, as with a general personal computer communication center, the host computer 63 may be configured to only withdraw money and issue an e-mail to a shareware registrant.
[0136]
FIG. 21 shows an example of the definition file 77 in the case of supporting only price withdrawal and issuance of electronic mail. Definition file BBBS. Of “BBB scheduler” in FIG. In CFG, the sections from [name] to [key] are the same as those in FIG. [Intype] describes only the remittance process, and the function restriction is not released on the spot. In this case, the author of “BBB scheduler” does not have to prepare CHK files and rewrite files as shown in FIGS. Definition file BBBS. When the CFG is uploaded to the host computer 63, SOKIN # MAIL is recorded in the type column of the content database 81.
[0137]
22, 23, and 24 show a charge withdrawal procedure for the software “BBB scheduler”. However, it is assumed that the shareware “BBB scheduler” is installed in the user system with a function restriction before this procedure. When the user intends to purchase this software, a command / response is exchanged between the host computer 63 and the terminal as shown in the figure.
[0138]
In FIG. 22, the terminal first transmits the user environment to the host computer 63 (step S51), and the host computer 63 returns a response when receiving this (step S52). Next, when the user requests a keyword list for software search (step S53), the host computer 63 returns the keyword list (step S54).
[0139]
At this time, as shown in FIG. 23, an option procedure menu 82 is displayed on the terminal screen, and the user designates “send money” from the menu and selects a keyword from the keyword list. Thereby, the remittance flag SOKIN is set, and an instruction to start searching for shareware is sent to the host computer 63 (step S55). The host computer 63 searches the content database 81 with the designated keyword, and returns the name of software whose type starts with SOKIN and the software code of the remittance software (step S56). The terminal lists only the remittance software, and the user designates the remittance software of the soft code 4001 from among the listings (step S57).
[0140]
Next, in FIG. 24, the host computer 63 displays a message 84 on the terminal screen and confirms with the user whether or not to charge (step S58). At this time, the host computer 63 refers to [intype] in the definition file of FIG. 21, changes the value of the flag SOKIN to “0x08” representing only mail issuance, and returns it to the terminal. The user selects OK if he / she can charge, or NG if he / she does not purchase. Here, OK is selected, and a mail issuance request for the registrant is sent from the terminal to the host computer 63 (step S59). In response to this, the host computer 63 withdraws the price from the user's account or the like, and sends an e-mail notifying the registrant of the “BBB scheduler” of the withdrawal. As the mail destination, the remittance destination FJOKI in the [type] section of the definition file is used.
[0141]
The registrant who has received the e-mail from the host computer 63 notifies the software purchaser of the function restriction release method by means of e-mail or the like. As a result, the purchaser can use all the functions of the “BBB scheduler”.
[0142]
By the way, depending on whether a user has already purchased an old version of software or related software, there is a case where it is desired to change the setting of the selling price for the user. In this case, the software registrant describes a plurality of prices and their sales conditions in the [price] section of the definition file 77. For example, the price change condition can be described using a software code of already purchased software, a user ID (UID), and a machine ID (MID). Here, the UID is an identifier that uniquely identifies a user, and the MID is an identifier that uniquely identifies an installation destination terminal. Such a plurality of pricing methods using the definition file 77 can be applied not only to shareware remittance procedures, but also to ISV (independent software vender) software priced as a normal product. .
[0143]
FIG. 25 shows an example of the definition file 77 in which a plurality of prices are set. The [type] section of the “CCC scheduler” in FIG. 25 represents ISV software. In the [price] section, three prices of 0 yen, 2000 yen, and 5000 yen and conditions for selecting a sales price from them are written. The selection conditions for the sales price are as follows.
(A) No charge if the accessing user and terminal have already purchased the software XSOFT with the software code 111. XSOFT may be, for example, software that is a predecessor of the CCC scheduler, or may be an older version of the CCC scheduler.
(B) 2000 yen when the accessing user or terminal purchases the software YSOFT with the software code 123 or 124. YSOFT is related software of the CCC scheduler.
(C) 5000 yen if not applicable to (a) or (b).
The database of the host computer 63 is configured as shown in FIG. In FIG. 26, a customer database 85 stores management information related to users of remote installation systems and their terminals, and a purchase database 86 stores purchase histories related to users who have purchased software in the past. Also, the storage location of the price file 87 describing the price selection conditions is recorded in the PRICE field of the CCC scheduler of the content database 81. These databases 85, 86, 81 are provided in the host computer 63 or in an external disk device, and the price file 87 is also stored in the disk device. The host computer 63 reads the price file 87 of the CCC scheduler with reference to the content database 81, and determines the price according to the description.
[0144]
FIG. 27 is a flowchart of price determination processing based on the price file 87. When processing is started in FIG. 27, the host computer 63 first refers to the customer database 85 and the purchase database 86, and the software of the software code 111 is purchased by combining the UID of the accessing user and the MID of the terminal. It is checked whether it has been performed (step S61). If there is such history data, the price is set to 0 yen (step S62), and the process is terminated. If there is no such history data, it is next checked whether there is a purchase record of the software code 123 or 124 in the purchase history including the UID of the accessing user or the MID of the terminal (step S63). ). If there is such history data, the price is set to 2000 yen (step S64), and the process is terminated. If there is no such history data, the price is set to 5000 yen (step S65), and the process is terminated.
[0145]
Now, the UID of the user who wishes to purchase the CCC scheduler is FJOTA, and the MID is 0005. In the purchase database 86 of FIG. 26, it is recorded that the user has purchased the software of the soft code 111 using the terminal. Therefore, the determination result in step S61 is YES, and the CCC scheduler is delivered free of charge. .
[0146]
If a user who has not purchased any of the software codes 111, 123, and 124 accesses from a terminal that has not purchased any of the software codes 111, 123, and 124, the price will be the maximum amount of 5000 yen. Even if there is a purchase history of the soft code 111, if one of the UID and MID does not match the identifier used for access, the software is charged.
[0147]
The definition file in FIG. 25 is merely an example of price setting, and the registrant may set other arbitrary selection conditions by combining soft codes, UIDs, and MIDs. For example, a specific UID or MID can be set to be sold at a special price. In this way, by describing and uploading the price setting conditions in the definition file 77, various software price settings can be made.
[0148]
If the software to be sold is shareware instead of ISV software, the price is determined based on the price file at the time of debiting in FIG. 19 or FIG.
[0149]
【The invention's effect】
According to the present invention, in a service for selling software via a communication line, it is possible to automatically determine various software charges and perform billing processing. In particular, in the case of shareware, it becomes possible to cancel the function restriction after debiting the price.
[0150]
Also, the software registrant can specify the payment method and register the information in advance. For example, a distinction between freeware, shareware, paid software, price setting conditions, and the like are designated.
[Brief description of the drawings]
FIG. 1 is a principle diagram of the present invention.
FIG. 2 is a system configuration diagram of the embodiment.
FIG. 3 is a first diagram showing a CFG file;
FIG. 4 is a second diagram showing a CFG file.
FIG. 5 shows a CFG file (part 3);
FIG. 6 is a diagram showing a CFG file (part 4);
FIG. 7 shows an explanation file.
FIG. 8 shows a main file.
FIG. 9 is a diagram showing a first CHK file.
FIG. 10 is a diagram illustrating an ICON file.
FIG. 11 is a diagram showing a file group created on the terminal.
FIG. 12 is a diagram showing a first definition file.
FIG. 13 is a diagram showing a second CHK file.
FIG. 14 is a diagram showing a rewrite file.
FIG. 15 is a diagram showing upload.
FIG. 16 is a diagram (No. 1) illustrating a shareware procedure;
FIG. 17 is a diagram (part 2) illustrating the shareware procedure;
FIG. 18 is a diagram (part 3) illustrating the shareware procedure;
FIG. 19 is a diagram (part 4) illustrating the shareware procedure;
FIG. 20 is a diagram illustrating file rewriting.
FIG. 21 is a diagram showing a second definition file.
FIG. 22 is a diagram (No. 1) showing a procedure for debiting a charge;
FIG. 23 is a diagram (No. 2) illustrating a procedure for debiting a charge.
FIG. 24 is a diagram (No. 3) illustrating a price debiting procedure;
FIG. 25 is a diagram showing a third definition file.
FIG. 26 is a diagram showing a database of a host computer.
FIG. 27 is a flowchart of price determination processing.
FIG. 28 is a configuration diagram of a remote installation system of a prior application.
FIG. 29 is a flowchart (No. 1) of remote installation;
FIG. 30 is a flowchart (part 2) of remote installation;
FIG. 31 is a flowchart (part 3) of remote installation;
FIG. 32 is a diagram illustrating an example of an installation method selection window.
FIG. 33 is a diagram (part 1) illustrating a remote installation protocol;
FIG. 34 is a diagram (part 2) illustrating a remote installation protocol;
FIG. 35 is a diagram showing a keyword selection protocol;
FIG. 36 is a diagram illustrating a display example of keywords.
FIG. 37 is a diagram illustrating a transmission protocol of environment information.
FIG. 38 is a diagram illustrating an environment check protocol;
FIG. 39 is a flowchart of automatic installation.
FIG. 40 is a diagram illustrating an example of a setting file.
[Explanation of symbols]
21, 63 Host computer
22 Communication line
23, 61-1, 61-N, 61-i terminal
24 display devices
25 hard disk
31, 38, 39 Environment file
32 First key table
33 Second key table
34, 44 Setting file
35 Software Group
36 Warehouse window
37 icons
40 Check script
41 File body
42, 43 Installation script
51 Software information storage means
52 Price information storage means
53 Processing means
54 Billing means
62 network
71 memory
72 CFG file
73 Description file
74 Body file
75 CHK file
76 Installation related files
77 definition files
78 Rewrite file
81 Content database
82 Menu
83 Dialog Box
84 messages
85 Customer Database
86 Purchase Database
87 Price file

Claims (11)

In an information processing system for delivering software to a user terminal device via a communication network,
Software information storage means for storing software information including a registered software main body file and management information;
Price information storage means for storing price information relating to the sales form and price of the registered software;
Purchase history storage means for storing purchase history information of software purchased by the user;
When receiving a delivery request for the registered software from the first user, the price information stored in the price information storage means and the purchase history information stored in the purchase history storage means are read out, the price information, and The price of the registered software is determined based on whether the software purchased by the user indicated by the purchase history information is the same software or related software, and a delivery process is performed according to the sales form. A software price approval system comprising: a processing means.   2. The software price settlement system according to claim 1, further comprising billing means for automatically billing said first user for the price determined by said processing means.   2. The software price approval system according to claim 1, wherein the processing means receives the software information and price information from a terminal device of a second user and registers them in the software information storage means and price information storage means.   When the registered software is shareware, the price information storage means stores the price information including a shareware function restriction release procedure, and the processing means is required based on the release procedure at the time of finalizing the price. 2. The software price settlement system according to claim 1, wherein processing is performed.   5. The processing means receives a flag for shareware procedure from the terminal of the first user, and if the flag is set, performs processing for releasing the function restriction of the shareware. Software price settlement system.   The processing means displays a menu for selecting a shareware procedure on the screen of the first user's terminal, and when the first user selects the shareware procedure, the processing means sends it from the terminal of the first user. 6. The software price approval system according to claim 5, wherein a flag for shareware procedure is set.   In the release process, the processing means sends a file necessary for releasing the restriction of the shareware to the terminal of the first user and instructs the terminal of the first user to release the function restriction. 6. The software price settlement system according to claim 5, wherein   6. The software according to claim 5, wherein the processing means issues an e-mail notifying that the first user has been charged for the fee to the shareware registrant in the release processing. Price settlement system.   The purchase history information includes a software identifier, and the processing means refers to the software identifier included in the purchase history information according to a user identifier of the first user and a machine identifier of the terminal of the first user. 2. The software price settlement system according to claim 1, wherein the price of the registered software is determined according to the price information.   The purchase history information includes a software identifier of software purchased by a user, and the processing means refers to the software identifier included in the purchase history information according to the user identifier of the first user, and 2. The software price settlement system according to claim 1, wherein the price of registered software is determined.   The purchase history information includes a software identifier of software purchased by the user, and the processing means refers to the software identifier included in the purchase history information according to a machine identifier of the terminal of the first user, and the price information 2. The software price settlement system according to claim 1, wherein the price of the registered software is determined according to:

Images