JP4265378B2 - Server device for online registration procedure - Google Patents

Description

  The present invention relates to a server device capable of providing a service limited to only a previously registered user via a communication network. More particularly, the present invention relates to a server device for an online registration procedure in which when a user registration is performed using electronic mail, a return destination after the user registration can be navigated for each user.

Recently, with the development of wired or wireless communication networks represented by the Internet and the spread of high-speed communication environments (ADSL, FTTH, CATV, etc., so-called broadband) in general homes, online services via communication networks are provided. It is being done. According to this, the user can receive a service freely at any time while staying at home using a personal computer or the like installed at home. As the online service, there is known an online service that provides a limited service only to a user who has been registered in advance, and a user who wants to receive such a limited online service provides a predetermined screen (also called a page) in advance. User registration is required. Conventionally, the user registration (or change of registration contents) that a user should perform to receive limited services is a single use on the WWW (World Wide Web) site in the server that provides the online service. From the online user registration screen for user registration. In addition, when registering a user, the user is temporarily registered by inputting predetermined registration information including an e-mail address on the registration screen on the WWW site, and the user is temporarily registered. Sending an e-mail describing the content that prompts access to the unique confirmation URL (Uniform Resource Locator), and confirming the identity and registration by accessing the confirmation URL by the user. Has been. Here, the URL is a description method indicating the location of resources (such as various files) existing on the Internet. For example, the URL “http://hoo.bar/script.php?param=value” is the HTTP (HyperText Transfer Protocol) communication protocol, and the document root on the server specified by “hoo.bar” This means that the parameter “param” whose value is “value” is passed to the existing resource “script.php”.
In this specification, the limited service provided only to users who have been registered in advance is not limited to a paid service that collects expenses from the user. For example, the display arrangement of online services differs for each user. It also includes free services that do not collect costs from users, such as providing customized (customized) screens or simply displaying registered user names or user IDs.
Japanese Patent Laid-Open No. 2001-209720

  As described above, as a user registration procedure to be performed by a user in order to newly receive an online service limited to only registered users, a confirmation operation by a user using an e-mail is conventionally performed. Is needed from. According to this procedure, the user needs to access the confirmation URL by looking at the contents of the e-mail sent from the service providing server. Must be interrupted (i.e. session expires). In addition, the Web screen (for example, registration completion screen) corresponding to the confirmation URL displayed when accessing the confirmation URL notified by e-mail and other screens (for example, each Web screen that provides each service) )), There are many cases in which the first screen on the WWW site or an online registration screen for user registration is set as a hyperlink destination on the displayed Web screen. Therefore, after browsing the web screen corresponding to the confirmation URL, the user must always return to the top screen of the WWW site or the registration screen, and the web screen that has been suspended or the service that has been suspended There was a problem that it took time and effort to search again the Web screen that was used and the Web screen that provided the service.

  The present invention has been made in view of the above points, and after a user who has registered as a user accesses the confirmation URL notified by e-mail and performs identity verification or registration confirmation work, the user can In order to reduce the trouble of searching for the web screen that the user originally used and the web screen that provides the service without getting lost, depending on the route until each user arrives at the online registration screen An object of the present invention is to provide a server device that can navigate the return destination after user registration for each user.

The server device according to claim 1 of the present invention prompts a user client to input registration information in a server device that can provide a predetermined service limited to registered users only via a communication network. Means for providing one or more content pages, means for receiving user registration information including an e-mail address of a new user from the user client, and means for generating a unique session ID for the received user registration information And a URL based on the content page or service on which the new user has entered user registration information, and the user was browsing before receiving the content page that prompts the user to enter the registration information Means for specifying a return URL indicating the page, and the session ID and the return URL. Means for storing, means for notifying a confirmation URL including information indicating the session ID to an e-mail address included in the user registration information, and in response to access to the confirmation URL, the session Means for confirming user registration based on the received user registration information corresponding to an ID and performing navigation to a return URL associated with the session ID based on the stored content.

According to the present invention, it receives the user registration information including the e-mail address of the new user from the user client Then, generates a unique session ID to the user registration information thus received. This session ID is stored the new user and return URL that is specified based on the content page or service was input user registration information associated Dzu only by. A confirmation URL including information indicating the generated session ID is notified to the e-mail address included in the user registration information. In this way, when the more the notified access to verification URL is made to the user, in addition to determining the user registration based on the received user registration information, return destination URL associated with the session ID Based on the above, navigation is performed to the URL related to the original page (the page before the transition to the content page) from which the user requested user registration to receive the service . In other words, the service user session out to the original page that due to the fact that perform user registration determined work and access to Make認用URL even when that occurred, which is always an individual user after user registration confirmed and registration procedures Since navigation is performed using the related original page or service as a return destination , it is possible to easily provide continuity to the browsing of the site and the service provided by the user client .

