JP2003337705A - System and method for distributing software using internet - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To realize a safety and suitable membership service by using a remote installation system on the Internet. <P>SOLUTION: A remote installation service (RIS) client 115 activated by a WWW browser 114 reports a RIS server 112 with a software number corresponding to an icon clicked on a homepage. The RIS server 112 provides various kinds of services such as software distribution, on-line shopping, communication service, and transaction service, based on the information. Passwords or contents exchanged on the Internet 117 are encoded. <P>COPYRIGHT: (C)2004,JPO

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a software delivery system and method using a communication network such as the Internet.

[0002]

2. Description of the Related Art With the widespread use of personal computers in recent years, users are becoming able to receive various services via communication lines. For example, as a conventional technique for automatically delivering software via a communication line,
There is a "remote installation system and method" (Japanese Patent Application No. 7-1797 and Japanese Patent Application Laid-Open No. 8-190472).

A conventional remote installation service system (RIS system) comprises a host computer at a software distribution center, a user terminal, and a communication line connecting these. The host computer stores a software group including a plurality of deliverable software, and a first key table and a second key table holding a list of keywords used when selecting specific software from the software group.

When the user requests a list of keywords from the terminal to the host computer, the host computer sequentially transmits the first key table and the second key table to display the keywords contained in them on the screen of the display device of the terminal. .
The user selects the one corresponding to the desired software from the displayed keywords and notifies the host computer.

The host computer displays a menu containing the names of some software corresponding to the notified keyword on the screen of the display device, and the user selects the desired software from the menu and notifies the host computer. Then, the host computer extracts the content (file) of the software selected by the user from the software group,
It is stored in the delivery directory set on the hard disk of the terminal.

At this time, an icon for starting the delivered software is automatically registered and displayed on the screen of the display device in a warehouse window provided corresponding to the directory. For example, when the terminal is equipped with WINDOWS (registered trademark), the delivered software is registered in the WINDOWS program manager. After that, the user can use the delivered software by simply clicking the icon with an input device such as a mouse.

Here, an operation flow of software delivery by the conventional remote installation system will be described with reference to FIGS. 44 to 46. In FIG. 44, the terminal of the user A acquires the information on the operating environment when installing the terminal software for communication, and creates the environment file 1 in which the acquired information is set (step S1). At this time, information such as the model of the user's terminal, the storage location (directory) SOUKO used for home delivery, which takes time to acquire, or the information which may need to be inquired to the user is acquired.

In determining the storage location SOUKO,
The terminal checks whether the hard disk has a free area of a predetermined capacity or more, and if there is a free area, creates a directory for home delivery at the root. At this time, the terminal automatically generates the directory name and the like, and the user A performs only the work of confirming it. Therefore, the user A does not need to input the directory name or the like.

Here, the model of the user A is TOWNS, and the directory of SOUKO is D: \ SOUKO.
It is written in the environment file 1 that it is (directory SOUKO of drive D). User A can 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 delivery is created there. Specifically, the directory D: \
If SOUKO is full, the terminal will display "D: \ S
OUKO is full. Change the warehouse to F: \ SOUKO. Is it OK. A message such as "is displayed on the screen of the display device.

When the user A approves this, F: \ SO
UKO becomes the new SOUKO directory. If there is no free space of the specified capacity in any hard disk, a message such as "Unfortunately there is not enough disk space. Please add another disk." Is displayed.

Next, when the terminal software is started (when the host computer 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 1 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 1 created in this way is the command RIS when user A accesses (connects) the host computer.
It is transmitted to the host computer by SENDENV (step S3).

The host computer holds the received information as the user A environment file 2. User A environment file 2
Includes the model, hard disk information HD, storage location SOU
In addition to KO, the OS (operating system) used and its storage location are described. here,
It can be seen that the OS of the terminal of the user A is WINDOWS and the storage location WINDIR is D: \ WINDOWS.

Command RIS from the host computer SEN
RIS as a response to DENV SENDE
When NV * RESP OK is received, the terminal sends the command R
IS Request the first key list by KEYLIST
(Step S4). In response to this, the host computer 21
RIS the contents of the first key table 3 KEYLIST *
Send back with RESP. Here, the first key table
The key corresponding to the key numbers 1, 2, 3, ...
As words, OS / basic software, development support, games,
... is stored.

When these keywords are displayed on the screen of the display device as the first key list (step S5), the user A selects the first keyword from them and inputs it to the terminal (step S6). Then, the terminal sends the 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 (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.

The host computer requested for the second key list corresponds to the received key number and the first key table 3
The corresponding second key table 4 is obtained by using the pointer stored in the KEYLIS
Send back with T * RESP. Here, in the second key table 4, RPGs, actions, puzzles / quizzes, ... Are stored as keywords corresponding to the key numbers 51, 52, 53 ,.

The second key table 4 is the first key table 3
Generally, a plurality of items are provided corresponding to the keywords in
The number is equal to or smaller than the number of keywords in the first key table 3. In the latter case, two or more keywords in the first key table 3 having the same second
It means the key table 4.

The keyword in the second key table 4 is the second
When the key list is displayed on the screen of the display device (step S8), the user A selects the second keyword from them and inputs it to the terminal (FIG. 45, step S9). Then, the terminal 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.
IS Send LIST to the host computer (step S1)
0). 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.

The host computer requested for the software list searches the software group 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 search conditions. Also, the model and OS type are treated as default keys,
Search after considering these. Thus, for example, T
It is prevented that software dedicated to a model other than OWNS is retrieved.

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

When the list of software is displayed on the screen of the display device (step S11), the user A selects desired software from them and inputs it to the terminal (step S12). Then, the terminal, 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 (step S13). Here, the user A selects Tetris and the corresponding software number 5 is sent to the host computer.

The host computer which has received the software number selected by the user A prepares a check script 5 for checking the consistency between the operating environment of the software corresponding to the number and the environment of the terminal of the user A, Check.

Since this check is automatically performed by the interaction between the execution program of the check script 5 and the terminal software of the terminal, the user A 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 makes the inquiry.

Here, as the operating environment of Tetris selected by the user A, OS is WINDOWS and model is TOW.
The recommended directory (DIR) name is T for NS, PC98, etc.
It is described as ET. On the other hand, in the user A environment file 2, the model is TOWNS and the OS is W
It is described as INDOWS, and by comparing the two, it can be seen that the model and the OS are compatible.

Next, looking at the Tetris check script 5, VBRJP is stored in the storage location WINDIR on the user A side.
200. Command "ST4 @ WINDIR @ VBRJP" to check if there is a file called DLL
200. Since there is a DLL "(MQ1), the host computer executes RIS" Send to the terminal with CHKENV * RESP. At this time, the host computer refers to the user A environment file 2 and sets @ WINDIR @ to D: \ WINDOW.
Replace with WS and send. Also, the file VBRJP20
0. DLL is one of the files necessary for the operation of Tetris.

The terminal receiving this command stores the file VBRJ in the directory WINDOWS of drive D.
P200. Check if there is a DLL and the result is AN
It is sent back to the host computer as S. Here, since there is no corresponding file, ANS = OFF is returned.

The file VBRJP200. DLL
When the host computer has learned that there is no such request, it sends an inquiry "May I copy VBRJP200?" To the terminal according to the check script 5 (MQ2), and this inquiry is displayed on the screen of the display device. User A inputs the answer to the displayed inquiry, and the terminal sends the answer back to the host computer. Here, ANS = Yes is sent back, and the host computer accepts the remote installation according to the check script 5 (RIS = Yes).
OK), VBRJP200. The flag F2 for instructing the DLL copy is turned on (MA2).

If the file VBRJP200. DLL
Is in the specified directory on the terminal, ANS
Since = ON is sent back, RIS = OK at that point (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, after purchasing a certain package software through a communication line, knowing that it does not operate without a specific driver is prevented.

When RIS = OK, the host computer finishes the environment check, and sends the delivery destination directory SOUKODIR together with the determination result (JUDGE = OK) to the terminal. This SOUKODIR is the directory of SOUKO stored in the user A environment file D:
It is specified in a format in which TET, which is a recommended directory of Tetris, is added as a subdirectory under \ SOUKO.

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

The installation means that the software selected by the user A is registered in the terminal system, for example, WINDOWS, and can be used on the terminal. Therefore, in this case, the executable file of the software is
This includes the work of registering icons on INDOWS. On the other hand, the icon registration of the installer means that the program for executing the installation is icon-registered on the terminal.

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 suggested that the icon registration of the installer is required instead of permitting the installation. In addition, when a terminal equipped with WINDOWS requests an application for TOS (TOWNS OS), only the download is permitted.

Next, the terminal software of the terminal is installed,
The installer is given priority in the order of icon registration and download, and a higher priority is set as a default and displayed on the screen of the display device. Here, the installation having the higher priority of the installation and the download permitted by the host computer is set as a default and displayed in the installation method selection window.

The 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 you want to register the installer icon, select "Installer icon registration" in the installation method selection window and enter it.

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 you select "Download", you will be able to obtain software for a model different from the model of the terminal and try whether it works.

Next, the terminal is a subdirectory for home delivery D: \ SOUKO \ TET designated by the host computer.
Is automatically generated in the hard disk (step S
16). Again, in the terminal subdirectory D: \ S
If OUKO \ TET already exists, create a subdirectory such as D: \ SOUKO \ TET 001. If this also already exists, D: \ S
Create a subdirectory called OUKO \ TET 002.

The file body 6 of Tetris is the file TE
T1. LZH (F1) and VBRJP200. DLL (F
2) and TET1. LZH has four files T
ETRIS. EXE, TOWNS. DRV, PC98.
DRV, and MAC. It is made by compressing (freezing) the DRC. TET1. When LZH is expanded (decompressed) to the state before compression, it is divided into these four files.
T1. Decompression of LZH is performed after it is delivered from the host computer to the terminal.

The terminal which has generated the subdirectory for home delivery uses the command R for requesting the start of remote installation.
IS Send INSTALL along with the selected software number to the host computer (FIG. 46, step S1).
7). In response to this, the host computer starts remote installation of the software corresponding to the sent number. The remote installation is automatically performed by the communication between the host computer and the terminal according to the Tetris installation script 7 created by the host computer (step S18).

In the installation script 7, first, the files TET1. LZH is stored at user A side @SOU
There is a description instructing to download to KO @.
Therefore, the host computer replaces @ SOUKO @ with SOUKOD
Replace IR = D: \ SOUKO \ TET to replace the subdirectory on the hard disk D: \ SOUKO \ TET
To TET1. Download LZH.

