JPH09101986A - System and method for settling account of software - Google Patents

Abstract

PROBLEM TO BE SOLVED: To automatically clear the bill of a delivered software in the service of vending the software through a communication line. SOLUTION: The designer of software up loads a main body registration file and a money transfer procedure file through a communication network to a host computer. The host computer registers this information into a contents data base 81 and when a delivery request is received from a user, charging/ delivery is performed corresponding to the type of software. In the case of shareware, for example, the drop of price from account and the cancel of function limitation are simultaneously performed in place of the information of money transfer procedure file. Besides, the host computer can variously set prices by storing a price file describing the algorithm of price decision.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a service for installing software in a terminal device of a user via a communication line, and relates to a software price approval system and method for approving the price of software.

[0002]

2. Description of the Related Art With the recent development of personal computer communication and the like, there has been a desire of users to obtain software through a communication line. However, a full-scale system for automatically delivering such software is Not realized. In order to automatically deliver the software, first, the user requests the desired software from the home terminal device to the delivery center, and the delivery center notified by the user sends the requested software to the user terminal device via the communication line. The format of sending may be considered.

In order to realize such automatic delivery of software, a prior application "remote installation system and method" (Japanese Patent Application No. 7-1797) was devised. The technology of the prior application will be described below with reference to the drawings.

FIG. 28 is a block diagram of the remote installation system of the prior application. The remote installation system of FIG. 28 comprises a host computer 21 at a software distribution center, a user terminal 23, and a communication line 22 connecting these. The terminal 23 is, for example, a personal computer at the user's home far from the distribution center, and the communication line 22 is, for example, a line for a personal computer communication network.

The host computer 21 has a first key that holds a software group 35 including a plurality of software deliverable in a storage area (not shown) and a list of keywords used when selecting specific software from the software group 35. Table 32 and second key table 3
3 is stored.

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 displays the keywords contained therein on the terminal 23. It is displayed on the screen of the device 24. The user selects a keyword corresponding to the desired software from the displayed keywords and notifies the host computer 21 of it.

The host computer 21 displays a menu including the names of some software corresponding to the notified keyword on the screen of the display device 24, and the user selects the desired software from the menus and notifies the host computer 21 of it. To do. Then, the host computer 21 takes out the content (file) of the software selected by the user from the software group 35 and stores it in the directory D: \ SOUKO for delivery (home delivery or distribution) set in the hard disk 25 of the terminal 23. .

At this time, the icon 37 for activating 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. It For example, when the terminal 23 is equipped with WINDOWS, the delivered software is registered in the WINDOWS program manager. After that, the user can use the delivered software by simply clicking the icon 37 with an input device such as a mouse.

An environment file 31 that describes the operating environment of the 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 accesses it. 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.

The host computer 21 also prepares an individual setting file 34 for each user, and describes the set of files required for the operation of the software selected by the user and the storage location thereof. Then, it is possible to collectively send the setting file 34 together with the set of files to the terminal 23 to cause the terminal 23 to automatically install the software.

Next, the operation flow of software delivery by the remote installation system shown in FIG. 28 will be described with reference to FIGS. 29 to 31. In FIG. 29, the terminal 23 of the user A acquires the information on the operating environment when installing the terminal software for communication, and creates the environment file 38 in which the acquired information is set (step S1).
At this time, information that takes time to obtain the model of the user's terminal, the storage location SOUKO used for home delivery, or
Obtain information that may need to contact the user.

In determining the storage location SOUKO,
The terminal 23 checks whether or not the hard disk 25 has a free area of a predetermined capacity or more, 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 work of confirming the name. Therefore, the user A does not need to input a directory name or the like.

In this case, the model of the user A is TOWNS, and the directory of SOUKO is D: \ SOUKO.
It is written in the environment file 38 that it is (directory SOUKO of drive D). User A can also change D: \ SOUKO to another directory if necessary.

If there is no free space of a predetermined capacity in the partition that has already been set, another partition is searched for the largest free space and a directory for home delivery is created there. Specifically, directory D: ￥
If SOUKO is full, the terminal 23 displays "D:
¥ SOUKO is full. Change warehouse to F: \ SOUKO. Is it OK. A message such as "" is displayed on the screen of the display device 24. When the user A approves it, F: \ SOUKO becomes a new SOUKO directory. When there is no free space of a predetermined capacity in any hard disk. , "Unfortunately there is not enough disk space. Add more disks. A message such as "is displayed.

Next, when the terminal software is started (when the host computer 21 is accessed), information that may have changed after installation, such as the status of the hard disk and 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 space is 300 Mbytes. The content of the environment file 38 created in this way is 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).

The host computer 21 holds the received information as a user A environment file 39. In the user A environment file 39, in addition to the model, hard disk information HD, storage location SOUKO, the OS (operating system) being used and its storage location are described. Here, the OS of the terminal 23 of the user A is WINDOWS, and its storage location WINDOWR is D: \ WINDOW.
It turns out that it is S.

Command RIS from the host computer 21 S
RIS as a response to ENDENV SEN
Upon receiving DENV * RESP OK, the terminal 23 sends the command RIS The 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. KEY
Return with LIST * RESP. Here, the first
In the key table 32, OS / basic software, development support, games, ... Are stored as keywords corresponding to the key numbers 1, 2, 3 ,.

When these keywords are displayed as the first key list on the screen of the display device 24 (step S
5) The user A selects the first keyword from them and inputs it to the terminal 23 (step S6). Then, terminal 2
3 is a command RIS requesting the second key list together with the key number of the first keyword selected by the user A. KEY
LIST 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.

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, The contents are RIS KE
Send back with YLIST * RESP. Here, in the second key table 33, key numbers 51, 52, 53,
As keywords corresponding to ..., RPG, action, puzzle / quiz, ... are stored.

The second key table is the first key table 32.
There are generally multiple keywords corresponding to the keywords in
The number is equal to or smaller 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 will point to the same second key table.

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 S
9). Then, the terminal 23 requests the 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 key number 52 corresponding to it is sent to the host computer 21.

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, a flat search is performed without distinguishing between the first keyword and the second keyword as search conditions. In addition, the model and the type of OS are treated as default keys, and these are also taken into consideration when searching. As a result, for example, it is possible to prevent searching for software dedicated to a model other than TOWNS.

Then, the list of the names and numbers of the corresponding software is obtained by RIS. It is sent to the terminal 23 together with LIST * RESP. Here, since software such as Tetris and pachinko having the key numbers 3 and 52 is applicable, those names are sent to the terminal 23 together with the respective software numbers 5 and 30.

When the 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 software number selected by the user A, a command RIS requesting a check as to 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.

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. , Environmental check. This check is automatically performed by the interaction between the execution program of the check script 40 and the terminal software of the terminal 23.
Does not necessarily have to be aware that the environment check is being performed (step S14). Only when it becomes necessary to make an inquiry to the user A, the host computer 21 makes the inquiry.