A server device according to claim 2 of the present invention prompts a user client to input registration information in a server device that can provide a predetermined service limited to registered users only via a communication network. Means for providing one or more content pages; means for receiving user registration information relating to a change or confirmation of registration contents of an existing user who has previously registered a user including registration of an e-mail address; means for generating a unique session ID to the user registration information to the received, the existing user a based rather URL to the content page or service performs an input of the user registration information, the user is the identify the return URL that shows the original page you were viewing prior to receiving the provision of content page to promote the registration information input Means for associating and storing the session ID and the return URL, means for notifying the confirmation URL including information indicating the session ID to the previously registered e-mail address, In response to access to the confirmation URL, confirmation or change of registration contents based on the received user registration information corresponding to the session ID is confirmed, and navigation to a return URL associated with the session ID is performed. Means for performing. According to this, even for an existing user who has input user registration information related to change or confirmation of registration contents from one or more content pages that prompts input of registration information, the specified return destination URL associated with the session ID Based on the above, it becomes possible to navigate to the original page (the page before the transition to the content page) from which the user requested user registration to receive the service.

  The present invention can be constructed and implemented not only as a device invention but also as a method invention. Further, the present invention can be implemented in the form of a program of a processor such as a computer or a DSP, or can be implemented in the form of a storage medium storing such a program.

  According to this invention, a unique session ID is generated in response to acceptance of user registration information, and the session ID is included in the confirmation URL and notified to the user by e-mail. The return URL is associated with the session ID. This allows navigation to the return URL associated with the session ID even if the session has expired when the user who performed the registration access accesses the confirmation URL and performs identity verification or registration confirmation. Is possible. In particular, by specifying the return URL to the original page or a page located in the upper hierarchy, the user who accessed the confirmation URL can be redirected to the Web screen that was displayed when the Web browsing was interrupted or when the service usage was interrupted. You can navigate. This not only prevents the user from getting lost on the WWW site, but also saves the user from searching for the Web screen that the user originally used or the Web screen on the WWW site that provides the desired service. There is an effect that it can be reduced.

  Embodiments of the present invention will be described below in detail with reference to the accompanying drawings.

FIG. 1 is a system block diagram showing an embodiment of the overall configuration of an online service system to which a server device according to the present invention is applied. The online service system shown in this embodiment is a system that provides various services via a communication network, and includes a user client PC such as a personal computer terminal or a mobile communication terminal (for example, a mobile phone or a PDA) on the service receiving side. The server MS is a service providing side and a communication network X such as the Internet. As will be described in detail later, each device (the client PC and the server MS) constituting the online service system is composed of independent computers each including a CPU, a ROM, a RAM, a communication interface, etc. The apparatuses can transmit and receive various types of information between the apparatuses via a wired or wireless communication network X using the Internet or a dedicated line. As an example of the service content that can be provided by such an online service system, for example, according to the performance practice process of the musical instrument according to the proficiency level of each user for each user, the music data of the practice music is provided, the luck when playing the practice music Teaching service that teaches performance lessons of musical instruments and performance equipment by displaying performance techniques such as fingers and dynamics on the screen as a video, or displaying musical guidance (advice) for users on the screen. So-called e-learning service).
Such an online service system may have hardware other than that shown in FIG. 1. Here, a case where the minimum necessary resources are used will be described. The server MS or the client PC may be constituted by a plurality of devices. In such a case, a server MS or a client PC is formed by connecting these devices to each other via the communication network X. Needless to say, it can be used.

