WO2017134922A1 - サービス提供システム、認証装置、及びプログラム - Google Patents

サービス提供システム、認証装置、及びプログラム Download PDF

Info

Publication number
WO2017134922A1
WO2017134922A1 PCT/JP2016/086189 JP2016086189W WO2017134922A1 WO 2017134922 A1 WO2017134922 A1 WO 2017134922A1 JP 2016086189 W JP2016086189 W JP 2016086189W WO 2017134922 A1 WO2017134922 A1 WO 2017134922A1
Authority
WO
WIPO (PCT)
Prior art keywords
authentication
user
key
secret key
telephone
Prior art date
Application number
PCT/JP2016/086189
Other languages
English (en)
French (fr)
Inventor
昇 菱沼
博 豊泉
東　陽一
Original Assignee
昇 菱沼
Ａ・Ｔコミュニケーションズ株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 昇 菱沼, Ａ・Ｔコミュニケーションズ株式会社 filed Critical 昇 菱沼
Priority to JP2017505260A priority Critical patent/JP6115884B1/ja
Publication of WO2017134922A1 publication Critical patent/WO2017134922A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/42—User authentication using separate channels for security data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M11/00—Telephonic communication systems specially adapted for combination with other electrical systems

Definitions

  • the present invention relates to a service providing system, an authentication device, and a program.
  • Patent Document 1 describes an invention in which such a service can be used more safely by transmitting a calling number from a mobile phone to the system side.
  • the present invention has been made in view of the above circumstances, and an object of the present invention is to provide a service providing system and the like that can ensure high security when using a service and do not require a user's trouble.
  • a service providing system includes: A login request receiver for receiving a service login request from a user terminal operated by the user; A key authenticating unit that authenticates the user based on the acquired secret key and a pre-stored secret key when the secret key for authentication can be acquired from the user terminal; When the private key cannot be acquired from the user terminal, or when the key authentication unit fails to authenticate, a telephone authentication unit that performs authentication of the user based on an incoming call from a mobile terminal associated with the user When, A service providing unit that executes processing for providing the service to a user terminal that is a transmission source of a login request when authentication is successful in the key authentication unit or the telephone authentication unit; Is provided.
  • a secret key for authenticating the user is newly created and held in the service providing system, and the created secret key is stored in the user terminal. You may provide the private key transmission part to transmit.
  • the telephone authentication unit may perform authentication when receiving a telephone authentication request from the user terminal after receiving an incoming telephone call from the portable terminal.
  • the telephone authentication unit may not authenticate the user if the telephone authentication request is not received within a predetermined waiting time after receiving the incoming call from the mobile terminal.
  • the telephone authentication unit Notifying the user terminal of a connection number selected from a plurality of local phone numbers, If the destination telephone number of incoming calls from the mobile terminal does not match the notified connection number, the user need not be authenticated.
  • the telephone authentication unit obtains the device identification information of the mobile terminal from the user terminal, and if it matches the corresponding device identification information stored in advance, performs authentication of the user based on the incoming call, If not, the user need not be authenticated.
  • a service providing system provides: A login request receiver for receiving a service login request from a mobile terminal operated by the user; A key authenticating unit that authenticates the user based on the acquired secret key and a pre-stored secret key when the secret key for authentication can be acquired from the portable terminal; When the private key cannot be obtained from the mobile terminal, or when the key authentication unit fails to authenticate, a telephone authentication unit that performs authentication of the user based on an incoming call from the mobile terminal; A service providing unit that executes processing for providing the service to the portable terminal when the key authentication unit or the telephone authentication unit succeeds in authentication; Is provided.
  • an authentication apparatus provides: An authentication device connected to a server that provides a service to a user terminal operated by a user via a network, When the server can acquire a secret key for authentication from the user terminal when receiving a service login request from the user terminal, based on the acquired secret key and a secret key held in advance, A key authenticator for authenticating the user; If the private key could not be obtained, or if the key authentication unit could not be authenticated, based on the incoming call from the mobile terminal associated with the user, a telephone authentication unit that authenticates the user, Is provided.
  • an authentication apparatus provides: An authentication device connected to a server that provides a service to a mobile terminal operated by a user via a network, When the server can acquire a secret key for authentication from the portable terminal when receiving a service login request from the portable terminal, based on the acquired secret key and a secret key held in advance, A key authenticator for authenticating the user; If the private key could not be obtained, or if the key authentication unit could not be authenticated, based on the incoming call from the mobile terminal, a telephone authentication unit that authenticates the user, Is provided.
  • a program provides: A computer connected to a server providing a service to a user terminal operated by a user via a network; When the server can acquire a secret key for authentication from the user terminal when receiving a service login request from the user terminal, based on the acquired secret key and a secret key held in advance, A key authenticator that authenticates users, If the private key could not be obtained, or if the key authentication unit could not be authenticated, a telephone authentication unit that authenticates the user based on an incoming call from a mobile terminal associated with the user, To function as.
  • a program provides: A computer connected to a server that provides services to a mobile terminal operated by a user via a network, When the server can acquire a secret key for authentication from the portable terminal when receiving a service login request from the portable terminal, based on the acquired secret key and a secret key held in advance, A key authenticator that authenticates users, When the private key could not be obtained or when the key authentication unit could not authenticate, a telephone authentication unit that authenticates the user based on an incoming call from the mobile terminal, To function as.
  • FIG. 10 is a flowchart for explaining an operation of a login process according to the second embodiment. It is a figure which shows the example of the telephone authentication screen in Embodiment 2.
  • FIG. 10 is a figure which shows the structural example of customer DB in Embodiment 3.
  • FIG. 10 is a flowchart for explaining an operation of a login process according to the third embodiment. It is a figure which shows the example of a manufacture number input screen. It is a figure which shows the whole structure of the service provision system which concerns on a modification.
  • FIG. 1 is a diagram showing an overall configuration of a service providing system 1 according to Embodiment 1 of the present invention.
  • the service providing system 1 includes a server 10 connected to the user terminal 30 via the Internet N1, and an authentication device 20 connected to the portable terminal 40 via the telephone network N2.
  • the server 10 and the authentication device 20 are connected by a dedicated line N3 (or the Internet).
  • the server 10 provides various services to the user terminal 30 via the Internet N1.
  • the “service” here is, for example, net banking using the Internet N1, online shopping, online trading, an electronic ticket system, a service for restoring files that are divided and held on the network, and the like. It is necessary to authenticate whether it is a legitimate user at the time of use.
  • the server 10 is managed by, for example, a company that operates a service to be provided. As illustrated in FIG. 2, the server 10 includes a communication unit 11, a storage unit 12, and a control unit 13. In addition, the server 10 may be comprised from one computer, and may be comprised from the several computer. Although only one server 10 is shown in FIG. 1, a plurality of servers 10 that provide different services are each connected to the authentication device 20.
  • the communication unit 11 performs data communication with the user terminal 30 and the authentication device 20 through the Internet N1 and the dedicated line N3 under the control of the control unit 13.
  • the communication unit 11 includes a communication interface such as a NIC (Network Interface Card).
  • NIC Network Interface Card
  • the communication unit 11 receives a service login request from the user terminal 30 via the Internet N1.
  • the storage unit 12 is a hard disk drive or the like, and stores various data necessary for the server 10 to operate.
  • the storage unit 12 stores a company code that is identification information of the server 10.
  • the storage unit 12 has a customer DB 121.
  • the customer DB 121 stores information about each user who can use the service provided by the server 10. Specifically, as shown in FIG. 3, the customer DB 121 stores a user ID, name, password, mobile phone number, and the like for each user.
  • the user ID is an ID for uniquely identifying the user.
  • the password is used for authentication when the user logs in to the service.
  • the mobile phone number is the phone number of the user's mobile terminal 40.
  • control unit 13 includes a CPU (Central Processing Unit), a ROM (Read Only Memory), a RAM (Random Access Memory), etc. (none of which are shown), and the CPU uses the RAM as a work memory.
  • the entire server 10 is controlled by appropriately executing various programs stored in the ROM or the storage unit 12.
  • the authentication device 20 authenticates a user when there is a login request from the user terminal 30 to the server 10.
  • the authentication device 20 includes a communication unit 21, a storage unit 22, and a control unit 23.
  • the authentication device 20 may be composed of one computer or a plurality of computers.
  • the communication unit 21 performs telephone communication with the portable terminal 40 via the telephone network N2 under the control of the control unit 23.
  • the communication unit 21 performs data communication with the server 10 through the dedicated line N3 under the control of the control unit 23.
  • the storage unit 22 is a hard disk drive or the like, and stores various data necessary for the service providing server 10 to operate.
  • the storage unit 22 includes a user code DB 221, a secret key DB 222, and a common setting DB 223.
  • the user code DB 221 registers the user code and the date and time (phone authentication date and time) when the phone authentication was performed using the user code.
  • the user code is a code irreversibly converted from the incoming call number when a call is received from the mobile terminal 40.
  • the user code is used for user authentication (telephone number authentication) in a login process to be described later.
  • a secret key used for user authentication is registered in a login process described later.
  • a user code, a private key used for user authentication, and a telephone necessary for registering the private key The date on which authentication was performed (telephone authentication date) is registered. It is possible to hold a plurality of secret keys so that one user can use a plurality of user terminals 30, and a plurality of secret keys can be registered in one record in the secret key DB 222. .
  • two secret keys are registered for the user code “1ac279e09da2.
  • the common setting DB 2223 In the common setting DB 223, information commonly set in the server 10 is registered for each connected server 10. Specifically, as shown in FIG. 7, the common setting DB 223 stores a company code, a telephone authentication waiting time, and a secret key validity period for each server 10.
  • the telephone authentication waiting time indicates a time limit from the incoming call from the portable terminal 40 until the telephone authentication request is made, and when the telephone authentication request is received exceeding the telephone authentication waiting time, the authentication fails.
  • the secret key validity period indicates a period during which the secret device is valid, and a secret key created in the past beyond this period cannot be used for authentication.
  • control unit 23 includes a CPU, a ROM, a RAM, and the like (all not shown), and the CPU uses the RAM as a work memory and appropriately executes various programs stored in the ROM and the storage unit 22. By executing this, the entire authentication apparatus 20 is controlled.
  • the control unit 23 includes a key authentication unit 231 and a telephone authentication unit 232 as functional configurations.
  • the key authenticating unit 231 determines that the user is based on the secret key and the secret key held in the secret key DB 222. It is determined (key authentication) whether or not the user is a legitimate user.
  • the telephone authentication unit 232 determines whether there is an incoming call from the portable terminal 40 Based on the above, it is determined (telephone authentication) whether or not the user is a regular user.
  • the user terminal 30 is, for example, a general PC, and is connected to the server 10 via the Internet N1.
  • a web browser (hereinafter simply referred to as a browser) is preinstalled in the user terminal 30, and login to the server 10, service application, and the like are performed from the browser screen.
  • a secret key used for user authentication is stored in the browser of the user terminal 30 by a mechanism such as “Web Storage” or “Cookie” by a login process described later.
  • the user terminal 30 includes a communication unit 31, an input unit 32, a display unit 33, a storage unit 34, and a control unit 35.
  • the communication unit 31 includes a communication interface, and performs data communication with the server 10 via the Internet N1 under the control of the control unit 35.
  • the input unit 32 includes a keyboard and a mouse, and is used to input various information to the user terminal 30. For example, the user operates the input unit 32 and inputs a user ID and password necessary for logging in.
  • the display unit 33 is a liquid crystal display, for example, and outputs various information under the control of the control unit 35.
  • the display unit 33 displays a login screen, a telephone authentication screen described later, and the like.
  • the storage unit 34 is, for example, a hard disk drive, and stores various data necessary for the user terminal 30 to operate.
  • the storage unit 34 stores a secret key transmitted from the server 10.
  • the control unit 35 includes a CPU, a ROM, a RAM, and the like (all not shown), and the CPU uses the RAM as a work memory and appropriately executes various programs stored in the ROM and the storage unit 34. The entire user terminal 30 is controlled.
  • the mobile terminal 40 is, for example, a mobile phone or a smartphone, and is connected to the authentication device 20 via the telephone network N2. In the present embodiment, the mobile terminal 40 is used for determining (phone authentication) whether or not the login made from the user terminal 30 to the server 10 is by a legitimate user.
  • the portable terminal 40 includes a communication device, a touch panel, a flash memory, a CPU, and the like (all not shown).
  • the user who wants to use the service provided by the server 10 operates the input unit 32 of the user terminal 30 to start the browser and causes the display unit 33 to display a login screen for starting the service. Then, the user operates the input unit 32 of the user terminal 30, inputs his / her user ID and password on the login screen, and clicks the login button on the login screen. When the login button is clicked, the control unit 35 transmits a login request including the input user ID and password to the server 10 (step S101).
  • the control unit 13 of the server 10 When receiving the login request, the control unit 13 of the server 10 performs authentication using the user ID and password included in the login request (step S102). Specifically, the control unit 13 may perform user authentication by confirming that a record including the user ID and password included in the received login request is registered in the customer DB 121. If no record corresponding to the customer DB 121 is registered, the user authentication is unsuccessful and the process ends as an error.
  • the control unit 13 of the server 10 searches the customer DB 121 with the user ID included in the login request and acquires the telephone number of the user's mobile terminal 40. And the control part 13 produces a user code from the acquired telephone number (step S103). For example, the control part 13 should just produce
  • the control unit 13 attempts to acquire a secret key for authentication by transmitting a request to the user terminal 30 that is the transmission source of the login request.
  • the secret key cannot be acquired because the secret key is not held in the browser of the user terminal 30.
  • the control unit 13 transmits screen data of a telephone authentication screen that prompts the mobile device 40 to call (call) the authentication device 20 from the mobile terminal 40 to the user terminal 30 (see FIG. 10, Step S105), the control unit 35 of the user terminal 30 displays the telephone authentication screen shown in FIG. 11 on the display unit 33 (Step S106).
  • the telephone number (03-1111-0001) displayed on the telephone authentication screen shown in FIG. 11 is a telephone number for making a call to the authentication apparatus 20.
  • the user who has confirmed the telephone authentication screen of the user terminal 30 calls the authentication device 20 from the mobile terminal 40 owned by the user according to the message on the screen.
  • the control unit 23 of the authentication device 20 creates a user code from the incoming call number and registers it in the user code DB 221 (step S107).
  • the user code registered here is created by the same method as the user code created in step S103.
  • the control unit 23 sets the telephone authentication date and time of the record newly registered in the user code DB 221 in step S107 as the current date and time.
  • the user of the portable terminal 40 confirms the response (ringing sound) from the authentication device 20, and then operates the input unit 32 of the user terminal 30 to click the telephone authentication button (see FIG. 11) on the telephone authentication screen. .
  • the control unit 35 of the user terminal 30 transmits a telephone authentication request to the server 10 (step S108).
  • the control unit 13 of the server 10 transmits a telephone authentication request including the user code created in step S103 and the company code of the server 10 to the authentication device 20 (step S109). ).
  • the control unit 23 of the authentication device 20 performs a telephone authentication process (step S110). Specifically, the control unit 23 first searches the common setting DB 223 using the company code included in the telephone authentication request as a key, and acquires the telephone authentication waiting time of this company (server 10). Then, the control unit 23 registers the record having the user code included in the authentication request in the user code DB 221, and the elapsed time from the telephone authentication date and time to the present of the record is the acquired telephone number. Authentication may be performed by confirming that it is within the authentication waiting time. When authentication fails (that is, when there is no record corresponding to the user code DB 221 or when the elapsed time exceeds the telephone authentication waiting time even if it exists), the subsequent processing is executed as authentication failure. The process ends without being processed.
  • control unit 23 executes a secret key registration process for registering an authentication secret key in the secret key DB 222 (step S111). Details of the secret key registration process will be described with reference to the flowchart of FIG.
  • control unit 23 of the authentication device 20 creates a secret key by creating a random number with a predetermined number of digits (step S11). Then, the control unit 23 determines whether or not the record having the user code included in the telephone authentication request received from the server 10 is registered in the secret key DB 222 (Step S12).
  • step S12 When the record is registered (step S12; Yes), the control unit 23 updates the secret key and telephone authentication date of the record to the secret key created in step S11 and today's date (step S13). The key registration process ends.
  • step S12 if the record is not registered because of the first login or the like (step S12; No), the control unit 23 newly registers a record having the user code included in the telephone authentication request in the secret key DB 222. (Step S14). At this time, the control unit 23 sets the secret key of the newly registered record as the secret key created in step S11, and the telephone authentication date as today's date.
  • the secret key registration process ends here.
  • the control unit 23 of the authentication device 20 subsequently uses the secret key registered or updated in the secret key registration process as the request source of the telephone authentication request. It transmits to the server 10 (step S112).
  • the control unit 13 of the server 10 transmits the received secret key to the user terminal 30 that is the transmission source of the login request (step S113).
  • the control unit 35 of the user terminal 30 stores the secret key received from the server 10 using a mechanism such as “Web Storage” or “Cookie” in the browser (physically the storage unit 34) (step S114). If the secret key is already stored in the browser, the received secret key is updated.
  • the control unit 13 of the server 10 starts a predetermined service for the user terminal 30 that has transmitted the login request, assuming that the user has been correctly authenticated as a regular user (step S115). For example, the control unit 13 displays the service menu screen for the user terminal 30 on the display unit 33 of the user terminal 30.
  • the login process when the secret key cannot be acquired by the first login from the user terminal 30 (FIG. 9, Step S104; No) is completed.
  • step S104 when the secret key can be acquired from the user terminal 30 that is the transmission source of the login request (FIG. 9, step S104; Yes), the control unit 13 of the server 10 determines the secret key and the user code created in step S103. A key authentication request including the company code of the server 10 is transmitted to the authentication device 20 (step S116).
  • the authentication device 20 that has received the key authentication request executes a key authentication process for authenticating the user using the requested secret key (step S117). Details of the key authentication processing will be described with reference to the flowchart of FIG.
  • control unit 23 of the authentication device 20 determines whether or not a record including the user code included in the key authentication request is registered in the secret key DB 222 (step S21). When such a record is not registered (step S21; No), the control unit 23 determines that the secret key is invalid (step S22), and ends the key authentication process.
  • step S21 the control unit 23 determines whether any of the secret keys included in the record matches the secret key included in the key authentication request. Is determined (step S23). If the secret keys do not match (step S23; No), the control unit 23 determines that the secret key is invalid (step S22), and ends the key authentication process.
  • step S23 If the secret keys match (step S23; Yes), the control unit 23 searches the common setting DB 223 using the company code included in the key authentication request as a key, and determines the key effective days of this company (server 10). Obtain (step S24).
  • control unit 23 obtains the telephone authentication date of the private key determined to match in step S23 from the private key DB 222, and whether the elapsed days from the telephone authentication date to the present date is within the key valid days obtained in step S24. It is determined whether or not (step S25). If it is not within the key validity days (step S25; No), the control unit 23 determines that the secret key is invalid (step S22), and ends the key authentication process.
  • step S25 if it is within the key valid days (step S25; Yes), the control unit 23 of the authentication device 20 creates a new secret key by creating a random number with a predetermined number of digits (step S26).
  • control unit 23 updates the secret key of the record registered in the secret key DB 222 determined to match in step S23 to the secret key created in step S26 (step S27). This completes the key authentication process.
  • step S117 when it is determined that the secret key is invalid in the key authentication process (step S118; Yes), the control unit 23 notifies the server 10 of the key authentication request source to that effect (step S119). ). Then, as in the case where the secret key could not be acquired at the time of login (step S104; No), authentication (telephone authentication) by calling the mobile terminal 40 was performed (FIG. 10, steps S105 to S110), and the authentication was successful. In this case, after the secret key is updated (steps S111 to S114), the service is provided to the user terminal 30 (step S115).
  • step S118 the control unit 23 of the authentication apparatus 20 creates the key authentication process (FIG. 13) in step S26.
  • the secret key is transmitted to the server 10 (FIG. 10, step S112), and the control unit 13 of the server 10 transmits the received secret key to the user terminal 30 that is the transmission source of the login request (step S113).
  • the control unit 23 of the user terminal 30 stores the secret key received from the server 10 in the browser (storage unit 34) (step S114).
  • the control part 13 of the server 10 starts the service with respect to the user terminal 30 of the transmission origin of a login request as what has succeeded in user authentication (step S115). This completes the login process.
  • step S104 when the secret key can be obtained from the user terminal 30 when logging in to the server 10 from the user terminal 30 (step S104; Yes), authentication using the secret key is performed.
  • Step S117 When (Step S117) is performed and this secret key is valid (Step S118; No), the service is provided to the user terminal 30 without requiring authentication by calling from the portable terminal 40 (Step S115). ).
  • the private key could not be acquired from the user terminal 30 when logging in to the server 10 from the user terminal 30 (step S104; No), or the acquired private key is invalid (step S118; Yes)
  • Authentication is performed by calling from the mobile terminal 40 (step S110). Therefore, according to the present invention, when there is a valid secret key, the user does not need to make a call from the portable terminal 40. It becomes possible to suppress the burden on the user as compared with the present invention.
  • every time login and authentication are successful a new secret key is created, and the secret key held in the secret key DB 222 of the server 10 and the browser of the user terminal 30 is updated. Therefore, the security of authentication using the secret key can be improved.
  • the user's personal information held by the server 10 is not transmitted to the authentication device 20.
  • a user code obtained by irreversibly converting a telephone number is held in the authentication device 20 instead of the telephone number of the mobile terminal 40. Therefore, there is no possibility that the personal information of the user is leaked from the authentication device 20.
  • Embodiment 2 In the first embodiment, when performing telephone authentication, the user needs to directly operate the portable terminal 40 to make a call to the authentication device 20.
  • the second embodiment is characterized in that a call is automatically made without a user operation when performing telephone authentication.
  • the configuration of the service providing system 1 according to the second embodiment is basically the same as that of the first embodiment.
  • the user terminal 30 and the portable terminal 40 are compatible with a short-range wireless standard such as Bluetooth (registered trademark).
  • the user terminal 30 and the portable terminal 40 can perform short-range communication with each other by a prior pairing process.
  • the authentication device 20 has a plurality of local phone numbers.
  • the portable terminal 40 can make a telephone communication with the authentication device 20 by making a call to any of the plurality of local telephone numbers.
  • the user code DB 221 stored in the storage unit 22 of the authentication device 20 stores a connection number in addition to the user code and the telephone authentication date and time. Yes.
  • the connection number is selected from any of a plurality of local telephone numbers held by the authentication device 20 described above, and indicates that a call is made from the portable terminal 40 to this connection number.
  • steps S101 to S116 and S117 to S119 are substantially the same as the operation of the first embodiment, and therefore will be described with reference to the flowchart shown in FIG. Other processing will be described with reference to the flowchart of FIG. Further, the same steps as those in the first embodiment are denoted by the same step numbers, the description thereof is simplified as appropriate, and steps unique to the second embodiment are mainly described.
  • step S101 When a login request is transmitted from the user terminal 30 (step S101), the control unit 13 of the server 10 performs authentication using the ID and password (step S102), and then uses the user telephone number acquired from the customer DB 121. A user code is generated (step S103).
  • step S201 of FIG. 15 when a private key cannot be acquired from the user terminal 30 (step S104; No).
  • step S104 when the secret key can be acquired from the user terminal 30 (step S104; Yes), the control unit 13 transmits a key authentication request to the authentication device 20, and the control unit 23 of the authentication device 20
  • step S117 the authentication process is executed (step S117) and it is determined that the secret key is invalid (step S118; Yes)
  • step S119 the server 10 is notified of this (step S119), and the process proceeds to step S201.
  • the control part 13 of the server 10 transmits a connection number acquisition request to the authentication apparatus 20 (step S201).
  • the control unit 23 of the authentication device 20 randomly acquires one of the plurality of local station telephone numbers (step S202).
  • the number acquired in step S202 is also referred to as a connection number.
  • the control unit 23 associates the acquired connection number with the user code created in step S103 and registers it as a new record in the user code DB 221 (step S203).
  • the control part 23 transmits the connection number acquired by step S202 to the server 10 of the transmission source of a connection number acquisition request (step S204).
  • the control unit 13 of the server 10 transmits the received connection number to the user terminal 30 (step S205).
  • the control unit 35 of the user terminal 30 instructs the portable terminal 40 to make a call to the connection number received from the server 10 by short-range wireless (step S206).
  • the portable terminal 40 makes a call to the designated connection number (that is, the authentication device 20).
  • the mobile terminal 40 calls the authentication device 20 with the instructed connection number.
  • the control unit 23 of the authentication device 20 creates a user code from the incoming call number by the same method as in step S103 (step S207).
  • control unit 23 confirms that a record including a set of the connection destination number (connection number) of the incoming call and the created user code is registered in the user code DB 221, and The current date and time is registered as the telephone authentication date and time of the record (step S208).
  • the authentication is successful only when the incoming call is made to the authentication device 20 by the connection number notified to the user terminal 30 in steps S204 and S205.
  • the control unit 35 of the user terminal 30 displays a telephone authentication screen as shown in FIG. 16 on the display unit 33 (step S209).
  • the subsequent processing is the same as the processing in the first embodiment. That is, moving to FIG. 10, when the “phone authentication” button is clicked by the user from the telephone authentication screen of FIG. 16, the control unit 35 of the user terminal 30 transmits a telephone authentication request to the server 10 (step S108).
  • the server 10 transmits a telephone authentication request to the authentication terminal (step S109), and the control unit 23 of the authentication device 20 executes a telephone authentication process (step S110) to authenticate the user.
  • the control unit 23 creates and registers a secret key for future authentication, transmits it to the user terminal 30 via the server 10 and stores it (steps S111 to S114).
  • a service is provided to the original user terminal 30 (step S115).
  • an instruction to make a call is made from the user terminal 30 to the portable terminal 40 by proximity communication (step S206), and the portable terminal 40 calls the authentication device 20 based on this instruction. Therefore, it is possible to automatically authenticate the telephone by making a call to the authentication device 20 without any user operation.
  • the authentication device 20 has a plurality of local station telephone numbers, and the connection number used for the authentication changes every time the telephone authentication is performed.
  • the connection number used for the authentication changes every time the telephone authentication is performed.
  • the telephone number of the portable terminal 40 is information unique to the device and cannot be changed. Therefore, in the first and second embodiments, when the authentication secret key cannot be acquired from the user terminal 30 or when the authentication cannot be performed with the acquired secret key, the mobile terminal 40 calls the authentication device 20, and the authentication device 20 Authentication (telephone authentication) was performed using the incoming phone number.
  • Japan for example, Japan
  • a service that can make a call from any telephone number is known. If such a service is used, there is a possibility that an unauthorized user can perform telephone authentication by impersonating a telephone number that can be telephone-authenticated to make a call to the authentication device 20.
  • the present embodiment is characterized by preventing such fraud.
  • the configuration of the service providing system 1 according to the third embodiment is basically the same as that of the first embodiment.
  • the storage unit 12 of the server 10 stores a customer DB 121 as shown in FIG.
  • the customer DB 121 newly stores device identification information, a device authentication necessity flag, an error count, and an authentication permission flag for each user.
  • the device identification information is IMEI (International Mobile Equipment Identity), which is a number (device ID) for uniquely identifying the mobile terminal 40 of the user.
  • the device identification information may be IMEISV (IMEIIMESoftware Version) or the like, and various pieces of information can be adopted as long as the information can uniquely identify the mobile terminal 40.
  • the device authentication necessity flag is a flag indicating whether or not it is necessary to perform authentication (device authentication) using device identification information for this user. When the device authentication necessity flag is “0”, device authentication is not necessary, and when it is “1”, device authentication is necessary.
  • the error count indicates the number of times that the device identification information input by the user does not match that of the customer DB 121 in the authentication process described later.
  • the authentication permission flag is a flag indicating whether or not to authenticate this user.
  • authentication permission flag is “0”, authentication is performed.
  • authentication permission flag is “1”, authentication is not performed (error termination).
  • the error count value is equal to or greater than a predetermined value (for example, 3 or more), the authentication permission flag is updated to “1”.
  • the login process of the third embodiment relates to authentication using the device identification information before the step of transmitting the telephone authentication screen to the user terminal (step S105 in FIG. 10). It is substantially the same except that each step is added. Therefore, only this added part will be described using the flowchart of FIG. 18, and description of other parts common to the first embodiment will be omitted.
  • step S104 in FIG. 9; No When the authentication private key cannot be acquired from the user terminal 30 to which the login request has been transmitted (step S104 in FIG. 9; No), or when the invalidity of the private key is notified (step S119), the process proceeds to FIG.
  • the control unit 13 of the server 10 refers to the device authentication necessity flag in the customer DB 121 to determine whether device authentication is necessary for the login user (step S301). If it is determined that device authentication is not required (step S301; No), the processing moves to step S105 in FIG. 10, and the subsequent processing is the same as in the first embodiment.
  • step S301 if it is determined that device authentication is necessary (step S301; Yes), the control unit 13 of the server 10 refers to the authentication permission flag of the customer DB 121 to determine whether the login user is permitted to be authenticated (authentication permission). Whether the flag is “0”) is checked (step S302). If the authentication is not permitted, the process ends without authenticating the login user.
  • the control unit 13 of the server 10 After confirming that the authentication is permitted, the control unit 13 of the server 10 transmits screen data of a manufacturing number input screen for inputting the device identification information (IMEI) of the mobile terminal 40 to the user terminal 30 ( In step S303, the control unit 35 of the user terminal 30 displays the production number input screen shown in FIG. 19 on the display unit 33 (step S304).
  • IMEI device identification information
  • the control unit 35 of the user terminal 30 transmits the input device identification information to the server 10 (step S305).
  • the mobile terminal 40 transmits its own device identification information to the user terminal 30 through the short-range wireless communication.
  • the device identification information received by the control unit 35 of the user terminal 30 may be transmitted to the server 10.
  • control unit 13 of the server 10 confirms that the device identification information received from the user terminal 30 matches the device identification information of the logged-in user stored in the customer DB 121 (step S306). If the device identification information does not match, the control unit 13 adds one error count and transmits a message or the like prompting the user to input the device identification information again to the user terminal 30.
  • step S105 After confirming that the device identification information matches, the process moves to step S105 in FIG. 10, and the subsequent processes are the same as those in the first embodiment. That is, a call is made from the mobile terminal 40 of the logged-in user to the authentication device, and telephone authentication is performed.
  • the server 10 before performing telephone authentication, acquires the device identification information of the mobile terminal 40 acquired from the user terminal 30 and the device identification information of the logged-in user registered in the customer DB 121 in advance. Confirm that they match, and perform phone authentication only if they match. Unlike telephone numbers, device identification information such as IMEI is confidential information and cannot be known by a third party. Therefore, in this embodiment, it is possible to prevent fraud using a service that can make a call with an arbitrary telephone number.
  • a telephone number is converted into a user code and used for telephone authentication.
  • telephone authentication may be performed using the telephone number directly without performing such conversion.
  • a telephone number authentication screen is displayed on the user terminal 30 (FIG. 10, step S106), and a telephone authentication request is transmitted from this screen (step S106).
  • the authentication device 20 performs telephone authentication (step S110).
  • the telephone authentication may be performed immediately when a call is made from the mobile terminal 40 without displaying the telephone number authentication screen.
  • the functions of the authentication device 20 and the server 10 may be realized by a single computer or the like.
  • the user terminal 30 transmits a login request including a user ID and a password to the server 10 (FIG. 9, step S101). ).
  • a login request that does not include a password may be transmitted to the server 10.
  • the server 10 confirms that the user ID included in the received login request is registered in the customer DB 121. If not registered, the server 10 ends as an error. If registered, step S103 is performed. You can proceed to.
  • the service providing system 1 authenticates the user after receiving a service login request from the user terminal 30, and provides the service to the user terminal 30 when the authentication is successful.
  • the mobile terminal 40 may accept a service login request from the mobile terminal 40, perform authentication, and provide the service to the mobile terminal 40 when the authentication is successful.
  • the overall configuration of the system in this case is shown in FIG.
  • the portable terminal 40 also functions as the user terminal 30 shown in FIG. 1, and the secret key received from the authentication device 20 is stored in the storage unit of the portable terminal 40.
  • a login request to the service from the mobile terminal 40 is transmitted to the server 10 via the Internet N1.
  • the server 10 performs authentication using the ID and password included in the login request. If the secret key can be acquired from the portable terminal 40 after the authentication is successful, the key authentication process is performed based on the secret key acquired by the authentication device 20. Further, when the private key cannot be obtained from the portable terminal 40 or when the authentication fails in the key authentication process, a call is made from the portable terminal 40 to the authentication device 20, and the authentication device 20 performs telephone authentication based on the incoming telephone number. Process. When the key authentication process or the telephone authentication process is successful, the mobile terminal 40 performs a process for providing a service (for example, login to the service).
  • a service for example, login to the service
  • the secret key held in the user terminal 30 is used for authentication of login to the server 10, but the secret key may be used for other purposes.
  • the user terminal 30 transmits data to the server 10
  • this data may be encrypted with the stored secret key and transmitted to the server.
  • the server 10 should just acquire the corresponding private key from the authentication apparatus 20, and should decode the received data with the acquired private key.
  • the authentication device 20 and the server 10 may be realized by a dedicated system or an ordinary computer system.
  • the authentication apparatus 20 and the server 10 are configured by storing and distributing a program for executing the above-described operation in a computer-readable recording medium, installing the program in a computer, and executing the above-described processing. May be.
  • the program may be stored in a disk device provided in the server 10 device on the network such as the Internet N1, and downloaded to a computer.
  • the above functions may be realized by cooperation between the OS and application software. In this case, a portion other than the OS may be stored and distributed in a medium, or a portion other than the OS may be stored in the server 10 device and downloaded to a computer.
  • the present invention is suitably used for various services using the Internet.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Telephonic Communication Services (AREA)