Here, as the operating environment of Tetris selected by the user A, the OS is WINDOWS and the model is TOW.
Recommended directory (DIR) name such as NS or PC98 is T
It is described as ET. On the other hand, in the user A environment file 39, the model is described as TOWNS and the OS is described as WINDOWS, and by comparing the two, it is understood that the model and the OS are compatible.

Next, the Tetris check script 40
Sees VBRJ in the storage location WINDIR on the user A side.
P200. Command "ST4 @ WINDIR @ VBRJ" to check if there is a file called DLL
P200. Since there is a DLL "(MQ1), the host computer 21 sends it to the RIS. Send to terminal 23 with CHKENV * RESP. At this time, the host computer 21 refers to the user A environment file 39 and replaces @ WINDIR @ with D: \ WINDOWS and sends it. Here, @ represents a wild card. In addition, file VBRJP20
0. DLL is one of the files required for the operation of Tetris.

Upon receiving this command, the terminal 23 stores the file VB in the directory WINDOWS of the drive D.
RJP200. It is checked whether or not there is a DLL, and the result is sent back to the host computer 21 as ANS. here,
Since there is no corresponding file, ANS = OFF is returned.

The file VBRJP200. D
The host computer 21, which has learned that there is no LL, follows the check script 40 (MQ2) and executes “VBRJP20
Can I copy 0? Inquiry "Terminal 23
This inquiry is displayed on the screen of the display device 24. The user A inputs an answer to the displayed inquiry, and the terminal 23 sends the answer back to the host computer 21. Here, ANS = Yes is returned, and the host computer 21 accepts the remote installation according to the check script 40 (RIS = OK), and VBRJP
200. A flag F2 for instructing DLL copy is turned on (MA2).

If the file VBRJP200. DLL
Is in the specified directory of the terminal 23, A
NS = ON is sent back, so RIS = O at that point
It becomes K (MA1).

By automatically performing the environment check in this way, it is possible to prevent the delivery of software that does not match the environment of the user A. For example, an accident such as purchasing a certain package software via the communication line 22 and then knowing that it does not operate without a specific driver is prevented.

When RIS = OK, the host computer 21 finishes the environment check, and the judgment result (JUDGE = OK)
At the same time, the delivery destination directory SOUKODIR is sent to the terminal 23. This SOUKODIR is specified in a format in which TET, which is a recommended directory for Tetris, is added as a subdirectory under D: \ SOUKO which is a SOUKO directory stored in the user A environment file.

At this time, at the same time, whether the installation is possible (R
IS), presence / absence of icon registration of the installation program (installer) (ICON), and availability of download (DLOAD) are sent to the terminal 23. By these flags RIS, ICON, DLOAD, the host computer 21 is installed, the installer icon is registered,
It notifies the terminal 23 which of the downloads is possible.

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 up to the icon registration of the execution file of the software on WINDOWS is included. On the other hand, the icon registration of the installer means the icon registration of the program for executing the installation on the terminal 23.

Here, the condition that installation and download are permitted (RIS = OK, DLOAD = OK) and the installer icon is not registered (ICON = NG) is presented. In the case of software having a complicated installation program, it is presented that installation of the icon of the installer is required instead of permitting the installation. When a terminal equipped with WINDOWS requests a TOS (TOWNS OS) application, only downloading is permitted.

Next, the terminal software of the terminal 23 is prioritized in the order of installation, installer icon registration, and download, and the higher priority is set as a default and displayed on the screen of the display device 24. Here, the installation with the higher priority of the installation and the download permitted by the host computer 21 is set as the default and displayed in the installation method selection window.

FIG. 32 shows a display example of the installation method selection window. In FIG. 32, “system registration” corresponds to installation, and this is selected by default.

The user A confirms the displayed installation method and inputs the confirmation (step S15).
Further, the user A can change the setting displayed here. For example, to register the icon of the installer, select and enter "register icon of installer" in the installation method selection window of FIG.

Basically, the user A selects “system registration” when he / she wants to perform a quick installation without any trouble, and selects “installer icon registration” when he / she wants to make detailed installation settings himself / herself. If you want to change the storage location later (install it on a terminal of another model), select "Download". If "Download" is selected, it is also possible to obtain software for a model different from the model of the terminal 23 and try whether it operates.

Next, the terminal 23 sends a sub-directory for home delivery D: \ SOUKO \ instructed by the host computer 21.
TET is automatically generated in the hard disk 25 (step S16). Here, if the subdirectory D: \ SOUKO \ TET already exists in the terminal 23, a subdirectory such as D: \ SOUKO \ TET 001 is created, and if this also already exists, D: \ Create a subdirectory called SOUKO \ TET 002.

The file body 41 of Tetris is the file T
ET1. LZH (F1) and VBRJP200. DLL
(F2) and TET1. LZH has four files, TETRIS. EXE, TOWNS. DRV, PC9
8. DRV, and MAC. It is made by compressing the DRC. TET1. When LZH is expanded (decompressed) to the state before compression, it is divided into these four files.
Decompression of LZH is performed after delivery from the host computer 21 to the terminal 23.

The terminal 23, which has generated the subdirectory for home delivery, uses the command RIS for requesting the start of remote installation. INSTALL is sent to the host computer 21 together with the selected software number (FIG. 31, step S17). In response to this, the host computer 21 starts remote installation of software corresponding to the sent number. Remote installation is performed by the host computer 21.
In accordance with the Tetris installation script 42 created by the above, this is automatically performed by the communication between the host computer 21 and the terminal 23 (step S18).

In the install script 42, the file TET1. Store LZH at user A side storage location @SO
There is a description instructing to download to UKO @. Therefore, the host computer 21 sets @ SOUKO @ to SO
Replace with UKODIR = D: \ SOUKO \ TET, and subdirectory D: \ SO of the hard disk 25.
TUK1 to UKO \ TET. Download LZH.

Download completed from terminal 23 (OK)
Is notified, the host computer 21 next sends @WIND
Replace IR @ with D: \ WINDOWS and add VB to the directory D: \ WINDOWS on the hard disk 25.
RJP200. Download DLL.

Download completed from terminal 23 (OK)
Is notified, the host computer 21 next stores the storage location @
Download TET1.SOUKO @ (D: \ SOUKO \ TET). Instructions to defrost LZH, LHA X
D: \ SOUKO \ TET \ TET1. Send LZH. In response to this, the terminal 23 receives the TET1. LZH in the four files TETRIS. EXE, TOWN
S. DRV, PC98. DRV, and MAC. DRC
Unzip to. These four files are TET1. LZ
It is stored in the same subdirectory D: \ SOUKO \ TET as H.