When the completion of download (OK) is notified from the terminal, the host computer next replaces @ WINDIR @ with D: \ WINDOWS and writes VBRJP20 to the directory D: \ WINDOWS on the hard disk.
0. Download the DLL.

When the completion of download (OK) is notified from the terminal, the host computer next moves to the storage location @SOUK.
O @ (D: \ SOUKO \ TET) downloaded TET1. Instruction to decompress LZH, LHA X D: \
SOUKO \ TET \ TET1. Send LZH. In response to this, the terminal receives TET1. LZH contains the four files TETRIS. EXE, TOWNS. DRV, PC
98. DRV, and MAC. Thaw to DRC. These four files are TET1. It is held in the same subdirectory D: \ SOUKO \ TET as LZH.

When the completion of decompression (OK) is notified from the terminal, the host computer next moves to the storage location @ SOUKO @
(D: \ SOUKO \ TET) model @. Store a file called DRV @ WINDIR @ (D: \ WIND)
OWS) and change the file name to FONT. Instruction to change to DRV, MOVE D: \ SOUKO \ TET \
TOWNS. DRV D: \ WINDOWS \ FON
T. Send DRV.

At this time, the host computer refers to the user A environment file 2 and replaces the model @ with TWNS and sends it. In response to this, the terminal subdirectory D: \ S
OUKO \ TET file TOWNS. Move the DRV to the directory D: \ WINDOWS (file move), and move the FONT. Change the file name to DRV (rename).

When the completion of the file move and rename (OK) is notified from the terminal, the host computer then sends the file TETRIS. Instruction to register EXE icon,
ICON TETRIS. Send EXE. In response to this, the terminal receives the subdirectory D: \ SOUKO \ TET.
File TETRIS. Make EXE an icon and register it in the terminal.

As a result, in the warehouse window displayed on the screen of the display device, for example, TETRIS. An icon to start EXE is displayed, and when you click the icon, Tetris starts operating.

When the completion of icon registration (OK) is notified from the terminal, the host computer returns RETURN to notify the terminal of the end of remote installation, and the series of installation work is completed. The terminal 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).

When software is sold to users by using such a remote installation system, as a conventional technique for managing distributed software, "identifier management device and method in software distribution system" (Japanese Patent Application No. 7- 1798, JP-A-8-19052.
There is 9).

In this system, the host computer issues a terminal identifier (machine ID: MID) to each user terminal, and issues a user identifier (user ID: UID) different from the machine ID to the user of the terminal. A terminal password (machine password: MPSW) is provided for each machine ID, and a user password is provided for each user ID.

The host computer uses these machine ID, machine password, user ID, and user password to manage information on terminals and users who sell software.

When the software sold to the user is destroyed for some reason and becomes unusable, the host computer refers to the sales record and provides a recovery service for the software. It also provides a service to upgrade the sold software. Further, the host computer dynamically changes the machine password given to the terminal and checks it every time it is accessed to monitor whether the installed software has been copied to another terminal.

When a user transfers a terminal to another user, the software installed in the terminal can be transferred including the right to receive services such as version upgrade and recovery. This kind of transfer leads to prevention of illegal copying and smooth transfer of rights, which is beneficial to both users and vendors.

Here, the flow of processing in the conventional software distribution system will be described with reference to FIGS. 47 to 50. FIG. 47 is a flowchart of a user ID registration process. When the process is started, the user first connects the terminal to the host computer of the distribution center (step S21) and inputs personal information such as name, cash card number, and address (step S22). In response to this, the host computer issues a temporary user ID and a temporary user password to temporarily register the user (step S
23). Here, the user once disconnects from the host computer and waits until the cash card is authenticated (step S4).

When the cash card is authenticated and the official user ID and the official user password are mailed from the distribution center (step S25), the user connects the terminal to the host computer again (step S26) and receives it. The formal user ID and the formal user password are input (step S27).

As a result, the host computer confirms that the mail in which the formal user ID and the user password are described has arrived at the user himself, officially registers the user (main registration), and finishes the process. At this time, the user can input and register another password together with the user password sent by mail.

FIG. 48 is a flowchart of the terminal ID registration process. When the process is started, the user first connects the terminal to the host computer of the distribution center (step S
31) Enter the registered user ID and user password (step S32). After that, the terminal automatically sends machine information such as the model and the OS used to the host computer (step S33). The host computer adds the terminal ID and the terminal password to the sent machine information, stores it in a predetermined format, and sends the terminal ID and the terminal password to the terminal (step S34). In this way, the issued terminal ID and terminal password are held in the terminal.

FIG. 49 is a flowchart of a process for selling software to users registered in the distribution center via the network. In FIG. 49, when the process is started by a user request or the like, first, the user terminal is connected to the network (step S41). Next, the host computer checks the user ID and the user password input by the user (step S42). If they are not correct (NG), the process ends.

If the user ID and the user password are correct (OK), then the host computer automatically reads the terminal ID and the terminal password held in the terminal and checks them (step S43). If the terminal ID and the terminal password are not correct (NG), there is a possibility that an illegal copy has been made, so processing that corresponds illegally (illegal processing)
Is performed (step S44).

If the terminal ID and the terminal password are correct (OK), a list of software, which is a product, is displayed on the screen of the terminal, and the user is made to select the product to be purchased (step S45). The user selects a product from the displayed list and inputs the request when the restoration service is requested.

Next, the host computer judges whether the request from the user is a purchase of a new product or a request for restoration of a product already sold (step S46). In the case of a restoration request, the purchase information of the user is referred to, It is checked whether or not the corresponding product has been purchased in the past (step S47). If the user has requested the recovery of the product not purchased (step S47, NO), it is not the target of the recovery service, and therefore the process returns to step S45 again.

When the user has requested the restoration of the product purchased in the past (step S47, YES), the host computer delivers the product to the terminal via the network,
Reinstall (step S49). Then, the user is charged based on the usage contract or the like (step S5
0), the process ends. However, if there is a contract for free restoration service, no charge will be made.

When the user requests the purchase of a new product in step S46, the sale of the selected product is determined (step S48), and the product is delivered to the terminal via the network and installed (step S48). S49).
Then, the price of the product is charged to the user (step S5
0), the process ends.

In step S50, the user having the inputted user ID is charged, but the management of the user ID is entrusted to the user. Each user manages the user ID by designating the user password.

The product sales contract does not target the user,
If the terminal to be installed is to be sold, the price is charged to the terminal in step S50. In this case, in step S47, it is checked whether the terminal has purchased the corresponding product in the past, and the recovery service is provided only when the product is purchased.

Regarding the terminal ID, the host computer adds a terminal password, and every time the terminal is connected once, the terminal password of the terminal is automatically rewritten and managed. When an illegal copy is made, the fact is accessed because the access is made with the terminal password before rewriting. The host computer can backtrace the terminal ID and the terminal password.

FIG. 50 is a flowchart of the checking and rewriting of the terminal password in step S43, and the illegal processing of step S44. When the processing is started in FIG. 50, the host computer compares the terminal password of the connected terminal with the terminal password given when the terminal was connected last time (step S51).

If they match, a new terminal password is generated, written in that terminal, and held in the host computer (step S52). At this time, the host computer determines the next terminal password by using an unpredictable one such as a random number. Also, the rewritten old terminal password is saved for later reference (step S53), and the process is terminated.

If the two terminal passwords do not match in step S51, the host computer determines that an illegal copy has been made, and gives a new terminal ID to the connected terminal for new management (step S54). Then, the terminal password at the time of connection is sequentially compared with the stored old terminal password to obtain the date and time of access by the terminal password (step S55). As a result, the timing at which the illegal copy is performed is specified, and the process ends.

As a technique of the prior application for registering the software created by the user in the remote installation system, there is "Software registration system and method" (Japanese Patent Application No. 7-258506).

FIG. 51 shows the structure of the field within this system. In the system of FIG. 51, a group of users called a club, which is virtually created in the host computer, serves as the minimum unit and forms a place for exchanging software information. Club members are also called members.
Clubs 12, 13, and 14 belong to the same level, each with a conference room function and a remote installation system (RIS).
It has the function of.

The upper club 11 is in the upper hierarchy of these clubs 12, 13 and 14. In this example, the club has two hierarchies, but generally any number of hierarchies may be used. The software, which is the content to be delivered to the home, is always uploaded to one of the clubs and registered there. For example, when the software 15 is uploaded to the club 12, it is first registered with the club 12 and the club 12 becomes the software 15's original club. To take the software registered in the original club to another club, there are a reprint method and a transfer method.

Reproduction means making the software visible to other clubs, and transfer means transferring the function itself of the original club to another club. Members who desire the software 15 can download it from either the original club 12 or the reprint destination clubs 11 and 13.

Basically, the member who created the software 15 has the right to select the original club. However, once the author uploads the software 15 and allows it to be published, the right to reprint or transfer it to another club is transferred to the administrator of the original club. In actual operation, it is necessary to negotiate these rights between the uploading author and the administrator of each club, but as a mechanism in the computer, each right is decided in advance as follows. The obligations of the author and each manager are determined by contract as follows, for example. (1) Rights and obligations of general authors The right to upload content (software) The right to test-deliver the software you have uploaded free of charge (the RIS fee at the time of testing becomes free) The right to publish the software Obligation to support uploaded software (answer questions from software users and make corrections when errors occur) (2) Rights and obligations of original club administrator Testing software in club free of charge The right to publish (the software fee for testing is free of charge) The right to publish the software The right to give permission to reprint to the reprinting club Obligation to support the software in the club Reprinting to a higher club unless there is a special reason Obligation to give permission. (3) Rights and obligations of reprint destination club administrator Right to publish software that is allowed to be reprinted Obligation to support software in the club (4) Upper right of club administrator Right to publish software that is allowed to reprint Clubs can basically reprint the software of subordinate clubs, so that members of the highest club can view all the software.
In addition, since the reprint is performed under the condition that the administrator of the club to which the software is copied securely supports the usage of the software, the support can always be received in the club where the software can be viewed.

Now, with reference to FIGS. 52 to 54, the procedure of the work of the author and the administrator in the software registration system will be described. FIG. 52 is a flowchart of the work of the author. When the work is started, the author first creates software and prepares a file group necessary for uploading (step S61). Next, select the club to upload and upload the software using the command UPLOAD (step S6).
2) Receive the result of the automatic check at the upload destination (step S63).

