User authentication methods, user authentication systems, programs

Abstract

Provided is a user authentication method that takes into consideration a user's IT literacy.　In the present invention, a prescription code is used for authentication when activating a treatment application on a patient terminal. An access password is automatically generated on the basis of the prescription code or the like, and is then stored in the patient terminal, the access password enabling the patient terminal to initiate data communication with a management server when the treatment application is used. Furthermore, when the treatment application is newly launched, the patient terminal automatically transmits the access password to the management server, without a patient input-operation having to be performed.

Description

Technical Field

[0001] The present invention relates to a user authentication method and the like when widely accessing a server from a user terminal, and more particularly, to a method and the like for authenticating a user via an application installed in a user terminal accessing the server.

Background Art

[0002] Conventionally, as an authentication method when accessing a server from a user terminal, a password control method has been adopted. In the conventional password control method, a user registers a user ID and password determined by the user himself / herself in advance in the server, and at the time of use, the ID and password input by the user are compared with the registered password and the like on the server side to determine whether the user can use the service. In this case, since the ID and password are managed by the user himself / herself, as the number of services provided to the user increases, it becomes more and more cumbersome for the user to memorize different IDs and passwords for each individual service. In view of such problems, various devices have been made so far.

[0003] For example, a system has been proposed that generates a password on the system side and stores this password in a recording medium such as a user terminal to assist the user in memorization and complex password management (Patent Document 1).

[0004] That is, the system disclosed in Patent Document 1 is a system including an external storage device operating on a recording medium for a user, at least one request-side processing device having a communication function, and an execution-side processing device capable of communicating by connecting to the request-side processing device. (A) When registering a password, a password generation registration means for inputting a user identifier sent from the request-side processing device, generating a password associated with the input user identifier, and storing and registering the generated password together with the input user identifier in a password master storage area. (B) A password writing means that sends the password generated by the password generation and registration means to the requesting processing unit, and outputs and writes it to the external storage device. (C) When using the execution-side processing unit, a password reading means inputs a user identifier sent from the request-side processing unit and reads the password for the sent user identifier from the request-side processing unit's external storage device and inputs it. (D) A password search means that searches the password master storage area using the user identifier entered by the password reading means and extracts a password corresponding to the entered user identifier. (E) The execution-side processing device is characterized by having a password verification means that determines whether a password is valid or invalid by checking whether the password entered by the password reading means matches the password extracted by the password search means.

[0005] Furthermore, systems have been proposed that allow users to pre-store passwords and lock keys on a floppy disk, and then insert this floppy disk when accessing the system, thereby simplifying the input of passwords and lock keys (Patent Document 2).

[0006] In other words, Patent Document 2 discloses a security protection system comprising login control that controls login to a computer system using a user password, menu control that controls the execution of a program menu after login using a menu password, and key lock control that prevents unnecessary key input using a lock key, the system comprising: a floppy disk prepared for each user in which the user keyword, the menu keyword, and the lock key are stored in advance using a predetermined writing means; a user password storage unit that stores the user passwords of all users permitted to access the computer system; a menu password storage unit that stores the menu passwords permitted to each user; a lock key storage unit that stores the lock key registered for each user; and a CPU that compares and verifies information read from the floppy disk set by the user when accessing the computer system with information read from the password storage unit, the menu password storage unit, and the lock key storage unit at the required time for program execution.

[0007] Furthermore, methods have been proposed for easily configuring network connections while maintaining a high level of security (Patent Document 3).

[0008] In other words, Patent Document 3 describes a remote access method for a client computer to remotely access a server computer connected to a first network that is sufficiently secure against unauthorized access from an external network, the method comprising: an identification code transmission step in which a profile connection management unit of the client computer connected to the first network reads an identification code that is pre-stored in an area of ​​the storage unit of the client computer that is inaccessible to the user, and a request message generation unit generates a request message containing the identification code and sends the request message to the server computer via a communication unit; an authentication step in which an authentication unit of the server computer authenticates the client computer that sent the request message based on the identification code that is pre-stored in an area of ​​the storage unit of the server computer that is inaccessible to the user and the identification code contained in the request message sent in the identification code transmission step, and notifies the client computer of the authentication result; and in the authentication step If the notified authentication result is "Authentication OK", the client computer's profile connection management unit generates an information generation step in which it generates an account name and password to be used when remotely accessing the server computer based on a random number generated using a predetermined random number generation algorithm; the client computer's request message generation unit generates a network setting request message including the account name and password, and sends the network setting request message to the server computer via the communication unit in a network setting request step; the server computer's profile connection management unit generates a remote connection profile containing various information to be used when the client computer remotely accesses the server computer based on the account name and password included in the network setting request message, notifies the client computer of the remote connection profile via the communication unit, and stores the remote connection profile in the storage unit in a profile generation step; and the client computer's profile connection management unitA remote access method is disclosed, comprising: a profile storage step of storing the remote connection profile notified in the profile generation step into a storage unit; a remote access start request step of a client computer connected to a second network different from the first network, generating a remote access start request message including the remote connection profile read from the storage unit via a profile connection management unit, and sending the remote access start request message to the server computer via a communication unit; and a remote access permission determination step of the server computer's authentication unit determining whether or not to permit remote access from the client computer based on the remote connection profile included in the remote access start request message and the remote connection profile stored in the server computer's storage unit. [Prior art documents] [Patent Documents]

[0009] [Patent Document 1] Japanese Patent Application Publication No. 3-192456 [Patent Document 2] Japanese Patent Application Publication No. 9-16476 [Patent Document 3] Japanese Patent Publication No. 2008-187673 [Overview of the Initiative] [Problems that the invention aims to solve]