The client PC accepts designation of a URL (abbreviation of Uniform Resource Locator) according to the user operation, accesses the URL, and sequentially receives responses such as page description information issued in response to the URL from the server MS. In addition to the process of presenting a Web screen based on the received page description information, the apparatus performs transmission / reception or display processing of electronic mail. Since the presentation of the Web screen based on the page description information received from the server MS is a well-known technique, the description is omitted here.
On the other hand, the server MS is a device that provides services and performs user registration procedures. In addition to various processes related to user registration procedures (see FIGS. 6 and 7 to be described later), various processes as a normal HTTP server are performed. E-mail transmission / reception processing is appropriately executed. This server MS is a database (DB) that stores page description information (see FIG. 4 for details) of a large number of Web screens constituting the WWW site for each of a plurality of WWW sites that provide different services, and various information related to registered users. Stored in Y, and corresponding page description information is read out from the database Y and returned to the client PC in response to an access request (for example, designation of a URL) from a client PC connected via the communication network X, or Various information related to the registered user is updated based on the registration information from the client PC. Transmission / reception of various information, e-mail, and the like between the client PC and the server MS is performed using a predetermined software program such as an Internet browser and mail software.

  In this specification, “page description information” that is the basis of the Web screen transmitted from the server MS to the client PC is described by a program such as HTML (abbreviation of Hyper Text Markup Language). In addition to the main HTML source program, it may include resource data that can be transmitted and presented based on the so-called HTTP, such as images, sounds, movies, scripts, and cookies inserted or executed in the source. . That is, the page description information may include non-display information (such as the script and various parameter information) in addition to the information displayed or reproduced on the client PC. Furthermore, a unique “URL ID” is assigned to at least the HTML source program, and is registered and managed in a URL table (described later) in the database Y.

  Note that the device used as a client PC that can be connected to the online service system via the communication network X is not limited to the personal computer terminal or the portable communication terminal as described above, but is connected to the server MS via the communication network X. Any device may be used as long as it can transmit and receive various types of information. That is, it may be an automatic performance device such as karaoke or an automatic performance piano, or may be a game machine or an electronic musical instrument. Needless to say, a plurality of client PCs, servers MS, and the like may be connected to the online service system via the communication network X.

  Next, an example of the hardware configuration of either the client PC or the server MS shown in FIG. 1 will be briefly described with reference to FIG. FIG. 2 is a block diagram of a hardware configuration showing an embodiment of the overall configuration of any one of the above devices. However, since each of the above devices can be described as using a similar hardware configuration, only one block diagram of the server MS will be described as a representative.

  The server MS shown in this embodiment is controlled by a microcomputer including a microprocessor unit (CPU) 1, a read only memory (ROM) 2, and a random access memory (RAM) 3. The CPU 1 controls the operation of the entire server MS. A read only memory (ROM) 2, a random access memory (RAM) 3, an output device 4, an input device 5, and a communication device 6 are connected to the CPU 1 via a data and address bus 1D. The ROM 2 stores various programs executed by or referred to by the CPU 1, various data, and the like. The RAM 3 is a working memory that temporarily stores various information transmitted from the client PC or various data generated when the CPU 1 executes a predetermined program, or a currently executing program and data related thereto. Is used as a memory for storing. A predetermined address area of the RAM 3 is assigned to each function and used as a register, flag, table, memory, or the like. The output device 4 is a Web screen to be presented to the client PC, such as “Service screen 1”, “Registration screen”, “Temporary registration notification” screen, “Registration completion notification” screen (see FIG. 5), and each of these Web screens. For example, an output device such as a liquid crystal display panel (LCD) or a display such as a CRT is used to display page description information that is the basis of the display. The input device 5 is an input device such as a character data input keyboard and numeric data input numeric keypad used for generating the page description information, or a pointing device such as a mouse for operating a pointer displayed on the display. is there.

  The communication device 6 is connected to a communication network X such as a LAN, the Internet, or a telephone line, and is connected to a predetermined client PC or the like via the communication network X. This is a communication interface for receiving registration information, e-mail, and the like from the client PC, which transmits page description information that is the basis of the above, an application program that executes various processes, or e-mail. Such a communication device 6 is not limited to a wired device but may be a wireless device, or may include both. Further, as the communication device 6, MIDI standard musical tone information (that is, MIDI data) is input to the server MS from an external MIDI device or the like, or MIDI standard musical tone information (MIDI data) is externally input from the server MS. It may have a MIDI interface for output to MIDI devices.