Here, malfunction check, virus check, copyright check, trademark check, etc. are automatically performed. If an error occurs as a result of the check (step S64), the error portion is corrected, only the corrected portion is uploaded again (step S65), and the work from step S63 is repeated.

If the automatic check passes, then R
Test home delivery is performed by IS (step S66). In the test delivery, it is checked whether the uploaded software causes a problem at the time of remote installation (step S67). If an error occurs in the test delivery, the error part is corrected, only that part is uploaded again (step S68), and the work after step 66 is repeated. If the test delivery is successful, PUSH permits the software to be released (step S69), and the work is completed.

FIG. 53 is a flowchart of the work of the administrator of the original club. When the work is started, the administrator first delivers the software whose authorizing is permitted to be released to the test home (step S71), and checks whether there is any problem (step S72). If there is no problem in the test delivery, use the command PUBLISH to release the software to the members of the original club (step S73),
If there is a problem, contact the author (step S7).
4), the work is completed.

FIG. 54 is a flow chart of the work of the administrator of the copy destination club. When the work is started, the administrator requests the original club for permission to reprint the desired software (step S81). A response to the request is received (step S82), and if the reprint is not permitted, the work is finished as it is. Command PE
If reprinting is permitted by RMIT, command LINK
Then, the software is reprinted in one's own club (step S83). At this time, change the keywords to make it easier to search in your club.

Next, the reprinted software is delivered to the test home (step S84), and it is checked whether there is any problem (step S85). If there is no problem in the test delivery, the software is released to the members of the club by the command PUBLISH (step S86), and if there is a problem, the software is notified to the original club (step S87), and the work is completed.

By the way, there are various kinds of software distributed by personal computer communication. For example, what is called freeware is basically distributed free of charge,
Shareware, which has function restrictions, is sent once for free, and then the function restrictions are lifted when a predetermined amount of money is sent. Also, what is sold as a product is 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 required to ensure that the payment is received. As a prior application regarding such payment decision, "Software payment decision system and method" (Japanese Patent Application No. 7-
258507).

FIG. 55 shows an example of upload processing of a file group used in this system. The shareware author first creates a CFG file 21 (AAA.CFG) and an explanation file 22 (A) as main body registration files.
AA. TXT), the installation-related file 23 (here, the icon file ICON.DEF), and the main body file 24 (AAA.LZH) are uploaded from their own terminals.

The host computer registers these pieces of upload information in the content database 28. Here, the software code, name, type (TYPE), body file name, description file name, icon file name, etc. of the uploaded software "AAA scheduler" are registered as management information. SHA in the type column
RE indicates that the type of software is shareware. The content database 28 is provided in, for example, the host computer or an external disk device.

Next, the author creates a remittance procedure file,
Definition file 25 (AAA.CFG), CHK file 26 (AAA.CHK), and rewrite file 2
7 (INI.DEF) is uploaded. Accordingly, 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 28.

As a file for post-processing, here, the file name INI. DEF is written. Further, SOKIN # RIS in the type column indicates that the type of software is a shareware remittance procedure file. CFG's [intype
e] corresponds to the information described in the section.

Next, with reference to FIGS. 56, 57, 58 and 59, a shareware remittance procedure using the uploaded files will be described. In the shareware procedure, a remittance flag is provided on the protocol in addition to the above remote installation procedure. Then, the shareware procedure can be selected by setting this flag from the terminal and requesting the software search. Also, turn on / off the remittance flag on the terminal screen.
Display the FF menu.

In this example, 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 following command / response exchanges are performed between the host computer and the terminal.

The terminal first transmits the user environment to the host computer (FIG. 56, step S91), and the host computer returns a response upon receiving this (step S92). next,
When the user requests the keyword list for software search (step S93), the host computer returns the keyword list (step S94).

At this time, as shown in FIG. 57, the option procedure menu 29 is displayed on the screen of the terminal,
The user designates “remittance” from the list 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 (FIG. 57, step S95).

The host computer searches the content database 28 with the designated keyword, and the type is SOK.
The name of the software starting with IN and the software code of the remittance procedure file (remittance software) are returned (step S96). Here, "AAA scheduler", "BB
Names such as "B scheduler" and software codes 4000 and 4001 of remittance software are returned.

The terminal only lists the remittance software, and the user specifies the particular remittance software in the listing (step S97). Here, soft code 40
00 is specified. The host computer negotiates with the terminal side under the condition of the remittance software of the software code 4000 (step S98). Here, first, the command ST4 is used to initialize the initialization file AAA.A stored in the user system. Instruct the terminal to find 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 that it is E: \ AAA (step S99). It is assumed that the command ST4 is provided in advance on the terminal side.

Next, the host computer executes the dialog box 3
0 is displayed on the screen of the terminal, and AAA. Confirm with the user whether the position of INI is E: \ AAA (Fig. 5).
8, step S100). If the directory displayed in the dialog box 30 is correct, the user returns the directory as it is (step S101), and the host computer determines that the directory path of the file to be rewritten in the user system is E: \ AAA \ AAA. Confirm as INI.

If the displayed directory is not correct, the user inputs the correct directory name. For example, if you enter G: \ GGG, the terminal will display the directory path G: \ GGG \ AAA. Returns INI to the host computer. AAA. Since the storage location of the INI has been determined, the host computer notifies the terminal that shareware remittance is possible (step S102).

Next, the user requests cancellation of the function restriction (FIG. 59, step S103). In response to this, the host computer refers to the [intype] section of the definition file 25, deducts the payment from the user's account, etc., and Rewriting file INI.INI that describes the rewriting procedure of INI. Send DEF. Further, referring to the [last] section of the definition file, the post-processing command CHGINI is sent, and INI. DEF
Instruct the terminal to rewrite according to the procedure.

In response to this, the terminal receives the downloaded INI. DEF, refer to AAA. Rewrite INI.
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 changed the INI. The DEF is deleted from the terminal and the process ends.

In this example, the [ins
In the [Type] section, there was information that the restrictions would be lifted on the spot, so the restrictions on shareware functions were lifted at the same time as the withdrawal of the price. However, like a general PC communication center, the host computer may be configured to only deduct the price and issue an e-mail to the shareware registrant.

FIGS. 60, 61 and 62 show the procedure for deducting the cost of such software "BBB scheduler". However, before this procedure, the shareware "BBB scheduler" is assumed to be installed in the user system with the function restriction. When the user wants to purchase this software, the following command / response exchanges are performed between the host computer and the terminal.

The terminal first transmits the user environment to the host computer (FIG. 60, step S111), and the host computer returns a response upon receiving this (step S112). Next, when the user requests a keyword list for software search (step S113), the host computer returns the keyword list (step S114).

At this time, as shown in FIG. 61, the option procedure menu 29 is displayed on the screen of the terminal.
The user designates “remittance” from the list 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 (FIG. 61, step S115).

The host computer searches the content database 28 with the designated keyword, and the type is SOK.
The name of the software starting with IN and the software code of the remittance software are returned (step S116). The terminal lists only the remittance software, and the user specifies the remittance software of the software code 4001 from among the listed (step S117).

Next, the host computer causes the message 31 to be displayed on the screen of the terminal and asks the user whether or not to charge the fee (FIG. 62, step S118). At this time, the host computer refers to the [intype] section of the definition file, changes the value of the flag SOKIN to "0x08" indicating only the mail issuance, and returns it to the terminal.

If the user may be charged, OK
If you do not want to purchase, select NG. Here, OK is selected, and a request to issue a mail to the registrant is sent from the terminal to the host computer (step S119).

In response to this, the host computer deducts the payment from the user's account or the like, and sends an electronic mail notifying the debit to the registrant of the "BBB scheduler". The destination of the email is [ty in the definition file
The remittance destination FJOKI described in the [pe] section is used.

The registrant receiving the electronic mail from the host computer 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 will be able to use all the functions of the "BBB scheduler".

[0106]

However, the conventional remote installation system as described above has the following problems.

Since the software to be sold is confidential information, it is necessary to deliver it to the home via a secure line. Therefore, in order to apply it to the Internet where security cannot be guaranteed in advance, it is necessary to take measures to prevent hacking.

Further, a WWW browser (world wide web) which is a software tool for searching information on the Internet.
Various mechanisms are conceivable as a method of linking the browser) and the remote installation system, and it is necessary to construct a mechanism suitable for the service to be provided.

The machine ID of the terminal in the conventional remote installation system is created / managed on the assumption that only one host computer exists. For this reason, if a plurality of host computers serve as RIS servers, each host computer may give the same machine ID to different terminals. In this case, there is a problem that the host computer mistakenly identifies the terminal.

Further, it is difficult to accurately identify the communication partner because the identification information and the like may be stolen on the Internet. Therefore, it is possible to impersonate the host computer of the RIS by using the identification information obtained by the third party illegally. In such cases, the user needs to be able to see it.

An object of the present invention is to provide a system and method for realizing a safe and appropriate membership service by using a remote installation system on the Internet.

[0112]

FIG. 1 is a principle diagram of a service system of the present invention. The service system of FIG. 1 includes the first, second, third, fourth, fifth, sixth, seventh, eighth, ninth, tenth, and eleventh principles of the present invention.

According to the first principle, the service system includes a registration means 80, a key information addition means 81, and an encryption means 82, and provides a software delivery service. The registration unit 80 signs up the client via a communication channel with a secured security, and the key information addition unit 81 adds key information corresponding to the machine identifier of the client in the sign-up process. . Then, the encryption means 82 uses the above key information to encrypt at least one of the password and the software content on the Internet.

Since the key information used for encryption is exchanged via a communication channel ensuring security,
It cannot be stolen. By encrypting the password using the secret key information provided in this way, it is possible to enhance the security of the login sequence to the remote installation system on the Internet. Also, by encrypting the content using this key information, the security of the remote installation sequence can be enhanced on the Internet.

According to the second principle, the service system includes a remote installation means 83 and a browser means 88.
And provide software delivery service. The remote installation means 83 automatically delivers the software specified by the anchor file on the home page from the server to the client, and the browser means 88
When the anchor file is accessed, the remote installation means 83 is automatically started.

When the browser means 88 activates the remote installation means 83, the software designated by the user is automatically delivered. Therefore, the user can use the remote installation service on the Internet home page without being aware of the remote installation means 83.

According to the third principle, the service system includes a charging means 84 and a browser means 88, and provides an online shopping service. The charging means 84 is
The client automatically connects to the server to perform the charging process for the product or service specified by the anchor file on the home page, and the browser means 88 automatically controls the charging means 84 when the anchor file is accessed. to start.