Abstract

サービス提供システム（１）は、ユーザが操作するユーザ端末（３０）からサービスのログイン要求を受信し、このユーザ端末（３０）から認証用の秘密鍵を取得できた場合、取得した秘密鍵と予め保持している秘密鍵とに基づいてユーザの認証を行う。また、サービス提供システム（１）は、ユーザ端末（３０）から秘密鍵を取得できない場合、又は秘密鍵による認証に失敗した場合、ユーザに関連付けられている携帯端末（４０）からの電話着信に基づいて、ユーザの認証を行う。

Description

サービス提供システム、認証装置、及びプログラム
　本発明は、サービス提供システム、認証装置、及びプログラムに関する。
　インターネットを利用したネットバンキング、ネットショッピング、オンライントレード等のサービスが普及している。ユーザは、ＰＣ（Personal Computer）等の端末装置を操作して専用のサイトにアクセスし、パスワード等による認証を行うことにより、このようなサービスを利用することができる。特許文献１には、携帯電話からシステム側に発呼番号を送信することで、より安全にこのようなサービスを利用することができる発明について記載されている。
特許第３４９７７９９号公報
　特許文献１に記載された発明では、パスワード方式の認証よりもセキュリティを高めることが期待できる。しかしながら、特許文献１に記載された発明では、サービスを利用する度に携帯電話を用いてシステム側に発呼する必要があり、ユーザにとって面倒である。
　本発明は、上記実情に鑑みてなされたものであり、サービスを利用する際に高いセキュリティを確保できるとともに、ユーザの手間もかからないサービス提供システム等を提供することを目的とする。
　上記目的を達成するため、本発明の第１の観点に係るサービス提供システムは、
　ユーザが操作するユーザ端末からサービスのログイン要求を受信するログイン要求受信部と、
　前記ユーザ端末から認証用の秘密鍵を取得できた場合、取得した前記秘密鍵と予め保持している秘密鍵とに基づいて、前記ユーザの認証を行う鍵認証部と、
　前記ユーザ端末から前記秘密鍵を取得できない場合、又は前記鍵認証部で認証に失敗した場合、前記ユーザに関連付けられている携帯端末からの電話着信に基づいて、前記ユーザの認証を行う電話認証部と、
　前記鍵認証部又は前記電話認証部で認証に成功した場合に、ログイン要求の送信元のユーザ端末に対して前記サービスを提供するための処理を実行するサービス提供部と、
　を備える。
　前記鍵認証部又は前記電話認証部で認証に成功した場合に、前記ユーザの認証用の秘密鍵を新たに作成して前記サービス提供システムで保持するとともに、作成した前記秘密鍵を前記ユーザ端末に送信する秘密鍵送信部を備えてもよい。
　前記電話認証部は、前記携帯端末からの電話着信を受信後、前記ユーザ端末からの電話認証依頼があった場合に認証を行ってもよい。
　前記電話認証部は、前記携帯端末からの電話着信を受信後に、予め定めた待ち時間以内に前記電話認証依頼が無かった場合、ユーザを認証しなくてもよい。
　前記電話認証部は、
　前記ユーザ端末に複数の自局電話番号の中から選択した接続番号を通知し、
　前記携帯端末からの電話着信の着信先の電話番号が通知した接続番号と一致しない場合はユーザを認証しなくてもよい。
　前記電話認証部は、前記携帯端末の機器識別情報を前記ユーザ端末から取得し、予め記憶している対応する機器識別情報と一致する場合は前記電話着信に基づいて前記ユーザの認証を行い、一致しない場合は前記ユーザの認証を行わなくてもよい。
　上記目的を達成するため、本発明の第２の観点に係るサービス提供システムは、
　ユーザが操作する携帯端末からサービスのログイン要求を受信するログイン要求受信部と、
　前記携帯端末から認証用の秘密鍵を取得できた場合、取得した前記秘密鍵と予め保持している秘密鍵とに基づいて、前記ユーザの認証を行う鍵認証部と、
　前記携帯端末から前記秘密鍵を取得できない場合、又は前記鍵認証部で認証に失敗した場合、前記携帯端末からの電話着信に基づいて、前記ユーザの認証を行う電話認証部と、
　前記鍵認証部又は前記電話認証部で認証に成功した場合に、前記携帯端末に対して前記サービスを提供するための処理を実行するサービス提供部と、
　を備える。
　上記目的を達成するため、本発明の第３の観点に係る認証装置は、
　ネットワークを介してユーザが操作するユーザ端末にサービスを提供するサーバに接続された認証装置であって、
　前記サーバが前記ユーザ端末からサービスのログイン要求を受信した際に前記ユーザ端末から認証用の秘密鍵を取得できた場合、取得した前記秘密鍵と予め保持している秘密鍵とに基づいて、前記ユーザの認証を行う鍵認証部と、
　前記秘密鍵を取得できなかった場合、又は前記鍵認証部で認証できなかった場合、前記ユーザに関連付けられている携帯端末からの電話着信に基づいて、前記ユーザの認証を行う電話認証部と、
　を備える。
　上記目的を達成するため、本発明の第４の観点に係る認証装置は、
　ネットワークを介してユーザが操作する携帯端末にサービスを提供するサーバに接続された認証装置であって、
　前記サーバが前記携帯端末からサービスのログイン要求を受信した際に前記携帯端末から認証用の秘密鍵を取得できた場合、取得した前記秘密鍵と予め保持している秘密鍵とに基づいて、前記ユーザの認証を行う鍵認証部と、
　前記秘密鍵を取得できなかった場合、又は前記鍵認証部で認証できなかった場合、前記携帯端末からの電話着信に基づいて、前記ユーザの認証を行う電話認証部と、
　を備える。
　上記目的を達成するため、本発明の第５の観点に係るプログラムは、
　ネットワークを介してユーザが操作するユーザ端末にサービスを提供するサーバに接続されたコンピュータを、
　前記サーバが前記ユーザ端末からサービスのログイン要求を受信した際に前記ユーザ端末から認証用の秘密鍵を取得できた場合、取得した前記秘密鍵と予め保持している秘密鍵とに基づいて、前記ユーザの認証を行う鍵認証部、
　前記秘密鍵を取得できなかった場合、又は前記鍵認証部で認証できなかった場合、前記ユーザに関連付けられている携帯端末からの電話着信に基づいて、前記ユーザの認証を行う電話認証部、
　として機能させる。
　上記目的を達成するため、本発明の第６の観点に係るプログラムは、
　ネットワークを介してユーザが操作する携帯端末にサービスを提供するサーバに接続されたコンピュータを、
　前記サーバが前記携帯端末からサービスのログイン要求を受信した際に前記携帯端末から認証用の秘密鍵を取得できた場合、取得した前記秘密鍵と予め保持している秘密鍵とに基づいて、前記ユーザの認証を行う鍵認証部、
　前記秘密鍵を取得できなかった場合、又は前記鍵認証部で認証できなかった場合、前記携帯端末からの電話着信に基づいて、前記ユーザの認証を行う電話認証部、
　として機能させる。
　本発明によれば、サービスを利用する際に高いセキュリティを確保できるとともに、ユーザの手間も低減することができる。
本発明の実施形態に係るサービス提供システムの全体構成を示す図である。 サーバの構成を示すブロック図である。 顧客ＤＢの構成例を示す図である。 認証装置の構成を示すブロック図である。 利用者コードＤＢの構成例を示す図である。 秘密鍵ＤＢの構成例を示す図である。 共通設定ＤＢの構成例を示す図である。 ユーザ端末の構成を示すブロック図である。 本発明の実施形態１に係るログイン処理の動作を説明するためのフローチャート（その１）である。 本発明の実施形態１に係るログイン処理の動作を説明するためのフローチャート（その２）である。 電話認証画面の例を示す図である。 秘密鍵登録処理の動作を説明するためのフローチャートである。 鍵認証処理の動作を説明するためのフローチャートである。 実施形態２に係る利用者コードＤＢの構成例を示す図である。 実施形態２に係るログイン処理の動作を説明するためのフローチャートである。 実施形態２における電話認証画面の例を示す図である。 実施形態３における顧客ＤＢの構成例を示す図である。 実施形態３に係るログイン処理の動作を説明するためのフローチャートである。 製造番号入力画面の例を示す図である。 変形例に係るサービス提供システムの全体構成を示す図である。
（実施形態１）
　以下、本発明の実施形態１について図面を参照しながら詳細に説明する。なお、図中、同一または同等の部分には同一の符号を付す。
　図１は、本発明の実施形態１に係るサービス提供システム１の全体構成を示す図である。このサービス提供システム１は、インターネットＮ１を介してユーザ端末３０に接続されるサーバ１０と、電話網Ｎ２を介して携帯端末４０に接続される認証装置２０と、を備える。なお、サーバ１０と認証装置２０とは専用線Ｎ３（又はインターネット）により接続されている。
　サーバ１０は、インターネットＮ１を介してユーザ端末３０に各種のサービスを提供する。なお、ここでいう「サービス」とは、例えば、インターネットＮ１を利用したネットバンキング、ネットショッピング、オンライントレード、電子チケットシステム、ネットワーク上で分割して保持されているファイルを復元するサービス等であり、利用時に正規のユーザであるかどうかの認証を受ける必要がある。サーバ１０は、例えば、提供するサービスを運営する企業によって管理される。サーバ１０は、図２に示すように、通信部１１と、記憶部１２と、制御部１３と、を備える。なお、サーバ１０は、１台のコンピュータから構成されていてもよいし、複数台のコンピュータから構成されていてもよい。なお、図１では１つのサーバ１０しか示していないが、異なるサービスを提供する複数のサーバ１０がそれぞれ認証装置２０に接続されている。
　通信部１１は、制御部１３の制御の下、インターネットＮ１や専用線Ｎ３を介して、ユーザ端末３０や認証装置２０とデータ通信を行う。通信部１１は、例えば、ＮＩＣ（Network Interface Card）などの通信インタフェースを備える。例えば、通信部１１は、インターネットＮ１を介して、ユーザ端末３０からサービスのログイン要求を受信する。
　記憶部１２は、ハードディスクドライブなどであり、サーバ１０が動作するために必要な各種のデータを記憶する。例えば、記憶部１２には、サーバ１０の識別情報となる企業コードが記憶されている。また、記憶部１２は、顧客ＤＢ１２１を有している。
　顧客ＤＢ１２１には、このサーバ１０が提供するサービスを利用可能な各ユーザに関する情報が記憶される。具体的には、図３に示すように、顧客ＤＢ１２１には、ユーザ毎に、ユーザＩＤ、氏名、パスワード、携帯電話番号等が記憶される。
　なお、ユーザＩＤは、ユーザを一意に識別するためのＩＤである。パスワードは、ユーザがサービスにログインする際の認証に利用される。携帯電話番号は、ユーザの携帯端末４０の電話番号である。
　図２に戻り、制御部１３は、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）等（何れも図示せず）を備え、ＣＰＵが、ＲＡＭをワークメモリとして用い、ＲＯＭや記憶部１２に記憶されている各種プログラムを適宜実行することにより、サーバ１０の全体を制御する。
　図１に戻り、続いて、認証装置２０について説明する。認証装置２０は、ユーザ端末３０からサーバ１０へのログイン要求があった際にユーザの認証を行う。認証装置２０は、図４に示すように、通信部２１と、記憶部２２と、制御部２３と、を備える。なお、認証装置２０は、１台のコンピュータから構成されていてもよいし、複数台のコンピュータから構成されていてもよい。
　通信部２１は、制御部２３の制御の下、電話網Ｎ２を介して、携帯端末４０と電話通信を行う。また、通信部２１は、制御部２３の制御の下、専用線Ｎ３を介して、サーバ１０とデータ通信を行う。
　記憶部２２は、ハードディスクドライブなどであり、サービス提供サーバ１０が動作するために必要な各種のデータを記憶する。例えば、記憶部２２は、利用者コードＤＢ２２１と、秘密鍵ＤＢ２２２と、共通設定ＤＢ２２３と、を備える。
　利用者コードＤＢ２２１には、図５に示すように、利用者コードとその利用者コードを用いた電話認証が行われた日時（電話認証日時）とが登録される。利用者コードは、携帯端末４０からの電話着信の際に、その着信番号から不可逆に変換されたコードである。利用者コードは、後述するログイン処理において、ユーザの認証（電話番号認証）のために利用される。
　秘密鍵ＤＢ２２２には、後述するログイン処理において、ユーザの認証のために利用される秘密鍵が登録される。具体的には、図６に示すように、秘密鍵ＤＢ２２２には、ユーザ毎に、ユーザの利用者コードと、ユーザの認証に用いる秘密鍵と、その秘密鍵を登録する際に必要となる電話認証の行われた日（電話認証日）と、が登録される。なお、一人のユーザで複数のユーザ端末３０を利用可能とするために複数の秘密鍵を保持することも可能であり、秘密鍵ＤＢ２２２には、１つのレコードに複数の秘密鍵が登録可能である。例えば、図６の先頭レコードでは、利用者コード「1ac279e09da2‥」に対して２つの秘密鍵が登録されている。
　共通設定ＤＢ２２３には、接続されているサーバ１０毎に、そのサーバ１０で共通に設定される情報が登録される。具体的には、共通設定ＤＢ２２３には、図７に示すように、サーバ１０毎に、サーバ１０の企業コードと電話認証待ち時間と秘密鍵有効期間とが格納されている。
　電話認証待ち時間は、携帯端末４０からの電話着信から電話認証依頼がなされるまでの制限時間を示し、電話認証待ち時間を超えて電話認証依頼を受信した際には認証失敗となる。また、秘密鍵有効期間は、秘密機が有効な期間を示し、この期間を超えて過去に作成された秘密鍵を認証に利用することはできない。
　図４に戻り、制御部２３は、ＣＰＵ、ＲＯＭ、ＲＡＭ等（何れも図示せず）を備え、ＣＰＵが、ＲＡＭをワークメモリとして用い、ＲＯＭや記憶部２２に記憶されている各種プログラムを適宜実行することにより、認証装置２０の全体を制御する。また、制御部２３は、機能的な構成として鍵認証部２３１と電話認証部２３２とを備える。
　鍵認証部２３１は、ユーザ端末３０からログイン要求を受信した際にサーバ１０が秘密鍵を取得できた場合に、この秘密鍵と秘密鍵ＤＢ２２２に保持している秘密鍵とに基づいて、ユーザが正規のユーザであるか否かを判別（鍵認証）する。
　電話認証部２３２は、ユーザ端末３０からログイン要求を受信した際にサーバ１０が秘密鍵を取得できなかった場合や鍵認証部２３１で認証できなかった場合に、携帯端末４０からの電話着信の有無に基づいて、ユーザが正規のユーザであるか否かを判別（電話認証）する。
　図１に戻り、続いて、ユーザ端末３０について説明する。ユーザ端末３０は、例えば、一般的なＰＣであり、インターネットＮ１を介して、サーバ１０に接続される。また、ユーザ端末３０には、Ｗｅｂブラウザ（以下、単にブラウザとする）が予めインストールされており、サーバ１０へのログインやサービスの申し込み等はブラウザの画面から行われる。また、後述するログイン処理により、ユーザ端末３０のブラウザには、「Ｗｅｂ　Ｓｔｏｒａｇｅ」や「Ｃｏｏｋｉｅ」等の仕組みにより、ユーザの認証に用いる秘密鍵が格納される。ユーザ端末３０は、図８に示すように、通信部３１と、入力部３２と、表示部３３と、記憶部３４と、制御部３５と、を備える。
　通信部３１は、通信インタフェースを備え、制御部３５の制御の下、インターネットＮ１を介して、サーバ１０とデータ通信を行う。
　入力部３２は、キーボードやマウス等から構成され、ユーザ端末３０に様々な情報を入力するために使用される。例えば、ユーザは、入力部３２を操作して、ログインするために必要なユーザＩＤやパスワードを入力する。
　表示部３３は、例えば液晶ディスプレイ等であり、制御部３５の制御の下、様々な情報を出力する。例えば、表示部３３には、ログイン画面や後述する電話認証画面等が表示される。
　記憶部３４は、例えば、ハードディスクトライブであり、ユーザ端末３０が動作するために必要な各種のデータを記憶する。また、記憶部３４には、サーバ１０から送信された秘密鍵が格納される。
　制御部３５は、ＣＰＵ、ＲＯＭ、ＲＡＭ等（何れも図示せず）を備え、ＣＰＵが、ＲＡＭをワークメモリとして用い、ＲＯＭや記憶部３４に記憶されている各種プログラムを適宜実行することにより、ユーザ端末３０の全体を制御する。
　図１に戻り、続いて、携帯端末４０について説明する。携帯端末４０は、例えば、携帯電話やスマートフォンであり、電話網Ｎ２を介して認証装置２０に接続される。本実施形態では、携帯端末４０は、ユーザ端末３０からサーバ１０へなされたログインが、正規のユーザによるもので有るかどうかを判別（電話認証）するために利用される。携帯端末４０は、通信装置、タッチパネル、フラッシュメモリ、及びＣＰＵ等（何れも図示せず）を備える。
　続いて、上述したサービス提供システム１で、ユーザ端末３０がサーバ１０が提供するサービスにログインする際の処理（ログイン処理）の動作について、図９、１０のフローチャートを用いて説明する。
　サーバ１０が提供するサービスを利用したいユーザ（ログインユーザ）は、ユーザ端末３０の入力部３２を操作してブラウザを起動させ、サービス開始用のログイン画面を表示部３３に表示させる。そして、ユーザは、ユーザ端末３０の入力部３２を操作して、ログイン画面に自分のユーザＩＤとパスワードとを入力し、ログイン画面のログインボタンをクリックする。ログインボタンがクリックされると、制御部３５は、入力されたユーザＩＤとパスワードとを含んだログイン要求をサーバ１０に送信する（ステップＳ１０１）。
　ログイン要求を受信すると、サーバ１０の制御部１３は、このログイン要求に含まれるユーザＩＤとパスワードとを用いて認証を行う（ステップＳ１０２）。具体的には、制御部１３は、受信したログイン要求に含まれるユーザＩＤとパスワードとを含むレコードが顧客ＤＢ１２１に登録されていることを確認してユーザ認証を行えばよい。なお、顧客ＤＢ１２１に該当するレコードが登録されていない場合、ユーザ認証は不成功となりエラーとして処理は終了する。
　ユーザ認証に成功するとサーバ１０の制御部１３は、ログイン要求に含まれるユーザＩＤで顧客ＤＢ１２１を検索してユーザの携帯端末４０の電話番号を取得する。そして、制御部１３は、取得した電話番号から利用者コードを作成する（ステップＳ１０３）。例えば、制御部１３は、ＭＤ５等のハッシュ関数を用いて電話番号を変換したハッシュ値を利用者コードとして作成すればよい。利用者コードは、認証装置２０がユーザを認証する際に利用される。
　続いて、制御部１３は、ログイン要求の送信元のユーザ端末３０にリクエストを送信して認証用の秘密鍵の取得を試みる。なお、初回ログイン時には、ユーザ端末３０のブラウザに秘密鍵は保持されていないため、秘密鍵を取得することはできない。秘密鍵を取得できない場合（ステップＳ１０４；Ｎｏ）、制御部１３は、携帯端末４０から認証装置２０に電話（発呼）することを促す電話認証画面の画面データをユーザ端末３０に送信し（図１０、ステップＳ１０５）、ユーザ端末３０の制御部３５は、図１１に示す電話認証画面を表示部３３に表示する（ステップＳ１０６）。なお、図１１に示す電話認証画面に表示されている電話番号（０３－１１１１－０００１）は、認証装置２０に発呼するための電話番号である。
　図１０に戻り、ユーザ端末３０の電話認証画面を確認したユーザは、画面のメッセージに従い、自分の所有する携帯端末４０から認証装置２０に対して発呼する。認証装置２０の制御部２３は、携帯端末４０からの電話着信があると、その着信番号から利用者コードを作成して、利用者コードＤＢ２２１に登録する（ステップＳ１０７）。なお、ここで登録される利用者コードは、ステップＳ１０３で作成した利用者コードと同一の手法により作成される。また、制御部２３は、ステップＳ１０７で利用者コードＤＢ２２１に新たに登録されるレコードの電話認証日時を現在の日時に設定する。
　一方、携帯端末４０のユーザは、認証装置２０からの応答（呼出音）を確認した後、ユーザ端末３０の入力部３２を操作して電話認証画面の電話認証ボタン（図１１参照）をクリックする。電話認証ボタンがクリックされると、ユーザ端末３０の制御部３５は、電話認証要求をサーバ１０に送信する（ステップＳ１０８）。
　ユーザ端末３０から電話認証要求を受信すると、サーバ１０の制御部１３は、ステップＳ１０３で作成した利用者コードとサーバ１０の企業コードとを含んだ電話認証依頼を認証装置２０に送信する（ステップＳ１０９）。
　電話認証依頼を受信すると認証装置２０の制御部２３は、電話認証処理を行う（ステップＳ１１０）。具体的には、制御部２３は、まず、電話認証依頼に含まれている企業コードをキーに共通設定ＤＢ２２３を検索して、この企業（サーバ１０）の電話認証待ち時間を取得する。そして、制御部２３は、認証依頼に含まれている利用者コードを有するレコードが利用者コードＤＢ２２１に登録されており、且つ、このレコードの電話認証日時から現在までの経過時間が、取得した電話認証待ち時間以内であることを確認することにより、認証を行えばよい。なお、認証に失敗した場合（即ち、利用者コードＤＢ２２１に該当するレコードが存在しない場合、若しくは存在しても経過時間が電話認証待ち時間を過ぎている場合）、認証失敗として以降の処理は実行されずに処理は終了する。
　認証に成功した場合、制御部２３は、秘密鍵ＤＢ２２２に認証用の秘密鍵を登録する秘密鍵登録処理を実行する（ステップＳ１１１）。秘密鍵登録処理の詳細について、図１２のフローチャートを用いて説明する。
　まず、認証装置２０の制御部２３は、所定桁数の乱数を作成する等して秘密鍵を作成する（ステップＳ１１）。そして、制御部２３は、サーバ１０から受信した電話認証依頼に含まれている利用者コードを有するレコードが秘密鍵ＤＢ２２２に登録されているか否かを判別する（ステップＳ１２）。
　レコードが登録されている場合（ステップＳ１２；Ｙｅｓ）、制御部２３は、そのレコードの秘密鍵と電話認証日を、ステップＳ１１で作成した秘密鍵と今日の日付に更新し（ステップＳ１３）、秘密鍵登録処理は終了する。
　一方、初回ログイン時などでありレコードが登録されていない場合（ステップＳ１２；Ｎｏ）、制御部２３は、電話認証依頼に含まれている利用者コードを有するレコードを新たに秘密鍵ＤＢ２２２に登録する（ステップＳ１４）。なお、このとき制御部２３は、新たに登録するレコードの秘密鍵はステップＳ１１で作成した秘密鍵、電話認証日は今日の日付とする。以上で秘密鍵登録処理は終了する。
　図１０のフローチャートに戻り、秘密鍵登録処理（ステップＳ１１１）が終了すると、続いて、認証装置２０の制御部２３は、秘密鍵登録処理で登録又は更新した秘密鍵を電話認証依頼の依頼元のサーバ１０に送信する（ステップＳ１１２）。サーバ１０の制御部１３は、受信した秘密鍵をログイン要求の送信元のユーザ端末３０に送信する（ステップＳ１１３）。ユーザ端末３０の制御部３５は、「Ｗｅｂ　Ｓｔｏｒａｇｅ」や「Ｃｏｏｋｉｅ」等の仕組みを用いてサーバ１０から受信した秘密鍵をブラウザ（物理的には記憶部３４）に格納する（ステップＳ１１４）。なお、既にブラウザに秘密鍵が格納されている場合は、受信した秘密鍵に更新する。
　続いて、サーバ１０の制御部１３は、ユーザを正規のユーザとして正しく認証できたものとして、ログイン要求の送信元のユーザ端末３０に対して所定のサービスを開始する（ステップＳ１１５）。例えば、制御部１３は、このユーザ端末３０用のサービスメニュー画面をユーザ端末３０の表示部３３に表示させる。以上で、ユーザ端末３０からの初回のログイン等により、秘密鍵を取得できなかった場合（図９、ステップＳ１０４；Ｎｏ）のログイン処理は終了する。
　一方、ログイン要求の送信元のユーザ端末３０から秘密鍵を取得できた場合（図９、ステップＳ１０４；Ｙｅｓ）、サーバ１０の制御部１３は、この秘密鍵とステップＳ１０３で作成した利用者コードとサーバ１０の企業コードとを含んだ鍵認証依頼を認証装置２０に送信する（ステップＳ１１６）。
　鍵認証依頼を受信した認証装置２０は、依頼された秘密鍵を用いてユーザの認証を行う鍵認証処理を実行する（ステップＳ１１７）。鍵認証処理の詳細について、図１３のフローチャートを用いて説明する。
　まず、認証装置２０の制御部２３は、鍵認証依頼に含まれている利用者コードを含むレコードが秘密鍵ＤＢ２２２に登録されているか否かを判別する（ステップＳ２１）。そのようなレコードが登録されていない場合（ステップＳ２１；Ｎｏ）、制御部２３は、秘密鍵は無効と判別して（ステップＳ２２）、鍵認証処理を終了する。
　一方、レコードが登録されている場合（ステップＳ２１；Ｙｅｓ）、制御部２３は、そのレコードに含まれている何れかの秘密鍵が、鍵認証依頼に含まれている秘密鍵と一致するか否かを判別する（ステップＳ２３）。秘密鍵が一致しない場合（ステップＳ２３；Ｎｏ）、制御部２３は、秘密鍵は無効と判別して（ステップＳ２２）、鍵認証処理を終了する。
　秘密鍵が一致する場合（ステップＳ２３；Ｙｅｓ）、制御部２３は、鍵認証依頼に含まれている企業コードをキーに共通設定ＤＢ２２３を検索して、この企業（サーバ１０）の鍵有効日数を取得する（ステップＳ２４）。
　そして、制御部２３は、ステップＳ２３で一致すると判別した秘密鍵の電話認証日を秘密鍵ＤＢ２２２から取得し、電話認証日から現在までの経過日数がステップＳ２４で取得した鍵有効日数以内であるか否かを判別する（ステップＳ２５）。鍵有効日数以内でない場合（ステップＳ２５；Ｎｏ）、制御部２３は、秘密鍵は無効と判別し（ステップＳ２２）、鍵認証処理を終了する。
　一方、鍵有効日数以内である場合（ステップＳ２５；Ｙｅｓ）、認証装置２０の制御部２３は、所定桁数の乱数を作成する等して新たな秘密鍵を作成する（ステップＳ２６）。
　そして、制御部２３は、ステップＳ２３で一致すると判別した秘密鍵ＤＢ２２２に登録されているレコードの秘密鍵を、ステップＳ２６で作成した秘密鍵に更新する（ステップＳ２７）。以上で鍵認証処理は終了する。
　図９に戻り、制御部２３は、鍵認証処理（ステップＳ１１７）で秘密鍵が無効と判別された場合（ステップＳ１１８；Ｙｅｓ）、その旨を鍵認証依頼元のサーバ１０に通知する（ステップＳ１１９）。そして、ログイン時に秘密鍵を取得できなかった場合（ステップＳ１０４；Ｎｏ）と同様に、携帯端末４０の発呼による認証（電話認証）が行われ（図１０、ステップＳ１０５～Ｓ１１０）、認証できた場合に秘密鍵が更新された後（ステップＳ１１１～Ｓ１１４）、ユーザ端末３０にサービスが提供される（ステップＳ１１５）。
　一方、鍵認証処理で秘密鍵が無効であると判別されなかった場合（図９、ステップＳ１１８；Ｎｏ）、認証装置２０の制御部２３は、鍵認証処理（図１３）のステップＳ２６で作成した秘密鍵をサーバ１０に送信し（図１０、ステップＳ１１２）、サーバ１０の制御部１３は、受信した秘密鍵をログイン要求の送信元のユーザ端末３０に送信する（ステップＳ１１３）。ユーザ端末３０の制御部２３は、サーバ１０から受信した秘密鍵をブラウザ（記憶部３４）に格納する（ステップＳ１１４）。その後、サーバ１０の制御部１３は、ユーザの認証に成功したものとして、ログイン要求の送信元のユーザ端末３０に対するサービスを開始する（ステップＳ１１５）。以上でログイン処理は終了する。
　このように、本実施形態によれば、ユーザ端末３０からのサーバ１０へのログインの際に、ユーザ端末３０から秘密鍵を取得できた場合は（ステップＳ１０４；Ｙｅｓ）、秘密鍵を用いた認証（ステップＳ１１７）が行われ、この秘密鍵が有効な場合は（ステップＳ１１８；Ｎｏ）、携帯端末４０からの発呼による認証を必要とせずに、ユーザ端末３０にサービスが提供される（ステップＳ１１５）。一方、ユーザ端末３０からのサーバ１０へのログイン時に、ユーザ端末３０から秘密鍵を取得できなかった場合（ステップＳ１０４；Ｎｏ）、又は取得できたものの秘密鍵が無効である場合（ステップＳ１１８；Ｙｅｓ）、携帯端末４０からの発呼による認証がなされる（ステップＳ１１０）。従って、本発明によれば、有効な秘密鍵がある場合には、ユーザは携帯端末４０から発呼する必要が無いため、ログイン時に常に携帯端末４０からの発呼を必要とする特許文献１記載の発明よりも、ユーザの負担を抑えることが可能となる。
　また、本実施形態によれば、ログインして認証に成功する度に、新たな秘密鍵が作成されて、サーバ１０の秘密鍵ＤＢ２２２およびユーザ端末３０のブラウザに保持される秘密鍵が更新されるため、秘密鍵を用いた認証のセキュリティを向上させることができる。
　また、本実施形態によれば、サーバ１０が保持するユーザの個人情報が認証装置２０に送信されることはない。具体的には、本実施形態では、携帯端末４０の電話番号の代わりに、電話番号を不可逆に変換した利用者コードが認証装置２０に保持される。そのため、認証装置２０からユーザの個人情報が漏えいする虞も無い。
（実施形態２）
　実施形態１では、電話認証をする際に、ユーザが携帯端末４０を直接操作して認証装置２０に発呼する必要があった。実施形態２では、電話認証する際に、ユーザの操作を介さないで自動的に発呼を行うことを特徴とする。
　なお、実施形態２に係るサービス提供システム１の構成は基本的に実施形態１と同じである。また、実施形態２では、ユーザ端末３０と携帯端末４０とは、ブルートゥース（登録商標）等の近距離無線規格に対応している。ユーザ端末３０と携帯端末４０とは、事前のペアリング処理により、相互に近距離通信を行うことができる。
　また、実施形態２に係る認証装置２０は、複数の自局電話番号を有している。携帯端末４０は、この複数の自局電話番号の何れか宛てに発呼することで、認証装置２０と電話通信することができる。
　さらに、実施形態２に係る認証装置２０の記憶部２２に格納されている利用者コードＤＢ２２１は、図１４に示すように、利用者コードと電話認証日時とに加えて、接続番号が記憶されている。接続番号は、上述した認証装置２０の保持する複数の自局電話番号の何れかから選択されたものであり、この接続番号宛に携帯端末４０からの発呼があることを示す。
　続いて、実施形態２に係るサービス提供システム１の動作について説明する。なお、ステップＳ１０１～Ｓ１１６、Ｓ１１７～Ｓ１１９の処理は実施形態１の動作と実質的に同一であるため、実施形態１と同じ図９に示すフローチャートを用いて説明する。それ以外の処理については、図１５のフローチャートを用いて説明する。また、実施形態１と同じステップについては、同じステップ番号を付し、適宜説明を簡略化し、実施形態２に特有のステップについて重点的に説明する。
　ユーザ端末３０からログイン要求が送信されると（ステップＳ１０１）、サーバ１０の制御部１３は、ＩＤとパスワードを用いて認証を行った後（ステップＳ１０２）、顧客ＤＢ１２１から取得したユーザの電話番号から利用者コードを生成する（ステップＳ１０３）。
　そして、サーバ１０の制御部１３は、ユーザ端末３０から秘密鍵を取得できない場合（ステップＳ１０４；Ｎｏ）、図１５のステップＳ２０１に処理を移す。図９に戻り、一方、ユーザ端末３０から秘密鍵を取得できた場合（ステップＳ１０４；Ｙｅｓ）、制御部１３は、鍵認証依頼を認証装置２０に送信し、認証装置２０の制御部２３は鍵認証処理を実行し（ステップＳ１１７）、秘密鍵が無効と判別された場合（ステップＳ１１８；Ｙｅｓ）、その旨をサーバ１０に通知し（ステップＳ１１９）、ステップＳ２０１に処理は移る。
　図１５のステップＳ２０１において、サーバ１０の制御部１３は、認証装置２０に接続番号取得要求を送信する（ステップＳ２０１）。接続番号取得要求を受信すると認証装置２０の制御部２３は、複数の自局電話番号のなかから１つをランダムに取得する（ステップＳ２０２）。なお、以下の説明では、ステップＳ２０２で取得した番号を接続番号とも呼ぶ。続いて、制御部２３は、取得した接続番号とステップＳ１０３で作成した利用者コードとを対応付けて、利用者コードＤＢ２２１に新規のレコードとして登録する（ステップＳ２０３）。そして、制御部２３は、ステップＳ２０２で取得した接続番号を接続番号取得要求の送信元のサーバ１０に送信する（ステップＳ２０４）。サーバ１０の制御部１３は、受信した接続番号をユーザ端末３０に送信する（ステップＳ２０５）。
　ユーザ端末３０の制御部３５は、サーバ１０から受信した接続番号宛てに発呼するよう、近距離無線で携帯端末４０に指示する（ステップＳ２０６）。携帯端末４０は、指示された接続番号宛（即ち認証装置２０）に発呼する。当該指示に従って、携帯端末４０は、指示された接続番号で認証装置２０に発呼する。認証装置２０の制御部２３は、携帯端末４０からの電話着信があると、ステップＳ１０３と同様の手法により、その着信番号から利用者コードを作成する（ステップＳ２０７）。続いて、制御部２３は、この電話着信の接続先の番号（接続番号）と作成した利用者コードとの組を含むレコードが、利用者コードＤＢ２２１に登録されていることを確認するとともに、当該レコードの電話認証日時に現在日時を登録する（ステップＳ２０８）。なお、このようなレコードが確認できない場合は、制御部２３は、エラーとして処理を終了する。ステップＳ２０８での確認を行うことにより、ステップＳ２０４、Ｓ２０５でユーザ端末３０に通知した接続番号による認証装置２０への電話着信の場合しか、認証は成功しないこととなる。
　一方、ユーザ端末３０の制御部３５は、携帯端末４０に発呼を指示した後、図１６に示すような電話認証画面を表示部３３に表示する（ステップＳ２０９）。
　以降の処理は、実施形態１の処理と同様である。即ち、図１０に移り、ユーザにより図１６の電話認証画面から「電話認証」ボタンがクリックされると、ユーザ端末３０の制御部３５は、電話認証要求をサーバ１０に送信し（ステップＳ１０８）、サーバ１０は電話認証依頼を認証端末に送信し（ステップＳ１０９）、認証装置２０の制御部２３は電話認証処理（ステップＳ１１０）を実行してユーザを認証する。そして、認証に成功すると、制御部２３は、今後の認証用の秘密鍵を作成、登録してサーバ１０経由でユーザ端末３０に送信して格納され（ステップＳ１１１～Ｓ１１４）、サーバ１０はログイン要求元のユーザ端末３０にサービスを提供する（ステップＳ１１５）。
　このように、本実施形態によれば、近接通信によりユーザ端末３０から携帯端末４０に発呼の指示がなされ（ステップＳ２０６）、この指示に基づいて携帯端末４０は認証装置２０へ発呼する。そのため、ユーザの操作を介さないで、自動的に認証装置２０に発呼を行って電話認証することが可能となる。
　また、本実施形態によれば、認証装置２０は複数の自局電話番号を有しており、電話認証の度に、その認証で用いる接続番号は変化する。そして、携帯端末４０からの発呼の際に、発呼先の番号と接続番号とが一致しない場合は認証エラーとなるため、セキュリティをより向上させることが可能となる。
（実施形態３）
　一般的に、携帯端末４０の電話番号は機器固有の情報であり変更することはできない。そのため、実施形態１、２では、ユーザ端末３０から認証用の秘密鍵を取得できない場合や取得した秘密鍵で認証ができない場合に、携帯端末４０が認証装置２０に発呼し、認証装置２０がその着信電話番号を用いて認証（電話認証）を行った。
　一方、日本以外の国（例えば米国）では、任意の電話番号から電話発信できるサービスが知られている。このようなサービスを用いれば、不正なユーザが、電話認証可能な電話番号から認証装置２０に発呼するように偽装して、電話認証ができてしまう可能性がある。本実施形態では、このような不正を防止することを特徴とする。
　なお、実施形態３に係るサービス提供システム１の構成は基本的に実施形態１と同じである。また、実施形態３では、サーバ１０の記憶部１２には、図１７に示すような顧客ＤＢ１２１が記憶されている。実施形態１、２と比較して、この顧客ＤＢ１２１には、新たにユーザ毎に、機器識別情報と、機器認証要否フラグと、エラーカウントと、認証許可フラグと、が記憶されている。
　機器識別情報は、ＩＭＥＩ（International Mobile Equipment Identity）であり、ユーザの携帯端末４０を一意に識別するための番号（機器ＩＤ）である。なお、機器識別情報は、ＩＭＥＩＳＶ（IMEI Software Version）等であってもよく、携帯端末４０を一意に識別できる情報であれば種々のものが採用可能である。
　機器認証要否フラグは、このユーザに対して機器識別情報を用いた認証（機器認証）を行う必要があるか否かを示すフラグである。機器認証要否フラグが「０」の場合は機器認証は不要であり、「１」の場合は機器認証が必要であることを示す。
　エラーカウントは、後述する認証処理において、ユーザが入力した機器識別情報が顧客ＤＢ１２１のものと一致しなかった回数を示す。
　認証許可フラグは、このユーザに対して認証を行うか否かを示すフラグである。認証許可フラグが「０」の場合は認証を行い、「１」の場合は認証を行わない（エラー終了させる）ことを示す。エラーカウントの値が所定値以上（例えば３以上）となった場合に、認証許可フラグは「１」に更新される。
　続いて、実施形態３に係るサービス提供システム１で実施されるログイン処理の動作について説明する。なお、実施形態１のログイン処理と比較して、実施形態３のログイン処理は、電話認証画面をユーザ端末に送信するステップ（図１０のステップＳ１０５）の前に、機器識別情報を用いた認証に関する各ステップが追加された点以外は実質的に同じである。そのため、この追加された部分のみを、図１８のフローチャートを用いて説明し、実施形態１と共通する他の部分の説明については省略する。
　ログイン要求が送信されたユーザ端末３０から認証用の秘密鍵を取得できない場合（図９のステップＳ１０４；Ｎｏ）、若しくは、秘密鍵の無効が通知された場合（ステップＳ１１９）、図１８に進み、サーバ１０の制御部１３は、顧客ＤＢ１２１の機器認証要否フラグを参照して、ログインユーザに対して機器認証が必要であるか否かを判別する（ステップＳ３０１）。機器認証が不要であると判別した場合（ステップＳ３０１；Ｎｏ）、図１０のステップＳ１０５に処理は移り、以降は実施形態１の処理と同様である。
　一方、機器認証が必要であると判別した場合（ステップＳ３０１；Ｙｅｓ）、サーバ１０の制御部１３は、顧客ＤＢ１２１の認証許可フラグを参照して、ログインユーザの認証が許可されているか（認証許可フラグが「０」であるか）を確認する（ステップＳ３０２）。認証が許可されていない場合、ログインユーザを認証せずに処理は終了する。
　認証が許可されていることを確認した後、サーバ１０の制御部１３は、携帯端末４０の機器識別情報（ＩＭＥＩ）を入力させるための製造番号入力画面の画面データをユーザ端末３０に送信し（ステップＳ３０３）、ユーザ端末３０の制御部３５は、図１９に示す製造番号入力画面を表示部３３に表示する（ステップＳ３０４）。
　そして、ユーザは、製造番号入力画面の指示に従って、機器識別情報を入力し確認ボタンを押下する。この操作に応答して、ユーザ端末３０の制御部３５は、入力された機器識別情報をサーバ１０に送信する（ステップＳ３０５）。なお、ユーザ端末３０と携帯端末４０とが、ブルートゥース（登録商標）等による近距離無線通信に対応している場合、携帯端末４０が、近距離無線通信により、ユーザ端末３０に自身の機器識別情報を送信し、ユーザ端末３０の制御部３５が受信した機器識別情報をサーバ１０に送信してもよい。
　続いて、サーバ１０の制御部１３は、ユーザ端末３０から受信した機器識別情報と、顧客ＤＢ１２１に記憶されているログインユーザの機器識別情報とが一致していることを確認する（ステップＳ３０６）。なお、機器識別情報が一致していない場合、制御部１３は、エラーカウントを１つ加算し、機器識別情報の入力を再度促すメッセージ等をユーザ端末３０に送信する。
　機器識別情報の一致を確認した後は、図１０のステップＳ１０５に処理は移り、以降は実施形態１の処理と同様である。即ち、ログインユーザの携帯端末４０から認証装置に発呼がなされて電話認証が行われる。
　このように、本実施形態によれば、電話認証を行う前に、サーバ１０は、ユーザ端末３０から取得した携帯端末４０の機器識別情報と顧客ＤＢ１２１に予め登録しているログインユーザの機器識別情報とが一致していることを確認し、一致している場合に限って電話認証を行う。電話番号と異なり、ＩＭＥＩのような機器識別情報は秘匿されている情報であり、第三者が知ることはできない。そのため、本実施形態では、任意の電話番号で電話発信できるサービスを利用した不正も防止することが可能となる。
（変形例）
　なお、上述した実施形態は一例であり、種々の変更及び応用が可能である。
　例えば、上記各実施形態では、電話番号を利用者コードに変換して電話認証に利用したが、このような変換を行わずに、電話番号を直接用いて、電話認証を行ってもよい。
　また、上記各実施形態では、携帯端末４０から認証装置２０に発呼した後、ユーザ端末３０に電話番号認証画面を表示し（図１０、ステップＳ１０６）、この画面から電話認証要求を送信（ステップＳ１０８）した際に、認証装置２０で電話認証（ステップＳ１１０）がなされた。しかしながら、電話番号認証画面を表示せずに、携帯端末４０からの発呼があった際に、即時に電話認証を行ってもよい。
　また、認証装置２０とサーバ１０との機能を１つのコンピュータ等で実現してもよい。
　また、上記各実施形態では、ユーザ端末３０がサーバにユーザＩＤとパスワードとを含んだログイン要求をサーバ１０に送信した（図９、ステップＳ１０１
）。しかしながら、パスワードを含まないログイン要求をサーバ１０に送信してもよい。この場合、サーバ１０は、ステップＳ１０２において、受信したログイン要求に含まれるユーザＩＤが顧客ＤＢ１２１に登録されていることを確認し、登録されていなければエラーとして終了し、登録されていればステップＳ１０３に進めばよい。
　また、上記各実施形態では、サービス提供システム１は、ユーザ端末３０からサービスのログイン要求を受け付けた後、ユーザの認証を行い、認証に成功するとユーザ端末３０にサービスを提供した。しかしながら、携帯端末４０がインターネットＮ１に接続する機能を有する場合には、携帯端末４０からサービスのログイン要求を受け付け、認証を行い、認証に成功した場合に携帯端末４０にサービスを提供してもよい。この場合のシステムの全体構成を図２０に示す。この場合、携帯端末４０は、図１に示すユーザ端末３０の機能も兼ね、携帯端末４０の記憶部には、認証装置２０から受信した秘密鍵が記憶される。
　続いて、この場合の認証処理の動作について概略を説明する。まず、携帯端末４０からサービスへのログイン要求がインターネットＮ１を介してサーバ１０に送信される。ログイン要求を受信すると、サーバ１０は、ログイン要求に含まれるＩＤとパスワードとを用いて認証を行う。この認証に成功した後、携帯端末４０から秘密鍵を取得できた場合、認証装置２０が取得した秘密鍵に基づいて鍵認証処理を行う。また、携帯端末４０から秘密鍵を取得できない場合や鍵認証処理で認証に失敗した場合、携帯端末４０から認証装置２０に発呼がなされ、認証装置２０が、その着信電話番号に基づいて電話認証処理を行う。そして、鍵認証処理又は電話認証処理に成功すると、携帯端末４０においてサービスを提供するための処理（例えば、サービスへのログイン）がなされる。
　また、上記各実施形態では、ユーザ端末３０に保持される秘密鍵をサーバ１０へのログインの認証に利用したが、秘密鍵を他の用途に利用してもよい。例えば、ユーザ端末３０がサーバ１０にデータを送信する際に、保持している秘密鍵でこのデータを暗号化してサーバに送信してもよい。そして、サーバ１０は、認証装置２０から対応する秘密鍵を取得して、受信したデータを取得した秘密鍵で復号すればよい。
　本各実施形態に係る認証装置２０やサーバ１０は、専用のシステムにより実現してもよいし、通常のコンピュータシステムにより実現してもよい。例えば、上述の動作を実行するためのプログラムをコンピュータ読み取り可能な記録媒体に格納して配布し、該プログラムをコンピュータにインストールして、上述の処理を実行することによって認証装置２０やサーバ１０を構成してもよい。また、上記プログラムをインターネットＮ１等のネットワーク上のサーバ１０装置が備えるディスク装置に格納しておき、コンピュータにダウンロード等できるようにしてもよい。また、上述の機能を、ＯＳとアプリケーションソフトとの協働により実現してもよい。この場合には、ＯＳ以外の部分を媒体に格納して配布してもよいし、ＯＳ以外の部分をサーバ１０装置に格納しておき、コンピュータにダウンロード等できるようにしてもよい。
　本発明は、本発明の広義の精神と範囲を逸脱することなく、様々な実施の形態及び変形が可能とされるものである。また、上述した実施形態は、本発明を説明するためのものであり、本発明の範囲を限定するものではない。つまり、本発明の範囲は、実施の形態ではなく、特許請求の範囲によって示される。そして、特許請求の範囲内及びそれと同等の発明の意義の範囲内で施される様々な変形が、本発明の範囲内とみなされる。
　本出願は、２０１６年２月５日に出願された、日本国特許出願２０１６－０２０６６９号に基づく。本明細書中に日本国特許出願２０１６－０２０６６９号の明細書、特許請求の範囲、図面全体を参照として取り込むものとする。
　本発明は、インターネットを利用した各種サービスに好適に利用される。
　１　サービス提供システム、１０　サーバ、１１　通信部、１２　記憶部、１２１　顧客ＤＢ、１３　制御部、２０　認証装置、２１　通信部、２２　記憶部、２２１　利用者コードＤＢ、２２２　秘密鍵ＤＢ、２２３　共通設定ＤＢ、２３　制御部、２３１　鍵認証部、２３２　電話認証部、３０　ユーザ端末、３１　通信部、３２　入力部、３３　表示部、３４　記憶部、３５　制御部、４０　携帯端末、Ｎ１　インターネット、Ｎ２　電話網、Ｎ３　専用線