When the completion of the decompression (OK) is notified from the terminal 23, the host computer 21 next determines the storage location @SOUK.
O @ (D: \ SOUKO \ TET) model @. A file called DRV is stored in @ WINDIR @ (D: \ WI
NDOWS) and change the file name to FONT. DR
Instruction to change to V, MOVE D: \ SOUKO \ TE
T \ TOWNS. DRV D: \ WINDOWS \ FO
NT. Send DRV. At this time, the host computer 21 refers to the user A environment file 39 and sets the model @ TOWN
Replace with S and send. In response to this, the terminal 23 sets the file TOW in the subdirectory D: \ SOUKO \ TET.
NS. DRV is moved to the directory D: \ WINDOWS (file move), and FONT. Change the file name to DRV (Rename).

When the terminal 23 is notified of the completion (OK) of the file move and rename, the host computer 21
Is the file TETRIS. Instruction to register the EXE icon, ICON TETRIS. Send EXE. In response to this, the terminal 23 receives the subdirectory D: \ SOUK.
The file TETRIS.O ¥ TET. The EXE is converted into an icon and registered in the terminal 23. Thereby, the display device 2
4 in the warehouse window 36 displayed on the screen of FIG. The icon 37 for starting EXE is displayed, and when the icon 37 is clicked, Tetris starts its operation.

Completion of icon registration from the terminal 23 (OK)
Is notified, the host computer 21 sends back RETURN to notify the terminal 23 of the end of remote installation, and ends a series of installation operations. The terminal 23 notified of the end of the remote installation selects the next software and remote installs it according to the instruction of the user A, or ends the process (step S19).

At the time of installation in step S18, if the software to be installed is larger than the free space of the storage location of the download destination, the storage location is changed and the software is downloaded.

Next, an example of a remote installation protocol and an example of displaying the first and second keywords will be described with reference to FIGS. 33 to 38. FIG.
Shows an example of a protocol in 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, a request ID (RID) and a machine ID that identifies a terminal
After (MID) and date and time (TIME), machine information (MACHINE :) regarding the terminal 23 is described.

Drive information (D in MACHINE:
RV :) includes hard disk 2 such as capacity and drive name
5 is described. For example, PART I
CAPACITY in NF: represents the capacity of the partition, VACANT represents the free capacity among them, and DRVNAME represents the drive name corresponding to the partition.