As the charging means 84, for example, a remote installation system is used, and when the browser means 88 activates the charging means 84, the product or service designated by the user is automatically charged. Therefore,
An online shopping service using a remote installation system will be realized on the Internet.

According to the fourth principle, the service system comprises a processing means 85 and a browser means 88, and provides a communication service. The processing means 85 performs a billing process for the communication service specified by the anchor file on the home page, and automatically sends information necessary for using the communication service from the server to the client. Also,
The browser means 88 automatically activates the processing means 85 when the anchor file is accessed.

As the processing means 85, for example, a remote installation system is used, and the browser means 88 activates the processing means 85 to charge the communication service specified by the user and the information necessary for using the service. Is automatically provided. Therefore, a communication service using the remote installation system is realized on the Internet.

In the fifth principle, the service system comprises a helper means 86, a processing means 87 and a browser means 88, and provides a transaction service.
The browser means 88 accesses the Internet, and the helper means 86 is activated by the browser means 88 and performs a part of processing of the transaction service. Further, the processing means 87 is activated by the browser means 88 and cooperates with the helper means 86 to perform processing relating to the granting of the transaction usage right and billing.

As the processing means 87, for example, a remote installation system is used, the browser means 88 activates the helper means 86 and the processing means 87, and the helper means 86 is activated.
The processing means 87 cooperates with each other, so that the right to use the transaction processing and the charge are automatically given to the user. Therefore, a transaction service using the remote installation system is realized on the Internet.

According to the sixth principle, the service system comprises a processing means 89 and a transaction means 91,
Providing transaction services. The transaction means 91 performs transaction service processing, and the processing means 89 is activated by the transaction means 91 and cooperates with the transaction means 91 to perform processing relating to the granting of transaction usage rights and billing.

As the processing means 89, for example, a remote installation system is used, and the transaction means 91 activates the processing means 89 and cooperates therewith,
The right to use the transaction process and the charge are automatically given to the user. Therefore, a transaction service using the remote installation system is realized without using a browser.

In the seventh principle, the service system comprises a processing means 90 and a transaction means 91,
Providing transaction services. The transaction means 91 performs transaction service processing, and the processing means 90 is activated by the transaction means 91 and automatically connects to the server from the client to obtain the data required for the transaction service.

As the processing means 90, for example, a remote installation system is used, and the transaction means 91 activates the processing means 90. The processing unit 90 obtains data from the server and transfers it to the transaction unit 91, and the transaction unit 91 uses the data to process the transaction service. Therefore,
A transaction service using a remote installation system is realized without using a browser.

According to the eighth principle, the service system comprises a receiving means 92 and a judging means 93. Receiving means 9
2 receives from the client a machine identifier generated by combining the server identifier and the client identifier.
Then, the determining unit 93 decomposes the machine identifier into a server unit and a client unit, checks the server identifier described in the server unit, and determines whether the connection with the client is correct.

The client sends the machine identifier mixed with the server identifier, so that the judging means 93 can specify to which server the connection request is directed.
Then, the server corresponding to the server identifier is determined as the correct connection destination of the client. Therefore, in an environment in which a plurality of servers provide services, even if the same client identifier is given to two or more clients, the server can reliably identify the clients.

According to the ninth principle, the service system includes a generating means 94, a storing means 95, and a connecting means 96.
Equipped with. The generation unit 94 synthesizes the server identifier and the client identifier to generate the machine identifier of the client, and the storage unit 95 stores the machine identifier.
Then, the connecting means 96 connects to the server using the machine identifier.

The generating means 94 generates a machine identifier including the server identifier, and the connecting means 96 connects to the server by using the machine identifier, so that the server identifies which server the connection request is directed to. You can
Therefore, similarly to the eighth principle, the server can surely identify the client.

In the tenth principle, the service system comprises communication means 97 and authentication means 98. Communication means 9
When logging in to the server, 7 transmits and receives designated information encrypted by using the electronic signature function based on the authentication key of the server, and the authentication means 98 authenticates the server via the designated information.

The server provides, for example, a remote installation service, and in the login sequence, encrypts the information specified by the client with the private key and sends it back. The authenticating means 98 decrypts the designated information with the corresponding public key and judges whether the server is correct or not based on the result. If the decrypted information matches the original designated information, the server is determined to be correct.

Since only the correct server can perform the correct encryption, the client can surely identify the server on the Internet. The same effect can be obtained even if the client sends the designated information encrypted with the public key to the server, and the server decrypts it with the secret key and sends it back.

In the eleventh principle, the service system includes a storage unit 99 and a connection unit 100, and provides a remote installation service. The storage unit 99 is provided on the client side and stores the address information of the server on the Internet, and the connection unit 100 automatically connects to the server from the client using the address information.

Since the address information (domain name and port number) of the server of the remote installation system is stored not in the home page but in the storage means 99 in the user terminal, it is not known to other users. By storing this address information only in the terminal of the user who has become an RIS member, a member-only remote installation service is realized on the Internet.

As described above, according to the service system of FIG. 1, various member services using the remote installation system can be safely and appropriately provided on the Internet.

Registration means 80 and key information addition means 8 in FIG.
1, encryption means 82, remote installation means 83,
Browser means 88, billing means 84, processing means 85, helper means 86, processing means 87, processing means 89, processing means 9
0, transaction means 91, reception means 92, determination means 93, generation means 94, connection means 96, storage means 95,
The communication unit 97, the authentication unit 98, the storage unit 99, and the connection unit 100 correspond to, for example, the functions of the host computer 111 and the user terminal 113 in FIG. 2 described later.

[0138]

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 service system of the embodiment. The service system of FIG. 2 includes a host computer 111 and a user terminal 113 connected to the Internet 117. The host computer 111 and the user terminal 113 are connected to the Internet 117
Besides, secure communication path (pipe)
Are connected to each other via the FENICS line 116.

The host computer 111 is equipped with the RIS server 112 as software for providing the remote installation service, and the user terminal 113 has the RIS client 115 as software for using the remote installation service in addition to the WWW browser 114.
Equipped with.

FIG. 3 is a block diagram of an information processing apparatus (computer) corresponding to the host computer 111 and user terminal 113 of FIG. The information processing apparatus in FIG. 3 has a CPU
(Central processing unit) 121, memory 122, input device 12
3, an output device 124, an external storage device 125, a medium drive device 126, and a network connection device 127, which are connected to each other by a bus 128.

The CPU 121 executes the program by using the memory 122 and realizes the processing required for the service. The memory 122 stores programs and data necessary for services, and the memory 112 is, for example, an RO.
M (read only memory), RAM (random access memo)
ry) etc. are used.

The input device 122 corresponds to, for example, a keyboard, a pointing device, etc., and is used for inputting a request or an instruction from the user. The output device 124 corresponds to a display device, a printer, or the like, and is used to output a service screen or the like.

The external storage device 125 is, for example, a magnetic disk device, an optical disk device, a magneto-optical disk device, or the like. The above-mentioned program and data may be stored in the external storage device 125, and may be loaded into the memory 122 and used as necessary. In addition, the external storage device 1
25 is also used as a database.

The medium driving device 126 is used for the portable recording medium 12
Drive 9 to access its stored contents. As the portable recording medium 129, a memory card, a flexible disk, a CD-ROM (compact disk read only memory)
), An optical disk, a magneto-optical disk, or any other computer-readable recording medium can be used.
The above-described program and data may be stored in the portable recording medium 129, and may be loaded into the memory 122 for use as needed.

The network connection unit 127 uses the FENI
It is used to connect to the CS line 116 and the Internet 117, performs data conversion accompanying communication, and transmits / receives programs and data to / from other information processing devices (host computer 111 or user terminal 113). The information processing apparatus can also receive the above-mentioned program and data from the external information provider's database 130 or the like via the network, and load them into the memory 122 for use as necessary.

In the present embodiment, the registration procedure (sign-up) to the system is always performed by a pipe with secured security. Then, in the process of signing up, the RIS server 112 determines that the user ID / password and the machine I
An encryption key for the Internet corresponding to the machine ID is added to the RIS client 115 together with the D / password. The encryption key is used to encrypt / decrypt passwords and contents on the Internet.

In order to realize such a service, FIG.
A sequence as shown in FIG. 4 is added to the sign-up sequence of 7 and 48, and the RIS server 112 gives the terminal 113 a secret key (for example, a DES key) uniquely corresponding to the terminal (machine) 113.

In FIG. 4, the RIS client 115
But the command RES without the machine ID (MID) SE
When NDENV is sent to the RIS server 112, the RIS server 112 refers to the private key database 131 and returns a response. The private key database 131 stores a correspondence table of MIDs and private keys in advance.

Here, as a response, MID = 1
234, MPSWD = ASDF, KEY = 9876 is R
It is returned to the IS client 115. Of these, KEY
Corresponds to the private key. The RIS client 115
The received setting information is used for the initialization file 132 (R
IS. INI) and save.

Further, in this initialization file 132, as shown in FIG. 5, an address (domain name) for connecting to the RIS server 112 via the Internet 117 and TCP / IP (transmission control pro).
port number of tocol / internet protocol) is described.

These addresses and port numbers are written in the initialization file 132 of the terminal 113 when the user becomes a RIS member and the RIS client 115 is installed in the terminal 113. The address information is
RIS client 115, not on the Internet
Since it is held by the side, it is not hacked by other users than the member. Therefore, only RIS members can access the RIS server 112.

Login on the Internet 117 using this address information is performed in the sequence shown in FIG. User ID from the RIS server 112 (UI
When the input instruction of D) is received, the RIS client 11
5 first sends out MID together with UID.

The RIS server 112 uses the Challenge
By using the e generation function 133, a random number different every time
generate an engine and send it to the RIS client 115.
Although this random number is sent as identification information of the RIS server 112, it is different every time and cannot be hacked and used by others. Therefore, it is possible to prevent another server from impersonating the RIS server 112.

The RIS client 115 uses the composite function 1
Cha sent from the RIS server 112 using
The llenge and the KEY acquired at the time of sign-up are combined to generate an encryption key. As the combination function 134, for example, EOR (exclusiveor) is used. Then, the encryption key is set to DES (Data Encryption Standa
The user password is encrypted by the encryption program 135 using the secret key (DES key) of the rd) algorithm and sent to the RIS server 112.