[0010] However, the technologies disclosed in Patent Documents 1-3 have not yet adequately proposed mechanisms that take into account the IT literacy of users. For example, when users are elderly or patients requiring medical treatment, existing authentication methods can be cumbersome. Therefore, users would like a system that allows them to start using an application on their device without even being aware of the concept of logging in.

[0011] Furthermore, when medical institutions prescribe therapeutic apps for patients, they need to dedicate a significant amount of time to supporting patients in using the apps after the prescription is issued. Therefore, it is desirable that the user login function be further simplified to lower the barrier to prescribing apps to patients. [Means for solving the problem]

[0012] Therefore, a user authentication method according to one embodiment of the present invention is a user authentication method performed in a user authentication system having a patient terminal used by a patient and a management server, wherein the user authentication method comprises a download step of downloading therapeutic application software from the management server to the patient terminal, an activation step of activating the therapeutic application software on the patient terminal, and an application usage step of executing the activated therapeutic application software on the patient terminal, wherein the activation step comprises a prescription code input step of receiving input of a prescription code acquired by the patient on the patient terminal, and on the patient terminal or the management server, The system includes a first activation authentication step which performs a first activation authentication based on the prescription code, and a password storage step which, if the first activation authentication is successful, generates an access password based on the prescription code in the patient terminal or the management server, stores the access password in the patient terminal, and also stores the access password in the management server. In the application usage step, when the therapeutic application software is newly started, the patient terminal transmits the stored access password to the management server, and the management server performs access authentication by comparing the access password received from the patient terminal with the stored access password.

[0013] According to the present invention, a prescription code is used for authentication when activating a treatment application on a patient's terminal. The prescription code can be obtained by the patient, for example, by being notified by the doctor, and only patients authorized by the doctor can activate the treatment application. Therefore, third parties not authorized by the doctor cannot use the treatment application, making it possible to appropriately manage the scope of use of the treatment application. Furthermore, prescription codes are information that makes it difficult for third parties to identify the patient, thus making it easier to protect personal information. [Effects of the Invention]

[0014] According to one embodiment of the present invention, a user authentication method can be provided that takes into account the user's IT literacy. Furthermore, when medical institutions release treatment apps for patients, the user login function is further simplified, which has the effect of lowering the hurdle to prescribing medication to patients. [Brief explanation of the drawing]

[0015] [Figure 1] This is an explanatory diagram illustrating an example of the overall configuration of a user authentication system according to one embodiment of the present invention. [Figure 2] This is an explanatory diagram illustrating the functional block configuration of the management server in a user authentication system according to one embodiment of the present invention. [Figure 3] This is an explanatory diagram illustrating an example of the external configuration of an information processing device (user terminal) in a user authentication system according to one embodiment of the present invention. [Figure 4] This is an explanatory diagram illustrating the functional block configuration of the hardware constituting an information processing device according to one embodiment of the present invention. [Figure 5] This is an explanatory diagram illustrating the processing flow in a user authentication system according to one embodiment of the present invention. [Figure 6] This is a flowchart illustrating the processing operation flow in a user authentication system according to one embodiment of the present invention. [Figure 7] It is a flowchart for explaining a processing operation flow in a user authentication system according to another embodiment of the present invention. [Figure 8] It is an explanatory diagram for explaining another processing operation flow in a user authentication system according to an embodiment of the present invention. [Figure 9] It is a flowchart for explaining a processing operation flow in a user authentication system according to an embodiment of the present invention. [Figure 10] It is a flowchart for explaining a processing operation flow in a user authentication system according to an embodiment of the present invention.

Mode for Carrying Out the Invention

[0016] Hereinafter, a user authentication method and the like according to an embodiment of the present invention will be described in detail with reference to the drawings.

[0017] FIG. 1 shows an example of the overall configuration of a user authentication system according to an embodiment of the present invention.

[0018] As shown in FIG. 1, the user authentication system 10 includes, as its configuration in one embodiment, a management server 11 and various information processing devices used by users (typically patients) and doctors as needed (in the figure, by way of example, a portable information terminal, a smartphone, or tablet terminals 12, 17 - 18, a mobile phone 13, and PCs 14 - 16 are shown. Hereinafter, they may be collectively referred to as "various terminals", "user terminals (patient terminals or doctor terminals)", or simply "terminals"). The management server 11 and the various terminals are connected to each other via a dedicated line or a public line such as the Internet (as a wired line, 37 - 39) as shown in FIG. 1 so as to be communicable. Also, the line may be wired or wireless. In the case of wireless, the portable information terminal or smartphones 12, 17 - 18 and the mobile phone 13 access the Internet 39 wirelessly via a base station or an access point not shown in the figure, and are further connected to the management server 11 via the line 38 so as to be communicable with each other.

[0019] Here, an access point is a wireless device used to connect wireless terminals such as PCs and smartphones to each other, or to connect them to other networks. Typically, wireless devices such as access points are devices that operate using communication protocols at Layer 1 (physical layer) and Layer 2 (data link layer) of the OSI reference model.

[0020] Furthermore, many mobile phones, personal digital assistants (PDAs), and tablets at the time of filing this application possessed processing capabilities (such as communication processing speed and image processing capabilities) equivalent to those of personal computers (PCs), and could be considered miniature computers.

[0021] Furthermore, the programs or software necessary for implementing the present invention are typically installed or stored in the HDD, SSD, etc., of a PC or portable information terminal's storage unit. When the programs or software are executed, they are read out as software modules, either in whole or in part, into the memory of the storage unit as needed, and then processed by the CPU.

[0022] Alternatively, a browser-based computer or mobile device can be used. In this case, the program is delivered to the device from other servers or computers as needed, and the program is executed by the browser on the device.

[0023] Furthermore, the hardware configuration of the management server 11 can basically consist of cloud servers or PCs (see Figure 2 for further details). While the present invention is not limited to this, the management server 21 can also be configured to handle large-scale data by operating multiple cloud servers or PCs (for example, tens to tens of thousands) in parallel, as needed to increase its hardware specifications.