An external storage device such as a hard disk for storing various information related to the registered user received from the client PC, page description information as a basis of the Web screen, various applications and programs executed by the CPU 1, and the like may be provided. . Of course, not only hard disks (HD) but also removable external storage media such as floppy disk (FD), compact disk (CD), magneto-optical disk (MO), DVD (abbreviation of Digital Versatile Disk), etc. A storage device may be used. Alternatively, a semiconductor memory or the like may be used.
The client PC and the server MS are not limited to those in which the output device 4 and the input device 5 are built in one apparatus main body, but are configured separately, and connect the respective apparatuses using a predetermined interface. Needless to say, the present invention can be similarly applied to the configured one.

  Here, the database Y included in the server MS will be described with reference to FIG. FIG. 3 is a conceptual diagram showing an embodiment of the data structure of the database Y. The database shown here includes, for example, table data of a session ID table, a session management table, a customer master table, and a URL table.

  The session ID table is a table for checking the uniqueness of the session ID, and includes, for example, a hash table. In this session ID table, session IDs generated from the past to the present are accumulated. The session management table is a table for holding various information related to the session ID (referred to as session information). In addition to the session ID that becomes the KEY, one table record contains the user ID, effective date, temporary A field (storage area) for storing registration data, return URL_ID, and the like is included. The “session ID” is a session ID generated at the time of user registration (details will be described later). “User ID” is the user ID of the customer who performed the session of this record, and “Effective Date” is the time limit for effectively handling the session information set at the time of registering the session information. “Temporary registration data” is registration content input by the user transmitted to the server MS using a predetermined registration form or the like, and is temporarily held in a corresponding field. “URL_ID” is return URL information to which the user is navigated after the registration confirmation operation. The customer master table is a table that holds various customer information, and one table record includes fields for storing an e-mail address, other information, a session ID, etc. in addition to a user ID as a KEY. The “user ID” is an identification ID unique to each user, and a unique ID automatically issued on the server MS side for each user at the time of initial user registration is given. “Mail address” is an email address registered by each user. “Other information” is so-called customer information such as personal information such as the name and address of each user, service contents during use registration, and service use history. “Session ID” is the session ID last acquired by each user, and is always updated to the latest one.

  The URL table is a table in which unique IDs and URLs are individually assigned to resources (resources such as page description language described in units of pages by HTML etc.) that can be provided by the server MS. It includes fields such as “URL ID” that stores the resource-specific ID and KEY, and “URL” that stores the URL assigned to each resource. That is, a large number of Web screens constituting each WWW site stored in the server MS are described by page description information such as HTML, and each page description information is assigned a unique ID, and a predetermined character string It is referred from the client PC by the URL indicating the Internet address composed of information. The URL table is a table for managing IDs of URLs that can be provided by the server MS.

  The Web screen corresponding to the URL managed by the URL table, that is, the configuration of the WWW site provided by the server MS has a hierarchical directory structure as shown in FIG. In FIG. 4, the web screen indicated by the top-level URL “http://hoo.bar/” is a top screen such as a home page showing an overview of the entire service. An overview service top screen is located (such as /svc1/index.html or /svc2/index.html). Each of these service top screens includes a number of “service screen 1” and “service screen 2” which are web screens for providing services (/svc1/page1.html, /svc1/page2.html, etc.). . Furthermore, it may be configured to include a plurality of sub-screens below each “service screen” (/svc2/sub/page1.html, /svc2/sub/page2.html, etc.). In this embodiment, the "registration screen" for user registration is the web screen for each service such as "/svc1/register.html" or "/svc2/sub/register.html". It is arranged at the lowest position or at the same position as the “service screen” (/svc2/page1.html, /svc2/page2.html, etc.) such as “/svc2/register.html”.

  In addition, when user registration is performed from each of the above “registration screens”, the “temporary registration completion notification” screen (see FIG. 5) displayed next is prepared in common for each service. Has been (/script/register.php). That is, as shown by the dashed line in the figure, when “/script/register.php” is executed according to the registration execution operation from the “registration screen” prepared for each service, it is prepared for each service. The display is shifted from the “registration screen” to the common “temporary registration completion notification” screen. At this time, an e-mail describing a predetermined URL (/script/confirm.php) is sent to the client PC. In other words, “/script/register.php” is composed of a script program that executes registration confirmation processing (in this case, it is a script language known as HTML Processer. Of course, perl, compiled applications, etc.) Or any other executable CGI application). When the registration information input from the “registration screen” is transferred to the “register.php”, the registration information reception process (see FIG. 6) is executed, and the display shifts to the “temporary registration completion notification” screen. Send an email with. The "registration completion notification" (see Fig. 5) that is displayed when the URL (/script/confirm.php) described in the sent e-mail is clicked by the user is also commonly used by each service Is prepared, and when the “/script/confirm.php” is executed, the display shifts to the “registration completion notification” screen. In other words, this “/script/confirm.php” consists of a script program that executes the registration confirmation process. When the session ID is passed to this “confirm.php”, the confirmation URL access process (see FIG. 7) is performed. When executed, the display shifts to the “registration completion notification” screen and the user is fully registered.

  In order for a user to receive an online service via the communication network X, a user accesses the predetermined WWW site corresponding to the service launched by the server MS that provides the online service, and registers the user of the service. It is necessary to do. Therefore, a user registration procedure for such an online service will be briefly described with reference to a Web screen and an e-mail display example that the server MS presents to the client PC. FIG. 5 is a conceptual diagram for explaining a user registration procedure. However, the description will be made according to the WWW site configuration shown in FIG.

  First, when a user selects a desired service from a service top screen (not shown), a “service screen 1” (http://hoo.bar/svc1/page1.html) is displayed as a screen for introducing the contents of the selected service. ) First. For example, in an online service providing musical instrument lessons, if there are multiple lesson courses for each instrument, the user selects a desired lesson course on the service top screen for each lesson course. A dedicated service screen 1 is presented. This service screen 1 introduces the contents of services to be provided, such as an introduction of an outline of a rough lesson (content) to be performed in the lesson course and an introduction of teaching materials used in the lesson. Of course, contents other than those described above may be displayed.

  Next, when the “register” button A displayed at the lower right of the service screen 1 is clicked, a “registration screen” (http://hoo.bar/svc1/register.html) is presented. This “registration screen” is a screen presented to prompt the user to input registration information. For example, the minimum input form and input contents when applying for a certain service are shown in the figure. In this way, it is configured to prompt the input of “email address” and “password”. In addition, the user may be prompted to input personal information such as a nickname given to the user or an address name on the screen. Since the contents of the registration information or the display mode of the registration screen are appropriately configured according to the site policy, the detailed description thereof will be omitted. When the user clicks the “Send” button B displayed in the lower right of the registration screen, the CGI application (http://hoo.bar/script/register.php) is launched and entered from the registration screen. Registration information is transmitted to the server MS. It is assumed that an existing user who has already registered has performed a login procedure in advance, and information indicating that the user has already logged in is held as a cookie on the client PC.

  The registration screen also includes a “return URL” that should be navigated when the user who sent the registration information from the registration screen accesses the “confirmation URL” notified by an e-mail (confirmation email) described later. "URL_ID" corresponding to is included in the page description information as a hidden parameter (indicated in the registration screen by enclosing the hidden part with a dotted line). URL_ID "is transmitted to the server MS. Furthermore, the user ID, which is user identification information, is transmitted together with the registration information and “URL_ID” (however, if the user is a new user or an unlogged user, the user ID is unconfirmed, so the parameter corresponding to the user ID The value is sent as null).

  When the “send” button B is clicked on the registration screen, a “temporary registration completion notification” screen and an e-mail are presented. Here, session disconnection occurs once. The “tentative registration completion notification” screen and the e-mail include information notifying that the input registration information has been temporarily registered in the server MS, and content prompting the user to perform an operation necessary for the main registration of the registration information. Present. The operation necessary for this registration is an operation for accessing the confirmation URL (http://hoo.bar/script/confirm.php?key=e7fecb37a9) described in the e-mail. The confirmation URL described in the electronic mail appropriately includes parameter information passed to the resource in addition to the resource allocation information. In the example shown in the figure, the allocation information is before the "?" (That is, the host name and path indicated by http://hoo.bar/script/confirm.php), and the following (key = e7fecb37a9) is the parameter. Information.

  When the confirmation URL described in the e-mail is clicked, a “registration completion notification” screen is displayed to notify that the user registration is completed. A “confirmation” button C on this “registration completion notification” screen (of course, it may be set to text instead of a button) indicates a hyperlink indicating the “return destination URL” associated with the session ID. When the user presses the confirmation button C, page description information corresponding to an appropriate URL is transmitted from the server MS and presented to the client PC. Here, an example of returning to the “service screen 1” as a return destination is shown. From the returned “service screen 1”, by clicking the “start” button D, the display is shifted to a login screen (not shown) or an appropriate service main body screen.

  In order for a user to receive an online service via the communication network X, it is necessary to perform user registration according to the user registration procedure as described above. A server process for realizing user registration according to the user registration procedure will be described with reference to FIGS. In the following, when the confirmation URL described in the e-mail is clicked using FIG. 6 with respect to the “registration information reception process” executed when the transmission button B of the “registration screen” (see FIG. 5) is clicked. The “confirmation URL process” to be executed will be described with reference to FIG. FIG. 6 is a flowchart illustrating an example of the “registration information reception process”. FIG. 7 is a flowchart showing an example of the “confirmation URL process”. Each of these processes is a resident program that is resident while the server MS is in operation and is always in a predetermined standby state, or a program that is called and executed as necessary from other resident programs such as a WWW server program. Are executed in response to a request or a command transmitted to the server MS when the corresponding operation is performed by the user.

First, the operation of the registration information reception process executed when the transmission button B on the “registration screen” is clicked will be described according to the flowchart shown in FIG. When the send button B is clicked, the registration information is transferred to register.php, and the registration information reception process is executed.
In step S1, registration information is received from a client PC connected via the communication network X. This registration information is an e-mail address or password entered by the user using the “registration screen”, and is data transmitted in response to a click on the send button B on the “registration screen”. When receiving the registration information from the client PC, the server MS in the registration information reception standby state determines whether or not there is an error (error) in the received registration information (step S2). If there is an error in the registered information, for example, if there is an input omission in a mandatory input item (“Yes” in step S2), an error response that prompts re-input of the information in which the error has occurred is sent to the client PC. Return (step S3). If there is no error in the registration information ("None" in step S2), the user who entered the registration information is an unregistered "new" user or an already registered user. It is determined whether or not there is (step S4). The determination as to whether or not the user is a new user is performed when the user ID in the received registration information is null and there is no user registered with the same e-mail address in the customer master table. It is determined that the user is a user. If the user is a new user (“new” in step S4), a unique user ID is newly issued and a record is added, that is, registered in the database (step S5). If the user has already been registered ("registered" in step S4), the user ID already issued to the user is specified (step S6). At this time, whether or not the record corresponding to the user ID in the registration information exists in the database, that is, whether or not the user ID included in the registration information is legitimate is also checked. If the user is not a user, an error response may be returned to the client PC as in step S3, and the process may be shifted to the subsequent step S7 only when the user is a legitimate user. In step S7, date and time information is acquired. In step S8, a session ID is generated based on the newly issued user ID or the specified existing user ID and the acquired date and time information. That is, if there is no error in the received registration information, time information (typically a long integer value) regarding the date and time when the registration information was received is acquired, and a session ID is generated based on the user ID and the date and time information.

Here, an example of a procedure for generating a session ID will be briefly described.
First, the user ID and the character string representation of date / time information are combined. For example, if there was an access at 1:00:00 on January 1, 2003, date / time information 1041346800000 (milliseconds) starting from 1970/1/1 0: 0: 0: 0 is acquired. . If the user ID is “poo”, a character string in which the user ID and date / time information are combined is generated as “poo + 1041346800000-> poo1041346800000”. Next, the combined character string is encrypted to obtain a session ID unique to the user registration session having an appropriate length. The encryption algorithm used at this time may be any algorithm as long as it is a one-way function. However, the encryption algorithm satisfies at least the following two conditions: it is mathematically difficult to specify the source character string from the operation result, and the possibility of generating the same result from different sources is extremely low. It is desirable to be. As a result of encrypting the combined character string, for example, a character string “e7fecb37a9” is acquired. This acquired character string is the generated session ID. In this way, a session ID is generated.

  It is desirable that the character string used as the session ID is as short as possible. In other words, when a confirmation URL is described in an e-mail, if the session ID is too long, it may not be possible to display the confirmation URL in one line on the e-mail display by the mail software. . In such a case, depending on the mail software, a line feed character string may be inserted in the line wrapping, and the user may not be able to correctly refer to the confirmation URL. On the other hand, if the character string is too short, the uniqueness is easily lost. Therefore, it is desirable to generate the session ID with a character string of about 10 characters as described above.

Returning to the description of the flowchart shown in FIG. 6, in step S9, it is determined whether the generated session ID is unique, that is, the uniqueness of the session ID is verified. That is, even if the encryption algorithm satisfies the above two conditions, there is no possibility that the same session ID will be generated stochastically. Therefore, in order to avoid duplication of session IDs, all session IDs generated previously are registered in the session ID table (see FIG. 3), and whether or not a session ID having the same value as the session ID generated this time exists. Inspect. If the session IDs are duplicated (“duplication” in step S9), the session ID is obtained again and reacquired (step S10). When the unique session ID is obtained in this way, the URL_ID transmitted together with the registration information is acquired, an expiration date is set, and a record is added to the session management table together with other information (step S11). That is, when a unique session ID is obtained, a new record with the session ID as a key is added to the session management table. In the “user ID” field, a user ID already specified is copied. In the “effective date” field, date and time information set after a predetermined time (for example, after 7 days) starting from the date and time when the session ID is generated is inserted. In the “temporary registration data” field, the registration information received from the user client is copied together. The “return destination URL_ID” field stores the URL_ID (return destination URL) transmitted as part of the registration information. In addition, the latest session ID is described in the “session ID” field of the customer management master.
In this embodiment, valid registration sessions are limited to the latest one. This is to prevent duplicate input due to user error.

  In step S12, the user's e-mail address is acquired, and an e-mail describing a confirmation URL with the session ID added to the parameter is transmitted to the user. That is, an e-mail describing a confirmation URL such as http: ///hoo.bar/script/confirm.php? Key = e7fecb37a9 is transmitted to the user's e-mail address. After performing the above processing, for example, an acceptance response such as “provisional registration completion notification” shown in FIG. 5 is transmitted to the client PC (step S13).

Next, the operation of the confirmation URL process executed when the confirmation URL described in the e-mail is clicked will be described with reference to the flowchart shown in FIG. When the confirmation URL is clicked, the session ID is passed to confirm.php, and the confirmation URL access process is executed.
In step S21, the access of the confirmation URL from the client PC connected via the communication network X is accepted. In step S22, the session ID is specified and the corresponding record is read from the session management table. At this time, it is also checked whether or not the record corresponding to the passed session ID exists in the database, that is, whether or not the session ID is genuine. If it is not a regular session ID, An error response may be returned to the client PC in the same manner as in step S25 described later, and the process may be shifted to the subsequent step S23 only when the session ID is a regular session ID. In step S23, the user ID is specified and the corresponding record is read from the customer master table. In step S24, it is determined whether or not the session ID corresponds. If they do not match, an error response is issued (step S25). In other words, confirm the match between the last session ID held in the customer management master table and the session ID handed over this time. If it does not match, confirm that the access is invalid, or confirm or register the session ID. An error response that prompts reworking is sent to the client PC. In step S26, it is determined whether or not there is a corresponding record. If it does not exist, an error response is issued (step S27). In step S28, it is determined whether or not the expiration date has been exceeded. If it has exceeded, an error response that prompts re-registration is generated (step S29). If it is within the expiration date (“not exceeded” in step S28), the registration information stored in the session management table (that is, the contents of the temporary registration data) is applied to the customer management master table as appropriate, and the customer management information Is updated to the latest state (step S30). That is, temporary registration is assumed to be main registration. In step S31, a response page (for example, registration completion notification) including navigation to the URL corresponding to the return URL_ID is generated. After this, the session ID record may be deleted from the session management table. In step S32, an update response is returned to the user client. In this way, when the update of the customer management master table is completed, an update response such as the “registration completion notification” is transmitted to the client PC.

  Each process described above is implemented by the CPU 1 in each device executing a predetermined program (software). Of course, the present invention can be implemented not only in the form of computer software but also in the form of a microprogram processed by a DSP (digital signal processor), and is not limited to this form of program, but is also a discrete circuit or an integrated circuit. Alternatively, it may be implemented in the form of a dedicated hardware device configured to include a large-scale integrated circuit or a gate array.

  In the embodiment described above, as shown in FIG. 5, the ID of the return destination (return destination URL_ID) is described in the page description information on the registration screen, and the return destination URL_ID is acquired together with the registration information (FIG. 6). In this way, the confirmation URL described in the e-mail sent to the user is determined, but the present invention is not limited to this. For example, as shown in FIG. 8A, a “return destination URL_ID” field is defined in the URL table, the ID of the URL to be returned is described there, and as shown in FIG. 8B. The confirmation URL described in the e-mail can also be determined by describing the URL_ID of the registration screen itself in the page description information of the registration screen. Briefly, the process from step S1 to step S9 of the “registration information reception process” shown in FIG. 6 is first executed to generate a session ID. Next, the following process is executed instead of the process of step S11 of FIG. That is, since the URL_ID of the registration screen itself is described in the page description information of the registration screen, the URL_ID of the registration screen itself transmitted from the client PC together with the registration information is acquired. Refers to the URL table shown in Fig. 8 (a) using the URL_ID of the received registration screen as a key, acquires the ID defined in the "return URL_ID" field of the corresponding URL table, and stores it in the session management table Keep it. Then, the process returns to step S12 in FIG. Since the following processes are the same, description is abbreviate | omitted. According to this configuration, in order to change the return URL, it is only necessary to rewrite the definition of the “return URL_ID” field of the URL table. Therefore, it is advantageous in that it is possible to efficiently perform the site construction work when it is necessary to change the return URL such as when changing the configuration of the WWW site.

  In the above-described embodiment, the “registration screen” is arranged for each service (see FIG. 4). However, as shown in FIG. Prepare one "registration screen" (/script/input.php) and determine the confirmation URL to be written in the email sent to the user by adopting the following mode It may be. In this case, as shown in FIG. 9B, each service screen is displayed together with a display element that requests a response of a common “registration screen” such as a “apply” button (or may be a “registration” button) for each service screen. Is defined in the page description information. Therefore, the service ID of the service is transmitted as a parameter to the server MS together with a request for requesting a response of the “registration screen”. As page description information corresponding to the response of the “registration screen”, page description information corresponding to each service is dynamically generated in the server MS according to the service ID. In addition to the tables described above, the database on the server MS includes a table defining the service ID and the return URL, and the return URL corresponding to the received service ID is stored in the session management table. Store. Then, using this, the confirmation URL to be described in the e-mail sent to the user is determined. However, since this process has already been described, the description thereof will be omitted.

  The session ID may be generated by, for example, an algorithm using a random number, a message digest algorithm known by RFC1321 (MD5), or the like. When using random numbers, for example, an appropriate random number sequence is initialized using the above access time (milliseconds) as a seed, and the random number value obtained as appropriate is divided by an appropriate value (for example, 16) to obtain the required number of characters. Then, this is used as the session ID. If the session IDs adopted in this way overlap, the seeds may be changed or random numbers may be acquired from the same random number sequence until different session IDs are obtained. When MD5 is used, a message digest for 32 characters can be obtained from the combined character string. This message digest (or part of this 10 characters) is used as the session ID. If the session ID adopted in this way is duplicated, the message string can be regenerated by changing the source combined character string (changing the date / time information corresponding part to the current time, adding a non-numeric character at the end, etc.) . When a part of the message digest is used for the session ID, 10 different characters out of 32 characters may be reacquired as the session ID.

The user may be able to input, confirm, or register the registration information not only from the “registration screen” (register.html) but also from the “registration completion notification” (confirm.php).
Although the URL including the session ID is notified to the user by e-mail as a confirmation URL, only the session ID is notified to the user, and an appropriate screen (preferably registration screen or registration completion notification) is sent. It is also possible to prepare a form for entering the session ID in, and pass the session ID as a parameter from the form to “confirm.php”. Whether to notify the user in any of the above modes may be determined based on the e-mail address registered by the user (for example, if the e-mail address is clear that the mobile phone is a platform) Notification may be made in this written form, and notification may be made in the above embodiment in other cases).

It is a system block diagram which shows one Example of the whole structure of the online service system to which the server apparatus based on this invention is applied. FIG. 2 is a hardware configuration block diagram illustrating an example of the overall configuration of any one of the client and the server illustrated in FIG. 1. It is a conceptual diagram which shows one Example of the data structure of the database which the server comprises. It is a conceptual diagram which shows one Embodiment of a structure of the WWW site which a server provides. It is a conceptual diagram for demonstrating a user registration procedure. It is a flowchart which shows one Example of a registration information reception process. It is a flowchart which shows one Example of confirmation URL process. It is a conceptual diagram for demonstrating another example of a setting of return destination URL, Fig.8 (a) is a data structure of a URL table, FIG.8 (b) is one Example of a registration screen. FIGS. 9A and 9B are conceptual diagrams for explaining an example of setting a return URL when a common “registration screen” is prepared on a WWW site, FIG. 9A is a WWW site configuration, FIG. 9B is a service screen, and FIG. It is one Example of a registration screen.

Explanation of symbols

1 ... CPU, 2 ... ROM, 3 ... RAM, 4 ... output device, 5 ... input device, 6 ... communication device, X ... communication network, 1D ... data and address bus, PC ... client, MS ... server

Claims (3)

In a server device capable of providing a predetermined service limited to registered users only via a communication network,
Means for providing one or more content pages that prompt the user client to enter registration information;
Means for receiving from the user client user registration information including an email address of the new user;
Means for generating a unique session ID for the received user registration information;
URL based on the content page or service on which the new user has entered user registration information, and the original page that the user was browsing before receiving the content page prompting the user to enter the registration information Means for specifying a return URL indicating
Means for associating and storing the session ID and the return URL;
Means for notifying a confirmation URL including information indicating the session ID to an e-mail address included in the user registration information;
In response to access to the confirmation URL, user registration based on the received user registration information corresponding to the session ID is confirmed, and a return destination URL associated with the session ID is based on the stored content. The server apparatus provided with the means to perform navigation. In a server device capable of providing a predetermined service limited to registered users only via a communication network,
Means for providing one or more content pages that prompt the user client to enter registration information;
Means for receiving, from a user client, user registration information related to a change or confirmation of registration contents of an existing user who has previously performed user registration including registration of an e-mail address;
Means for generating a unique session ID for the received user registration information;
The existing user is a based rather than URL to the content page or service performs an input of the user registration information, based on which the user was viewing before receiving the offer of content page to promote the registration information input Means for specifying a return URL indicating the page of
Means for associating and storing the session ID and the return URL;
Means for notifying the previously registered e-mail address of a confirmation URL including information indicating the session ID;
In response to access to the confirmation URL, confirmation or change of registration contents based on the received user registration information corresponding to the session ID is confirmed, and navigation to a return URL associated with the session ID is performed. And a server device. In each content page, a service ID indicating a service corresponding to the content page is described.
The user registration information includes the service ID,
The server apparatus according to claim 1 or 2, wherein the return URL specifies a return URL corresponding to a service ID included in the received user registration information.

Images