The RIS server 112 similarly synthesizes the DES key from the Challenge and KEY sent to the RIS client 115. Then, the decryption program 136 decrypts the encrypted user password and confirms the user password. Since the user password is encrypted and exchanged, the user password is prevented from being stolen at the time of login on the Internet 117.

In the delivery of contents on the Internet 117, the conventional remote installation method shown in FIGS. 44, 45 and 46 is expanded as shown in FIG. First, the RIS client 115
When the distribution of security-required content is requested through the RIS server 112,
Makes credit for the payment.

Next, the RIS server 112 receives the compressed content file ABC. The LZH is encrypted by the encryption program 135 using the private key corresponding to the MID, and downloaded to the RIS client 115.
Then, the encrypted content file ABC. DE
Send a command to decrypt S.

The RIS client 115 uses the content file ABC. The DES is decrypted by the decryption program 136 using the stored KEY, and the file A
BC. Take out LZH. Next, according to the command from the RIS server 112, the file ABC. Unzip LZH and execute ABC. Generate EXE. After that, ABC. DES and ABC. LZH is automatically erased.

As described above, by transmitting the secret key through the communication path in which security is secured in advance, the DES
It becomes possible to adopt a robust encryption algorithm like the algorithm. Further, as the encryption algorithm, any other algorithm using a secret key can be used.

Next, a remote installation system for delivering designated software by activating a helper application of a browser will be described.
In this system, the RIS client 115 is set to WWW.
It is registered in advance in the browser 114 as a helper application. Here, the helper application means a program that is started by being kicked by the WWW browser 114 and can display a file in a format other than the function incorporated therein.

Then, an anchor file for starting the helper is placed on the home page, and when the user clicks the anchor file with the pointing device,
The RIS client 115 automatically makes the RIS server 11
Connect to 2 so that specified software can be delivered.

FIG. 8 shows such an Internet 117.
The software delivery system above is shown. The software studio 141, which is a software vendor, opens the home page 142 on the Internet 117 and advertises the software developed by the company (process P1). At the same time, the software developed by the company is registered in the RIS server 112 by the method of the prior application shown in FIGS. 51 and 52 (process P1).

HTM which constitutes this home page 142
An L (hypertext markup language) file is described as shown in FIG. As a result, software names such as “horse racing software” and “pachinko software” and selection buttons (Ris icon) for receiving their delivery are displayed. An anchor file for starting the helper is set as a reference for each of these Ris buttons.

For example, the Ris icon 143 of "horse racing software" includes an anchor file 14 as shown in FIG.
4 (KEIBA.RIS) is linked. This K
EIBA. A software name and a software number (Soft) are described in the [RIS] section of the RIS.

Also, W in the anchor file 144
MIME (multipurpose internet mail e) of WW server
xtensions) As setting, file type ".RIS"
Is a MIME type "application / x-ri"
"MIME" is a method for handling various file formats in the WWW. Thus, when the WWW browser 114 refers to this reference, the corresponding WWW server has "MIME type" as the MIME type. application / x-ris "will be returned.

It is assumed that the user has already been given a user ID / password and a machine ID / password as an RIS member by the method shown in FIGS. Further, the RIS client 115 is registered in the WWW browser 114 as a helper application.

For example, the WWW browser 114 is Ne
When tscape is used, ".RIS" is registered as File-Type and "application / x-ris" is registered as MIME-TYPE.
Also, Launc that activates the RIS client 115
As an application, "C: \ RISW410 \"
RISWIN32 \ RISANC32. Register as "EXE".

In this state, the user accesses the software workshop home page 142 (process P2), and the "horse racing software" is selected.
It is assumed that the Ris icon 143 next to is clicked with the pointing device (process P3). At this time, W
The WW browser 114 automatically makes the RIS client 1
15 is started and the file K is stored in the RIS client 115.
EIBA. The contents of the RIS are passed (process P4).

The started RIS client 115
It connects to the RIS server 112 by the method shown in FIG. 6 (process P5). Then, after login, as shown in FIG. 11, the RIS is performed in the same sequence as in FIGS. 44, 45, and 46.
The server 112 distributes the software. At this time, the file KEIBA. The software number extracted from the RIS is the RIS client 115
Is sent to the RIS server 112, and the corresponding software is automatically delivered to the terminal 113.

When the above operation is performed, the RIS server 1
In the database on 12, the purchase history as described in the purchase table of FIG. 12 and the payment table of FIG. 13 remains. Therefore, the RIS server 112 collects the price from the purchaser via the credit company based on this purchase table, and pays back to the vendor based on the payment table (process P6).

In this way, by registering the RIS client 115 as a helper application activated from the WWW browser 114, the Internet 1
A software delivery system on 17 is realized. Also, instead of incorporating the RIS client 115 as a helper, it may be registered as a plug-in (application in the browser window) of the WWW browser 114.

Next, an online shopping system will be described in which an item can be easily purchased by activating a helper application of a browser. In this system, the RIS client 115
While registering as a helper in the WW browser 114,
Put the anchor file for starting the helper on the home page.

When the user clicks on this anchor file, the RIS client 115 automatically connects to the RIS server 112, and the RIS server 112 automatically charges the designated product and reports the purchase to the vendor. To do. The vendor receives this and sends the product to the user.

FIG. 14 shows such an online shopping system. Vendor α store 151
Opens the home page 152 on the Internet 117 and advertises products such as "towel set" and "handkerchief" handled by the company (process P11). At the same time, the software for purchasing the product is registered in the RIS server 112 by the method of the prior application shown in FIGS.
2).

The HTML file of the home page 152 is described in the same format as that shown in FIG. 9, and the Ris icon required for product selection / purchase is displayed on the home page 152 (process P13). The settings of the anchor file linked to each Ris icon and the user-side MIME etc. are the same as those of the software delivery system described above. For example, an anchor file 154 (TOWEL.RIS) is linked to the Ris icon 153.

In this state, the user accesses the α store home page 152 (process P14), and sets "towel set".
It is assumed that the Ris icon 153 next to is clicked (process P15). At this time, the WWW browser 114 activates the RIS client 115 registered as the helper, and the file TOWEL.
The contents of the RIS are passed (process P16).

The started RIS client 115
Connect to the RIS server 112, log in with the encrypted password, and register the registered remote installation process (RIS (INSTALL) is started (Process P1)
7). The setting contents and procedure at the time of login are the same as those of the software delivery system described above.

In the remote installation process started, the script is described so that the operation different from the case of software home delivery is performed. In this case, specifically, the process of sending the acceptance slip to the user and the process of sending the purchase notification to the vendor are described instead of the software delivery process. If necessary, the user can specify the shipping destination of the product.

The acceptance slip is sent to the user in the same manner as when downloading software (process P1).
8). Further, the purchase notification is sent to the vendor as a notification slip in a specified format via electronic mail or a dedicated line (process P18). From the vendor's point of view, the purchase notification sending process is a product ordering process. This purchase notification sending process is also executed immediately during the remote installation process.

FIG. 15 shows the sequence of these sending processes. First, the RIS client 115 uses the file TOWEL. The software number extracted from the RIS is sent to the RIS server 112 as the number of the ordered product. At this time, the command RIS Use CHKENV.

Next, when the RIS server 112 inquires about the shipping address of the product as a response, the user inputs the desired address / address. The entered shipping address is
Command RIS It is sent to the RIS server 112 using CHKENV. Then, when “OK” is returned from the RIS server 112, the RIS client 115 sends the command RIS. Send INSTALL.

At this time, the RIS server 112 downloads the acceptance slip and sends a purchase notification to the vendor. Then, the vendor that has received the purchase notification sends the product to the user by a predetermined method (process P19). When the processing of FIG. 15 is completed, the purchase table and the payment table similar to those of FIGS. 12 and 13 are created, so that the RIS server 112 collects the price from the user based on these and pays to the vendor (processing. P20).

In this way, by registering the RIS client 115 as a helper application activated from the WWW browser 114, the Internet 1
The online shopping system on 17 is realized. It is also possible to register the RIS client 115 as a plug-in for the WWW browser 114.

According to such a system, since the user information as the RIS member is registered in advance,
When purchasing a product, the user only needs to press the button of the product he / she likes. Therefore, very simple online shopping can be performed. Further, a shipping address different from the contact address at the time of registration can be designated, and for example, the product can be delivered as a gift to a third party.

Further, the RIS center can undertake part of sales-related work in the form of outsourcing. Therefore, in the case of selling the product only to the RIS members, there is an advantage that the vendor can save the troublesome work such as the contract with the individual card companies.

Next, an online communication service system for notifying a specific password by activating a helper application of a browser will be described. In this system, the RIS client 115 is registered as a helper in the WWW browser 114, and a helper activation anchor file is placed on the home page.

When the user clicks this anchor file, the RIS client 115 automatically connects to the RIS server 112. RIS server 112
Performs billing processing for the specified communication service, reports the purchase to the vendor, and notifies the user of the password for using the service. The user can receive the service by inputting this password on the screen of the WWW browser 114.

FIG. 16 shows such an online communication service system. The fortune teller 161 which is a communication service vendor opens a home page 162 on the Internet 117 and sets this as a reception screen for its own fortune telling service (process P21). In addition, the password information which is a fortune-telling ticket showing the right to use the fortune-telling service is shown in FIG.
RIS as a notification to the user by the method shown in 1, 52.
Register in the server 112 (process P21).

The HTML file of the home page 162 is described as shown in FIG. As a result, the Ris icon 163 corresponding to the fortune-telling ticket and the password input field 164 are displayed. The Ris icon 163 has an anchor file 165 (FT) for starting the helper.
ELL. RIS) is set as a reference.

This file FTELL. RIS [RI
In the [S] section, as shown in FIG. 18, the service name and software number (Soft) of the fortune-telling service are described. This software number is used as a service identification number.

Further, W in the anchor file 165
The MIME setting of the WW server is the same as that of the software delivery system described above. As a result, when the WWW browser 114 refers to this reference, the corresponding WWW server is applicable as the MIME type.
ation / x-ris.

It is assumed that the user side has already been given a user ID / password and a machine ID / password as a RIS member, as in the software delivery system described above. Furthermore, the WWW browser 114 displays RIS
Register the client 115 as a helper application.

In this state, it is assumed that the user accesses the fortune teller homepage 162 (process P22) and clicks the Ris icon 163 next to the fortune teller ticket (process P23). At this time, the WWW browser 114 displays the RIS
The client 115 is started, and the RIS client 11
The file FTELL. Pass the contents of RIS (Process P
24).

The activated RIS client 115
Connect to the RIS server 112 and log in with the encrypted password. The login sequence on the Internet 117 and the settings for using the RIS client 115 are the same as those shown in FIGS.

After login, the RIS client 115
File FILEL. The software number described in the RIS is sent to the RIS server 112 (process P25),
The RIS server 112 charges the purchase price of the service designated by the number, and then notifies the user of the password for identifying the service purchaser (process P26).

Notification of the password is a notification from the RIS center to the user, and is performed by displaying a screen as shown in FIG. 19 on the terminal 113 in the form of a message box.

By inputting the received password into the input field 164 displayed on the home page 162, the user can receive the fortune-telling service through the corresponding WWW server (process P27). For this reason, the WWW server that provides the fortune-telling service has a function of obtaining the value in the password field and confirming the service usage right.

As a method of realizing this function, H of FIG.
CGI (common gatew) described in the TML file
ay interface) script file ura. Use cgi. File ura. In cgi, the logic of the service usage right confirmation processing as shown in FIG. 20 is described.