Following DRV :, the warehouse directory SOUKODIR, which is a storage location for home delivery, and OS (WIN
WINDOW, which is the storage location of (DOWNS)
Is described. Here, SOUKODIR = D:
\ RIS \ SOUKO, and WINDIR = D: \ W
It is INDWS. Next is information about the memory (MEM :). By designating this SOUKODIR, the terminal 23 notifies the host computer 21 of the delivery destination.

Following MACHINE :, the machine password (MPSWD) of the terminal 23 and the like are 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, following the determination result (JUDGE) of the RID and environment check, information (STRPLACE :) regarding the delivery destination is described.

SOFT in STRPLACE: represents the software number selected by the user in step S12, WORKDIR represents a work area, and SOUKODI
R represents a delivery destination specified by the host computer 21. Here, WORKDIR is the same as SOUKODIR in FIG. 33, and SOUKODIR is SOUKODIR in FIG.
Is added with the subdirectory name FM.

Following STRPLACE :, the work area size WORKSIZE and the delivery destination size SOUKO
SIZ is 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 the command RIS When the first key list is requested by KEYLIST, the host computer 21 returns R as a response.
IS The content KEYLIST: of the first key table is sent back together with KEYLIST * RESP. This KEYL
In IST :, key numbers KEY = 1, 2, 3, ...
The keyword NAME = “OS / basic software”, “development support”, “game”, ...

Next, the terminal 23 sends the command RIS KEY
When the key number 3 of the first keyword “game” selected by the user A is sent together with LIST, the host computer 21
Responds with RIS KEYLIST * RESP
At the same time, the content KEYLIST: of the second key table corresponding to the key number 3 is sent back. This KEYLIST:
Key numbers are KEY = 51, 52, 53, 54, 5
Corresponding to 5, ..., the keyword NAME = "RP
G, “action”, “puzzle / quiz”, “simulate”, “joke”, ... Are described.

Then, the terminal 23 sends the command RIS LI
Along with ST, 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, and three key numbers 3, 52, 5 are sent.
Request a list of software with 5. here,
Since the host computer 21 has already stored the key number 3 of the first keyword already sent, only the key numbers 52 and 55 of the second keyword are sent.

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. 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, next, tools, text, DOS, W are displayed.
A second keyword such as IN, image, voice, game, etc. is displayed. The second keywords include those that overlap with the first keywords, such as images and games.

User A can select any of the displayed keywords. For example, an image is selected as the first keyword, and a tool, DO is used as the second keyword.
S, game, etc., or a game as the first keyword and DOS, WI as the second keyword
Select N, image, sound, etc. Also, the user A can simultaneously select two or more keywords as the second keyword.

In general, since there are many keywords for selecting desired software from the software group 35, it is difficult to display all of them at once, and some are not necessary at all. So, if you display this as a simple tree-structured menu, the keyword you select first plays an important role, and if you make a mistake in selecting it, you will not be able to get the software you want.

Therefore, as shown in FIG. 36, the keywords are displayed in two hierarchies while allowing duplication, so that the user can more flexibly select a necessary keyword from a large number of keywords. Note that the keyword hierarchy is not limited to two, and may be displayed in more hierarchies.

The contents of each software in the software group 35 are stored in advance in association with some keywords. 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.

FIG. 37 shows another example of the transmission protocol of the environment information sent from the terminal 23 to the host computer 21 at the time of host access in step S3. FIG.
In the protocol of No. 7, machine information MACHINE:
MODEL in is the information acquired when the terminal software was installed in step S1, and is the model T of the terminal 23.
Represents OWNS. Also, VAC in PARTINF:
The ANT is information acquired before the access to the host computer 21 in step S3 (step S2), and represents the free space of the corresponding partition.

FIG. 38 shows an example of the protocol for the environment check in step S14 and the installation start in the subsequent step S17. In the protocol of FIG. 38, the terminal 23 first sends the command RIS. CHK
The software number (soft code) SOFT = 5 selected by the user A together with ENV is sent to the host computer 21 to request an environment check.

The host computer 21 first checks the VBRJP20.
0. Instruction CHKEX for checking whether a file called DLL exists in the system directory of the terminal 23
E: is the response RIS Send to terminal 23 with CHKENV * RESP. CHKEXE: TAG
= “VBRJP200.DLL”, command CMD = ”
ST4 D: \ WINDOWS \ SYSTEM \ VBR
JP200. DLL ", work directory specification WO
RKDIR = "D: \ RIS \ KOBUTA", designation of delivery destination directory SOKODIR = "D: \ RI
“S ¥ KOBUTA” and the like are described.

The terminal 23 uses the directory W of the drive D.
File VBRJP20 in INDOWS \ SYSTEM
0. Check if there is a DLL and the result is RESUL
It is sent back to the host computer 21 as T :. RESUL
T: corresponds to TAG = “VBRJP200.DL
The check result VAL = “OFF” is described together with L ”, which means that the file VBRJP200.DLL was not in the system directory.

Therefore, the host computer 21 is selected
User is allowed to install software
The response ASKCHK:
S Send to terminal 23 with CHKENV * RESP. A
For SKCHK :, TAG = "Q1", question to be displayed
Sentence QUERY = "To execute this software
Are you sure you want to stall? , And the answer
-Matte ANS: is described.

The terminal 23 sends the answer entered by the user A to the R
ESULT: as command RIS It is sent back to the host computer 21 together with CHKENV. For RESULT :, the response result VAL with the corresponding TAG = "Q1"
= “OK” is described. This means that the software may be installed.

Therefore, if there is no other obstacle in the operating environment, the host computer 21 returns the response RIS. CHKEN
Environmental check result JUDGE = "with V * RESP
OK "is sent to the terminal 23. This is the file VBRJP
200. Except that there is no DLL, it means that the operating environment of the software of software code 5 is prepared and can be installed.

Since the result of the environment check is "OK", the terminal 23 sends the command RIS Along with INSTALL, type of installation method TYPE = “RIS”, home delivery destination designation STRPLACE: etc. are sent to the host computer 21 to request installation. STRPLACE: is the software code SO of the software to be installed
A work directory WORKDIR and a delivery destination directory SOUKODIR are described together with the FT.

Thereafter, the host computer 21 installs the software by the designated method. At the time of installation, for example, as described in step S18 of FIG. 31, the terminal 23 decompresses a file by a command sent from the host computer 21, copies the file, and sequentially registers it in the system. Since the terminal 23 sequentially sends back as a response whether or not these operations are completed, the host computer 21 can monitor the progress of the installation operation to the end.

However, with this method, the terminal 23 must frequently communicate with the host computer 21,
Communication efficiency becomes poor. Therefore, a method is conceivable in which the host computer 21 prepares a setting file in which a command for installation work is described, and transfers this to the terminal 23 to perform automatic installation.

FIG. 39 is a flow chart of automatic installation using a setting file. The installation work of FIG. 39 is performed after the sub-directory is created in step S16 of FIG.

The terminal 23 first sends the command RIS. INS
TALL with host software number 2
1 (step S21). In response to this, the host computer 21 starts remote installation of software corresponding to the sent number. The remote installation is performed according to the Tetris installation script 43 created by the host computer 21 and the host computer 21 and the terminal 2.
It is automatically performed by the communication between the three (step S
22).

The host computer 21 first sets @ SOUKO @
Is replaced with SOUKODIR = D: \ SOUKO \ TET, and the subdirectory D: \ of the hard disk 25 is replaced.
SOUKO \ TET file TET1. Download LZH.

Download completed from terminal 23 (OK)
Is notified, the host computer 21 next sends @WIND
Replace IR @ with D: \ WINDOWS and add VB to the directory D: \ WINDOWS on the hard disk 25.
RJP200. Download DLL.

Download completed from terminal 23 (OK)
Is notified, the host computer 21 next sends @SOUK
The O @ is replaced with SOUKO = D: \ SOUKO, and the setting file 44 (SETUP.INF) for the user A, which describes the command of the work to be performed by the terminal 23, is downloaded to the directory D: \ SOUKO of the hard disk 25. At this time, the host computer 21 executes step S1.
8, the user A environment file 39 is referred to, and the setting file SETUP. Models included in INF, SOUK
The information such as O and WINDIR is rewritten to the information for the user A and sent. Setting file SETUP. In the INF, the files TET1. Unzip LZH and save the file TOWNS.
Move and rename the DRV, and rename the file TETRIS.
A series of tasks for registering EXE in the system is described.

Download completed from terminal 23 (OK)
Is notified, the host computer 21 next sends the setting file SETUP. Instruction to perform automatic installation according to the INF description INSTALL D: \ SOUKO \ SET
UP. The INF is sent to the terminal 23.

In response to this, the terminal 23 receives the setting file S
ETUP. Automatic installation is performed according to the INF description. The terminal 23 first disconnects the line with the host computer 21 by the command LOG OFF. From now on,
Since the communication line 22 is not used, there is no communication charge.
Then, the command LHA X D: \ SOUKO \ TET
¥ TET 1. LZH allows the file TET1. LZH
The four files TETRIS. EXE, TO
WNS. DRV, PC98. DRV, and MAC. D
Thaw to RC.

Next, the terminal 23 sends the command MOVE D:
\ SOUKO \ TET \ TOWNS. DRV D: \ W
INDOWS \ FONT. File TO by DRV
WNS. DRV in the directory D: \ SOUKO \ TE
Move from T to D: \ WINDOWS and change the file name to FONT. Change to DRV. Then the command I
CON TETRIS. File TET by EXE
RIS. The EXE is converted into an icon and registered in the terminal 23. Then, the power is turned off by the command POFF,
Finish the installation work.

In the automatic installation using the setting file, the host computer 21 cannot make a final confirmation of the end of work, but the use efficiency of the communication line 22 can be improved by reducing the number of communications. In addition, solve the installation conditions such as model before purchasing the software,
After that, the installation will be done automatically.

FIG. 40 shows an example of a setting file in another format. In the setting file of FIG. 40, [Ds
tDirs] is a list of file storage destinations, and [F
ises] is a list of files to be stored. Here, the execution file S of the software desired by the user
oft2. Exe directory D: \ RIS \ KOB
TOW that is a driver for TOWNS stored in UTA
NS. The name of DRV is FONT. It is described that it is changed to DRV and stored in the directory D: \ WINDOWS \ SYSTEM.

[DstDi] is generated when the setting file is generated.
rs] is described as 1 = SOUKODIR, 2 = WINDIR, but the host computer 21 uses the actual SOUKODI
When the information of R and WINDIR is obtained, 1 = D: \ RI
S \ KOBUTA, 2 = D: \ WINDOWS \ SYS
Rewritten as TEM. In this way, the setting conditions in the setting file can be changed dynamically or selectively.

As described above, according to the prior application, the software desired by the user can be automatically installed in the terminal device from the distribution center via the communication line. By utilizing this, it becomes possible to sell the software to the user via the communication line.

At this time, since the delivered software is stored in a dedicated directory, maintainability is good, and the user does not need to input a character string designating a delivery destination directory or the like.

The user can efficiently select the desired software on the screen of the terminal device, and can also select the installation method. Moreover, the user does not need to check the operating environment of the software, and the environment is automatically checked.

Further, it is possible to minimize the use of the communication line when installing the software.

[0088]

However, the above remote installation system has the following problems.

Currently, there are various kinds of software distributed by personal computer communication. For example, what is called freeware is basically distributed free of charge, and what is called shareware is sent once for free with limited functions, and then the function restrictions are lifted when a prescribed amount of money is sent. Has become. Items sold as commodities are basically sent in exchange for the price.

