JP2004030618A - Service system using internet and its method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To realize a safe and proper membership service by using a remote install system on the Internet. <P>SOLUTION: A remote install service(RIS) client 115 started by a WWW browser 114 informs an RIS server 112 of a software number corresponding to an icon clicked on a home page. The RIS server 112 provides various services such as software delivery, on-line shopping, communication service, and transaction service based on the information. In this case, a password or contents are encrypted and transferred on the Internet 117. <P>COPYRIGHT: (C)2004,JPO

Description

[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a service system and a method using a communication network such as the Internet.
[0002]
[Prior art]
2. Description of the Related Art With the spread of personal computers in recent years, users can receive various services via communication lines. For example, as a conventional technique for automatically distributing software via a communication line, there is a "remote installation system and method" (Japanese Patent Application No. 7-1797, Japanese Unexamined Patent Application Publication No. 8-190472).
[0003]
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 software that can be distributed, and a first key table and a second key table that hold a list of keywords used when selecting specific software from the software group.
[0004]
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, and causes the keywords included in them to be displayed on the screen of the display device of the terminal. The user selects one corresponding to the desired software from the displayed keywords, and notifies the host computer.
[0005]
The host computer displays a menu including the names of some software corresponding to the notified keywords on the screen of the display device, and the user selects 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 and stores the content (file) in a delivery directory set on the hard disk of the terminal.
[0006]
At this time, an icon for activating the delivered software is automatically registered and displayed in a warehouse window provided corresponding to the directory on the screen of the display device. For example, when the terminal is equipped with WINDOWS (registered trademark), the delivered software is registered in the WINDOWS program manager. Thereafter, the user can use the delivered software only by clicking the icon using an input device such as a mouse.
[0007]
Here, an operation flow of home delivery of software 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 information on the operating environment when installing the terminal software for communication, and creates an environment file 1 in which the acquired information is set (step S1). At this time, information that requires a long time to obtain, such as a model of the user's terminal and a storage location (directory) SOUKO used for home delivery, or information that must be queried from the user in some cases, is obtained.
[0008]
In deciding the storage location SOUKO, the terminal checks whether or not the hard disk has a free space of a predetermined capacity or more, and if there is a free space, creates a home delivery directory 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 the directory name. Therefore, the user A does not need to input a directory name or the like.
[0009]
Here, it is written in the environment file 1 that the model of the user A is DOWNNS and the directory of SOUKO is D: \ SOUKO (directory SOUKO of the drive D). User A can also change D: \ SOUKO to another directory if necessary.
[0010]
If there is no free space of a predetermined capacity in the already set partition, a location having the largest free space in another partition is searched for, and a home delivery directory is created there. Specifically, assuming that directory D: ¥ SOKO is full, the terminal displays a message such as "D: ¥ SOKO is full. Change warehouse to F: ¥ SOKO. Are you sure?" Display on the screen.
[0011]
If the user A approves this, F: \ SOUKO becomes a new SOUKO directory. If there is no free space of the specified capacity on any hard disk, a message such as "Unfortunately, there is not enough disk space. Please add more disks."
[0012]
Next, at the time of starting the terminal software (at the time of accessing the host computer), 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. When the user A accesses (connects) the host computer, the contents of the environment file 1 thus created are stored in the command RIS.　It is transmitted to the host computer by SENDENV (step S3).
[0013]
The host computer holds the received information as the user A environment file 2. The user A environment file 2 describes the OS (operating system) used and its storage location in addition to the model, the hard disk information HD, and the storage location SOUKO. 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.
[0014]
Command RIS from host computer　RIS as a response to SENDENV　Upon receiving SENDENV * RESP @ OK, the terminal requests the first key list by a command RISKEYLIST (step S4). In response, the host computer 21 stores the contents of the first key table 3 in the RIS　Returned with KEYLIST * RESP. Here, the first key table 3 stores OS / basic software, development support, games,... As keywords corresponding to the key numbers 1, 2, 3,.
[0015]
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 keywords from them and inputs them 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.　The 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.
[0016]
The host computer that has been requested for the second key list obtains the corresponding second key table 4 using the pointer stored in the first key table 3 corresponding to the received key number, and RISs the contents.　Returned with KEYLIST * RESP. Here, RPG, action, puzzle / quiz,... Are stored in the second key table 4 as keywords corresponding to the key numbers 51, 52, 53,.
[0017]
Generally, a plurality of second key tables 4 are provided corresponding to the keywords in the first key table 3, and the number thereof is equal to or less 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 point to the same one second key table 4.
[0018]
When the keywords in the second key table 4 are displayed on the screen of the display device as the second key list (step S8), the user A selects the second keywords from them and inputs them to the terminal (FIG. 45, step S9). ). Then, the terminal sends a command RIS requesting a list of software corresponding to both the first and second keywords together with the key numbers of the first and second keywords selected by the user A.　The LIST is sent to the host computer (step S10). Here, the user A selects an action as the second keyword, and the corresponding key number 52 is sent to the host computer.
[0019]
The host computer requested for the software list searches the software group for software having the two key numbers of the first and second keywords. At this time, a flat search is performed without distinguishing between the first keyword and the second keyword as search conditions. Further, the model and the type of the OS are handled as default keys, and a search is performed after taking these into account. This prevents, for example, a search for software dedicated to a model other than DOWNS.
[0020]
Then, a list of the names and numbers of the software　Sent to terminal with LIST * RESP. Here, software such as tetris and pachinko having key numbers 3 and 52 is applicable, and their names are sent to the terminal together with their software numbers 5, 30 and the like.
[0021]
When the software list 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 number of the software selected by the user A, the command RIS requesting a check 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, user A selects Tetris, and the corresponding software number 5 is sent to the host computer.
[0022]
The host computer receiving 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, and performs an environment check. .
[0023]
Since this check is automatically performed by the exchange between the execution program of the check script 5 and the terminal software of the terminal, the user A does not always need 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.
[0024]
Here, as the operating environment of Tetris selected by the user A, it is described that the OS is WINDOWS, the model is TOWNS, the PC 98, etc., and the recommended directory (DIR) name is TET. On the other hand, in the user A environment file 2, the model is described as TOWNS, and the OS is described as WINDOWS. By comparing the two, it is found that the model and the OS are compatible.
[0025]
Next, when the Tetris check script 5 is viewed, the VBRJP200. Since there is a command "ST4 \ WINDIR \ VBRJP200.DLL" for checking whether there is a file called DLL (MQ1), the host computer executes RIS　It is sent to the terminal together with CHKENV * RESP. At this time, the host computer refers to the user A environment file 2 and replaces {WINDIR} with D: \ WINDOWS and sends it. In addition, file VBRJP200. DLL is one of the files required for the operation of Tetris.
[0026]
The terminal receiving this command stores the file VBRJP200.V in the directory WINDOWS of the drive D. It checks whether there is a DLL and sends the result back to the host computer as ANS. Here, ANS = OFF is returned because there is no corresponding file.
[0027]
File VBRJP200. The host computer, having learned that there is no DLL, sends an inquiry to the terminal according to the check script 5 (MQ2), "Can I copy VBRJP200?", And this inquiry is displayed on the screen of the display device. The user A inputs an answer to the displayed inquiry, and the terminal sends the answer back to the host computer. Here, ANS = Yes is returned, and the host computer accepts the remote installation according to the check script 5 (RIS = OK), and returns the VBRJP200. A flag F2 for instructing DLL copy is turned on (MA2).
[0028]
If the file VBRJP200. If the DLL is in the directory specified by the terminal, ANS = ON is sent back, so RIS = OK at that time (MA1).
[0029]
As described above, by automatically performing the environment check, it is possible to prevent software that does not conform to the environment of the user A from being delivered. For example, an accident such as knowing that a certain package driver does not operate without a specific driver after purchasing certain package software via a communication line is prevented beforehand.
[0030]
When RIS = OK, the host computer ends the environment check, and sends the destination directory SOUKODIR to the terminal together with the determination result (JUDGE = OK). This SOUKODIR is specified in a format in which a recommended directory of Tetris, TET, is added as a subdirectory under D: \ SOUKO, which is a directory of SOUKO stored in the user A environment file.
[0031]
At this time, whether or not the installation is possible (RIS), whether or not the icon of the installation program (installer) is registered (ICON), and whether or not the download is possible (DLOAD) are sent to the terminal. Based on these flags RIS, ICON, and DLOAD, the host computer notifies the terminal which of the installation, the icon registration of the installer, and the download is possible.
[0032]
The installation means that the software selected by the user A is registered in a terminal system, for example, WINDOWS, and made available on the terminal. Therefore, in this case, the operation includes registering the executable file of the software as an icon on WINDOWS. On the other hand, the icon registration of the installer means that the program for performing the installation is registered as an icon on the terminal.
[0033]
Here, a condition is presented that installation and downloading are permitted (RIS = OK, DLOAD = OK), and icon registration of the installer is not performed (ICON = NG). In the case of software having a complicated installation program, it is presented that installation of the icon of the installer is required instead of permitting the installation. When a terminal equipped with WINDOWS requests a TOS (TOWNS OS) application, only downloading is permitted.
[0034]
Next, the terminal software of the terminal assigns priorities in the order of installation, icon registration of the installer, and download, and sets a higher priority as a default, and displays the default on the screen of the display device. Here, an installation having a higher priority among installations and downloads permitted by the host computer is set as a default and displayed in an installation method selection window.
[0035]
The user A confirms the displayed installation method, and inputs the confirmation (step S15). Further, the user A can change the setting displayed here. For example, when registering an icon of an installer, the user selects and inputs “register icon of installer” in an installation method selection window.
[0036]
Basically, if user A wants to perform a ready installation without any hassle, he selects "system registration", and if he wants to make detailed installation settings himself, he selects "register installer icon" and stores it. If you want to change the location later (install it on another device), select Download. If you select "Download", you will be able to obtain software for a different model of the terminal and see if it works.
[0037]
Next, the terminal automatically generates the home directory D: ¥ SOKO ¥ TET specified by the host computer in the hard disk (step S16). Here, if the subdirectory D: \ SOKO \ TET already exists in the terminal, a subdirectory, for example, D: \ SOUKO \ TET \ 001 is created. If this subdirectory already exists, D: \ SOUKO Create a subdirectory of \ TET ¥ 002.
[0038]
The Tetris file body 6 contains the files TET1. LZH (F1) and VBRJP200. DLL (F2), and TET1. LZH has four files, TETRIS. EXE, TOWNS. DRV, PC98. DRV, and MAC. It is made by compressing (freezing) the DRC. TET1. When the LZH is expanded (decompressed) to a state before compression, these files are divided into these four files. The decompression of the LZH is performed after being delivered from the host computer to the terminal.
[0039]
The terminal that has created the sub-directory for home delivery uses a command RIS to request the start of remote installation.　INSTALL is sent to the host computer together with the number of the selected software (FIG. 46, step S17). In response, the host computer starts remote installation of the software corresponding to the transmitted number. The remote installation is automatically performed by an exchange between the host computer and the terminal according to the Tetris installation script 7 created by the host computer (step S18).
[0040]
The install script 7 first includes the files TET1. There is a description instructing that the LZH be downloaded to the storage location {SOUKO} on the user A side. Therefore, the host computer replaces {SOKOKO} with SOUKODIR = D: \ SOKO \ TET, and puts TET1. Download LZH.
[0041]
When the terminal notifies the completion of the download (OK) from the terminal, the host computer replaces {WINDIR} with D: \ WINDOWS and stores the directory D: \ WINDOWS on the hard disk in the VBRJP200. Download DLL.
[0042]
When the completion of download (OK) is notified from the terminal, the host computer next proceeds to the storage location {SOUKO} (D: \ SOUKO \ TET) and downloads TET1. Instruction to decompress LZH, LHA \ X \ D: \ SOKO \ TET \ TET1. Send LZH. In response, the terminal sets TET1. LZH in the four files TETRIS. EXE, TOWNS. DRV, PC98. DRV, and MAC. Decompress to DRC. These four files are TET1. It is held in the same subdirectory D: \ SOKO \ TET as LZH.
[0043]
When the terminal notifies the completion of decompression (OK), the host computer next proceeds to the storage location {SOUKO} (D: model of SOUKO @ TET). The file named DRV is moved to the storage location {WINDIR} (D: \ WINDOWS) and the file name is changed to FONT. Instruction to change to DRV, MOVE \ D: \ SOUKO \ TET \ TOWNS. DRV @ D: \ WINDOWS \ FONT. Send DRV.
[0044]
At this time, the host computer refers to the user A environment file 2, and replaces the model # with DOWNNS and sends it. In response to this, the terminal sends the file TOWNS. DRV is moved to the directory D: \ WINDOWS (file move), and the font. Change the file name to DRV (Rename).
[0045]
When the file transfer and the completion of the rename are notified (OK) from the terminal, the host computer next proceeds to the file TETRIS. EXE icon registration instruction, ICON @ TETRIS. Send EXE. In response to this, the terminal sends the file TETRIS. In the subdirectory D: \ SOKO \ TET. EXE is iconified and registered in the terminal.
[0046]
As a result, in the warehouse window displayed on the screen of the display device, for example, TETRIS. An icon for starting EXE is displayed, and when the icon is clicked, Tetris starts operating.
[0047]
When the completion of the icon registration (OK) is notified from the terminal, the host computer sends RETURN back to notify the terminal of the end of the remote installation, and ends a series of installation work. The terminal notified of the end of the remote installation selects the next software and remotely installs the next software according to the instruction of the user A, or ends the process (step S19).
[0048]
When selling software to a user using such a remote installation system, as a conventional technique for managing software to be distributed, “Identifier management apparatus and method in software distribution system” (Japanese Patent Application No. 7-1798, Kaihei 8-190529).
[0049]
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.
[0050]
The host computer uses the machine ID, machine password, user ID, and user password to manage information on the terminal to which the software is sold and the user.
[0051]
If 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 restoration service for the software. It also provides services for upgrading the software sold. Further, the host computer dynamically changes the machine password given to the terminal and checks it each time access is made, thereby monitoring whether the installed software has been copied to another terminal.
[0052]
When a terminal is transferred from one user to another user, the software installed in the terminal can be transferred including the right to receive services such as version upgrade and recovery. Such a transfer leads to the prevention of unauthorized copying and smooth transfer of rights, which is beneficial to both users and vendors.
[0053]
Here, the flow of processing in a 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 a name, a cash card number, an address (step S22). In response, the host computer issues a temporary user ID and a temporary user password, and registers the user temporarily (step S23). Here, the user temporarily disconnects from the host computer and waits for the authentication of the cash card (step S4).
[0054]
When the cash card is authenticated and the formal user ID and the formal user password are mailed from the distribution center (step S25), the user connects the terminal to the host computer again (step S26), and the received formal user An ID and a formal user password are input (step S27).
[0055]
As a result, the host computer confirms that the mail describing the formal user ID and the user password has arrived at the user himself, and officially registers the user (main registration), and ends the processing. At this time, the user can also input and register another password together with the mailed user password.
[0056]
FIG. 48 is a flowchart of a terminal ID registration process. When the process is started, the user first connects the terminal to the host computer of the distribution center (step S31), and inputs a registered user ID and user password (step S32). Thereafter, the terminal automatically sends machine information such as its model and OS used to the host computer (step S33). The host computer adds the terminal ID and the terminal password to the transmitted machine information, stores the information in a predetermined format, and sends the terminal ID and the terminal password to the terminal (step S34). Thus, the issued terminal ID and terminal password are also held in the terminal.
[0057]
FIG. 49 is a flowchart of a process for selling software via a network to a user registered at a distribution center. In FIG. 49, when the processing is started by a user request or the like, the user's terminal is first 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.
[0058]
If the user ID and the user password are correct (OK), 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 a process corresponding to the illegality (illegal process) is performed (step S44).
[0059]
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 selects a product to be purchased (step S45). The user selects a product from the displayed list, and inputs a request for a restoration service.
[0060]
Next, the host computer determines 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). If the request is a restoration request, the host computer refers to the purchase information of the user to determine the corresponding product. It is checked whether has been purchased in the past (step S47). If the user has requested restoration of a product that has not been purchased (step S47, NO), the process returns to step S45 again because the user is not a target of the restoration service.
[0061]
If the user has requested restoration of a product purchased in the past (step S47, YES), the host computer delivers the product to the terminal via the network and reinstalls the product (step S49). Then, the user is charged based on the usage contract and the like (step S50), and the process ends. However, if there is a contract for a free restoration service, no charge will be made.
[0062]
If the user has requested the purchase of a new product in step S46, sale of the selected product is determined (step S48), and the product is delivered to the terminal via a network and installed (step S49). Then, the user is charged for the price of the product (step S50), and the process ends.
[0063]
In step S50, the user having the input user ID is charged, but the management of the user ID is left to the user. Each user manages the user ID by designating the user password.
[0064]
If the sales contract of the product is not intended for the user but is to be sold to the terminal to be installed, the terminal is charged in step S50. In this case, in step S47, it is determined whether the terminal has purchased the corresponding product in the past, and the recovery service is performed only when the terminal has purchased the product.
[0065]
For 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 unauthorized copying is performed, access is performed together with the terminal password before rewriting, so that the fact can be recognized. For the terminal ID and the terminal password, the host computer can perform back trace.
[0066]
FIG. 50 is a flowchart of checking and rewriting of the terminal password in step S43, and an unauthorized process in step S44. When the process 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 previously connected (step S51).
[0067]
If they match, a new terminal password is generated, written in the terminal, and stored in the host computer (step S52). At this time, the host computer determines the next terminal password using an unpredictable one such as a random number, for example. The rewritten old terminal password is stored for later reference (step S53), and the process ends.
[0068]
If the two terminal passwords do not match in step S51, the host computer determines that unauthorized copying has been performed, and assigns a new terminal ID to the connected terminal to newly manage it (step S54). Then, the terminal password at the time of connection is sequentially compared with the stored old terminal password, and the date and time of access by the terminal password is obtained (step S55). As a result, the timing at which the illegal copy is performed is specified, and the process ends.
[0069]
Further, as a prior application technology for registering software created by a user in a remote installation system, there is “Software Registration System and Method” (Japanese Patent Application No. Hei 7-258506).
[0070]
FIG. 51 shows a configuration of a field in this system. In the system shown in FIG. 51, a group of users called a club virtually created in the host computer is the minimum unit, and forms a place for exchanging software information. Club members are also called members. The clubs 12, 13, and 14 belong to the same hierarchy, and each has a conference room function and a remote installation system (RIS) function.
[0071]
There is an upper club 11 in an upper hierarchy of these clubs 12, 13, and 14. In this example, the club has two hierarchies, but in general, any hierarchy may be used. The software to be delivered to the home is always uploaded to one of the clubs and registered there. For example, when software 15 is uploaded to club 12, it is initially registered with club 12, and club 12 becomes the original club of software 15. There are two ways to bring software registered in the original club to another club: reprinting and transferring.
[0072]
Reprinting means making the software visible to other clubs, and transferring means transferring the functionality of the original club itself to another club. A member who wants the software 15 can download it from either the original club 12 or the reprint destination clubs 11 and 13.
[0073]
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 transfer or transfer it to another club transfers to the administrator of the original club. In actual operation, it is necessary to negotiate these rights between the uploader and the manager of each club, but as a mechanism in the computer, each right is determined in advance as follows. The duties of the creator and each manager are determined by the contract as follows, for example.
(1) General author rights and obligations
Right to upload content (software)
The right to deliver a test home delivery of software that you have uploaded free of charge (RIS fee for testing will be free)
Right to authorize software release
Obligation to support your uploaded software (answer questions from users of the software and correct any errors that occur)
(2) Rights and obligations of the original club administrator
The right to test software in the club for free (the software usage fee for testing is free)
Right to publish software
The right to give permission to the destination club
Obligation to support software in the club
The upper club is obliged to give permission for reprinting unless there is a special reason.
(3) The rights and duties of the club administrator of the reprint destination
Right to publish licensed software
Obligation to support software in the club
(4) Rights of upper club managers
Right to publish licensed software
A higher-level club can basically transfer software of a lower-level club, so that members of the highest-level club can view all software. In addition, since the reprint is performed under the condition that the manager of the reprint destination club surely supports the usage method of the software and the like, the support can always be received in the club where the software can be viewed.
[0074]
Here, with reference to FIG. 52 to FIG. 54, the procedure of the work of the author or the manager 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 group of files necessary for uploading (step S61). Next, a club to be uploaded is selected, software is uploaded by the command UPLOAD (step S62), and a result of the automatic check at the upload destination is received (step S63).
[0075]
Here, a malfunction check, a virus check, a copyright or trademark right check, and the like are automatically performed. As a result of the check (step S64), if an error occurs, the error part is corrected, only the corrected part is uploaded again (step S65), and the operations after step S63 are repeated.
[0076]
Then, when the automatic check passes, a test home delivery is performed by RIS (step S66). In the test home delivery, it is checked whether or not the uploaded software causes a problem at the time of remote installation (step S67). If an error occurs in the test home delivery, the error part is corrected, only that part is uploaded again (step S68), and the operations after step 66 are repeated. If the test home delivery is successful, the release of the software is permitted by PUSH (step S69), and the operation ends.
[0077]
FIG. 53 is a flowchart of the operation of the administrator of the original club. When the operation is started, the administrator first distributes software permitted to be disclosed by the author to a test home (step S71), and checks whether there is any problem (step S72). If there is no problem with the test home delivery, the software is released to the members of the original club by the command PUBLISH (step S73), and if there is a problem, the fact is notified to the creator (step S74), and the operation is terminated.
[0078]
FIG. 54 is a flowchart of the operation of the manager of the destination club. When the work is started, if there is desired software, the administrator requests the original club to reprint the software (step S81). A response to the request is received (step S82), and if the reproduction is not permitted, the operation ends. If the transfer is permitted by the command PERMIT, the software is transferred to its own club by the command LINK (step S83). At this time, change the keyword so that it can be easily searched in your club.
[0079]
Next, the reprinted software is delivered to a test home (step S84), and it is checked whether there is any problem (step S85). If there is no problem in the test home delivery, the software is released to the members of the club by the command PUBLISH (step S86), and if there is a problem, it is notified to the original club (step S87), and the operation is completed.
[0080]
By the way, there are various types of software distributed by personal computer communication. For example, what is called freeware is basically distributed free of charge, and what is called shareware is sent once free of charge with function restrictions, and then the function restrictions will be released once the predetermined price is remitted Has become. Items sold as products are basically sent in exchange for the price.
[0081]
When a distribution center provides a service of selling software to a user by using a remote installation function, a mechanism for ensuring receipt of a price is required in correspondence with such various sales forms. A prior application for such a payment decision is “Software Payment Decision System and Method” (Japanese Patent Application No. Hei 7-258507).
[0082]
FIG. 55 shows an example of a file group upload process used in this system. The author of the shareware firstly registers the CFG file 21 (AAA.CFG), the description file 22 (AAA.TXT), the installation-related file 23 (here, the icon file ICON.DEF), and the main body file 24 (AAA) as the main body registration file. .LZH) from your terminal.
[0083]
The host computer registers the upload information in the content database 28. Here, the software code, name, type (TYPE), main body file name, description file name, icon file name, and the like of the uploaded software “AAA scheduler” are registered as management information. SHARE in the type column indicates that the type of software is shareware. The content database 28 is provided, for example, in the host computer or in an external disk device.
[0084]
Next, the author uploads a definition file 25 (AAA.CFG), a CHK file 26 (AAS.CHK), and a rewrite file 27 (INI.DEF) as remittance procedure files. Thereby, the soft code, name, type, CHK file name, post-processing file name, etc. of the remittance procedure file AAAS are registered in the content database 28.
[0085]
Here, as the post-processing file, the file name INI. DEF is indicated. SOKIN # RIS in the type column indicates that the type of software is a remittance procedure file of shareware, and AAAS. This corresponds to the information described in the [intype] section of the CFG.
[0086]
Next, with reference to FIGS. 56, 57, 58, and 59, a description will be given of a shareware remittance procedure using the uploaded file group. In the shareware procedure, a remittance flag is provided on the protocol in addition to the remote installation procedure described above. Then, by setting this flag from the terminal and requesting a search for software, the shareware procedure can be selected. Also, a menu for turning on / off the remittance flag is displayed on the screen of the terminal.
[0087]
In this example, it is assumed that the shareware “AAA scheduler” has been installed in the user system with limited functions before the remittance procedure. When the user tries to purchase this software, the following command / response is exchanged between the host computer and the terminal.
[0088]
The terminal first transmits the user environment to the host computer (FIG. 56, step S91), and upon receiving this, the host computer returns a response (step S92). Next, when the user requests a keyword list for software search (step S93), the host computer returns the keyword list (step S94).
[0089]
At this time, as shown in FIG. 57, a menu 29 of an optional procedure is displayed on the screen of the terminal, and the user designates "remittance" from the menu and selects a keyword from the keyword list. Thereby, the remittance flag SOKIN is set (turned on), and an instruction to start the search for shareware is sent to the host computer (FIG. 57, step S95).
[0090]
The host computer searches the content database 28 using the specified keyword, and returns the name of the software whose type starts with SOKIN and the software code of the remittance procedure file (remittance software) (step S96). Here, names such as “AAA scheduler” and “BBB scheduler” and soft codes 4000 and 4001 of remittance software are returned.
[0091]
The terminal lists only the remittance software, and the user designates a specific remittance software in the listing (step S97). Here, the soft code 4000 is specified. The host computer negotiates with the terminal according to the conditions of the remittance software of the soft code 4000 (step S98). Here, first, using the command ST4, the initialization file AAA. Instruct the terminal to look up the location of the INI.
[0092]
In response, the terminal receives the AAA. The location of the INI is checked, and the location is notified to the host computer that E: @AAA (step S99). It is assumed that the command of ST4 is provided in the terminal in advance.
[0093]
Next, the host computer causes the dialog box 30 to be displayed on the screen of the terminal, and the AAA. The user checks whether the position of the INI is E: ￥ AAA (FIG. 58, 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. INI is determined.
[0094]
If the displayed directory is not correct, the user enters the correct directory name. For example, if G: \ GGG is entered, the terminal returns the directory path G: \ GGG \ AAA. INI is returned to the host computer. AAA. Since the storage location of the INI is determined, the host computer notifies the terminal that shareware remittance is possible (step S102).
[0095]
Next, the user requests release 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, debits the price from the user's account, etc., and then changes the AAA. Rewriting file INI.INI in which the rewriting procedure of INI is described. Send DEF. Further, a post-processing command CHGINI is sent with reference to the [last] section of the definition file, and the INI. The terminal is instructed to rewrite according to the DEF procedure.
[0096]
In response to this, the terminal transmits the downloaded INI. See DEF, AAA. Rewrite INI. As a result, the function restriction of the shareware “AAA scheduler” is released, and the system fully operates on the user system. Thereafter, the host computer sends the INI. The DEF is deleted from the terminal, and the process ends.
[0097]
In this example, the information that the restriction is to be released on the spot is described in the [intype] section of the definition file 25, so the function restriction of the shareware is released at the same time as the payment is withdrawn. However, similarly to a general personal computer communication center, a configuration in which the host computer only debits money and issues an e-mail to the shareware registrant can be adopted.
[0098]
FIGS. 60, 61 and 62 show a procedure for withdrawing the price of such software “BBB scheduler”. However, it is assumed that the shareware “BBB scheduler” has been installed in the user system with limited functions before this procedure. When the user tries to purchase this software, the following command / response is exchanged between the host computer and the terminal.
[0099]
The terminal first transmits the user environment to the host computer (FIG. 60, step S111), and upon receiving this, the host computer returns a response (step S112). Next, when the user requests a keyword list for software search (step S113), the host computer returns the keyword list (step S114).
[0100]
At this time, as shown in FIG. 61, a menu 29 of the optional procedure is displayed on the screen of the terminal, and the user designates "remittance" from the menu 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).
[0101]
The host computer searches the content database 28 using the specified keyword, and returns the name of the software whose type starts with SOKIN and the soft code of the remittance software (step S116). The terminal lists only the remittance software, and the user designates the remittance software of the soft code 4001 from the listing (step S117).
[0102]
Next, the host computer displays the message 31 on the screen of the terminal, and confirms with the user whether or not to charge (step S118 in FIG. 62). 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 mail issuance, and returns the flag to the terminal.
[0103]
The user selects OK if the user can be charged, or NG if the user does not want to purchase. Here, OK is selected, and a request for issuing a mail to the registrant is sent from the terminal to the host computer (step S119).
[0104]
In response, the host computer withdraws the money from the user's account or the like, and sends an e-mail notifying the registrant of the "BBB scheduler" of the money withdrawal. As the mail destination, the remittance destination FJOKI described in the [type] section of the definition file is used.
[0105]
The registrant who has received the e-mail from the host computer notifies the software purchaser of the method of releasing the function restriction by e-mail or the like. This allows the purchaser to use all the functions of the “BBB scheduler”.
[0106]
[Problems to be solved by the invention]
However, the conventional remote installation system as described above has the following problems.
[0107]
Since the software to be sold is confidential information, it needs to be delivered via a secure line. Therefore, it is necessary to take measures to prevent hacking in order to apply the method to the Internet where security is not guaranteed in advance.
[0108]
In addition, various mechanisms are conceivable as a method of linking a WWW browser (world \ wide \ web \ browser) which is a software tool for searching information on the Internet with a remote installation system, and a mechanism suitable for a provided service is constructed. There is a need to.
[0109]
Further, the machine ID of the terminal in the conventional remote installation system is created / managed on the assumption that there is only one host computer. For this reason, if a plurality of host computers provide services as RIS servers, each host computer may assign the same machine ID to different terminals. In this case, there arises a problem that the host computer erroneously identifies the terminal.
[0110]
Furthermore, since identification information and the like may be stolen on the Internet, it is difficult to accurately identify a communication partner. For this reason, it is possible to impersonate the host computer of the RIS by using the identification information obtained by a third party illegally. In such a case, the user needs to be able to detect it.
[0111]
An object of the present invention is to provide a system and a method for realizing a secure and appropriate membership service using a remote installation system on the Internet.
[0112]
[Means for Solving the Problems]
FIG. 1 is a diagram showing the principle of a service system according to the present invention. The service system in FIG. 1 includes the first, second, third, fourth, fifth, sixth, seventh, eighth, ninth, tenth, and eleventh principles of the present invention.
[0113]
According to the first principle, the service system includes a registration unit 80, a key information addition unit 81, and an encryption unit 82, and provides a software delivery service. The registration unit 80 signs up the client via a secure communication channel, and the key information assignment unit 81 assigns key information corresponding to the machine identifier of the client in the sign-up process. . Then, the encrypting unit 82 encrypts at least one of a password and software content on the Internet using the key information.
[0114]
The key information used for encryption is exchanged via a secure communication channel, so that it is not stolen. By encrypting the password using the secret key information thus given, the security of the login sequence to the remote installation system on the Internet can be enhanced. Also, by encrypting the content using the key information, the security of the remote installation sequence can be enhanced on the Internet.
[0115]
According to the second principle, the service system includes a remote installation unit 83 and a browser unit 88, and provides a 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 automatically installs the remote installation means 83 when the anchor file is accessed. to start.
[0116]
When the browser unit 88 activates the remote installation unit 83, the software specified by the user is automatically delivered. Therefore, the user can use the remote installation service on the Internet homepage without being conscious of the remote installation means 83.
[0117]
According to the third principle, the service system includes an accounting unit 84 and a browser unit 88, and provides an online shopping service. The billing means 84 automatically connects the client to the server and performs a billing process for the goods or services specified by the anchor file on the home page. The browser means 88 automatically executes the processing when the anchor file is accessed. The accounting unit 84 is activated.
[0118]
As the charging unit 84, for example, a remote installation system is used. When the browser unit 88 activates the charging unit 84, the charging of the product or service specified by the user is automatically performed. Therefore, an online shopping service using the remote installation system on the Internet is realized.
[0119]
According to the fourth principle, the service system includes a processing unit 85 and a browser unit 88, and provides a communication service. The processing unit 85 performs a charging process for the communication service specified by the anchor file on the homepage, and automatically sends information necessary for using the communication service from the server to the client. The browser means 88 automatically activates the processing means 85 when the anchor file is accessed.
[0120]
As the processing unit 85, for example, a remote installation system is used, and when the browser unit 88 activates the processing unit 85, charging of the communication service designated by the user and provision of information necessary for using the service are performed. It is done automatically. Therefore, a communication service using the remote installation system is realized on the Internet.
[0121]
According to the fifth principle, the service system includes a helper unit 86, a processing unit 87, and a browser unit 88, and provides a transaction service. The browser means 88 accesses the Internet, and the helper means 86 is started by the browser means 88 and performs a part of the transaction service. Further, the processing means 87 is started by the browser means 88 and cooperates with the helper means 86 to perform processing relating to granting the right to use a transaction and charging.
[0122]
As the processing means 87, for example, a remote installation system is used, and the browser means 88 activates the helper means 86 and the processing means 87, and the helper means 86 and the processing means 87 cooperate to give the user the right to use the transaction processing. Granting and charging are performed automatically. Therefore, a transaction service using a remote installation system is realized on the Internet.
[0123]
In the sixth principle, the service system includes a processing unit 89 and a transaction unit 91, and provides a transaction service. The transaction means 91 performs processing of a transaction service, and the processing means 89 is activated by the transaction means 91 and cooperates with the transaction means 91 to perform processing relating to granting a right to use a transaction and charging.
[0124]
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 with the processing means 89 to automatically grant the user the right to use the transaction processing and charge the user. Therefore, a transaction service using a remote installation system is realized without using a browser.
[0125]
According to the seventh principle, the service system includes a processing unit 90 and a transaction unit 91, and provides a transaction service. The transaction means 91 performs processing of the transaction service, and the processing means 90 is started by the transaction means 91 and automatically connects from the client to the server to acquire data necessary for the transaction service.
[0126]
As the processing unit 90, for example, a remote installation system is used, and the transaction unit 91 activates the processing unit 90. The processing unit 90 acquires data from the server and passes it to the transaction unit 91, and the transaction unit 91 performs a transaction service process using the data. Therefore, a transaction service using a remote installation system is realized without using a browser.
[0127]
In the eighth principle, the service system includes a receiving unit 92 and a determining unit 93. The receiving means 92 receives, from the client, a machine identifier generated by combining the server identifier and the client identifier. Then, the determination 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.
[0128]
When the client sends the server identifier mixed with the machine identifier, the determination unit 93 can specify which server the connection request is for. Then, the server corresponding to the server identifier is determined to be a correct connection destination of the client. Therefore, in an environment where a plurality of servers provide services, even when the same client identifier is given to two or more clients, the servers can reliably identify the clients.
[0129]
According to the ninth principle, the service system includes a generation unit 94, a storage unit 95, and a connection unit 96. The generating unit 94 combines the server identifier and the client identifier to generate a client machine identifier, and the storage unit 95 stores the machine identifier. Then, the connection means 96 connects to the server using the machine identifier.
[0130]
The generation unit 94 generates a machine identifier including the server identifier, and the connection unit 96 connects to the server using the machine identifier, so that the server can specify which server the connection request is for. Therefore, similarly to the eighth principle, the server can reliably identify the client.
[0131]
In the tenth principle, the service system includes a communication unit 97 and an authentication unit 98. When logging in to the server, the communication unit 97 transmits and receives the designated information encrypted by using the electronic signature function based on the authentication key of the server, and the authentication unit 98 authenticates the server via the designated information. .
[0132]
The server provides, for example, a remote installation service, and encrypts information specified by the client with a secret key and sends it back in a login sequence. The authentication unit 98 decrypts the designated information with the corresponding public key, and determines whether the server is correct based on the result. If the decrypted information matches the original specified information, the server is determined to be correct.
[0133]
Only the correct server can perform the correct encryption, so that the client can reliably 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 the information with the private key and sends it back.
[0134]
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 address information of a server on the Internet, and the connection unit 100 automatically connects from the client to the server using the address information.
[0135]
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 the RIS member, a membership-based remote installation service is realized on the Internet.
[0136]
As described above, according to the service system of FIG. 1, it is possible to safely and appropriately provide various membership services using the remote installation system on the Internet.
[0137]
The registration means 80, key information provision means 81, encryption means 82, remote installation means 83, browser means 88, charging means 84, processing means 85, helper means 86, processing means 87, processing means 89, processing means 90 of FIG. The transaction means 91, reception means 92, determination means 93, generation means 94, connection means 96, storage means 95, communication means 97, authentication means 98, storage means 99, and connection means 100 are, for example, shown in FIG. This corresponds to the functions of the host computer 111 and the user terminal 113.
[0138]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.
FIG. 2 is a configuration diagram of the service system according to 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 each other via a FENICS line 116, which is a communication path (pipe) that ensures security, in addition to the Internet 117.
[0139]
The host computer 111 includes an RIS server 112 as software for providing a remote installation service. The user terminal 113 includes, in addition to the WWW browser 114, an RIS client 115 as software using the remote installation service.
[0140]
FIG. 3 is a configuration diagram of an information processing device (computer) corresponding to the host computer 111 and the user terminal 113 in FIG. The information processing apparatus in FIG. 3 includes a CPU (central processing unit) 121, a memory 122, an input device 123, an output device 124, an external storage device 125, a medium drive device 126, and a network connection device 127. They are connected to each other by 128.
[0141]
The CPU 121 executes a program using the memory 122 and implements a process required for a service. The memory 122 stores programs and data necessary for the service. As the memory 112, for example, a ROM (read only memory), a RAM (random access memory), or the like is used.
[0142]
The input device 122 corresponds to, for example, a keyboard, a pointing device, or the like, and is used for inputting a request or instruction from a user. The output device 124 corresponds to a display device, a printer, or the like, and is used for outputting a service screen or the like.
[0143]
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-described program and data can be stored in the external storage device 125, and can be loaded to the memory 122 and used as needed. Further, the external storage device 125 is also used as a database.
[0144]
The medium driving device 126 drives the portable recording medium 129 and accesses the stored contents. As the portable recording medium 129, any computer-readable recording medium such as a memory card, a flexible disk, a compact disk (read-only) memory, an optical disk, and a magneto-optical disk can be used. The above-described program and data can be stored in the portable recording medium 129, and can be loaded to the memory 122 and used as needed.
[0145]
The network connection device 127 is used for connection to the FENICS line 116 and the Internet 117, performs data conversion and the like accompanying communication, and performs programs and data exchanges with another information processing device (the host computer 111 or the user terminal 113). Transmission and reception. Further, the information processing apparatus can receive the above-described program and data from a database 130 or the like of an external information provider via a network, and can load and use the program and the memory 122 as necessary.
[0146]
In the present embodiment, the registration procedure (sign-up) to the system is always performed by a secure pipe. Then, during the sign-up process, the RIS server 112 gives the RIS client 115 an Internet encryption key corresponding to the machine ID together with the user ID / password and the machine ID / password. The encryption key is used to encrypt / decrypt passwords and contents on the Internet.
[0147]
In order to realize such a service, a sequence as shown in FIG. 4 is added to the sign-up sequence in FIGS. 47 and 48, and the RIS server 112 allows the terminal (machine) 113 to uniquely correspond to a secret key (for example, DES). Key) to the terminal 113.
[0148]
In FIG. 4, the RIS client 115 issues a command RES without a machine ID (MID).　When the SENDENV is sent to the RIS server 112, the RIS server 112 returns a response with reference to the secret key database 131. The secret key database 131 stores a correspondence table between the MID and the secret key in advance.
[0149]
Here, MID = 1234, MPSWD = ASDF, and KEY = 9876 are returned to the RIS client 115 as a response. Among them, KEY corresponds to the secret key. The RIS client 115 writes and stores the received information in the initialization file 132 (RIS.INI).
[0150]
Further, as shown in FIG. 5, the initial setting file 132 includes an address (domain name) for connecting to the RIS server 112 via the Internet 117 and a port number of TCP / IP (transmission @ control @ protocol / internet @ protocol) Is described.
[0151]
These addresses and port numbers are written to the initialization file 132 of the terminal 113 when the user becomes an RIS member and the RIS client 115 is installed on the terminal 113. Since the address information is stored not on the Internet but on the RIS client 115 side, it is not hacked by users other than the member. Therefore, only RIS members can access the RIS server 112.
[0152]
The log-in on the Internet 117 using the address information is performed in a sequence as shown in FIG. Upon receiving an instruction to input a user ID (UID) from the RIS server 112, the RIS client 115 first sends out the MID together with the UID.
[0153]
The RIS server 112 generates a different random number Challenge every time using the Challenge generation function 133 and sends it to the RIS client 115. Although this random number is sent as identification information of the RIS server 112, it is different each time and cannot be hacked and used by others. Therefore, it is possible to prevent another server from impersonating the RIS server 112.
[0154]
The RIS client 115 combines the Challenge sent from the RIS server 112 with the KEY acquired at the time of sign-up using the combining function 134 to generate an encryption key. As the combining function 134, for example, EOR (exclusive) is used. Then, using the encryption key as a secret key (DES key) of the DES (Data \ Encryption \ Standard) algorithm, the user password is encrypted by the encryption program 135 and transmitted to the RIS server 112.
[0155]
The RIS server 112 similarly synthesizes the DES key from the Challenge and the KEY sent to the RIS client 115. Then, the encrypted user password is decrypted by the decryption program 136, and the user password is confirmed. Since the user password is exchanged after being encrypted, at the time of login on the Internet 117, plagiarism of the user password is prevented.
[0156]
In the delivery of contents on the Internet 117, the conventional remote installation method shown in FIGS. 44, 45 and 46 is extended as shown in FIG. First, when the RIS client 115 requests distribution of content requiring security via the Internet 117, the RIS server 112 credits the price.
[0157]
Next, the RIS server 112 transmits the compressed content file ABC. The LZH is encrypted by the encryption program 135 using the secret key corresponding to the MID, and downloaded to the RIS client 115. Then, the encrypted content file ABC. Send a command to decrypt the DES.
[0158]
The RIS client 115 transmits the content file ABC. DES is decrypted by the decryption program 136 using the stored KEY, and the file ABC.DES is decrypted. Remove LZH. Next, according to the command from the RIS server 112, the file ABC. Decompress LZH and execute the executable file ABC. Generate EXE. Thereafter, ABC. DES and ABC. LZH is automatically erased.
[0159]
In this way, by transmitting a secret key via a communication path in which security is secured in advance, it becomes possible to employ a robust encryption algorithm such as the DES algorithm. Further, as the encryption algorithm, any other algorithm using a secret key can be used.
[0160]
Next, a remote installation system that delivers specified software by activating a browser helper application will be described. In this system, the RIS client 115 is registered in the WWW browser 114 as a helper application in advance. Here, the helper application refers to a program that can be started by being kicked from the WWW browser 114 and display a file in a format other than the functions incorporated therein.
[0161]
Then, an anchor file for starting the helper is placed on the home page, and when the user clicks the anchor file with a pointing device, the RIS client 115 automatically connects to the RIS server 112 and the specified software is delivered. To
[0162]
FIG. 8 shows such a software delivery system on the Internet 117. The software studio 141, which is a software vendor, opens a home page 142 on the Internet 117 and advertises 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).
[0163]
The HTML (hypertext \ markup \ language \) file constituting the homepage 142 is described as shown in FIG. Thereby, software names such as “horse racing software” and “pachinko software” and a selection button (Ris icon) for receiving the delivery are displayed. An anchor file for starting a helper is set as a reference to each of these Ris buttons.
[0164]
For example, an anchor file 144 (KEIBA.RIS) as shown in FIG. 10 is linked to the Ris icon 143 of “horse racing software”. This KEIBA. In the [RIS] section of the RIS, a software name and a software number (Soft) are described.
[0165]
Also, as the MIME (multipurpose @ internet @ mail @ extensions) setting of the WWW server in the anchor file 144, the file type ".RIS" is associated with the MIME type "application / x-ris". MIME is a method for handling various file formats in WWW. As a result, when the WWW browser 114 refers to this reference, the corresponding WWW server returns "application / x-ris" as the MIME type.
[0166]
It is assumed that the user has already been given a user ID / password and a machine ID / password as a RIS member by the methods shown in FIGS. Further, the RIS client 115 is registered in the WWW browser 114 as a helper application.
[0167]
For example, when Netscape is used as the WWW browser 114, “.RIS” is registered as File-Type, and “application / x-ris” is registered as MIME-TYPE. Also, “C: \ RISW410 \ RISWIN32 \ RISANSC32.EXE" is registered as a Launch application that starts the RIS client 115.
[0168]
In this state, it is assumed that the user accesses the software studio homepage 142 (process P2) and clicks the Ris icon 143 next to “horse racing software” with a pointing device (process P3). At this time, the WWW browser 114 automatically activates the RIS client 115 and sends the file KEIBA. The contents of the RIS are passed (process P4).
[0169]
The activated RIS client 115 connects to the RIS server 112 by the method shown in FIG. 6 (process P5). After the login, as shown in FIG. 11, the RIS server 112 performs software distribution in the same sequence as in FIGS. 44, 45, and 46. At this time, the file KEIBA. The software number extracted from the RIS is sent from the RIS client 115 to the RIS server 112, and the corresponding software is automatically delivered to the terminal 113.
[0170]
When the above operation is performed, the purchase history described in the purchase table of FIG. 12 and the payment table of FIG. 13 remains in the database on the RIS server 112. Therefore, the RIS server 112 collects the price from the purchaser via the credit company based on the purchase table, and returns the price to the vendor based on the payment table (process P6).
[0171]
By registering the RIS client 115 as a helper application started from the WWW browser 114, a software distribution system on the Internet 117 is realized. Instead of incorporating the RIS client 115 as a helper, the RIS client 115 may be registered as a plug-in (application in a browser window) of the WWW browser 114.
[0172]
Next, an online shopping system that can easily purchase items by activating a browser helper application will be described. In this system, the RIS client 115 is registered in the WWW browser 114 as a helper, and an anchor file for starting the helper is placed on a homepage.
[0173]
Then, when the user clicks the anchor file, the RIS client 115 automatically connects to the RIS server 112, and the RIS server 112 automatically performs the charging process for the specified product and reports the purchase to the vendor. In response to this, the vendor sends the product to the user.
[0174]
FIG. 14 shows such an online shopping system. The α store 151, which is the vendor, 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 the product purchase processing is registered in the RIS server 112 by the method of the prior application shown in FIGS. 51 and 52 (process P12).
[0175]
The HTML file of the homepage 152 is described in a format similar to that of FIG. 9, and the Ris icons required for selecting / purchasing a product are displayed on the homepage 152 (process P13). The settings of the anchor file linked to each Ris icon and the MIME and the like on the user side are the same as in the above-described software distribution system. For example, the Ris icon 153 is linked to an anchor file 154 (TOWEL.RIS).
[0176]
In this state, it is assumed that the user accesses the α store homepage 152 (process P14) and clicks the Ris icon 153 next to “towel set” (process P15). At this time, the WWW browser 114 starts the RIS client 115 registered as a helper, and sends the file TOWEL. The contents of the RIS are passed (process P16).
[0177]
The activated RIS client 115 connects to the RIS server 112, logs in with the encrypted password, and executes the registered remote installation processing (RIS　INSTALL) is started (process P17). The setting contents and procedure at the time of login are the same as those of the above-described software distribution system.
[0178]
In the started remote installation process, the script is described so as to perform an operation different from the case of software home delivery. In this case, specifically, a process of sending a reception slip to the user and a process of sending a purchase notification to the vendor are described instead of the software delivery process. In addition, if necessary, the destination of the product can be specified by the user.
[0179]
The reception slip is sent to the user in the same manner as when downloading software (process P18). Further, the purchase notice is sent to the vendor as a notice form in a prescribed format via e-mail or a dedicated line (process P18). The sending process of the purchase notice is the order receiving process of the product from the viewpoint of the vendor. This purchase notification sending process is also executed immediately during the remote installation process.
[0180]
FIG. 15 shows the sequence of these sending processes. First, the RIS client 115 sends the file TOWEL. The software number extracted from the RIS is sent to the RIS server 112 as the number of the product to be ordered. At this time, the command RIS　Use CHKENV.
[0181]
Next, when the RIS server 112 inquires of a shipping destination of the product as a response, the user inputs a desired address / address. The input destination is the command RIS　It is sent to the RIS server 112 using CHKENV. When "OK" is returned from the RIS server 112, the RIS client 115　Send INSTALL.
[0182]
At this time, the RIS server 112 downloads the reception 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 in FIG. 15 is completed, a purchase table and a payment table similar to those in FIGS. 12 and 13 are created. Based on these, the RIS server 112 collects the price from the user and pays the vendor (processing). P20).
[0183]
By registering the RIS client 115 as a helper application started from the WWW browser 114, an online shopping system on the Internet 117 is realized. Further, the RIS client 115 can be registered as a plug-in of the WWW browser 114.
[0184]
According to such a system, since the user information as the RIS member is registered in advance, the user only has to press the button of the favorite product when purchasing the product. For this reason, very simple online shopping becomes possible. In addition, it is possible to specify a shipping address different from the contact address at the time of registration, and for example, it is possible to deliver a product as a gift to a third party.
[0185]
In addition, the RIS center can undertake some sales-related operations in the form of outsourcing. Therefore, if the product is sold only to the RIS member, there is an advantage that the vendor can save troublesome work such as contracting with each card company.
[0186]
Next, an online communication service system that notifies a specific password by activating a browser helper application will be described. In this system, the RIS client 115 is registered in the WWW browser 114 as a helper, and an anchor file for starting the helper is placed on a homepage.
[0187]
When the user clicks the anchor file, the RIS client 115 automatically connects to the RIS server 112. The RIS server 112 performs a charging process 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.
[0188]
FIG. 16 shows such an online communication service system. The fortune-telling house 161 which is a communication service vendor opens a homepage 162 on the Internet 117 and uses it as a screen for receiving its own fortune-telling service (process P21). In addition, the password information serving as a fortune-telling ticket indicating the right to use the fortune-telling service is registered in the RIS server 112 as a notice to the user by the method shown in FIGS. 51 and 52 (process P21).
[0189]
The HTML file of the homepage 162 is described as shown in FIG. Thereby, the Ris icon 163 corresponding to the fortune-telling ticket and the password input field 164 are displayed. In the Ris icon 163, an anchor file 165 (FTELL.RIS) for starting a helper is set as a reference.
[0190]
This file FTELL. In the [RIS] section of the RIS, as shown in FIG. 18, a service name of a fortune-telling service and a software number (Soft) are described. This software number is used as a service identification number.
[0191]
The MIME setting of the WWW server in the anchor file 165 is set in the same manner as in the above-described software distribution system. As a result, when the WWW browser 114 refers to this reference, the corresponding WWW server returns application / x-ris as the MIME type.
[0192]
It is assumed that the user has already been given a user ID / password and a machine ID / password as an RIS member, as in the above-described software distribution system. Further, the RIS client 115 is registered in the WWW browser 114 as a helper application.
[0193]
In this state, it is assumed that the user accesses the fortune telling homepage 162 (process P22) and clicks the Ris icon 163 next to the fortune-telling ticket (process P23). At this time, the WWW browser 114 activates the RIS client 115 and sends the file FTELL. The contents of the RIS are passed (process P24).
[0194]
The activated RIS client 115 connects to the RIS server 112 and logs in with the encrypted password. The sequence of login on the Internet 117 and the setting for using the RIS client 115 are the same as those shown in FIGS.
[0195]
After login, the RIS client 115 sends the file FTELL. The software number described in the RIS is sent to the RIS server 112 (process P25), and the RIS server 112 performs a charging process for the purchase price of the service specified by the number, and thereafter, a password for identifying the service purchaser. Is notified to the user (process P26).
[0196]
The notification of the password is a notification from the RIS center to the user, and is performed by, for example, displaying a screen as shown in FIG. 19 on the terminal 113 in the form of a message box.
[0197]
By inputting the received password into the input field 164 displayed on the homepage 162, the user can receive the fortune-telling service through the corresponding WWW server (process P27). For this reason, the WWW server providing the fortune-telling service has a function of obtaining the value in the password field and confirming the right to use the service.
[0198]
As a method of realizing this function, a script file ura.file of CGI (common @ gateway @ interface) described in the HTML file of FIG. Use cgi. File ura. The logic of the service use right confirmation processing as shown in FIG. 20 is described in cgi.
[0199]
When the confirmation process is started, the CGI process on the WWW server first obtains the value of the input password (step S201), compares it with the password registered in the RIS server 112, and determines whether the password is correct. Confirm (step S202).
[0200]
If the password is correct, the user is deemed to have been charged, a paid fortune-telling service providing screen is displayed (step S203), and the process ends. If the password is not correct, a message indicating the error is displayed on the homepage 162 (step S204), and the process ends.
[0201]
As a mode of operation of a password in such a communication service, a method of giving a common password to all users and continuing the operation is conceivable. In addition, the password is changed at regular intervals (several minutes, several hours, several days, etc.) to prevent password leakage between users or unauthorized use due to password guessing, and to limit the service provision period. There is also a method and a method of issuing a different password for each user. Further, these password protection methods can be used together.
[0202]
Further, at the time of registration with the RIS server 112, a password can be dynamically generated by using a specific calculation algorithm instead of using the password as fixed information.
[0203]
When the above operation is performed, a service purchase history similar to that of FIGS. 12 and 13 remains in the database of the RIS server 112. Based on the service purchase history, the purchase price is determined in the same procedure as in the software delivery system described above (process P28).
[0204]
As described above, by registering the RIS client 115 as a helper application started from the WWW browser 114, an online communication service system on the Internet 117 is realized. Further, the RIS client 115 can be registered as a plug-in of the WWW browser 114.
[0205]
In the system of FIG. 16, the right to use the communication service is given by notifying the user of the password, but instead, a URL (uniform @ resource @ locator) for receiving the service may be notified. The URL is identification information that uniformly represents resources on a network.
[0206]
In this case, the RIS server 112 notifies the user of the URL of the communication service after the charging process. The URL is operated so that only the user who has been charged can know the URL. For example, if the URL is changed frequently, the user must purchase a ticket in order to know the latest URL.
[0207]
FIG. 21 shows such a communication service system. The operation of this system is basically the same as the system of FIG. First, the fortune-telling house 161 opens a homepage 166 on the Internet 117 and sets it as a reception screen of its fortune-telling service (process P31). Further, the URL information serving as a fortune-telling ticket is registered in the RIS server 112 by the method shown in FIGS. 51 and 52 (process P31).
[0208]
On the homepage 166, a Ris icon 167 corresponding to the fortune-telling ticket and a message “URL to fortune-telling room is displayed by ticket purchase” are displayed. In the Ris icon 167, an anchor file 165 (FTELL.RIS in FIG. 18) for starting a helper is set as a reference.
[0209]
It is assumed that the user accesses the fortune telling homepage 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 sends the file FTELL. The contents of the RIS are passed (process P34).
[0210]
The activated RIS client 115 connects to the RIS server 112, logs in with the encrypted password, and stores the file FTELL. The software number described in the RIS is sent to the RIS server 112 (process P35). The RIS server 112 performs a charging process for the purchase price of the service specified by the number, and then notifies the user of the URL of the fortune-telling service page 168 (process P36). The notification of the URL is performed using, for example, a message box similar to that shown in FIG.
[0211]
By specifying the URL to the fortune telling service obtained by the notification on the WWW browser 114, the user can access the service page 168 and receive the fortune telling service (process P37).
[0212]
In the system of FIG. 21, instead of notifying the user of the URL, it is also possible to automatically start a browser that refers to the URL. In this case, by launching the browser by software triggered by the URL notification from the RIS center, the user can access the service screen corresponding to the URL without directly handling the URL.
[0213]
According to the implementation of the WWW browser 114, if the already activated WWW browser 114 can automatically acquire the URL specification by an external event, the RIS client 115 writes the URL in a format that the WWW browser 114 can read. Notice. As such a method, for example, there is a method of writing a URL in a predetermined file of the WWW browser 114 and then sending a software signal to the operating WWW browser 114.
[0214]
In the case of WIN95 (Windows 95), for example, a file WORK. Create a URL. This file WORK. In the URL, the URL notified from the RIS server 112 is written according to the type of the browser such as mosaic or NETSCAPE.
[0215]
Then, the RIS client 115 starts up the WWW browser 114 using the API (application @ programming @ interface) of the WIN95. The API is a programming interface provided by the operating system.
[0216]
The API in this case is described, for example, as "ShellExecute (~," WORK.URL ", ~)". As a result, the WWW browser 114 opens the file WORK. The URL is automatically obtained from the URL and the corresponding service screen is accessed.
[0219]
In the case where the WWW browser 114 cannot automatically acquire the URL designation by software using the above-described method, a predetermined URL is given as an initial URL argument, and the WRIS browser 115 is separately activated from the RIS client 115. When it is inconvenient that a plurality of WWW browsers 114 operate at the same time in parallel, the WWW browsers 114 that have been operating previously may be temporarily terminated, and then the WWW browsers 114 may be activated again.
[0218]
Next, a transaction processing system including a transaction helper and an RIS system will be described. In this system, a transaction helper is prepared, and the right to use the transaction is registered in the RIS system. Then, the RIS system activated as a helper cooperates with another transaction helper to perform the distribution of the usage right of the transaction processing and the billing processing.
[0219]
FIG. 23 shows such a transaction processing system. The WWW server 171 of the VOICE studio, which is a vendor, provides, for example, a voice fortune-telling transaction service for performing fortune-telling based on the input user's voice. First, the WWW server 171 opens a home page 172 for voice fortune-telling on the Internet 117, and registers a voice fortune-telling ticket indicating the right to use the transaction service in the RIS server 112 as software (process P41).
[0220]
On the user terminal 113, the RIS client 115 and the voice processing program 178 are registered as helpers of the WWW browser 114. The Voice processing program 178 is dedicated software for receiving a voice input from the user and creating a voice file after performing various filtering processes, and is created / distributed by the VOICE studio.
[0221]
First, the user accesses the VOICE studio homepage 172 from the WWW browser 114 (process P42), and clicks on the icon 173 for selling fortune-telling tickets (process P43).
[0222]
In this icon 173, an anchor file 176 (URANA.RIS) for starting the RIS client 115 is set as a reference, and the WWW browser 114 starts the RIS client 115 and sets the file URANA.RIS. The contents of the RIS are passed (process P44). File URANA. MIME settings in the RIS are the same as in the system of FIG.
[0223]
The activated RIS client 115 connects to the RIS server 112 via the Internet 117 (process P45) and directly distributes the voice fortune telling ticket.
[0224]
Here, as the distribution processing, the RIS client 115 rewrites the information of the initialization file 179 (Voice.ini) of the voice processing program 178 (processing P46). For example, file Voice. By writing “YES” in the [Permission] section of the ini, the distribution of the voice fortune-telling ticket is performed, and the right to use the service is given to the user.
[0225]
Next, the user clicks the voice input start icon 174 on the homepage 172 (process P47). In this icon 174, an anchor file 177 (KUBO.VOC) for starting the voice processing program 178 is set as a reference, and the WWW browser 114 starts the voice processing program 178 (process P48). As the MIME setting in the anchor file 177, the file type “.VOC” is associated with the MIME type “application / x-voice”.
[0226]
The started voice processing program 178 performs processing as shown in FIG. First, the voice processing program 178 checks whether "YES" is described in the [Permission] section of the initialization file 179 (step S211). If "YES" is not described here, a message "fortune-telling ticket not purchased" is displayed (step S216), and the process ends.
[0227]
If "YES" is described here, the voice input operation is started (step S212), and various local processes such as filtering of the input voice are performed (step S213) to generate / output a voice file (not shown). (Step S214). Then, the file Voice. "YES" in the [Permission] section of the ini is deleted (step S215), and the process ends.
[0228]
When the audio file is output in this way, 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, for example, as shown in FIG. In FIG. 25, an audio file name input field 181, a Browse icon 182, an ADD icon 183, and an execution icon 184 are displayed.
[0229]
When the Browse icon 182 is clicked, a 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 input audio file. The HTML file 186 indicates a description method of the fortune-telling start page.
[0230]
When the voice file name is input by the user and the execution icon 184 is clicked, the specified voice file is uploaded to the WWW server 171 that performs the fortune-telling service. The upload of the audio file is performed using a known HTML file upload function. The WWW server 171 processes the uploaded audio file and returns a fortune-telling result 180 to the WWW browser 114 (processing P50).
[0231]
The usage fee for voice fortune-telling 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 studio (process P51).
[0232]
By using the above-mentioned initialization file 179, the RIS client 115 is started directly from a local transaction processing program, and the right to use the transaction processing is distributed and the accounting processing is performed in the same manner as in FIG. You can also.
[0233]
In this case, the transaction processing program is configured as shown in the flowchart of FIG. First, the transaction processing program first executes the file Voice. It is checked whether or not information "BUYING" indicating that the service usage right is being purchased is written in the [Permission] section of the ini (step S221).
[0234]
If "BUYING" is written here, the same determination is repeated until it is erased, and if "BUYING" is not written, then the information indicating purchase is added to the [Permission] section. Is checked (step S222).
[0235]
If "YES" is not written here, it is understood that the service use right (fortune telling ticket) is neither purchased nor purchased. Therefore, the transaction processing program inquires of the user whether to purchase a fortune telling ticket (step S228). Here, if the user does not select the purchase of the fortune telling ticket, the process is terminated as it is.
[0236]
When the user selects to purchase a fortune telling ticket, the transaction processing program causes the file Voice. "BUYING" is written in the [Permission] section of the ini (step S229), the RIS client 115 is activated (step S230), and the processing from step S228 is repeated.
[0237]
The activated RIS client 115 connects to the RIS server 112 in the same manner as in the system of FIG. 23 and purchases a fortune telling ticket. When the purchase of the fortune telling ticket is completed, the RIS client 115 transmits the file Voice. "BUYING" in the [Permission] section of the ini is erased, and "YES" is written instead.
[0238]
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 a voice input operation (step S223), performs processing such as filtering of input voice (step S224), and executes fortune-telling (step S225).
[0239]
Then, the fortune-telling result is displayed (step S226), and the file Voice. "YES" in the [Permission] section of the ini is deleted (step S227), and the process ends. By erasing “YES” in the [Permission] section, the transaction processing recovers the initial state.
[0240]
Thus, by providing the transaction processing program that cooperates with the RIS system on the user terminal 113, the RIS system can be used without the intervention of the WWW browser 114.
[0241]
Further, in the transaction service system of FIG. 23, it is possible to sell the service usage 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 uses a configuration in which the count number of the initialization file is decremented by one for each transaction processing.
[0242]
FIG. 27 shows such a transaction service system. In the system of FIG. 27, three types of fortune-telling tickets are registered in the RIS server 112 once, five times, and ten times, respectively, corresponding to the software numbers 160, 161, and 162, respectively. Then, on the VOICE studio homepage 191 of the vendor, icons 192, 193, and 194 of a one-time ticket, a five-time ticket, and a ten-time ticket are displayed as icons of the voice fortune-telling ticket sales.
[0243]
In these icons 192, 193, and 194, anchor files 195 (URANA.RIS), 196 (URANA2.RIS), and 197 (URANA3.RIS) are set as references. Then, the file URANA. The software number 160 is described in the RIS, and the file URANA2. The software number 161 is described in the RIS, and the file URANA3. The software number 162 is described in the RIS.
[0244]
When the user selects one of the fortune telling tickets 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, and the [Permission] of the initialization file 179. ] Section, write the corresponding count number (Count). For example, if ten tickets have been purchased, Count = 10. As a result, the service usage right is set to the user terminal 113 a plurality of times.
[0245]
FIG. 28 is a flowchart of the processing of the voice processing program 178 in this system. First, the Voice processing program 178 checks whether or not the value of Count in the [Permission] section of the initialization file 179 is 0 (step S231). If Count is 0, a message "fortune-telling ticket not purchased" is displayed (step S236), and the process ends.
[0246]
If Count is larger than 0, the voice input operation is started (step S232), various local processes such as filtering of the input voice are performed (step S233), and a voice file is generated / output (step S234). Then, the file Voice. The value of the Count in the [Permission] section of the ini is decremented by 1 (step S235), and the process ends.
[0247]
By using such a voice processing program 178, the user can receive the service as many times as the number of uses of the purchased service use right. Other settings and operations in the system in FIG. 27 are the same as those in the system in FIG.
[0248]
Next, a description will be given of a system for acquiring and charging data by cooperative processing between a local transaction processing program and the RIS system. In this system, the RIS client 115 is started directly from the transaction processing program, and data for transaction processing is obtained in the same manner as in FIG.
[0249]
For example, when the transaction processing program is horse race prediction software, a flowchart of the processing is as shown in FIG. When starting, the horse racing prediction software asks the user whether to acquire new data (step S241).
[0250]
Then, when the user has made a decision not to acquire new data, the prediction is executed using the existing horse race data (step S243), and the process ends. When the user has made a decision to acquire new data, the RIS client 115 is activated (step S242).
[0251]
The RIS client 115 accesses the RIS server 112 based on the software number. As shown in FIG. 30, horse racing data is registered in the RIS server 112 in advance, and distribution of horse racing data is directly performed in the same manner as in FIG. Then, the horse racing prediction software executes the prediction using the delivered horse racing data (step S243), and ends the processing.
[0252]
FIG. 31 shows a distribution process of horse racing data by the RIS client 115 and the RIS server 112. This processing is executed using the method shown in FIGS. First, the RIS client 115 transmits the horse racing data file KEIBA. The DAT date is checked and sent to the RIS server 112 (step S251). File KEIBA. For example, as shown in FIG. 32, data A, B, and C of a racehorse are stored in the DAT.
[0253]
The RIS server 112 refers to a date / file name correspondence table as shown in FIG. 33, searches for a file name corresponding to the sent date, and sends the corresponding file to the RIS client 115 as an additional data file. (Step S252). Then, the contents are stored in the file KEIBA. DAT and the file KEIBA. The DAT is updated (step S253), and the process ends.
[0254]
The date / file name correspondence table of FIG. 33 is registered in the RIS server 112 in advance, and is updated as necessary. File FILE1. LZH, FILE2. LZH, FILE3. The LZH includes a combination of data as shown in FIG.
[0255]
For example, file FILE1. The LZH includes data D, E, F, and G, and the file FILE2. The LZH includes data E, F, and G, and the files FILE3. The LZH includes data F and G. As described above, by changing the combination of data for each file, the file KEIBA. The DAT allows more additional data to be provided.
[0256]
According to the transaction processing program as shown in FIG. 29, it is possible to deliver data required for a service using the RIS system without the intervention of the WWW browser 114.
[0257]
Alternatively, the transaction processing program may be configured to connect to the RIS server 112 and acquire data only when a certain period of time has passed since the last data update by looking at the date of the data file at the time of startup. 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 from the date of the data file.
[0258]
FIG. 35 is a flowchart of such horse race prediction software. The horse racing prediction software starts up the current date and data file KEIBA. The difference between the dates of the DAT is calculated, and it is determined whether the difference exceeds two months (step S261).
[0259]
If the difference does not exceed two months, the prediction is executed using the existing horse racing data (step S263), and the process is terminated. If the difference exceeds two months, the RIS client 115 is activated and new horse racing data is acquired from the RIS server 112 (step S262). The file KEIBA. Updated with the delivered horse racing data. The prediction is executed using the DAT (step S263), and the process ends.
[0260]
Next, an RIS system that prevents a server from erroneously recognizing a user terminal by mixing a server identifier with a machine ID (MID) of a user terminal (client machine) in a network environment in which a plurality of RIS servers exist will be described.
[0261]
In this system, a server identifier and an identifier of a client machine 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 disconnects from the client if the server unit is different from the server identifier.
[0262]
The conventional method of identifying a client by the RIS system is based on the premise that there is only one server. On the other hand, if the method according to the present embodiment is used, even when a plurality of servers provide services and one client connects to each server, it is possible to prevent the servers from erroneously recognizing the clients.
[0263]
In this system, each of a plurality of different servers has a unique identifier representing itself, and the MID of a 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.
[0264]
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 α (eg, directory information and memory amount) for the client number 1 and holds information on the machine β for the client number 2. The other server B holds information of the machine α for the client number 2 and holds information of the machine β for the client number 1.
[0265]
In the conventional method shown in FIG. 48, the client number itself is used as the MID. When 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 this as the MID of the machine β and sends the information sent from the machine α to the machine β. An accident that could overwrite information could have occurred.
[0266]
However, by generating an MID by mixing a server identifier with a client identifier, when a client connects to a server using an incorrect identifier, the server can check this and detect an error. . Thus, the server can prevent the machine information from being erroneously overwritten, and can notify the client of the error.
[0267]
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 are “A2” and “B1”, respectively. And
[0268]
At this time, if the machine α erroneously accesses the server A with “B2” as the MID, the server A first decomposes the MID into a server unit “B” and a client unit “2”, and Look up the identifier of. In this case, since the server unit “B” is different from its own identifier, this access is determined to be erroneous, and the connection with the machine α is disconnected.
[0269]
Also, when the machine α accidentally accesses the server B with “A1” as the MID, the error is similarly detected and the connection with the machine α is disconnected. Here, the access error is notified to the client by a method of disconnecting the connection, but an error message or the like may be used instead.
[0270]
As the server identifier of this system, the domain name ris. gmsnet. or. It is desirable to use one that is guaranteed to be unique in the world, such as jp. Then, the accident of duplication of the server identifier can be avoided, and the client can be completely identified. Therefore, even when one client uses a plurality of servers, it is possible to prevent the client machine information from being confused.
[0271]
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.
[0272]
For example, the file RIS. INI as a basic initialization file, and a file RIS2. Let INI be an initialization file for another server. In this way, if different initialization files are prepared for each server, completely different user IDs / passwords and MIDs can be handled as indicated by arrows.
[0273]
The file RIS. In the INI, an [EXTENSION] section is provided, in which whether or not to activate another initialization file can be described. Here, the file RIS. INI and RIS2. INI is active (ON), and the other files RIS2. The INI is also automatically referenced.
[0274]
If the method shown in FIG. 36 is used, the server can correctly handle the information of the client machine. The next problem is to make sure that the client can connect to the right server. This is because there is a risk that if there are multiple servers, you may accidentally connect to a malicious server.
[0275]
Therefore, next, an RIS system for identifying a correct server will be described. In this system, a login session using an electronic signature function by RSA (Rivest-Shamir-Adleman @) encryption is provided. The RSA encryption is an asymmetric encryption system, and different key information is used for encryption and decryption.
[0276]
In this login session, the server encrypts the determined information with the secret key and sends it to the client, and the client authenticates the server by decrypting the information with the public key. This allows the client to determine whether the login destination is the correct server.
[0277]
FIG. 39 shows such a server identification system. In FIG. 39, each server holds an RSA private key and registers a corresponding public key on the homepage 201. It is assumed that the user determines whether the home page 201 displaying the server list can be trusted. Alternatively, the URL of the trusted homepage 201 may be embedded in the client in advance.
[0278]
The server has the client pass arbitrary information in plaintext at the time of connection, encrypts it with a private key, and returns it. The client can correctly restore the original plaintext with the server's public key. The fact that the server has been correctly restored means that the server holds the private key that is paired with the public key, so that the server can be determined to be correct.
[0279]
In FIG. 39, prior to connection to the server A, the machine α acquires server information such as its identifier “A” and public key “public A” from the homepage 201 and creates an MID “A1”. At this time, if necessary, information of another server is also acquired.
[0280]
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 for information (Word) for server identification. Then, when the machine α sends the information “apple” in plain text, the server A encrypts it with the secret key “secret A” and sends it back as a secret (apple, secret A).
[0281]
The machine α decrypts the secret (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.
[0282]
On the other hand, the login sequence for the server A 'impersonating the server A is as shown in FIG. It is the same as FIG. 40 until the machine α connects to the server A ′ and sends information “apple” to the server A ′. The server A encrypts the received information with an appropriately set secret key “secret A ′” and sends it back as a secret (apple, secret A ′).
[0283]
However, when the machine α decrypts the secret (apple, secret A ′) with the public key “public A”, the plaintext “bqqmf” is extracted. Since this information is different from the information sent earlier, it is determined that the connection destination is not the correct server A, and the connection is disconnected. Thus, the fake server A 'can be identified.
[0284]
Unlike the sequence shown in FIGS. 40 and 41, the same effect can be obtained even if the client sends information encrypted with the server's public key to the server, and the server decrypts it with the secret key and sends it back to the client as plain text. Is obtained. In this case, if the plaintext returned from the server is correct, the client recognizes the server as a correct server.
[0285]
In the server identification system of FIG. 39, if the operation is continued while the public key and the private key serving as the server authentication key are fixed, the encryption may be broken someday. Therefore, it is necessary to improve the security of encryption by updating these periodically. However, it is inconvenient to reset the server information on the client side every time the public key is changed. Therefore, this process is automated, and the server information is acquired every time the client logs in to the server.
[0286]
Then, the RIS client 115 is started from the home page by using the method shown in FIG. In this case, the anchor file linked to the Ris icon is extended as shown in FIG. 42, and the server identifier is described in the [SERVER] section and the public key is described in the [OKKEY] section.
[0287]
The RIS client 115 started from the WWW browser 114 performs a process as shown in FIG. 43 before connecting to the RIS server. The RIS client 115 first checks the anchor file RIS2. By looking at the [SERVER] section of the RIS, it is checked whether or not there is an access right to the RIS server "0002" (step S271).
[0288]
If the server identifier "0002" is described here, it is determined that the user has the access right. Next, the [OKY] section is looked up and a new public key "1234" is fetched (step S272). Then, by looking at the [RIS] section, it is known that "Start = menu" is described instead of the software number. Therefore, it is recognized that the RIS server "0002" is accessed from the initial menu instead of requesting the software (step S273), and the process is terminated.
[0289]
If it is determined in step S271 that there is no access right to the server "0002", processing such as displaying an error is performed (step S274), and the processing ends. Thus, the file RIS2. When the reading of the RIS is completed, the RIS client 115 starts a login session as shown in FIG.
[0290]
In the embodiment described above, the encryption algorithm is not limited to DES and RSA, and any other encryption algorithm can be used. In addition, the online shopping system of FIG. 14 can sell any product or service other than a towel set and a handkerchief, and the communication service system of FIGS. Can be. Further, the transaction service system of FIGS. 23 and 27 can provide any transaction service other than the voice fortune-telling service.
[0291]
【The invention's effect】
ADVANTAGE OF THE INVENTION According to this invention, it becomes possible to provide various membership-based services, such as a software delivery service, online shopping, a communication service, and a transaction service, using a remote installation system on the Internet. In addition, authentication of a connection destination on the Internet and encryption of passwords, contents, and the like are also performed, so that service security is guaranteed.
[Brief description of the drawings]
FIG. 1 is a principle diagram of a service system of the present invention.
FIG. 2 is a system configuration diagram of the embodiment.
FIG. 3 is a configuration diagram of an information processing apparatus.
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 distribution system on the Internet.
FIG. 9 is a diagram showing an HTML file of a software studio homepage.
FIG. 10 is a diagram showing a first anchor file.
FIG. 11 is a diagram showing software distribution.
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 sending 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 use 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 a first horse race prediction process.
FIG. 30 is a diagram showing information of the RIS server.
FIG. 31 is a flowchart of data distribution processing.
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 a second horse race prediction process.
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 flowchart of sales.
FIG. 50 is a flowchart of a terminal password check.
FIG. 51 is a diagram showing a configuration of a place.
FIG. 52 is a flowchart of the work of the author.
FIG. 53 is a flowchart of the operation of the original club administrator.
FIG. 54 is a flowchart of the operation of the transfer destination club administrator.
FIG. 55 is a diagram showing upload.
FIG. 56 is a diagram (part 1) illustrating a shareware procedure;
FIG. 57 is a diagram (part 2) illustrating the shareware procedure;
FIG. 58 is a diagram (part 3) illustrating a shareware procedure;
FIG. 59 is a diagram (part 4) illustrating the shareware procedure;
FIG. 60 is a diagram (No. 1) showing a payment withdrawal procedure;
FIG. 61 is a diagram (part 2) illustrating a payment withdrawal procedure;
FIG. 62 is a diagram (No. 3) illustrating a 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 Description file
23. Installation related files
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 providing means
82 encryption means
83 Remote installation means
84 Billing means
85, 87, 89, 90 ° processing means
86 helper means
88 Browser means
91 Transaction means
92 receiving means
93 judgment means
94 generation means 94
95, 99 storage means
96, 100 ° connection means
97 Communication means
98 authentication means
111 @ host computer
112 @ RIS 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
127 Network connection device
128 bus
129 Portable recording medium
130 database
131 @ private key database
132, 179 Initial setting file
133 @ Challenge generation function
134 composite function
135 encryption program
136 decryption program
141 soft workshop
142 @ software studio homepage
143, 153, 163, 167, 192, 193, 194 @ Ris icon
144, 154, 165, 176, 177, 195, 196, 197 Anchor file
151 α store
152 α store homepage
161 fortune-telling house
162, 166 Fortune-telling homepage
164 @ Password entry field
168 fortune-telling service page
171 @ VOICE studio server
172,191 @ VOICE studio homepage
173, 174, 175, 182, 183, 184 icon
178 @ Voice processing program
180 divination result
181 Audio file name input field
185 file selector
186 HTML file
201 homepage you can trust

Claims (5)

Receiving means for receiving, from a client, a machine identifier generated by combining a server identifier and a client identifier;
A service unit for decomposing the machine identifier into a server unit and a client unit, checking the server identifier described in the server unit, and determining whether the connection with the client is correct or not. system. Generating means for generating a client machine identifier by combining the server identifier and the client identifier;
Storage means for storing the machine identifier;
A service means for connecting to a server using the machine identifier. A server identifier and a client identifier are combined to generate a machine identifier,
Decomposing the machine identifier sent from the client to the server into a server part and a client part,
A service method comprising: checking a server identifier described in the server unit to determine whether a connection with the client is correct. A recording medium recording a program for a computer,
A function of receiving a machine identifier generated by combining a server identifier and a client identifier from a client,
A program for realizing the function of decomposing the machine identifier into a server part and a client part, checking the server identifier described in the server part, and determining whether the connection with the client is correct is realized by the computer. A computer-readable recording medium on which is recorded. A recording medium recording a program for a computer,
A function of combining the server identifier and the client identifier to generate a machine identifier of the client;
A function of storing the machine identifier;
A computer-readable recording medium recording a program for causing the computer to realize a function of connecting to a server using the machine identifier.

Images