When the confirmation processing is started, the CGI process on the WWW server first obtains the value of the input password (step S201), and then acquires it.
The password registered in step 2 is compared to confirm whether the password is correct (step S202).

If the password is correct, it is considered that the user has been charged, the pay fortune-telling service providing screen is displayed (step S203), and the process ends.
If the password is incorrect, a message indicating the error is displayed on the home page 162 (step S
204), the process ends.

As a password operation mode in such a communication service, a method of giving a common password to all users and continuing the operation can be considered. In addition, in order to prevent password leakage between users or unauthorized use due to password guessing, and to limit the service provision period, a certain period (minutes, hours, days, etc.)
There is also a method of changing the password for each and a method of issuing a different password for each user. Also, these password protection methods can be used together.

Further, at the time of registration in the RIS server 112, it is possible to dynamically generate a password by using a specific calculation algorithm instead of using the password as fixed information.

When the above operation is performed, the RIS server 1
The service purchase history similar to that of FIGS. 12 and 13 remains in the database of FIG. Based on the service purchase history, the purchase price is settled in the same procedure as the above-described software delivery system (process P28).

As described above, by registering the RIS client 115 as a helper application activated from the WWW browser 114, the Internet 1
An online communication service system on 17 is realized. It is also possible to register the RIS client 115 as a plug-in for the WWW browser 114.

In the system of FIG. 16, the communication service usage right is given by notifying the user of the password, but instead, the URL (un
iform resource locator) may be notified. The URL is identification information that uniformly expresses resources on the network.

In this case, the RIS server 112 notifies the user of the URL of the communication service after the billing process. And this URL is operated so that only those who have been charged can know. For example, if the URL is changed frequently, the user will have to purchase a ticket in order to know the latest URL.

FIG. 21 shows such a communication service system. The operation of this system is basically as shown in FIG.
It is similar to the system of No. 6. First, the fortune teller 161
Open the homepage 166 on the Internet 117,
This is the reception screen of the company's fortune-telling service (Process P3)
1). In addition, the URL information for the fortune-telling ticket is shown in FIG.
It is registered in the RIS server 112 by the method shown in Nos. 1 and 52 (process P31).

On the home page 166, a Ris icon 167 corresponding to the fortune-telling ticket and a message "The URL to the fortune-telling room is displayed by purchasing the ticket" are displayed. The Ris icon 167 includes an anchor file 165 (FTEL in FIG. 18) for starting the helper.
L. RIS) is set as a reference.

It is assumed that the user accesses the fortune-telling website 166 (process P32) and clicks the Ris icon 167 next to the fortune-telling ticket (process P33). At this time, the WWW browser 114 activates the RIS client 115 and causes the RIS client 115 to send the file FTELL. The contents of the RIS are passed (process P34).

The activated RIS client 115
Connect to the RIS server 112, log in with the encrypted password, and enter the file FTELL. The software number described in the RIS is sent to the RIS server 112 (process P35). The RIS server 112 charges the purchase price of the service designated by the number, and then
The URL of the fortune-telling service page 168 is notified to the user (process P36). The notification of the URL is made using, for example, a message box similar to that shown in FIG.

The user can access the service page 168 and specify the URL to the fortune-telling service, which he or she has learned by the notification, on the WWW browser 114, and can receive the fortune-telling service (process P3).
7).

Further, in the system of FIG. 21, URL
Instead of notifying the user, a browser that refers to the URL can be automatically started. In this case, using the URL notification from the RIS center as a trigger,
By activating the browser by the software, the user can access the service screen corresponding to the URL without directly handling the URL.

Depending on the implementation of the WWW browser 114,
When the WWW browser 114 that has already been activated can automatically acquire the URL designation by an event from the outside, the RIS client 115 determines that the WWW browser 11
4 notifies it of the URL in a readable format. As such a method, for example, the WWW browser 114
After writing the URL in a predetermined file of the above, there is a method of sending a software signal to the operating WWW browser 114.

In the case of WIN95 (Windows95), a file WORK. UR
Create L. This file WORK. In the URL, the URL notified from the RIS server 112 is written according to the browser type such as mosaic or NETSCAPE.

Then, the RIS client 115 uses the W
IN95 API (application programming interfac
e) is used to launch the WWW browser 114.
The API is a programming interface provided by the operating system.

In this case, the API is, for example, "Shell
It is described as Execute (~, "WORK.URL", ~) ", which allows the WWW browser 114.
Is the file WORK. The URL is automatically obtained from the URL and the corresponding service screen is accessed.

When the WWW browser 114 cannot automatically acquire the URL designation by software by the above method, a predetermined URL is given as an initial URL argument and the WRIS browser 115 separately activates the WWW browser 114. . If it is inconvenient for a plurality of WWW browsers 114 to operate in parallel at the same time, the WWW browsers 114 that have been operating from before may be temporarily terminated, and then the WWW browsers 114 may be restarted.

Next, the transaction helper and RIS
The transaction processing system composed of the system is described. In this system, a transaction helper is prepared and transaction usage rights are registered in the RIS system. Then, the RIS system activated as a helper cooperates with another helper for transactions to perform distribution of usage right of transaction processing and billing processing.

FIG. 23 shows such a transaction processing system. The WWW server 171 of VOICE Kobo, which is the vendor, provides a voice fortune-telling transaction service that performs fortune-telling based on the input voice of the user. First, the WWW server 171 opens the voice fortune telling homepage 172 on the Internet 117, and registers the voice fortune telling ticket representing the right to use the transaction service in the RIS server 112 as software (process P41).

On the user terminal 113, as a helper for the WWW browser 114, the RIS client 11
5 and Voice processing program 178 are registered. V
The voice processing program 178 is dedicated software for receiving a voice input from the user and performing various filtering processes, and then creating a voice file, and is created / distributed by the VOICE workshop.

The user first accesses the VOICE Kobo homepage 172 from the WWW browser 114 (process P42), and clicks the voice fortune teller ticket icon 173 (process P43).

The icon 173 includes an anchor file 176 for starting the RIS client 115.
(URANA.RIS) is set as a reference, and the WWW browser 114 activates the RIS client 115 to generate the file URANA.RIS. The contents of the RIS are passed (process P44). File URANA. The MIME setting in RIS is the same as that in the system of FIG.

The activated RIS client 115
The voice divination ticket is directly distributed by connecting to the RIS server 112 via the Internet 117 (process P45).

Here, as the distribution process, the RIS client 115 sets the initialization file 179 (Voice.i) of the Voice processing program 178.
The information of ni) is rewritten (process P46). For example, the file Voice. ini's [Permission]
By writing "YES" in the section, the voice divination ticket is distributed and the user is given the right to use the service.

Next, the user clicks the voice input start icon 174 on the home page 172 (process P4).
7). The icon 174 includes an anchor file 177 for starting the Voice processing program 178.
(KUBO.VOC) is set as a reference, and the WWW browser 114 activates the Voice processing program 178 (processing P48). As the MIME setting in the anchor file 177, the file type “.VOC” is the MIME type “applicatio”.
n / x-voice ”.

Voice processing program 17 which has been started
8 performs processing as shown in FIG. The Voice processing program 178 first checks whether or not “YES” is described in the [Permission] section of the initialization file 179 (step S211).
If "YES" is not entered here, the message "Fortune-telling ticket not purchased" is displayed (step S21).
6), the process ends.

If "YES" is described here, a voice input operation is started (step S212), various local processes such as filtering of the input voice are performed (step S213), and a voice file (not shown) is created. Generate / output (step S214). And the file Voice
e. “YES” in the [Permission] section of ini is erased (step S215), and the process ends.

[0228] Thus, when the audio file is output,
The user next clicks the fortune-telling start icon 175 to execute the fortune-telling service (process P49). The fortune-telling start page is configured as shown in FIG. 25, for example. In FIG. 25, a voice file name input field 181, Bro
A wse icon 182, an ADD icon 183, and an execution icon 184 are displayed.

[0229] When the Browse icon 182 is clicked, the file selector 185 opens, and the audio file name selected here is automatically input to the input field 181. The ADD icon 183 is used when adding an audio file to be input. The HTML file 186 is
Shows the method of writing this fortune-telling start page.

[0230] The user inputs the voice file name,
When the execute icon 184 is clicked, the designated audio file is uploaded to the WWW server 171 which provides a fortune-telling service. To upload the audio file,
This is done using the known HTML file upload function. The WWW server 171 processes the uploaded voice file and returns the fortune telling result 180 to the WWW browser 114 (process P50).

The voice fortune-telling usage fee is charged when the RIS client 115 connects to the RIS server 112, and then paid back from the RIS server 112 to the VOICE workshop (process P51).

By the way, the above-mentioned initialization file 179.
23, the RIS client 115 is directly activated from the local transaction processing program by using
The distribution of the usage right of the transaction processing and the charging processing can be performed in the same manner as in the above.

In this case, the transaction processing program is constructed as shown in the flowchart of FIG.
The transaction processing program starts with the file V
oice. It is checked whether or not the information "BUYING" indicating that the service usage right is being purchased is written in the [Permission] section of the ini (step S221).