[0024] Figure 2 shows a functional block diagram of the management server in a user authentication system according to one embodiment of the present invention. Exemplarily, the operation of the management server is realized through the individual operations of the hardware described below, and the coordinated operation of the software and this hardware.

[0025] In Figure 2, the management server 200 as a whole hardware block consists of a CPU 201 for performing various comparison and calculation processes, a storage unit 202 such as RAM, ROM, and flash memory, an input unit 203 such as a keyboard and pointing device, an output unit 204 such as a display and speaker, a control unit 205 for controlling various signals, a communication (interface) unit 206 (whether wireless or wired), a timing unit 207 for timing the time, and a power supply unit 208.

[0026] These modules are connected as needed by communication buses and power lines (in Figure 2, for convenience, these lines are grouped together and referred to as connection 299).

[0027] Furthermore, programs or software executed on the management server 200 necessary for implementing the present invention are typically installed or stored on a hard disk, SSD (Solid State Drive), flash memory, etc., which constitute the storage unit 202. When the program or software is executed, it is read out as a software module, either in whole or in part, into the memory of the storage unit 202 as needed, and then executed by the CPU 201.

[0028] Furthermore, the calculations do not necessarily have to be performed by a central processing unit such as the CPU201; auxiliary arithmetic devices such as a digital signal processor (DSP), which are not shown in the diagram, can also be used.

[0029] Figure 3 shows the external configuration of a smartphone or tablet terminal 12, which serves as an information processing device (user terminal) in a user authentication system according to one embodiment of the present invention. In Figure 3, the smartphone or tablet terminal 12 consists of a housing 121, a display 122, and a hardware button 123 located in the lower center of the housing 121. The display 122 is typically composed of a liquid crystal display (LCD) or the like, and can display various information such as text, still images, and videos. In addition, menu buttons and a software keyboard can be displayed on the display 122, and by touching these with a finger or a stylus (not shown), instructions (commands) can be given to the tablet terminal 12. In this respect, the hardware button 123 is not an essential component, but for the convenience of explaining the present invention, it is implemented as a button that performs a certain function. In one embodiment of the present invention, it is also possible to replace physical buttons such as the hardware button 123 with menu buttons displayed on a part of the display 122.

[0030] Furthermore, the display 122 includes a multi-touch input panel, and the touch input position coordinates on the touch input panel are transmitted to the processing system (CPU) of the smartphone or tablet terminal 12 via an input device interface (not shown) for processing. This multi-touch input panel is configured to simultaneously sense multiple contact points on the panel. This detection (sensing) can be implemented in various ways and is not necessarily limited to contact sensors; for example, it is possible to extract instruction points on the panel using an optical sensor. In addition to contact sensors and optical sensors, it is also possible to use a capacitive sensor that senses human skin contact.

[0031] Although not shown in Figure 3, the smartphone or tablet device 12 can also be equipped with a microphone and speaker. In this case, it is possible to identify the user's voice picked up by the microphone and use it as an input command. Furthermore, although not shown in Figure 3, a camera device such as a CMOS sensor can also be mounted on the back of the smartphone or tablet device 12.

[0032] Furthermore, the information processing device used as the user terminal is not limited to these, and wearable computers such as so-called smartwatches or HMDs (Head-Mounted Displays) may also be used. In this case, some or all of the application according to the present invention will run on this wearable computer. Furthermore, input devices are not limited to the use of devices such as fingers or styluses as described above. For example, various interfaces, including voice interfaces already implemented in VR (Virtual Reality), eye movements, and hand gestures, may be adopted.

[0033] Figure 4 illustrates a functional block diagram of the hardware constituting a smartphone or tablet terminal 12 according to one embodiment of the present invention. The operation of the smartphone or tablet terminal 12 is realized by the individual operations of the hardware described below, and the coordinated operation of the software and this hardware.

[0034] In Figure 4, the smartphone or tablet terminal 400 as a whole hardware block can be broadly divided into: an input unit 401 consisting of hardware buttons 123 in Figure 3, a multi-touch input panel on the display 122, a microphone, etc.; a storage unit 402 consisting of a hard disk, RAM and / or ROM, etc. for storing programs and data, etc.; a central processing unit 403 consisting of a CPU that performs various numerical calculations and logical operations according to the program; a display unit 404 consisting of the display 122, etc.; a control unit 405 for controlling chips, electrical systems, etc.; and an interface The device consists of a communication interface unit 406 comprising a slot for accessing the network, a port for optical communication, and a communication interface; an output unit 407 comprising a speaker, vibration, infrared projector, etc.; a timing unit 408 for timing the time, etc.; a sensor unit 409 comprising an image sensor such as a CMOS, an infrared sensor, an inertial sensor, etc.; and a power supply unit 410 for supplying power to each module in the device. These modules are connected as needed by communication buses and power supply lines (in Figure 4, for convenience, each line is shown as a single connection 499 with the lines appropriately separated).

[0035] The sensor unit 409 may also include a GPS sensor module for determining the location of a smartphone or tablet terminal 400(12). Furthermore, signals detected by the image sensor such as a CMOS or infrared sensor that constitute the sensor unit 409 can be processed as input information in the input unit 401.

[0036] Furthermore, programs or software that are necessary for implementing the present invention and run on a smartphone or tablet terminal 400 are typically installed or stored in a hard disk, SSD (Solid State Drive), flash memory, etc., which constitute the storage unit 402. When the program or software is executed, all or part of it is read out as a software module into the memory of the storage unit 402 as needed, and calculations are performed by the CPU 403.

[0037] Furthermore, the calculations do not necessarily have to be performed by the central processing unit 403 such as the CPU; auxiliary arithmetic devices such as a digital signal processor (DSP), which are not shown, can also be used.