When the distribution center uses the function of remote installation to provide a service for selling software to users, in response to such various sales forms,
A mechanism is needed to ensure that the money is received. Especially in the case of shareware, how to handle the receipt of the payment and the release of the function restriction becomes a problem.

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 of selling software via a communication line.

[0092]

FIG. 1 is a principle diagram of a software price settlement system of the present invention. The software price approval system of FIG. 1 is provided in an information processing system that delivers software to a user's terminal device via a communication network, and includes software information storage means 51, price information storage means 52, processing means 53, and charging means 5.
4 is provided.

The software information storage means 51 stores software information including a main file of registered software and management information. The price information storage means 52 stores price information regarding the sales form and price of the registered software.

When the processing means 53 receives the delivery request for the registered software from the first user, the processing means 53 determines the price of the registered software based on the price information stored in the price information storage means 52, and sells it. Delivery processing according to the form is performed.

The price information describes the sales form and the price of registered software such as freeware and shareware. The processing means 53 refers to this price information and determines the price of the software for which a delivery request has been received. It can be determined and appropriate delivery processing can be performed. For example, if the registered software is freeware, it is installed free of charge on the terminal of the first user, and if it is a product, it is installed in exchange for the specified price. In the case of shareware, the processing required for releasing the function restriction is performed in exchange for a predetermined price. In this way, the price of the software is automatically approved.

The processing means 53 uses the above-mentioned software information and price information for the second software registration, for example.
From the user's terminal in advance and registered in the software information storage means 51 and the price information storage means 52, respectively.

The charging means 54 automatically charges the first user for the price determined by the processing means 53. This ensures that the distribution center or second user will receive the payment for the paid software.

For example, the software information storage means 51 and the price information storage means 52 in FIG. 1 correspond to the storage device attached to the host computer 63 in FIG. 2 of the embodiment,
The processing means 53 and the charging means 54 are provided by the host computer 63.
Corresponding to the CPU (Central Processing Unit).

[0099]

BEST MODE FOR CARRYING OUT THE INVENTION Embodiments of the present invention will be described in detail below with reference to the drawings. FIG. 2 is a configuration diagram of the remote installation system of the embodiment. In the system of FIG. 2, N terminals 61-1, ..., 61-
N is coupled to the host computer 63 via the communication network 62. The terminals 61-1, ..., 61-N are terminal devices of each user who is a target of the service, and the host computer 63 is on the distribution center side. Host computer 63
Appears to be one from the network 62, but in reality, distributed processing by a plurality of computers is also possible. First, a method of registering software (content) in the host computer 63 via the network 62 will be described. The software author needs to upload the information necessary for registration together with the created main body file, but at this time, the information to be uploaded should be standardized. As a specific method for uploading software information, standardized and classified information is
Send a TAG indicating the contents. By standardizing the information, it is possible to automate registration work and check work. In addition, by dividing and uploading the information, it is possible to retransmit only the necessary portion when a bug is found, and to shorten the time required for uploading again. The 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 for registering in the database Content name Previous version of the content, current version (not required) Sales mode (freeware / shareware / commercial item) Price Operable hardware Operable OS search keyword ○ Installation book Processing information Content compression method Installation method ○ Installation pre-processing and post-processing information Pre-processing presence and method Post-processing presence and method [2] Explanation file: Description that outlines the software Information) [3] Main file: Files necessary for execution are compressed and put together into one (essential information) [4] CHK file (check file): Remote installation by examining the environmental conditions under which the software operates A file written in a special language to qualify Only certain software is needed. The most commonly used ones are provided by the system, but special ones are optionally created by the user. The CHK file includes the following information, for example.

CHKEXE: Execution program for optional environment check VERSION: Created when it is necessary to optionally check version information of DLL (dynamic link library).

Information such as the check script 40 shown in FIG. 30 may be described in the CHK file. [5] Installation-related files: Describes the actual procedure of remote installation, and includes the following information.

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.

1. If specified, perform preprocessing. 2. Download the compressed body to the work area of the terminal. 3. Extract the main body and copy the file to an appropriate directory.

4. If specified, the file attributes are changed. 5. If specified, register menus and icons. 6. If specified, perform post-processing.

ICON: Information for registering software in what is called a menu or manager FIRST: Pre-processing performed before standard installation processing when standardizing INSTALL, for example, backup of old version in version upgrade processing Refers to processing, etc.

LAST: Post-processing performed after standard installation when INSTALL is standardized. For example,
Environment variable file CONFIG. Refers to the SYS rewriting process and the like. Next, a specific example of the file will be described with reference to FIGS. 3 to 10. 3 to 6 show examples of CFG files, and FIGS. 7, 8, 9, and 10 show examples of explanation files, main files, CHK files, and installation-related files, respectively.

In the CFG files shown in FIGS. 3, 4, 5 and 6, lines beginning with; are comment statements. FIG.
[Name] of represents the name for software search, and [vers]
[ion] represents the version, and [oldversi]
on] represents the old version. Also, [type]
Represents a sales form, and [price] represents a price. Here, [type] is SHARE, indicating that it is shareware. [Machine] represents operable hardware, here, TOWNS,
Four models of FMR, PC98, and PC-AT are listed.

In FIG. 4, [os] is an operable OS.
And only WIN31J is listed here.
[Key] represents a keyword for search, and "Chinese" is described as a keyword here. [Compr
session] represents the compression format of the main body, and here is LH.
It is written as A method. [Intype] represents a possible remote installation method. "RI
Sicon. def ”is the icon file icon.icon. Indicates the method of registering in def, "INSTALLER ico
n2. def ”is the installer (INSTALL.E
XE) represents the method to register itself as an icon,
"D" represents the method of downloading. Both of these methods are possible here.

In FIG. 5, [souko] represents a recommended directory for storing software at the time of installation, and here, two directories P1 and P2 are described.

[Source] represents information of the compressed main file (archive file), and here, S1.
And the information of the two archive files S2 are described. The file name of S1 is NEWWP. In LZH, the storage directory after decompression (after decompression) is @ P1 @, the mode at decompression is M, the file capacity is 800000 bytes, and the minimum required capacity after decompression is 2000000 bytes. Also,
The file name of S2 is NEWPLIB. In LZH, the expanded storage directory is @ P2 @, the expanded mode is F, the file size is 7000 bytes, the minimum required size after expansion is 13000 bytes, and the duplication check target file name is GSWDLL. DLL.

Here, if the mode M is specified, the expansion destination directory can be changed on the terminal side, and if the mode F is specified, it cannot be changed. Also, GS
WDLL. DLL is the archive file NEWWPL
IB. It is one of the files compressed and stored in LZH, and is written to check whether there is a duplicate file name on the terminal.

[Destination] represents a special expansion destination directory, and here D1 is @WINS.
YSTEM @ is written. Further, [copy] represents information such as a file to be moved at the time of installation, and here, as C1, the file GSWDLL. DLL,
It is written that the file is moved to the directory designated by D1 with the same file name. N in the Attr column indicates that the attribute remains unchanged after the movement.