Claims (11)

  1. 　ユーザが操作するユーザ端末からサービスのログイン要求を受信するログイン要求受信部と、
    　前記ユーザ端末から認証用の秘密鍵を取得できた場合、取得した前記秘密鍵と予め保持している秘密鍵とに基づいて、前記ユーザの認証を行う鍵認証部と、
    　前記ユーザ端末から前記秘密鍵を取得できない場合、又は前記鍵認証部で認証に失敗した場合、前記ユーザに関連付けられている携帯端末からの電話着信に基づいて、前記ユーザの認証を行う電話認証部と、
    　前記鍵認証部又は前記電話認証部で認証に成功した場合に、ログイン要求の送信元のユーザ端末に対して前記サービスを提供するための処理を実行するサービス提供部と、
    　を備えるサービス提供システム。
  2. 　前記鍵認証部又は前記電話認証部で認証に成功した場合に、前記ユーザの認証用の秘密鍵を新たに作成して前記サービス提供システムで保持するとともに、作成した前記秘密鍵を前記ユーザ端末に送信する秘密鍵送信部を備える、
    　請求項１に記載のサービス提供システム。
  3. 　前記電話認証部は、前記携帯端末からの電話着信を受信後、前記ユーザ端末からの電話認証依頼があった場合に認証を行う、
    　請求項１又は２に記載のサービス提供システム。
  4. 　前記電話認証部は、前記携帯端末からの電話着信を受信後に、予め定めた待ち時間以内に前記電話認証依頼が無かった場合、ユーザを認証しない、
    　請求項３に記載のサービス提供システム。
  5. 　前記電話認証部は、
    　前記ユーザ端末に複数の自局電話番号の中から選択した接続番号を通知し、
    　前記携帯端末からの電話着信の着信先の電話番号が通知した接続番号と一致しない場合はユーザを認証しない、
    　請求項１から４の何れか１項に記載のサービス提供システム。
  6. 　前記電話認証部は、前記携帯端末の機器識別情報を前記ユーザ端末から取得し、予め記憶している対応する機器識別情報と一致する場合は前記電話着信に基づいて前記ユーザの認証を行い、一致しない場合は前記ユーザの認証を行わない、
    　請求項１から５の何れか１項に記載のサービス提供システム。
  7. 　ユーザが操作する携帯端末からサービスのログイン要求を受信するログイン要求受信部と、
    　前記携帯端末から認証用の秘密鍵を取得できた場合、取得した前記秘密鍵と予め保持している秘密鍵とに基づいて、前記ユーザの認証を行う鍵認証部と、
    　前記携帯端末から前記秘密鍵を取得できない場合、又は前記鍵認証部で認証に失敗した場合、前記携帯端末からの電話着信に基づいて、前記ユーザの認証を行う電話認証部と、
    　前記鍵認証部又は前記電話認証部で認証に成功した場合に、前記携帯端末に対して前記サービスを提供するための処理を実行するサービス提供部と、
    　を備えるサービス提供システム。
  8. 　ネットワークを介してユーザが操作するユーザ端末にサービスを提供するサーバに接続された認証装置であって、
    　前記サーバが前記ユーザ端末からサービスのログイン要求を受信した際に前記ユーザ端末から認証用の秘密鍵を取得できた場合、取得した前記秘密鍵と予め保持している秘密鍵とに基づいて、前記ユーザの認証を行う鍵認証部と、
    　前記秘密鍵を取得できなかった場合、又は前記鍵認証部で認証できなかった場合、前記ユーザに関連付けられている携帯端末からの電話着信に基づいて、前記ユーザの認証を行う電話認証部と、
    　を備える認証装置。
  9. 　ネットワークを介してユーザが操作する携帯端末にサービスを提供するサーバに接続された認証装置であって、
    　前記サーバが前記携帯端末からサービスのログイン要求を受信した際に前記携帯端末から認証用の秘密鍵を取得できた場合、取得した前記秘密鍵と予め保持している秘密鍵とに基づいて、前記ユーザの認証を行う鍵認証部と、
    　前記秘密鍵を取得できなかった場合、又は前記鍵認証部で認証できなかった場合、前記携帯端末からの電話着信に基づいて、前記ユーザの認証を行う電話認証部と、
    　を備える認証装置。
  10. 　ネットワークを介してユーザが操作するユーザ端末にサービスを提供するサーバに接続されたコンピュータを、
    　前記サーバが前記ユーザ端末からサービスのログイン要求を受信した際に前記ユーザ端末から認証用の秘密鍵を取得できた場合、取得した前記秘密鍵と予め保持している秘密鍵とに基づいて、前記ユーザの認証を行う鍵認証部、
    　前記秘密鍵を取得できなかった場合、又は前記鍵認証部で認証できなかった場合、前記ユーザに関連付けられている携帯端末からの電話着信に基づいて、前記ユーザの認証を行う電話認証部、
    　として機能させるプログラム。
  11. 　ネットワークを介してユーザが操作する携帯端末にサービスを提供するサーバに接続されたコンピュータを、
    　前記サーバが前記携帯端末からサービスのログイン要求を受信した際に前記携帯端末から認証用の秘密鍵を取得できた場合、取得した前記秘密鍵と予め保持している秘密鍵とに基づいて、前記ユーザの認証を行う鍵認証部、
    　前記秘密鍵を取得できなかった場合、又は前記鍵認証部で認証できなかった場合、前記携帯端末からの電話着信に基づいて、前記ユーザの認証を行う電話認証部、
    　として機能させるプログラム。