[0038] Next, Figure 5 shows the processing flow in a user authentication system according to one embodiment of the present invention. The processing flow shown in Figure 5 exemplifies how, in one embodiment of the present invention, a user installs and launches an application according to one embodiment of the present invention, inputs initial information, generates a password, and registers with the server (times t11 to t35). The embodiments of the present invention are not limited thereto; for example, at least a portion of the processing performed by the management server can be performed by a physician's terminal or a user's terminal.

[0039] Figure 5, from time t11 to t14, shows the flow of events until the prescription code is notified to the patient. Specifically, from time t11 to t12, the doctor examines the patient and enters the examination results into the doctor's terminal (step S501). The entered information is registered in the management system (hospital system) of the hospital to which the doctor belongs. Then, if the doctor determines that a prescription for a treatment application is necessary, the doctor's terminal requests a prescription code from the management server in response to the doctor's operation (step S502). Note that the complete configuration of the hospital management system (hospital system) is not shown in Figure 5. Information regarding patient examinations and prescriptions is exchanged between the hospital system and the doctor's terminal as needed. On the other hand, some of the information managed by the hospital system can also be managed by the management server shown in Figure 5. Below, we will not explain all of the functions of the hospital system, but will explain only to the extent necessary for understanding the present invention. In one embodiment of the present invention, a physician accesses a website managed by a management server, enters their physician ID and password, and logs in to the website. Then, they perform an operation on the website screen to request the transmission of a prescription code. At this time, patient identification information (patient's name, date of birth, etc.) may be attached. Alternatively, at this point, in order to make it difficult to identify the patient, only the patient ID used in the hospital system may be attached. Alternatively, it is possible not to attach any patient identification information. In one embodiment of the present invention, a management server operates a website, and doctors log in to the website by entering an ID and password via a doctor's terminal to perform necessary processing and requests. However, the present invention is not limited to this, and the website may be implemented as an application installed on a computer such as a server. Furthermore, if the website (or an application with equivalent functionality) is operated on a closed network such as an in-hospital network, doctors can omit entering an ID and password to connect to it. Similar variations can be applied in the following description of embodiments, but for the sake of clarity, repetitive explanations will be omitted as appropriate.

[0040] Between times t12 and t13, the management server, having received a request for a prescription code, issues a new prescription code (step S503). In one embodiment of the present invention, the issued prescription code is registered in the management server's database along with physician identification information (name of the hospital to which the physician belongs, physician's name, etc.) identified when the physician logs in, registration date and time, etc. If patient identification information is attached to the prescription code request, the patient identification information is also registered. Alternatively, data consisting of the issued prescription code and patient identification information as a pair may be registered.

[0041] The management server then transmits the newly issued prescription code to the physician's terminal (step S505). In one embodiment, this transmission can be done by displaying it on a website, etc. Upon receiving notification of the prescription code, the physician operates the physician's terminal to print the prescription code (step S504). In one embodiment, the printed document may also include information such as the contents of the treatment application and how to download it. The printed document is then handed from the physician to the patient. In the hospital system, an administrative terminal managed by the medical office staff or a nurse's terminal managed by a nurse (not shown in Figure 5) is network-connected to the physician's terminal. The printing of the document may also be done at the administrative terminal or the nurse's terminal. Furthermore, the prescription code can be transmitted to the patient by methods other than printing (for example, by email to the patient). In another embodiment of the present invention, some or all of the information necessary for printing the above-mentioned printed material can be managed by a management server.

[0042] Figure 5, from time t21 to t28, shows the flow when a patient installs and first uses the treatment app. At time t21, the patient, having received notification of the prescription code from the doctor, accesses the management server (or website) by operating the user terminal according to the method described in the printed document and requests the management server to download the treatment app (step S511). Upon receiving this request, the management server sends the treatment app to the user terminal at time t22 (step S512). The user terminal, having received the treatment app, installs and then launches the app between time t22 and t23, in accordance with the patient's operations (step S513). On the initial screen after launch, the user is prompted to enter the prescription code. After the patient enters the prescription code while looking at the printed document provided by the doctor, the user terminal sends the entered prescription code to the management server (step S514).

[0043] Between times t23 and t24, the management server performs authentication using the prescription code received from the user terminal (step S515). That is, the management server determines whether the prescription code received from the user terminal (received prescription code or input prescription code) matches a prescription code in the management server's database (registered prescription code or standard prescription code). If both prescription codes match, authentication is successful; if no matching registered prescription code exists in the database, authentication is unsuccessful. The management server then sends the authentication result to the user terminal (S516). If authentication is successful, the authentication result includes a code that authorizes the activation of the treatment application (activation authorization code). If authentication is unsuccessful, the authentication result does not include an activation authorization code, and an error message is displayed on the user terminal. In one embodiment of the present invention, if the authentication in step S516 is successful, another code managed as a pair with the prescription code in the management server's database can be sent to the user terminal instead of, or together with, the authentication result (hereinafter, the above "other code" can be used similarly when using the prescription code).

[0044] Furthermore, in the authentication process at step S515, information other than the prescription code (physician identification information, patient identification information) may be used. In that case, the initial screen when the treatment application is launched (step S513) will display input fields for the prescription code as well as input fields for the other information. The prescription code and the other information are then sent together to the management server, and the management server authenticates by matching the input prescription code with the standard prescription code, as well as using the other information. For example, when using physician information, the system also checks for a match between the physician information received from the user terminal (receiving physician information) and the physician information registered in the database (registered physician information).

[0045] At time t24, a user terminal that has received an authentication result including, for example, an activation authorization code, activates the therapeutic application using, for example, the activation authorization code (step S517). This enables normal use of the therapeutic application. Alternatively, the user terminal generates a patient ID and password based on, for example, a prescription code. Or, it generates a patient ID and password based on other codes managed as a pair with the prescription code in the management server's database. The patient ID and password here are the login ID (access ID) and login password (access password) used to log in to the website managed by the management server. However, this patient ID and password are information codes that the patient is unaware of. Furthermore, this patient ID and password do not necessarily have to be separate codes; they may be internal codes that uniquely identify the user (the same applies to "patient ID and password" hereinafter).