[0113] In Fig. 6, [first] represents the information of the preprocessing, and the command to be executed before downloading the archive file at the time of installation is described. [Last] represents post-processing information, and the command to be executed after the icon registration command is executed at the time of installation is described.

The explanation file of FIG. 7 is information for explaining to the user the outline of the software called the new word processor-A2 described in the CFG file of FIGS. 3 to 6, and the main file of FIG. Indicates an archive file. Archive file NEWWP. LZH
Has three files WP. EXE, NEWWP. IC
O, README. DOC, including the archive file NEWWLIB. LZH is one file GS
WDLL. It can be seen that it contains only the DLL.

The CHK file in FIG. 9 corresponds to the check script for the environment check at the time of installation. Here, WP. A check is made to see if a file named EXE exists in the user's terminal, if any, the latest version, and a process corresponding to the result of each check.

FIG. 10 shows an ICON file which is a type of installation-related file. IC of Figure 10
The ON file is an execution file of the new word processor-A2,
Information such as a current working directory and a file for icon registration is described. This ICON file is used for system registration during remote installation.

The new word processor-A2 is automatically registered by uploading the CFG file, the explanation file, the main body file, the CHK file, and the installation-related file from the terminal to the host computer 63. The registered software is delivered to the terminal for a fee or free of charge according to the request from the user.

By the way, when the software is sold by the remote installation system, a special procedure for charging or a change in the price may be required depending on the type of the software or the past purchase history of the user. Therefore, in order to charge according to the type of software to be delivered to the home, a file that defines the procedure for charging is uploaded at the time of software registration.

FIG. 11 shows that the terminal 61-i (i = 1,
2,. . . , N) of the files created above. In FIG. 11, in the memory 71, the CFG file 72, the explanation file 73, the body file 74, C
In addition to the HK file 75 and the installation-related file 76, the definition file 77 and the rewrite file 78 are created. Then, these files are uploaded to the host computer 63.

Here, consider the case where the author of the shareware software registers it in the host computer 63. In the case of shareware, the author describes the remittance procedure of shareware in the definition file 77. Definition file 77
The software name, software code, remittance destination, remittance amount, remittance type, and method of updating the user system are described.

FIG. 12 shows an example of the definition file 77 for shareware. Definition file AAA in FIG.
S. In CFG, [name] is shareware “A
“AA scheduler” is represented, and the remittance procedure is described in [type]. Here, soft code 5
FJOKI is written as the ID of the remittance destination for 55. AAA represents the label of the designated serial number, which means “AAA scheduler” here. [Pric
e] represents the price, and [machine] and [os] are
Each represents an operable model and OS, and [key] represents a search keyword.

[Intype] describes the type of remittance, and here, if a remittance request is made, processing for canceling the function restriction on the spot is described. Also, in [last], update processing of the user file is described as post-processing of installation. Here, the command CHG
INI, the file INI. A process for rewriting a user's file according to the contents described in DEF is described.

The difference in remittance procedure between normal software and shareware is identified in the section [type]. The CHK file 75 is also used as one of the option files relating to the remittance procedure, and describes the contents that the user and the host computer 63 interactively exchange at the time of installation. FIG. 13 shows an example of such a CHK file 75. CH in Figure 13
K file AAAS. CHK contains the file AAA. I
A process for checking whether the NI exists in the user system and confirming the storage location to the user is described. AA
A. The INI is a file for setting the function of the shareware. If correct information is not written in the [UserInfo] section of the shareware, the shareware will not operate completely.

The rewriting file 78 is an option file that defines the rewriting method of the user system. FIG.
4 shows an example of the rewrite file 78. The rewrite file INI. In the DEF, the file AAA. It describes a process of rewriting the License value of the [UserInfo] section in the INI to AA123AAA. License = AA
123AAA plays the role of an encryption code for removing the function limitation of the shareware.

FIG. 15 shows an example of upload processing of the file group shown in FIG. In FIG. 15, the shareware author first writes C as a main body registration file.
FG file 72 (AAA.CFG), explanation file 7
3 (AAA.TXT), installation related files 76
(Here, the icon file ICON.DEF) and the main body file 74 (AAA.LZH) are uploaded from one's own terminal. The host computer 63 registers these pieces of upload information in the content database 81. Here, the uploaded software "AA
A scheduler "software code, name, type (TY
PE), main body file name, description file name, icon file name, etc. are registered as management information. SHARE in the type column indicates that the type of software is shareware. The content database 81 is provided, for example, in the host computer 63 or in an external disk device.

Next, the author creates a remittance procedure file,
Definition file 77 (AAA.CFG), CHK file 75 (AAA.CHK), and rewrite file 7
8 (INI.DEF) is uploaded. As a result, the soft code, name, type, CHK file name, file name for post-processing, etc. of the remittance procedure file AAAS are registered in the content database 81. As the file for post-processing, here, the file name INI. DEF is indicated. Also, SOKIN # RIS in the type column indicates that the software type is a shareware remittance procedure file,
AAAS. It corresponds to the information of [intype] of CFG.

Next, with reference to FIGS. 16 to 20, a shareware remittance procedure using the uploaded file group will be described. In the shareware procedure, a remittance flag is provided on the protocol in addition to the remote installation procedure of the previous application. Then, by setting this flag from the terminal and requesting a search for software, the shareware procedure can be selected. Further, a menu for turning on / off the remittance flag is displayed on the screen of the terminal.

16, 17, 18, and 19 show the remittance procedure of the shareware "AAA scheduler".
However, it is assumed that the shareware “AAA scheduler” is installed in the user system with limited functions before the remittance procedure. When the user wants to purchase this software, the commands / responses shown in the figure are exchanged between the host computer 63 and the terminal.

In FIG. 16, the terminal first sends the user environment to the host computer 63 (step S31), and the host computer 63 returns a response upon receiving this (step S32). Next, when the user requests a keyword list for software search (step S33), the host computer 63 returns the keyword list (step S3).
4).

At this time, as shown in FIG. 17, the option procedure menu 82 is displayed on the screen of the terminal.
The user designates "remittance" from among them, and selects a keyword from the keyword list. As a result, the remittance flag SOKIN is set (turned on), and an instruction to start the search for shareware is sent to the host computer 63 (step S35). The host computer 63 searches the content database 81 with the designated keyword, and returns the name of the software whose type starts with SOKIN and the soft 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.

The terminal only lists the remittance software, and the user designates the particular remittance software listed (step S37). Here, soft code 40
00 is specified. The host computer 63 negotiates with the terminal side under the condition of the remittance software of the software code 4000 (step S38). Here, first, the command ST4 is used to AA in the user system.
A. Instruct the terminal to look up the location of the INI. In response to this, the terminal receives the AAA. The location of INI is checked, and the location is notified to the host computer 63 that it is E: \ AAA (step S39). It is assumed that the command of ST4 is provided in the terminal in advance.