If "BUYING" is written here, the same judgment is repeated until it is erased, and "BUYING" is written.
If "YING" is not written, then [Per
In the "Mission" section, the information "Y
It is checked whether or not "ES" has been written (step S222).

If "YES" is not written here,
It can be seen that the service usage right (fortune teller) is neither purchased nor already purchased. Therefore, the transaction processing program inquires of the user whether or not to purchase the fortune-telling ticket (step S228). Here, if the user does not select the purchase of the fortune-telling ticket, the processing is ended as it is.

When the user selects the purchase of a fortune teller, the transaction processing program displays the file Voice.
In the [Permission] section of ini, "BU
Write "YING" (step S229), and RIS
The client 115 is activated (step S230), and the processes of step S228 and subsequent steps are repeated.

The activated RIS client 115
Connect to the RIS server 112 in the same manner as the system of FIG. 23 to purchase a fortune teller ticket. When the purchase of the fortune-telling ticket is completed, the RIS client 115 displays the file Voice
e. Erase "BUYING" in the [Permission] section of ini and write "YES" instead.

At this time, the determination result of step S221 is NO, and the determination result of step S222 is YES. Therefore, the transaction processing program starts the voice input operation (step S223), performs processing such as filtering of the input voice (step S224),
Fortune-telling is executed (step S225).

Then, the fortune-telling result is displayed (step S2
26), file Voice. ini's [Permis
"YES" in the section section is erased (step S227), and the process ends. [Permissio
By deleting "YES" in the [n] section, the transaction processing restores the initial state.

As described above, by providing the transaction processing program in cooperation with the RIS system on the user terminal 113, the RI without the intervention of the WWW browser 114.
It becomes possible to use the S system.

Further, in the transaction service system of FIG. 23, it is possible to sell the service use right a plurality of times. In this case, the usage right is registered in the RIS server 112 a plurality of times, and the Voice processing program 178 side decrements the count value of the initialization file by 1 for each transaction processing.

FIG. 27 shows such a transaction service system. In the system shown in FIG. 27, the RIS server 112 has three types of fortune tellers, one time, five times, and ten times, respectively, with software number 16
Registered in correspondence with 0, 161, 162. And on the VOICE Kobo homepage 191 of the vendor,
One-time ticket, five-time ticket, 1
The zero-pass ticket icons 192, 193, and 194 are displayed.

These icons 192, 193, 194
To the anchor file 195 (URAN
A. RIS), 196 (URANA2.RIS), 19
7 (URANA3.RIS) is set as a reference. Then, the file URANA. The software number 160 is described in the RIS, and the file URAN
A2. The software number 161 is described in the RIS,
File URANA3. Software number 1 for RIS
62 is described.

When the user selects one of the fortune tellers and clicks the corresponding icon, the RIS client 115 sends the software number of the anchor file linked to the icon to the RIS server 112,
The corresponding count number (Count) is written in the [Permission] section of the initialization file 179. For example, if a 10-time ticket is purchased, Coun
t = 10. As a result, the service usage right for a plurality of times is set in the user terminal 113.

FIG. 28 shows the Voic in this system.
14 is a flowchart of the processing of an e-processing program 178. The Voice processing program 178 first checks whether or not the value of Count in the [Permission] section of the initialization file 179 is 0 (step S
231). If Count is 0, "Fortune-telling ticket not purchased"
Is displayed (step S236), and the process ends.

If Count is greater than 0, the voice input operation is started (step S232), and various local processes such as filtering of the input voice are performed (step S2).
33), generate / output a voice file (step S2)
34). Then, the file Voice. ini's [Pe
The value of Count in the [rmission] section is 1
Is only decremented (step S235), and the process ends.

[0247] Such a Voice processing program 17
By using 8, the user can receive the service for the number of times of using the purchased service usage right. Other settings and operations in the system of FIG. 27 are similar to those of the system of FIG.

[0248] Next, a system for acquiring data and billing by the cooperation processing of the local transaction processing program and the RIS system will be described. In this system, the RIS client 115 is activated directly from the transaction processing program, and transaction processing data is obtained in the same manner as in FIG.

For example, when the transaction processing program is horse racing prediction software, the flowchart of the processing is as shown in FIG. The horse racing prediction software first asks the user whether or not to acquire new data when starting up (step S241).

Then, when the user makes a decision not to acquire new data, the prediction is executed using the existing horse racing data (step S243), and the process is terminated.
If the user makes a decision to acquire new data, the RIS client 115 is activated (step S242).

The RIS client 115 accesses the RIS server 112 based on the software number.
As shown in FIG. 30, the horse racing data is registered in advance in the RIS server 112, and the horse racing data is directly distributed in the same manner as in FIG. Then, the horse racing prediction software executes the prediction using the delivered horse racing data (step S243),
The process ends.

FIG. 31 shows the RIS client 115 and R.
The distribution process of the horse racing data by the IS server 112 is shown. This process is shown in FIGS.
It is performed using the method shown in FIG. First, the RIS client 115 determines that the horse racing data file KEIBA. Check the date of DAT,
It is sent to the RIS server 112 (step S251). File KEIBA. In the DAT, as shown in FIG. 32, for example, racehorse data A, B, and C are stored.

The RIS server 112 refers to the date / file name correspondence table as shown in FIG. 33, searches for the file name corresponding to the sent date, and uses the corresponding file as an additional data file as the RIS client. 11
5 (step S252). The contents of the file KEIBA. Add to DAT, file K
EIBA. DAT is updated (step S253), and the process ends.

The date / file name correspondence table of FIG. 33 is registered in the RIS server 112 in advance and updated as necessary. The file FILE1.txt described in the date / file name correspondence table. LZH, FILE2. LZH, F
ILE3. The LZH includes a combination of data as shown in FIG.

For example, the file FILE1. LZH includes data D, E, F, and G, and files FILE2.
LZH includes data E, F, G, and file FIL
E3. The data F and G are included in LZH. In this way, by changing the combination of data for each file, the file KEIBA. More additional data can be provided for DAT.

According to the transaction processing program as shown in FIG. 29, without the intervention of the WWW browser 114,
It becomes possible to deliver the data required for the service using the RIS system.

Also, the transaction processing program should look at the date of the data file at startup and connect to the RIS server 112 and acquire data only when a certain time has elapsed since the last data update. You can also In this case, the transaction processing program connects to the RIS server 112 and updates the data file with the latest data if the current date has passed a predetermined number of days after the date of the data file.

FIG. 35 is a flowchart of such horse racing prediction software. Horse Racing Prediction Software
At startup, the current date and data file KEIBA. D
The difference in AT dates is calculated, and it is determined whether or not it exceeds two months (step S261).

If the difference does not exceed two months, the prediction is executed using the existing horse race data (step S26).
3), the process ends. If the difference exceeds two months, the RIS client 115 is activated to acquire new horse racing data from the RIS server 112 (step S262). Then, the file KEIBA.updated by the delivered horse racing data. Prediction is performed using DAT (step S263), and the process ends.

Next, in a network environment in which a plurality of RIS servers exist, a RIS system will be described in which the server ID is mixed with the machine ID (MID) of the user terminal (client machine) to prevent the server from erroneously recognizing the user terminal. .

In this system, the server identifier and the client machine identifier are combined to generate an MID for identifying the client machine. Then, the server decomposes the MID sent from the client into a server unit and a client unit, and if the server unit differs from the identifier of the server, disconnects from the client.

The conventional method of client identification by the RIS system is based on the assumption that there is only one server. On the other hand, by using the method of this embodiment, even when a plurality of servers provide services and one client connects to each server, it is possible to prevent the server from erroneously recognizing the client.

In this system, a plurality of different servers each have their own unique identifier, and the MID of the client is always created using the server identifier of the access destination. Therefore, even in the same machine, the MID differs depending on the access destination.

FIG. 36 shows a system including servers A and B and client machines α and β. In this system, the server A holds information on the machine α (directory information, memory amount, etc.) for the client number 1, and holds information on the machine β for the client number 2. Further, the other server B holds the information of the machine α for the client number 2 and the information of the machine β for the client number 1.

In the conventional method shown in FIG. 48, the client number itself is used as the MID. If this method is applied to the system of FIG. 36 as it is, when the machine α connects to the server B with the client number 1 as the MID, the server regards it as the MID of the machine β and regards the information sent from the machine α of the machine β. An accident could occur in which the information was overwritten.

However, by mixing the client identifier with the server identifier to generate the MID, when the client connects to the server using an incorrect identifier, the server side can check this and detect an error. It will be possible. As a result, the server can avoid overwriting the machine information by mistake and notify the client of the error.

For example, the MIDs when the machine α accesses the servers A and B are "A1" and "B2", respectively, and the MIDs when the machine β accesses the servers A and B, respectively.
Are designated as "A2" and "B1", respectively.

At this time, if the machine α mistakenly accesses the server A with "B2" as the MID, the server A
First, the MID is decomposed into a server part "B" and a client part "2" to check the identifier of the server part. In this case, since the server unit "B" is different from its own identifier,
This access is judged as an error and the connection with the machine α is cut off.

Further, the machine α mistakenly sets "A1" to MI.
When the server B is accessed as D, an error is similarly detected and the connection with the machine α is disconnected. Here, an error in access is notified to the client by a method of disconnecting the connection, but an error message or the like may be used instead.

As the server identifier of this system, the domain name ris. gmsnet. or. like jp,
It is desirable to use one that is guaranteed to be unique in the world. By doing so, the accident of duplication of the server identifier can be avoided, and the client can be perfectly identified. Therefore, even if one client uses a plurality of servers properly, it is possible to avoid confusing the client machine information.

Further, in handling such a plurality of servers, it is conceivable that the client has an initialization file corresponding to each server. In this case, whether or not there is an initialization file of another server in the initialization file of the basic server is described as extended information.

For example, the file RIS. I
NI as a basic initialization file, and the file RIS2. Let INI be the initialization file for another server. In this way, if different initial setting files are prepared for each server, completely different user IDs / passwords and MIDs can be handled as indicated by arrows.

Also, the file RIS. In [INITENSION] section is provided in INI,
You can specify here whether to activate other initialization files. Here, the file RIS. INI and RIS 2. INI is active (ON),
In operation, another file RIS2. The INI is also automatically referenced.

By using the method shown in FIG. 36, the server side can correctly handle the information of the client machine. The next issue is to make sure that the client can connect to the correct server. This is because if you have multiple servers, you risk accidentally connecting to a malicious server.

Then, next, R for identifying the correct server
The IS system will be described. In this system, RS
A login session using the electronic signature function of A (Rivest-Shamir-Adleman) encryption is provided. The RSA cryptosystem is an asymmetric cryptosystem, and different key information is used for encryption and decryption.

In this login session, the server encrypts the determined information with the private key and sends it to the client, and the client decrypts it with the public key to authenticate the server. This allows the client to determine whether the login destination is the correct server.