[0046] At time t25, the user terminal sends the generated patient ID and password to the management server (step S518). The generated access ID and access password are also stored in the user terminal's storage device.

[0047] The management server registers the access ID and access password received from the user terminal in its database (step S519). For ease of understanding, the access ID and access password stored in the user terminal will be referred to as the first access ID and first access password, and the access ID and access password registered in the management server's database will be referred to as the second access ID and second access password. Once the registration of the second access ID and second access password is complete, at time t26, the management server sends a registration completion notification to the user terminal (step S520).

[0048] In other embodiments of the present invention, the generation of the patient ID and password based on the prescription code may be performed by the management server instead of the user terminal. That is, if authentication is successful in step S515, the management server generates the patient ID and password based on the prescription code, and when transmitting the authentication result (S516), it also transmits the patient ID and password, and registers the patient ID and password in its own database. The user terminal then stores the patient ID and password received from the management server in its own storage device.

[0049] In another embodiment of the present invention, a user terminal that has received a registration completion notification (S524) displays a screen asking whether to enter patient identification information (also simply referred to as "patient information"). If the user selects to enter patient information, the user terminal accepts the input of patient information (step S521). At time t27, the entered patient information is sent to the management server (step S522). The management server that has received the patient information registers the patient information in the database in association with the prescription code, etc. (step S523), and at time t28, sends a registration completion notification to the user terminal (step S524). The registration completion notification is displayed on the user terminal.

[0050] If the user does not choose to enter patient information, or after receiving the registration completion notification (S524), the user's terminal will be able to use the treatment application normally. Normal use may be possible immediately after activation completion (S517). Furthermore, even if patient information is not entered in step S521, it can be entered afterward.

[0051] Figure 5 shows the flow of events when the treatment app is launched after activation (S513), from time t31 to t35. Between time t31 and t32, the user launches the treatment app by operating an icon on the user terminal screen (step S531). Once the app is launched, the user terminal reads the first access ID and first access password from the user terminal's storage device and sends them to the management server (step S532).

[0052] The management server performs authentication using the received first access ID and first access password (step S533). Specifically, the management server searches the database to see if a second access ID and second access password corresponding to the received first access ID and first access password exist. If such a second access ID and second access password exist in the database, authentication is considered successful; if such a second access ID and second access password do not exist in the database, authentication is considered unsuccessful. Then, at time t33, the management server sends the authentication result to the user terminal (step S534). If the authentication result indicates success, the user terminal accepts user data (data used for treatment) during normal use of the treatment application (step S535), and sends this data to the management server at time t34 (step S536). The management server registers the received user data in the database, associating it with the second access code, etc. (step S537). On the other hand, if the authentication result indicates unsuccessful authentication, the user terminal displays an error message indicating that it could not access the management server. However, even when displaying an error, the system may allow user data input, store it in the user terminal's memory, and then send it to the management server.

[0053] User data may be manually entered by the user (patient) themselves, or automatically entered by sensors on the user terminal. Furthermore, user data registered in the management server's database can be viewed from the physician's terminal. This allows physicians to understand the patient's condition and provide appropriate treatment.

[0054] Figure 6 is a flowchart showing the processing at the start of the treatment application in one embodiment of the present invention. The contents of Figure 6 correspond to the times t21-t26 and t31-t35 in Figure 5. While Figure 5 mainly described the hardware (user terminal, doctor terminal, management server), Figure 6 mainly describes the treatment application.

[0055] When the process shown in Figure 6 begins (step S601), the user terminal downloads the treatment application from the management server in response to the user's operation and installs the application (step S602). When the treatment application is launched for the first time after installation, the user enters a prescription code into the treatment application (step S603). The entered prescription code is sent from the user terminal to the management server, authenticated, and then activated (step S604).

[0056] Then, a password (access password) is generated by the treatment app on the user's terminal based on the prescription code, and this password is saved to the user's terminal's storage device by the treatment app (step S605). In step S603, the user is registered with the management server using the entered prescription code and the password (access password) generated in step S605 (step S606). As a result, the treatment app becomes available for normal use (step S607).

[0057] Steps S608 to S611 describe the normal operation of the treatment application. Specifically, when the treatment application is launched by the user (patient) operating an icon or similar, the treatment application attempts to log in to the management server (step S608). At this time, the first access ID and first access password sent from the user terminal to the management server are automatically read from the storage device by the treatment application and used without the user (patient) having to enter them. If the login is successful (S608: Yes), the process proceeds to step S609.

[0058] The treatment app determines whether a certain amount of time has passed after logging in (S608:Yes) or after step S610. If a certain amount of time has not passed (S609:No), it repeats step S609. If a certain amount of time has passed (S609:Yes), it proceeds to step S610.

[0059] In step S610, the treatment application updates session information with the management server using the ID (first access ID) and password (first access password) stored within the application. That is, it sends user data and other information updated during the certain period of time in step S609 to the management server. The management server, upon receiving this user data and other information, updates the contents of its database. If the user does not log out (step S611: No), the process returns to step S609. If the user logs out (step S611: Yes), the current process ends (step S612).

[0060] Figure 7 is a flowchart showing how prescription codes and patient identification information are associated in a treatment application in one embodiment of the present invention. The contents of Figure 7 correspond to the time t26 to t28 in Figure 5. While Figure 5 mainly described the hardware (user terminal, physician terminal, management server), Figure 7 mainly describes the treatment application.