Next, referring to FIG. 18, the host computer 63
Causes the dialog box 83 to be displayed on the terminal screen, and AA
A. The user is confirmed whether the position of INI is E: \ AAA (step S40). Dialog Box 8
If the directory displayed in 3 is correct, the user returns the directory as it is (step S41),
In the host computer 63, the directory path of the file to be rewritten in the user system is E: \ AAA \ AAA.
INI is determined. If the directory displayed is incorrect, the user enters the correct directory name. For example, if G: \ GGG is entered, the terminal returns the directory path G: \ GGG \ AAA. The 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).

Next, in FIG. 19, the user requests cancellation of the function restriction (step S43). In response,
The host computer 63 uses the [inst
After deducting the price from the user's account etc., refer to AAA. INI rewriting file INI. Send DEF. Further, the post-processing command CHGINI is sent by referring to [last] in the definition file, and INI. Instruct the terminal to rewrite according to the DEF procedure.

In response to this, the terminal receives the downloaded INI. Referring to DEF, as shown in FIG.
Rewrite INI. In FIG. 20, after the rewriting, [U
serInfo] License to AA123AAA
You can see that is written. As a result, the function limitation of the shareware “AAA scheduler” is released, and the user system can be fully operated.

After that, the host computer 63 sends the INI. DE
F is deleted from the terminal, and the process ends. In the definition file of FIG. 12, the information that the restriction is canceled on the spot was written in the [intype] section, so the function restriction of the shareware was canceled at the same time when the price was withdrawn. However, like a general PC communication center,
The host computer 63 may be configured to only deduct the price and issue an e-mail to the shareware registrant.

FIG. 21 shows an example of the definition file 77 in the case of supporting only deduction and payment of electronic mail. The definition file BBBS. In the CFG, the sections from [name] to [key] are the same as in FIG. Only the remittance process is described in [intype], and the function restriction is not released on the spot. In this case, the author of the "BBB scheduler" is
It is not necessary to prepare CHK files and rewrite files such as 3 and 14. Definition file BBBS. When the CFG is uploaded to the host computer 63, the type column of the content database 81 shows SOKIN # MAIL.
Is recorded.

22, 23, and 24 show software "B".
The procedure for debiting the "BB scheduler" is shown. However, before this procedure, shareware "BBB
The "scheduler" is assumed to be installed in the user system with limited functions. When the user wants to purchase this software, the commands / responses shown in the figure are exchanged between the host computer 63 and the terminal.

In FIG. 22, the terminal first sends the user environment to the host computer 63 (step S51), and when the host computer 63 receives this, it returns a response (step S52). Next, when the user requests a keyword list for software search (step S53), the host computer 63 returns the keyword list (step S5).
4).

At this time, as shown in FIG. 23, the option procedure menu 82 is displayed on the screen of the terminal.
The user designates "remittance" from among them, and selects a keyword from the keyword list. As a result, the remittance flag SOKIN is set, and an instruction to start the search for shareware is sent to the host computer 63 (step S5).
5). The host computer 63 searches the content database 81 with the designated keyword, and the type is SOKI.
The name of the software starting with N and the software code of the remittance software are returned (step S56). The terminal only lists the remittance software, and the user specifies the remittance software of the software code 4001 from among the listed (step S57).

Next, referring to FIG. 24, the host computer 63
Displays a message 84 on the screen of the terminal and asks the user whether to charge or not (step S58). At this time, the host computer 63 refers to [intype] of the definition file of FIG. 21, changes the value of the flag SOKIN to “0x08” indicating only mail issuance, and returns it to the terminal. The user selects OK if it is acceptable to be charged, and NG if not purchasing. Here, OK is selected, and a request to issue a mail to the registrant is sent from the terminal to the host computer 63 (step S59). In response to this, the host computer 63 deducts the price from the user's account or the like, and sends an electronic mail notifying the debit to the registrant of the "BBB scheduler". As the mail destination, the remittance destination FJOKI in the [type] section of the definition file is used.

The registrant who receives the electronic mail from the host computer 63 informs the purchaser of the software of the method of canceling the function restriction by means of electronic mail or the like. This allows the purchaser to use all the features of the "BBB scheduler".

By the way, there may be a case where the user wants to change the setting of the selling price depending on whether the user has already purchased an old version of a certain software or related software. In this case, the registrant of the software 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 the software code of the already purchased software, the user ID (UID), and the machine ID (MID). Here, UID is an identifier that uniquely identifies the user, and M
The ID is an identifier that uniquely identifies the installation destination terminal. Such a method of setting a plurality of prices using the definition file 77 is not limited to the shareware remittance procedure,
ISVs (independent soft) sold as normal products
ware vender) can be applied to software pricing as well.

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 indicates that the ISV software is used. Also, in the [price] section, three prices of 0 yen, 2000 yen, and 5000 yen and conditions for selecting a selling price from them are described. The conditions for selecting the selling price are as follows. (A) Free if the accessing user and terminal have already bought the software XSOFT of the soft code 111. XSOFT may be, for example, the predecessor of the CCC scheduler, or it may be an older version of the CCC scheduler. (B) 2000 yen when the accessing user or terminal buys the software YSOFT with the software code 123 or 124. YSOFT is related software of the CCC scheduler. 5000 if not applicable to (c) (a) or (b)
Circle. The database of the host computer 63 is configured as shown in FIG. In FIG. 26, a customer database 85 stores management information about users of the remote installation system and their terminals, and a purchase database 86 stores purchase history about users who purchased software in the past. In addition, in the PRICE column of the CCC scheduler of the content database 81,
The storage location of the price file 87 that describes the price selection conditions is recorded. These databases 85, 86, 81 are
It is 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 refers to the content database 81 and price file 87 of the CCC scheduler.
, And determine the price according to the description.

FIG. 27 is a flowchart of the price determination process based on the price file 87. When the processing is started in FIG. 27, the host computer 63 first refers to the customer database 85 and the purchase database 86, and purchases the software of the soft code 111 with the combination of the UID of the accessing user and the MID of the terminal. It is checked whether it has been done (step S6).
1). If there is such history data, the price is set to 0 yen (step S62), and the process ends. If there is no such history data, then it is checked whether or not there is a purchase record of the software of the soft 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 ends. And
If there is no such history data, the price is set to 5000 yen (step S65), and the process ends.

Now, the UID of the user who wishes to purchase the CCC scheduler is FJOTA, and its MID is 000.
5 is assumed. Since the purchase database 86 of FIG. 26 records that the user purchased the software of the soft code 111 using the terminal, step S
The determination result of 61 is YES, and the CCC scheduler is delivered to the home free of charge.