PCT/JP2016/086189 2016-02-05 2016-12-06 サービス提供システム、認証装置、及びプログラム WO2017134922A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2017505260A JP6115884B1 (ja) 2016-02-05 2016-12-06 サービス提供システム、認証装置、及びプログラム

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2016020669 2016-02-05
JP2016-020669 2016-02-05

Publications (1)

Publication Number Publication Date
WO2017134922A1 true WO2017134922A1 (ja) 2017-08-10

Family

ID=59500781

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2016/086189 WO2017134922A1 (ja) 2016-02-05 2016-12-06 サービス提供システム、認証装置、及びプログラム

Country Status (1)

Country Link
WO (1) WO2017134922A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2021093031A (ja) * 2019-12-11 2021-06-17 ＳｉｎｇｕｌａＮｅｔ株式会社 プログラム、ウェブサーバ、認証方法および認証システム

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009003501A (ja) * 2007-06-19 2009-01-08 Dainippon Printing Co Ltd ワンタイムパスワード認証システム
JP2015082140A (ja) * 2013-10-21 2015-04-27 株式会社りーふねっと ワンタイムパスワード発行装置、プログラムおよびワンタイムパスワード発行方法
JP2015111329A (ja) * 2013-11-06 2015-06-18 株式会社あいびし ネットワークサービス提供システム、ネットワークサービス提供方法、及びプログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009003501A (ja) * 2007-06-19 2009-01-08 Dainippon Printing Co Ltd ワンタイムパスワード認証システム
JP2015082140A (ja) * 2013-10-21 2015-04-27 株式会社りーふねっと ワンタイムパスワード発行装置、プログラムおよびワンタイムパスワード発行方法
JP2015111329A (ja) * 2013-11-06 2015-06-18 株式会社あいびし ネットワークサービス提供システム、ネットワークサービス提供方法、及びプログラム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2021093031A (ja) * 2019-12-11 2021-06-17 ＳｉｎｇｕｌａＮｅｔ株式会社 プログラム、ウェブサーバ、認証方法および認証システム