[0061] When the process shown in Figure 7 is initiated (step S701), the treatment app accepts the user's email address in response to user input (step S702). In addition to or instead of an email address, the app may accept other user information (patient information). Other user information may include SMS (Short Message Service) or SNS (Social Networking Service) accounts. The treatment app then sends the accepted email address (and / or other user information) to the management server (step S703).

[0062] The management server verifies the received email address (step S704). That is, the management server sends an email to the received email address. This email contains an authentication URL. When the user who received the email accesses this URL via a web browser, authentication is successful (i.e., verification by the management server is successful). If verification is not successful within a predetermined time (step S705: No), the process returns to step S702. At this point, an alert may be displayed, or the process may be terminated with an error message.

[0063] If the verification is successful (Step S705: Yes), the management server links the email address with other user information (second access ID, prescription code, etc.) (Step S706) and terminates the process (Step S707). If SMS or SNS account information is used as user information entered in Step S702, verification may be performed in the same manner as described above.

[0064] Next, Figure 8 shows another processing flow in the user authentication system according to one embodiment of the present invention. The processing flow shown in Figure 9 exemplifies the situations in one embodiment of the present invention when a user changes the model of their user terminal, uninstalls and then reinstalls the treatment application, or loses data from the treatment application (times t51~t70).

[0065] The time intervals t51 to t57 in Figure 8 show the process when a user changes their user terminal or when they uninstall and then reinstall the treatment app. Specifically, at time t51, the patient operates the user terminal, which has been changed based on the method described in the printed material given to them by the doctor (S505 in Figure 5), to access the management server (or website) and requests the management server to download the treatment app (step S801). Upon receiving this request, the management server sends the treatment app to the user terminal at time t52 (step S802). The user terminal, having received the treatment app, installs and then launches the app between times t52 and t53, in accordance with the patient's operation (step S803). In one embodiment, the initial screen after launch displays a field for entering the user's email address in addition to the field for entering the prescription code. When the patient enters their email address, the user terminal sends the entered email address to the management server (step S804).

[0066] Between times t53 and t54, the management server performs data verification using the email address received from the user terminal (step S805). That is, the management server determines whether the email address received from the user terminal (received email address) matches an email address in the management server's database (registered email address). If both email addresses match, it is determined that the user is registered; if no matching registered email address exists in the database, it is determined that the user is not registered. If the user is registered, in one embodiment of the present invention, the management server sends an email containing a one-time code to that email address (i.e., the user terminal) (step S806).

[0067] The user who receives the email enters the one-time code contained in the email into the one-time code input field displayed in the treatment app (step S807). The user terminal (treatment app) sends the entered one-time code to the management server (step S808). The management server authenticates whether the one-time code received from the user terminal (received one-time code) matches the one-time code sent by the management server within a predetermined time (sent one-time code). If authentication is successful, the management server reads the second access ID corresponding to the one-time code from the database, generates a new second access password, and registers it in the database (step S809). Then, the management server sends the second access ID, second access password, and activation authorization code to the user terminal (treatment app) (step S810).

[0068] Upon receiving the second access ID, second access password, and activation authorization code, the user terminal (therapy application) activates the therapy application based on the activation authorization code (step S811). In addition, the user terminal stores the received second access ID and second access password in its storage device as the new first access ID and first access password. This makes it possible to perform authentication using the new first access ID and first access password (S531-S533 in Figure 5) the next time the therapy application is launched. In another embodiment of the present invention, if authentication is successful in step S809, an activation authorization code corresponding to the one-time code may be sent to the user, and the user terminal (treatment application) may be configured to generate a second access ID and a second access password. In this case, the generated second access ID and second access password are sent again to the management server for registration and management.

[0069] Figure 8, from time t61 to t70, shows the sequence of events when a user loses data in the therapeutic app. Data loss here includes, for example, cases where a user accidentally or intentionally deletes their user data in the therapeutic app.

[0070] In one embodiment, a physician who has been consulted by a patient about the loss of data operates a physician terminal to access the hospital system database and retrieves, for example, the medical record corresponding to the patient (step S821). Then, the physician identifies the information corresponding to the patient (prescription code or patient information). After that, the physician accesses the management server (website) from the physician terminal and requests a one-time code from the management server to recover the patient's data (to request permission to retrieve the data again) (step S822). Upon receiving the request, the management server identifies the patient (or prescription code, etc.) based on the information contained in the request, generates a one-time code for that patient (step S823), and sends it to the physician terminal (step S824). This one-time code is, so to speak, a data retrieval code.

[0071] Upon receiving the one-time code, the physician's terminal displays it and, in response to the physician's operation, prints a document containing the one-time code from a printer or similar device (step S825). The physician then gives the printed document to the patient to prompt data recovery. Alternatively, instead of using a printed document, the one-time code may be sent from the physician's terminal to the user's terminal via email, SMS, SNS, etc.

[0072] At time t65, the user launches the treatment application on the user terminal (step S826). Subsequent steps S827, S828, and S829 are the same as steps S532, S533, and S534 in Figure 5. Between times t67 and t68, the user enters the one-time code notified by the doctor into the treatment application (step S830). That is, the operation screen of the treatment application includes a "data recovery" screen, and the user can select this screen and enter the one-time code. Once the patient enters the one-time code, the user terminal sends the entered one-time code to the management server (step S831).

[0073] The management server authenticates whether the one-time code received from the user terminal (received one-time code) matches the one-time code sent by the management server within a predetermined time (sent one-time code). If authentication is successful, the management server reads the second access ID corresponding to the one-time code and the corresponding user data from the database, generates a new second access password, and registers it in the database (step S832). Then, the management server sends the user data and the second access password to the user terminal (treatment application) (step S833).

[0074] The user terminal (treatment application) that receives the user data and second access password updates (restores) its own user data using the received user data and stores the received second access password in its storage device as the new first access password (step SS834). This allows the lost data to be recovered and enables authentication using the new first access password (S531-S533 in Figure 5) the next time the treatment application is launched.