If the soft codes 111, 123, 12
Users who have not purchased any of the 4 software,
If you access from a terminal that has not purchased any of them, the price will be the maximum price of 5000 yen. Even if there is a purchase history of the soft code 111, the U
If one of the ID and MID does not match the identifier used for access, the software will be charged.

The definition file of FIG. 25 is only an example of price setting, and the registrant may set other arbitrary selection conditions by combining the soft code, UID, and MID. For example, a specific UID or MID can be set to be sold at a special price. In this way, by describing the price setting conditions in the definition file 77 and uploading them, it becomes possible to set various prices of software.

If the software to be sold is not ISV software but shareware, then FIG. 19 or FIG.
The price is determined based on the price file when the price is deducted in 4.

[0149]

According to the present invention, in a service of selling software through a communication line, it is possible to automatically determine the price of various software and perform a billing process. In particular, in the case of shareware, it becomes possible to cancel the function restriction after deducting the price.

Further, the software registrant can specify the payment decision method and register the information in advance. For example, the distinction between freeware, shareware, and pay software, price setting conditions, etc. are specified.

[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 diagram (No. 1) showing a CFG file.

FIG. 4 is a diagram (No. 2) showing a CFG file.

FIG. 5 is a diagram (No. 3) showing a CFG file.

FIG. 6 is a diagram showing a CFG file (No. 4).

FIG. 7 is a diagram showing an explanation file.

FIG. 8 is a diagram showing a main body file.

FIG. 9 is a diagram showing a first CHK file.

FIG. 10 is a diagram showing an ICON file.

FIG. 11 is a diagram showing a file group created on a 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 uploading.

FIG. 16 illustrates a shareware procedure (No. 1).

FIG. 17 is a diagram showing a shareware procedure (No. 2).

FIG. 18 is a diagram (No. 3) showing the shareware procedure.

FIG. 19 is a diagram (4) showing the shareware procedure.

FIG. 20 is a diagram showing file rewriting.

FIG. 21 is a diagram showing a second definition file.

FIG. 22 is a diagram (No. 1) showing the procedure for withdrawing money.

FIG. 23 is a diagram (No. 2) showing the payment withdrawal procedure.

FIG. 24 is a diagram (No. 3) showing the payment withdrawal 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 a price determination process.

FIG. 28 is a block diagram of a remote installation system of the prior application.

FIG. 29 is a flowchart (part 1) of remote installation.

FIG. 30 is a flowchart (part 2) of remote installation.

FIG. 31 is a flowchart (3) of remote installation.

FIG. 32 is a diagram showing an example of an installation method selection window.

FIG. 33 is a diagram showing a remote installation protocol (No. 1).

FIG. 34 is a diagram showing a remote installation protocol (No. 2).

FIG. 35 is a diagram showing a protocol for keyword selection.

FIG. 36 is a diagram showing a display example of keywords.

FIG. 37 is a diagram showing a transmission protocol of environment information.

FIG. 38 is a diagram showing an environment check protocol.

FIG. 39 is a flowchart of automatic installation.

FIG. 40 is a diagram showing 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 device 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 Icon 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 Main body file 75 CHK file 76 Installation-related file 77 Definition file 78 Rewrite file 81 Content database 82 Menu 83 Dialog box 84 Message 85 Customer Database 86 purchase database 87 price file

 ─────────────────────────────────────────────────── ─── Continuation of the front page (72) Takashi Hara, 1015 Kamiodanaka, Nakahara-ku, Kawasaki City, Kanagawa Prefecture, Fujitsu Limited (72) Inventor, Rijiro Okada, 1015, Kamikodanaka, Nakahara-ku, Kawasaki, Kanagawa Prefecture, Fujitsu Limited ( 72) Inventor Toshiya Yamazaki 1015 Kamiodanaka, Nakahara-ku, Kawasaki City, Kanagawa Prefecture, Fujitsu Limited

Claims (14)

[Claims] 1. An information processing system for delivering software to a terminal device of a user via a communication network, the software information storage means for storing software information including a main file of the registered software and management information, and the registered software. Price information storage means for storing price information relating to sales form and price; and, when a delivery request for the registered software is received from a first user, the registered software based on the price information stored in the price information storage means. Determine the price of
A software price approval system, comprising: a processing unit that performs delivery processing according to the sales form. 2. The price determined by the processing means is the first
2. The software price settlement system according to claim 1, further comprising a billing means for automatically billing the user. 3. The processing means receives the software information and the price information from the terminal device of the second user and registers them in the software information storage means and the price information storage means. Software payment system. 4. If the registered software is shareware, the price information storage means stores the price information including a procedure for canceling the function restriction of the shareware, and the processing means at the time of approving the price. The software price settlement system according to claim 1, wherein necessary processing is performed based on the above. 5. The processing means receives a shareware procedure flag from the terminal of the first user, and if the flag is set, performs processing for canceling the function restriction of the shareware. The software price settlement system according to claim 4. 6. The processing means causes a menu for selecting a shareware procedure to be displayed on the screen of the terminal of the first user, and when the first user selects the shareware procedure, the first 6. A flag for shareware procedure sent from the user's terminal is set.
Described software payment system. 7. The processing means, in the canceling process, sends a file required for canceling the restriction of the shareware to the terminal of the first user, and cancels the function restriction for the terminal of the first user. The software price settlement system according to claim 5, wherein 8. The processing means issues an electronic mail to the registrant of the shareware notifying that the first user has been charged for the price in the cancellation processing. The software price approval system according to item 5. 9. A purchase history storage means for storing purchase history information including a software identifier of software purchased by the user, wherein the processing means includes a user identifier of the first user and a 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 by referring to the software identifier included in the purchase history information according to the machine identifier of. 10. A purchase history storage unit for storing purchase history information including a software identifier of software purchased by the user, wherein the processing unit stores the purchase history information in accordance with the user identifier 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 by referring to the included software identifier. 11. A purchase history storage unit for storing purchase history information including a software identifier of software purchased by the user, wherein the processing unit is configured to perform the purchase history according to a machine identifier of a 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 by referring to the software identifier included in the information. 12. An information processing system for registering software via a communication network to a software distribution center for delivering software to a user's system via a communication network, the software including a main file of registered software and management information. Storage means for storing information and price information on the sales form and price of the registered software; and uploading means for uploading the software information and price information to the software distribution center via the communication network. Characteristic terminal device. 13. A storage medium in an information processing system for delivering software to a user's terminal device via a communication network, the software information including a main file of registered software and management information, and a sales form of the registered software. And a price information regarding price from a first user and a delivery request for the registered software from a second user, the price of the registered software is determined based on the price information. A storage medium comprising: a processing unit that performs a delivery process according to a sales form. 14. A method of delivering software to a user's terminal device via a communication network, the software information including a main file of the registered software and management information, and price information regarding the sales form and price of the registered software. When receiving a delivery request for the registered software from a first user and a second user, determining the price of the registered software based on the price information and performing delivery processing according to the sales form Software payment method characterized by.