Similar Documents

Publication Publication Date Title
US10348715B2 (en) Computer-implemented systems and methods of device based, internet-centric, authentication
EP3420677B1 (en) System and method for service assisted mobile pairing of password-less computer login
US20220191016A1 (en) Methods, apparatuses, and computer program products for frictionless electronic signature management
US8572701B2 (en) Authenticating via mobile device
JP2009211632A (ja) サービスシステム
JP5764501B2 (ja) 認証装置、認証方法、及び、プログラム
CN112912875A (zh) 认证系统、认证方法、应用提供装置、认证装置、认证用程序
JP6430689B2 (ja) 認証方法、端末およびプログラム
JP2015130028A (ja) 代行ログイン装置、端末、制御方法およびプログラム
KR101739446B1 (ko) 사용자 인증 시스템 및 인증 방법
JP6115884B1 (ja) サービス提供システム、認証装置、及びプログラム
JP6325654B2 (ja) ネットワークサービス提供装置、ネットワークサービス提供方法、及びプログラム
JP7079528B2 (ja) サービス提供システム及びサービス提供方法
WO2017134922A1 (ja) サービス提供システム、認証装置、及びプログラム
WO2016009497A1 (ja) データ改竄検知装置、ネットワークサービス提供装置、データ改竄検知方法、ネットワークサービス提供方法、及びプログラム
JP5550175B2 (ja) サーバ装置、情報処理システム及び情報処理方法
US20230043031A1 (en) Information processing apparatus and information processing method, authentication device and authentication method, authentication system, authentication method in authentication system, and computer program
JP5584102B2 (ja) 認証システム、クライアント端末、サーバ、被認証方法、認証方法、認証クライアントプログラム、及び認証サーバプログラム
JP6080282B1 (ja) 認証処理システム、認証補助サーバ及びウェブ表示プログラム
WO2023079625A1 (ja) 認証システム、認証方法、及び、プログラム
CN112688943B (zh) 动态密码生成方法、服务器、终端设备及存储介质
JP5495333B2 (ja) 認証装置、認証システム、認証方法、およびプログラム
KR20150102652A (ko) 사내 게시판 서비스 제공을 위한 사내 이메일 계정을 이용한 인증 방법
JP2017219918A (ja) サービス提供システム、サービス提供方法、および、プログラム
JP6273737B2 (ja) 機器登録システム、機器管理装置、無線通信装置、登録装置及び機器管理プログラム

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 2017505260

Country of ref document: JP

Kind code of ref document: A

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16889405

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16889405

Country of ref document: EP

Kind code of ref document: A1