[0075] In another embodiment of the present invention, if authentication is successful in step S832, an activation authorization code corresponding to the one-time code may be sent to the user, and the user terminal (treatment application) may be configured to generate a second access ID and a second access password. In this case, the generated second access ID and second access password are sent again to the management server for registration and management.

[0076] Furthermore, in Figure 8, if a user (patient) loses data in the treatment app, the system is operated so that a doctor attempts to recover the lost data by operating the doctor's terminal. However, the present invention is not limited to this, and a support center or support system of the hospital system (hereinafter simply referred to as "support center") commissioned by a doctor or hospital (not shown) may be operated to recover the lost data on behalf of the doctor. In this case, the support center, upon receiving a consultation from a patient about the loss of data, accesses the hospital system database without going through the doctor's terminal, for example, reads the medical record corresponding to the patient (corresponding to step S821), and identifies the information corresponding to the patient (prescription code or patient information). Then, without going through the doctor's terminal, it accesses the management server (website) and requests a one-time code from the management server to recover the patient's data (corresponding to step S822). Similarly, the support center supports the patient on behalf of the doctor or doctor's terminal in the process after requesting permission to retrieve the data. Here, the support center can function in conjunction with the hospital system, constitute a part of the hospital system, or perform some of the functions of the hospital system on its behalf. Therefore, in one embodiment of the present invention, the processes performed by the hospital system can be considered as being performed by the support center.

[0077] Figure 9 is a flowchart showing the process when a user terminal is updated in one embodiment of the present invention. The contents of Figure 9 correspond to the times t51 to t57 in Figure 8. While Figure 8 mainly described the hardware (user terminal, doctor terminal, management server), Figure 9 mainly describes the treatment application.

[0078] When the process shown in Figure 9 begins (step S901), the new user terminal downloads the treatment application from the management server in response to user operations and installs the application (step S902). When the treatment application is launched for the first time after installation, the application displays an input field for an email address in addition to the prescription code input field. When the user enters their email address through user operations, it is sent to the management server (step S903). The management server sends a one-time code to the received email address (step S904). Then, the user terminal enters the one-time code received from the management server into the treatment application through user operations and sends it to the management server (step S905). The management server verifies whether the one-time code it sent (sent one-time code) matches the one-time code received from the user terminal (received one-time code) (step S906).

[0079] If verification is successful (S907:Yes), the management server regenerates a new access password, replaces the old password in the user registration information with the regenerated new access password, and sends the access ID and new access password to the user's treatment app (step S908). The receiving user terminal (treatment app) internally stores the received access ID and new access password (step S909). If verification fails (S907:No) or after step S909, the process ends (step S910).

[0080] Figure 10 is a flowchart illustrating the process when data from a treatment application is lost on a user terminal in one embodiment of the present invention. The contents of Figure 10 correspond to the times t61 to t70 in Figure 8. While Figure 8 mainly described the hardware (user terminal, doctor terminal, management server), Figure 10 mainly describes the treatment application.

[0081] When the process shown in Figure 10 is initiated (step S1001), in a medical institution such as a hospital, the application on the doctor's terminal requests the management server to generate a one-time code in response to the doctor's operation, and the doctor's terminal obtains the one-time code (step S1002). The doctor who obtained the one-time code notifies the patient of the one-time code via printed material, email, SMS, SNS, etc. (step S1003). The patient enters the notified one-time code into the treatment application on their user terminal (step S1004). The user terminal sends the one-time code to the management server.

[0082] The management server compares the one-time code it sent to the doctor's terminal (sent one-time code) with the one-time code received from the user terminal (received one-time code) to verify if they match (step S1005). If the verification is successful (S1006: Yes), the management server regenerates a new access password, replaces the old password in the user registration information with the regenerated new access password, and sends the access ID and new access password to the user's treatment application (step S1007). The receiving user terminal (treatment application) internally stores the received access ID and new access password (step S1008). When setting a new access password, the user data stored in the management server's database can be sent to the user terminal to update the user data in the user terminal's storage device. If the verification fails (S1006: No) or after step S1008, the process ends (step S1009).

[0083] Based on the above, a prescription code is used for authentication when activating therapeutic application software (therapeutic app) on the patient's terminal (S515 in Figure 5, S604 in Figure 6). Since the prescription code is notified to the patient by the physician, only patients approved by the physician can activate the therapeutic application software. Therefore, third parties not authorized by the physician cannot use the software, making it possible to appropriately manage the scope of use of the software. Furthermore, prescription codes are information that makes it difficult for third parties to identify the patient, thus making it easier to protect personal information.

[0084] Furthermore, according to the above, when using the treatment app, the user terminal (patient terminal) automatically generates and stores access passwords (first and second access passwords) for initiating data communication with the management server, for example, based on the prescription code (S517 in Figure 5, S605 in Figure 6) on the user terminal (Figure 5, S605 in Figure 6). Then, when the app is launched for the first time, the user terminal automatically sends the first access password to the management server without requiring any input from the patient (S532 in Figure 5, S608 in Figure 6). Therefore, if the patient has difficulty with information and communication technology or remembering passwords, or if the patient finds the software startup process cumbersome, it becomes possible to improve patient convenience.

[0085] Furthermore, as described above, by storing patient identification information other than the prescription code on the management server (S521-S523 in Figure 5, Figure 7), it becomes possible to prepare for situations where the user terminal (patient terminal) model is changed, or when the treatment application is uninstalled from the user terminal and the treatment application is newly installed. In addition, even when the treatment application is newly installed, the patient does not need to set an access password themselves, thus improving patient convenience.