FIG. 39 shows such a server identification system. In FIG. 39, each server holds an RSA private key and stores the corresponding public key in the home page 201.
Register in. The user determines whether or not the home page 201 displaying the list of servers can be trusted. Alternatively, the URL of the trustworthy home page 201 may be embedded in the client in advance.

When the server has the client pass arbitrary information in plaintext at the time of connection, encrypts it with the private key and returns it, the client can correctly restore the original plaintext with the public key of the server. If it can be restored correctly, it means that the server holds the private key that makes a pair with the public key, so it can be judged that the server is correct.

In FIG. 39, the machine α acquires server information such as its identifier “A” and public key “public A” from the home page 201 before connecting to the server A, and the MID
Create "A1". At this time, if necessary, information on other servers is also acquired.

In this state, the login sequence for the machine α to identify the server A is as shown in FIG. When the machine α connects to the server A, the server A inquires about information (Word) for identifying the server. Therefore,
When the machine α sends the information “apple” in plaintext, the server A encrypts it with the secret key “secret A”,
e, send back as secret A).

The machine α decrypts the dark (apple, secret A) with the public key "public A", and extracts the information "apple". Since this information matches the information sent earlier, it is determined that the connection destination is the correct server A. Then, the user inputs the UID and the machine α shifts to a normal login sequence.

On the other hand, the login sequence for the server A'impersonating the server A is as shown in FIG. 40 until the machine α connects to the server A ′ and sends the information “apple” to the server A ′.
Is the same as. The server A encrypts the received information with the secret key "secret A '" set appropriately, and
e, send back as secret A ').

However, when the machine α decrypts dark (apple, secret A ') with the public key "public A", the plaintext "bqq
mf ″ is taken out. Since this information is different from the information sent earlier, it is judged that the connection destination is not the correct server A and the connection is disconnected. In this way, the fake server A ′ can be identified.

Also, unlike the sequence of FIGS. 40 and 41, even if the client sends information encrypted with the server's public key to the server, the server decrypts it with the private key, and sends it back to the client as plain text, The same effect can be obtained. In this case, the client recognizes the server as a correct server if the plaintext sent back from the server is correct.

In the server identification system shown in FIG. 39, if the operation is continued with the public key and the secret key, which are the server authentication keys, fixed, there is a possibility that the code will be broken sometime. Therefore, it is necessary to improve the security of encryption by regularly updating these. However, since it is inconvenient to reset the server information on the client side every time the public key is changed, this process is automated and the server information is acquired every time the client logs in to the server.

Then, using the method shown in FIG. 8, the RIS client 115 is activated from the home page.
In this case, the anchor file linked to the Ris icon is expanded as shown in FIG.
The server identifier is described in the [R] section, and [OKE
The Y] section describes the public key.

RI launched from WWW browser 114
The S client 115 performs processing as shown in FIG. 43 before connecting to the RIS server. The RIS client 115 first determines the anchor file RIS of FIG.
2. Looking at the [SERVER] section of RIS,
It is checked whether or not there is an access right to the S server "0002" (step S271).

[0288] If the server identifier "0002" is described here, it is judged that there is an access right, and then [OK
EY] section, and takes in a new public key “1234” (step S272). Then, look at the [RIS] section and look for "St
Knowing that "rt = menu" is described, thereupon, it is recognized that the RIS server "0002" is accessed from the initial menu instead of requesting software (step S273), and the processing is terminated.

[0289] In step S271, the server "00" is selected.
If it is determined that the user does not have the access right to 02 "(step S274), the processing is terminated. When the reading of the file RIS2.RIS is completed in this way, the RIS client 115 Start a login session as shown in.

In the embodiment described above, the encryption algorithm is not limited to DES and RSA, and any other one can be used. In addition, the online shopping system of FIG. 14 can sell arbitrary products and services other than towel sets and handkerchiefs.
The communication service systems 6 and 21 can provide any communication service other than the fortune-telling service. The transaction service system of FIGS. 23 and 27 can provide any transaction service other than the voice fortune-telling service.

[0291]

According to the present invention, it is possible to provide various membership services such as software delivery service, online shopping, communication service, transaction service and the like by using a remote installation system on the Internet. Also, the security of the service is guaranteed by authenticating the connection destination on the Internet and encrypting the password, the content, and the like.

[Brief description of drawings]

FIG. 1 is a principle diagram of a service system of the present invention.

FIG. 2 is a system configuration diagram of an embodiment.

FIG. 3 is a configuration diagram of an information processing device.

FIG. 4 is a diagram showing a sign-up sequence.

FIG. 5 is a diagram showing a first initialization file.

FIG. 6 is a diagram showing a first login sequence.

FIG. 7 is a diagram showing delivery of encrypted content.

FIG. 8 is a diagram showing a software delivery system on the Internet.

FIG. 9 is a diagram showing an HTML file of a software studio home page.

FIG. 10 is a diagram showing a first anchor file.

FIG. 11 is a diagram showing delivery of software.

FIG. 12 is a diagram showing a purchase table.

FIG. 13 is a diagram showing a payment table.

FIG. 14 is a diagram showing an online shopping system.

FIG. 15 is a diagram showing a reception slip / purchase notification transmission process.

FIG. 16 is a diagram showing an online communication service system.

FIG. 17 is a diagram showing an HTML file of a fortune-telling homepage.

FIG. 18 is a diagram showing a second anchor file.

FIG. 19 is a diagram showing a password display screen.

FIG. 20 is a flowchart of a service usage right confirmation process.

FIG. 21 is a diagram showing a communication service system for notifying a URL.

FIG. 22 is a diagram showing a URL storage file.

FIG. 23 is a diagram showing a first transaction service system.

FIG. 24 is a flowchart of a first Voice processing program.

FIG. 25 is a diagram showing a fortune-telling start screen.

FIG. 26 is a flowchart of a transaction processing program.

FIG. 27 is a diagram showing a second transaction service system.

FIG. 28 is a flowchart of a second Voice processing program.

FIG. 29 is a flowchart of first horse racing prediction processing.

FIG. 30 is a diagram showing information on an RIS server.

FIG. 31 is a flowchart of a data distribution process.

FIG. 32 is a diagram showing a horse racing data file.

FIG. 33 is a diagram showing a date / file name correspondence table.

FIG. 34 is a diagram showing data included in each file.

FIG. 35 is a flowchart of second horse racing prediction processing.

FIG. 36 is a diagram showing a system in which a plurality of servers exist.

FIG. 37 is a diagram showing a second initialization file.

FIG. 38 is a diagram showing a third initialization file.

FIG. 39 is a diagram showing a server identification system.

FIG. 40 is a diagram showing a second login sequence.

FIG. 41 is a diagram showing a third login sequence.

FIG. 42 is a diagram showing a third anchor file.

FIG. 43 is a flowchart of processing of a client.

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

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

FIG. 46 is a flowchart (part 3) of remote installation.

FIG. 47 is a flowchart of user ID registration.

FIG. 48 is a flowchart of terminal ID registration.

FIG. 49 is a sales flowchart.

FIG. 50 is a flowchart of terminal password check.

FIG. 51 is a diagram showing a structure of a field.

FIG. 52 is a flowchart of the work of the author.

FIG. 53 is a flowchart of the work of the original club manager.

FIG. 54 is a flowchart of work performed by a reprint destination club administrator.

FIG. 55 is a diagram showing uploading.

FIG. 56 is a diagram showing a shareware procedure (No. 1).

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

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

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

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

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

FIG. 62 is a diagram (No. 3) showing the payment withdrawal procedure.

[Explanation of symbols]

1, 2 Environment file 3, 4 Key table 5 Check script 6 File body 7 Installation script 11, 12, 13, 14 Club 15 Software 21 CFG file 22 Explanation file 23 Installation-related file 24 Body file 25 Definition file 26 CHK file 27 Rewrite File 28 Content database 29 Menu 30 Dialog box 31 Message 80 Registration means 81 Key information addition means 82 Encryption means 83 Remote installation means 84 Accounting means 85, 87, 89, 90 Processing means 86 Helper means 88 Browser means 91 Transaction means 92 Reception Means 93 determination means 94 generation means 94 95, 99 storage means 96, 100 connection means 97 communication means 98 authentication means 111 host computer 112 RI S server 113 user terminal 114 WWW browser 115 RIS client 116 FENICS line 117 Internet 121 CPU 122 memory 123 input device 124 output device 125 external storage device 126 medium drive device 127 network connection device 128 bus 129 portable recording medium 130 database 131 secret key Database 132, 179 Initialization file 133 Challenge generation function 134 Synthesis function 135 Encryption program 136 Decryption program 141 Soft Kobo 142 Soft Kobo homepage 143, 153, 163, 167, 192, 193, 1
94 Ris icons 144, 154, 165, 176, 177, 195, 1
96, 197 Anchor file 151 α store 152 α store homepage 161 Fortune teller 162, 166 Fortune teller homepage 164 Password input field 168 Fortune teller page 171 VOICE workshop server 172, 191 VOICE workshop homepage 173, 174, 175, 182, 183 , 184 Icon 178 Voice processing program 180 Divination result 181 Voice file name input field 185 File selector 186 HTML file 201 Reliable home page

   ─────────────────────────────────────────────────── ─── Continued front page    (72) Inventor Naoto Nakamura             4-1, Kamiodanaka, Nakahara-ku, Kawasaki-shi, Kanagawa             No. 1 within Fujitsu Limited (72) Inventor Toshiya Yamazaki             4-1, Kamiodanaka, Nakahara-ku, Kawasaki-shi, Kanagawa             No. 1 within Fujitsu Limited (72) Inventor Rijiro Okada             4-1, Kamiodanaka, Nakahara-ku, Kawasaki-shi, Kanagawa             No. 1 within Fujitsu Limited F-term (reference) 5B076 AB14 AB17 BB06

Claims (3)

[Claims] 1. A remote installation means for automatically delivering software specified by an anchor file on a home page from a server to a client, and automatically starting the remote installation means when the anchor file is accessed. A software delivery system comprising a browser means. 2. A remote installation system is registered as a helper for a browser, an anchor file for starting the helper is placed on a home page, and when the anchor file is accessed, the designated software automatically causes a client to execute the client. A software delivery method characterized by delivering to a customer. 3. A recording medium for recording a program for a computer, a remote installation function for automatically delivering software specified by an anchor file on a homepage from a server to a client, and the anchor file accessing And a computer-readable recording medium recording a program for causing the computer to automatically start the remote installation function incorporated in a browser.