[0086] Furthermore, as described above, the physician's terminal (hospital system) or the hospital system's support center requests permission from the management server to retrieve data on a user terminal (patient terminal) related to a specific patient. In response, the physician's terminal obtains a one-time code (data retrieval code) (S822-S824 in Figure 8, S1001 in Figure 10). The user terminal accepts the input of the one-time code and sends it to the management server, from which user data is retrieved (S830-S834 in Figure 8, S1004-S1008 in Figure 10). This makes it possible to prepare for the case where treatment application data is lost from the user terminal.

[0087] The embodiments of a user authentication system and the like have been described above based on specific examples. However, embodiments of the present invention can also include methods or programs for implementing a system or device, as well as storage media on which a program is recorded (for example, optical discs, magneto-optical discs, CD-ROMs, CD-Rs, CD-RWs, magnetic tapes, hard disks, memory cards, etc.).

[0088] Furthermore, the implementation form of the program is not limited to application programs such as object code compiled by a compiler or program code executed by an interpreter; it may also take the form of a program module embedded in an operating system.

[0089] Furthermore, the program does not necessarily have to be entirely processed by the CPU on the control board; it can be configured so that some or all of its processing is carried out by other processing units (such as DSPs) implemented on expansion boards or expansion units attached to the board, as needed.

[0090] All of the constituent elements described herein (including the claims, abstract, and drawings) and / or all steps of all disclosed methods or processes may be combined in any combination, except for any combination in which these features are mutually exclusive.

[0091] Furthermore, each of the features described herein (including the claims, abstract, and drawings) may be replaced by an alternative feature that serves the same, equivalent, or similar purpose unless expressly disregarded. Thus, unless expressly disregarded, each of the disclosed features is merely an example of a comprehensive set of identical or equivalent features.

[0092] Furthermore, the present invention is not limited to any specific configuration of the embodiments described above. The present invention can be extended to all novel features or combinations thereof, or all novel methods or processing steps or combinations thereof, described herein (including the claims, abstract, and drawings). [Explanation of symbols]

[0093] 10. User Authentication System 11 Management Server 12. Smartphone or tablet device (a form of user device) 13. Mobile phone (a form of user terminal, etc.) 14-16 PC (a form of user terminal, etc.) 17-18 Smartphone or tablet device (a form of user device) 37, 38 Communication lines 39. Public networks (dedicated lines, internet, etc.)

Claims

1. A user authentication method performed in a user authentication system having a patient terminal used by a patient and a management server, The aforementioned user authentication method is: A download step of downloading therapeutic application software from the management server to the patient terminal, An activation step of activating the therapeutic application software on the patient terminal, The patient terminal includes an application usage step in which the activated therapeutic application software is executed, and It has, The aforementioned activation step is, The patient terminal includes a prescription code input step that accepts the input of the prescription code acquired by the patient, A first activation authentication step is performed in the patient terminal or the management server, based on the prescription code; If the first activation authentication is successful, the patient terminal or the management server generates an access password based on the prescription code, stores the access password in the patient terminal, and also stores the access password in the management server (password storage step). It has, In the application usage step described above, when the therapeutic application software is newly launched, the patient terminal sends the stored access password to the management server, and the management server performs access authentication by comparing the access password received from the patient terminal with the stored access password. A user authentication method characterized by the following features.

2. The aforementioned user authentication method is: A prescription code issuance step in which the prescription code is issued in the hospital system including the management server or a physician's terminal used by a physician, In the management server, a standard prescription code registration step is performed to register the prescription code as a standard prescription code. It has, In the first activation authentication step, the management server performs authentication by comparing the prescription code received from the patient terminal with the standard prescription code. The user authentication method according to feature 1.

3. The aforementioned user authentication method is: The patient terminal includes a first patient identification information input step that accepts input of patient identification information for identifying the patient, A standard patient information registration step, which involves transmitting the patient identification information from the patient terminal to the management server and registering the patient identification information as standard patient information in the management server. It has, The aforementioned activation step is, Prior to the success of the first activation authentication using the prescription code, a second patient identification information input step is performed in which the patient terminal accepts the input of patient identification information instead of the prescription code and transmits it to the management server. The management server performs a second activation authentication step, which involves comparing the patient identification information received from the patient terminal with the reference patient information to perform authentication. A password reset step in which, with the success of the second activation authentication as one of the conditions, a new access password is generated on the management server or the patient terminal based on the access password stored on the management server, and the new access password is stored on the patient terminal and the management server, respectively. A user authentication method according to claim 1 or 2, characterized by having the following features.

4. The aforementioned user authentication method is: A data retrieval request step in which the physician terminal or the hospital system requests permission from the management server to retrieve data on the patient terminal relating to a specific patient, A data retrieval code transmission step in which, in response to the request for permission to retrieve the data, the management server transmits a data retrieval code to the physician terminal or the hospital system, The patient terminal includes a data retrieval code input step, which involves receiving the input of the data retrieval code and transmitting it to the management server, A data transmission step in which the management server, having received the data retrieval code from the patient terminal, transmits data to the patient terminal. The user authentication method according to claim 2, characterized by having the following features.

5. A program that performs the user authentication method described in any one of claims 1 to 4.

6. A user authentication system comprising a patient terminal used by the patient and a management server, The aforementioned patient terminal is Download the therapeutic application software from the aforementioned management server. Activate the aforementioned therapeutic application software, Run the activated therapeutic application software, When activating the aforementioned therapeutic application software, The patient terminal accepts the input of the prescription code acquired by the patient. The patient terminal or the management server performs activation authentication based on the prescription code. If the activation authentication is successful, the patient terminal or the management server generates an access password based on the prescription code, stores the access password in the patient terminal, and also stores the access password in the management server. When the aforementioned application is used and the therapeutic application software is newly launched, the patient terminal transmits the stored access password to the management server, and the management server performs access authentication by comparing the access password received from the patient terminal with the stored access password. A user authentication system characterized by the following features.

Images