WO2015108924A2 - Système d'authentification - Google Patents

Système d'authentification Download PDF

Info

Publication number
WO2015108924A2
WO2015108924A2 PCT/US2015/011330 US2015011330W WO2015108924A2 WO 2015108924 A2 WO2015108924 A2 WO 2015108924A2 US 2015011330 W US2015011330 W US 2015011330W WO 2015108924 A2 WO2015108924 A2 WO 2015108924A2
Authority
WO
WIPO (PCT)
Prior art keywords
server
access
resource
authentication
authentication server
Prior art date
Application number
PCT/US2015/011330
Other languages
English (en)
Other versions
WO2015108924A3 (fr
Inventor
Christopher M. CANFIELD
Todd HICKERSON
Vincent Conroy
Herbert W. SPENCER
Original Assignee
Acuity Systems, Inc.
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 Acuity Systems, Inc. filed Critical Acuity Systems, Inc.
Priority to US15/111,778 priority Critical patent/US20160337351A1/en
Publication of WO2015108924A2 publication Critical patent/WO2015108924A2/fr
Publication of WO2015108924A3 publication Critical patent/WO2015108924A3/fr

Links

Classifications

    • 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
    • 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/44—Program or device authentication

Definitions

  • PCT/US2013/32040 filed March 15, 2013 (attorney docket 50062- 3 PCT); PCT
  • Identity fraud is the leading type of credit card fraud in the US. Over nine million adults are victims each year, which results in $100 million in merchant losses. Despite the increased digital power at our disposal, the state of the current security systems avail able for the prevention of identity fraud is still inadequate. A problem associated with current security systems is that they lack the ability to truly discern an identity of an individual at the fundamental level . Accordingly, there is a need for a better security system that is able to truly discern an individual's identity in order to prevent identity fraud.
  • the present invention is directed to methods and systems that satisfy this need to prevent identity fraud.
  • An exemplary method described herein comprises steps of obtaining user information about a user of a hardware device, authenticating the user from the user information, obtaining a hardware profile of the device, the hardware profile comprising user generated data stored on the device, and linking the user information and the hardware profile as a combined electronic identification.
  • the hardware device can comprise a processor, memory, a touchscreen interface, and a wireless communication module, and can be a device such as a mobile phone, computer, or tablet computer.
  • aspects of the present invention are directed to utilizing more than one device to provide user access to a secure resource.
  • FIG. 1 depicts a system for authenticating multiple devices
  • FIG. 2 depicts a direct mode authentication binding using access code
  • FIG. 3 is a device screen shot depicting a direct mode access button
  • FIG. 4 is a device screen shot depicting an exemplar list of resources
  • FIG. 5 depicts a direct mode authentication system binding using tap to login
  • FIG. 6 depicts a direct mode authentication binding using single device login
  • FIG. 7 depicts direct mode login after binding
  • FIG. 8 depicts single device login using web browser or access
  • FIG. 9 is a device screen shot depicting an exemplar website set up for a second factor authentication
  • FIG. 10 is a device screen shot depicting an exemplar authentication server's website
  • FIG. 11 is a device screen shot depicting an authentication application
  • FIG. 12 is a device screen shot depicting access granted to a resource on a device.
  • FIG. 13 depicts an automatic redirect to authentication server during login.
  • This invention is directed to increasing security for access to a secure resource by making sure that not only the user is authorized to access the resource, but addition, ensuring that the user is using an authenticated device for access, or a device that has been vetted by an authenticated device.
  • Methods of this invention describe an additional layer of security as compared to security relying only on a user name and password. So even if there is a password available, there is no access to a secure resource until an authentication server confirms an authenticated dev ice is being used or has been vetted by an authenticated device.
  • Authentication can utilize an authentication application on a device such as a smart phone in combination with an authentication server.
  • the server has access to information about registered devices and can be used to authenticate that a particular device in communication with it is a particular registered dev ice and authenticate it.
  • the dev ice to be authenticated can have an authentication program that initiates
  • TRAIT WARETM A preferred version of an authentication protocol is known as TRAIT WARETM and is described in PCT application serial numbers PCT/US2013/032040 ( Publication No: WO2013138714 Al) and
  • PCT/US2013/061245 Publication No: WO2014055279 A l.
  • TRAITWARETM any suitable authorization program and server can be utilized.
  • server refers to a system that responds to a request across a computer network to provide or help to provide a network serv ice.
  • the server can run on a dedicated computer.
  • a server as specified by this application can be provided by one or more than one computer type device.
  • the reference to a dev ice or hardware dev ice is any device configured such that the device has the ability to engage in communication with a communication network (such as the internet), and includes dev ices such as cellular, satellite, and other forms of internet connectivity.
  • the device can be capable of capturing biometric input including, but not limited to, fingerprint, facial recognition, voice verification, and vein verification.
  • the dev ice typical ly comprise a processor, memory, input interface transmitter, and touch screen, the processor being programmed to process, through the input interface, user information, transmit through the transmitter user information to a server, and receive input from a server.
  • the device is a mobile phone, computer, or tablet computer.
  • the interface preferably is a touch screen interface, and preferably the transmitter is a wireless communication module.
  • FIG. 1 Tu ning now to FIG. 1 , multiple device authentication 100 and the steps numerated therein, after a person has been successfully identity proofed on a first device they should easily be able to pass that identity to another device in a secure manner.
  • the process described herein allows someone with an authenticated first device to pass a credential to a second dev ice - allowing the second device to be authenticated and linked to the user associated with the first device.
  • a device is authenticated when it is confirmed that it is the actual device that was previously registered.
  • Device authentication differs from authorization - authorization being the function of specifying access rights to resources.
  • a second device can be authenticated based on a percentage of a matching hardware profile in relation to the first dev ice, where the hardware profiles of the first and second devices are compared against each other.
  • the second dev ice can be authorized by sim ly receiv ing a credential from the first dev ice.
  • the credential can be a one-time generated code in a numeric or v isual form such as a matrix code, also known as a quick response code (QR codes).
  • QR codes quick response code
  • the code can be transmitted from the first device to the second device by manual entry, a QR scan, Bluetooth communication, NFC (near field communication ), or other communication methods known in the art.
  • a user registers in a proofing process 1 10 with a server 105 and is assigned a unique User ID, also referred to as a user
  • first device 1 15 is registered by the user in step 4.
  • Proofing 1 10 can be done as usual in the art such as asking questions (e.g. date of birth, mother's maiden name, where a significant other was met, e-mail address).
  • Proofing 1 10 can be performed on a first device, on a server or elsewhere, such as in front of a governmental authority with access to a biometric database. If proofing happens separate from first device 1 15, preferably a registration code or similar code is used to associate first device 1 15 with the proofed individual whose User ID is stored on the server.
  • the proofing authority may be the owner adm i n istrator of the server or a third party. If the proofing authority is a third party, the third party communicates the results of the proofing to the server, which would then create a unique User ID associated with that user.
  • I f proofing 1 10 occurs on the first device the proofing authority can send a credential to the first device indicating that the user has been successful ly proofed.
  • proofing can be initiated on the first device from within the TRAITWARETM application.
  • Proofing 1 18 is initiated on first device 1 1 5, wherein a user can register themselves on the first device 1 15 by using the TRAITWARETM application.
  • Step 1 the user enters 120 the registration code on the first device for transmission to server 105.
  • the user may scan a QR code containing the registration code or receive the registration code through other communication protocols known in the art, such as Bluetooth and NFC. If the user was proofed on first device 1 1 5 and has received a credential on first device 1 1 5 indicating a successful proofing, this credential can be passed, acting as a registration code, to server 105. [0024] Step 2. If the user is proofed, the user is assigned a unique User ID and a unique device ID for first device 1 1 5.
  • a registration code or similar dev ice I D is used to associate first dev ice 1 1 5 with the proofed indiv idual.
  • a registration code can be prov ided by a proofing authority and entered into a registration screen of first dev ice 1 1 5 to create an initial association.
  • the first dev ice is sent 125 a User I D and a Device I D by server 105.
  • a User I D may be associated with a number of Device I Ds (one-to-many) whi le a Dev ice I D is specific to a particular device (one-to-one).
  • Step 3 This step begins the process to register and authenticate the first device. Dev ice trait characteristics are collected and sent 130 from first device 1 1 5.
  • “Dev ice trait characteristics” include the "hardware profile” described in aforementioned PCX Application PCT/US2013/032040, (Publication No: WO2013138714 A l), and also include device prov ided identi fication information such as serial number, processor number, and device type.
  • the User ID is used to salt the device trait characteristics by adding data to the device trait characteristics, before they are hashed. Salting optionally can be performed with other user credentials alone or in combination with the User ID.
  • the credential can be a password, pin, biometric information, and/or image code information such as a PHOTOAUTHTM key (described below). Salting with the User I D instead of the Dev ice ID makes it possible to salt the dev ice trait
  • Step 4 - The first dev ice 1 15 is now registered 135.
  • Step 4 A The user is given the ability to authenticate first device 1 1 5.
  • dev ice trait characteristics are collected and sent 140 to server 105 and compared against those collected in sent 130 in step 3 during registration.
  • Authentication is an optional step because the registration can also serve as the first authentication.
  • Authentication can be effected by an authentication application, and preferably with a
  • the TRAITWARETM application gathers device trait characteristics and user information (PIN, biometric,
  • PHOTOAUTHTM key salts and hashes the gathered characteristics and information, and transmits this to server 105 capable of comparing the salted and hashed characteristics and information and comparing them against stored information.
  • server 105 is a TRAITWARETM server that stores the authentication and authorization components of the process. It receives and holds the device trait characteristics used for authentication. It also holds a list of available client applications used in this process and any associated user/device authorization credentials for those applications. It also holds the client application ' s client identification and secret keys used in the OAuth process described below.
  • Step 4 A device trait characteristics such as a hardware profile arc collected from first device 1 15.
  • the User ID is used to salt the device trait characteristics which are then hashed. Salting optionally can be performed with user information alone, or the User I D in combination with user information.
  • Salting with the User I D and/or user information instead of the Device I D makes it possible to salt the hardware profile elements on a second device while allowing for different Device IDs for each device. Since hardware profiles from separate dev ices are salted w ith the same User I D and/or under information it is possible to compare hardware profiles from separate devices to look for similarity. Additional credentials can be requi ed to be passed to server 105, such as a password, PI or PHOT OAU THTM key for additional authentication. These additional credentials may also be used in combination with a User I D and/or user information to salt the hardware profi le.
  • Step 4B The first device 1 1 5 is authenticated 145 and the user is given the ability to request the addition of a second device 1 50.
  • Step 5 When the user wants to add the second device 150 (without having to go through the proofing process again), the user requests 155 a new device code with the first device 115.
  • This code can be provided via a one-time password (OTP) o a QR code.
  • OTP one-time password
  • the code could be requested from a button located in a settings page within a TRAITWARETM application on the first device 1 15 where first device 1 15 queries the server 105 for a new dev ice code.
  • Step 6 A new device code is returned 160 to first dev ice 1 15.
  • Step 6 A the second device 150 user opens a second device
  • a TRAITWARETM application such as, in one embodiment, a TRAITWARETM application (the TRAITWARETM application can be stand alone on a server or embedded in an application).
  • the application displays a registration prompt on the second device, and the user enters 162 the new code on the second dev ice such as inputting the OT P or scanning the QR from first device 1 15 into second dev ice 150.
  • second dev ice 150 passes 165 this code to server 105.
  • Step 8 - Server 105 returns 170 the User ID associated with that OTP/QR, a new Dev ice ID and other login associated elements to second device 150.
  • the other login-associated elements could be a PHOTO AUTHTM image array, a biometric hash, a biometric feature set, a full biometric representation, a password requirement, a PIN hash, or a PIN sequence.
  • the user can be required to provide one or more of the following elements on the second device to be sent to the serv er for additional authentication: a PHOTOAUTHTM image sequence, a biometric identifier, a password or PIN, and/or a unique identifier.
  • the second device can also use the User ID, a
  • the PHOTOAUTHTM Hash is a hash of concatenated image data from user individually selected images from a PHOTOAUTHTM sequence of images.
  • the PHOTOAUTHTM sequence is the images chosen, in a specific order by a user, to unlock the TRAITWARETM application.
  • Step 9 - The second device 150 trait characteristics are sent 175 from second device 150 to server 105 for comparison 180 against the trait characteristics from one or more devices previously registered by the user, such as first device 1 15. If comparison 180 is within system specified tolerances, second device 150 is authenticated 185 and the new Device ID is associated with the User ID. If the comparison is not within allowed tolerances, the Device ID is discarded from server 105 and second device 150 is not authenticated or associated with the User I D. For example, a user with an IPHONE® as a first device and an IP AD® as a second device is expected to have very similar hardware profiles because such data as contacts and music are commonly the same across platforms. The allowed tolerance is dependent on the level of security requi ed, and can be as high as 99% matching or as low as 10% matching, or even lower.
  • first dev ice 115 as initial proof of identity we have now authenticated second device 150 when the trait characteristics comparisons 180 of the first 1 15 and second 150 devices are within allowed tolerances.
  • difference in trait characteristics from one device to another upon registering a new device can be used to determine whether a transaction may proceed or not.
  • the business rules of the system can dictate the outcome of an authentication attempt or a level of assurance of an identity on a new device.
  • embodiments of the invention disclose a method for a user having a first device to authorize a second device comprising the acts of: a) accessing a first server with the first device; b) requesting with the first device authorization for the second device from the first server; c) receiving an authorization code from the first server on the first device; d) transmitting the authorization code from the first device to the second device; e) transmitting the authorization code to a second server with the second device so that the second server can authenticate the second device; and f) receiving a notice that the second device has been authenticated.
  • the first and second servers are the same server.
  • the first device is authorized.
  • the inventive method comprises the additional acts of:
  • the inventive method teaches a user having an identification code and the act of transmitting the first device trait characteristics includes salting the first device trait characteristics with the user identification code and/or user information, and the act of transmitting a second device trait characteristics includes salting the second device trait characteristics with the user identification code and/or user information.
  • the salting of first device and second device are independent. In another embodiment, the salting of first device and second device is the same.
  • the salting is with the user identification code in combination with a password, PIN, user biometric information, or image code information.
  • no salting of either the first or second device hardware profiles occurs. Additionally, whether salted or unsalted, the hardware profile may be truncated to prevent disclosure of personal information.
  • the present invention discloses a computer implemented system for authorizing a second device for a user having a first authorized device comprising the acts of: (a) receiving a request from the first device for an authorization code for the second device; (b) transmitting the authorization code to the first device; (c) receiving the authorization code from the second device; (d) authenticating the second device; and (e) transmitting a notice that the second device has been authenticated.
  • this system includes a computer or memory device having a program for performing the method described in steps (a) - (e).
  • FIG. 1 The system of FIG. 1 is useful for authenticating a second device owned by a user where a second device has a hardware profile similar to the hardware profile of a first device.
  • This routinely occurs is a single user owns such devices as an IPHONE® and an IP AD®. But this system does not work if a second device does not have a similar profile, such as the case of public computers found at hotels, or public internet facilities, or where a borrowed device is the second device. In such cases, an alternative system will allow a second device to access a secure resource. This system also allows a first device to access the secure resource.
  • FIG. 1 The following is an embodiment of this invention illustrated by FIG.
  • a secure resource is a web site or application that requires authorization to access, i.e. is not available to the general public.
  • the secure resource is hosted on a resource server.
  • Step 0 - A login page for the secure resource is presented 205 to a second device 210 via a web browser on the second device 210.
  • One option on the login page is to select an authentication server to achieve access to the secure resource.
  • Step OA If the user selects the authentication server, the resource login page is automatically redirected 212 to the authentication server 230.
  • the resource login page is automatically redirected 212 to the authentication server 230.
  • a user may click on a "login with TRAITWARETM " button, and the login page is directed 212 to authentication server 230.
  • Step 0B - The authentication server automatically presents 220 a login page, such as a TRAITWARETM login page, to the web browser on the second device 210.
  • the login page can contain an access code such as a QR code and a field to enter a credential.
  • Steps OA and 0B can happen instantly without the notice of the user, appearing as if the initially rendered page was originating from resource server 215, when it is actually coming from authentication server 230.
  • the portion of the page from authentication server 230 can also be embedded in a page from resource server 215.
  • Step 1 The first device 235, which has been authorized, passes 225 authorization credentials, including device trait characteristics and a user identification, to the authentication server 230 for authentication
  • the user identification can be those conventionally used such as an e-mail address, user name, pin number, password, user information, or biometric.
  • Step 2 If authentication is successful, first device 235 receives 240 a successful authentication response. The user is allowed to use the functionality of the TRAITWARETM application on first device 235.
  • Steps 1 and 2 can be performed before step 0, OA, and 0B. Steps 1 and 2 only need to be performed before step 4.
  • Step 3 - Using first device 235, the user acquires the access code 245, such as by scanning or taking a picture of a QR code, presented on the website on second device 210. Because the access code is generated by authentication server 230 upon a request from resource server 215, the access code is associated with the particular resource or resources accessible through or on resource server 215.
  • Step 4 - First device 235 sends the scanned access code 250, such as a QR credential, to authentication server 230.
  • authentication server 230 associates the User ID or Device ID from first device 235 with the resource server 215 hosting the server application that initially requested the QR code.
  • Device ID is a unique string that is created by authentication server 230 when the user registers a device with authentication server 230. It is assigned to the user's authentication server account and passed to the registered device.
  • the User ID here refers to a unique string that is created by authentication server 230 and associated with a user account when a user account is created in authentication server 230. This association acts as a secure resource authorization code or credential for subsequent login attempts to the secure resource.
  • Step 4A - This system can also be used to gain access to the resource for first device 235.
  • first device 235 Upon receipt of the access code from the authenticated first device, first device 235, having been authenticated, can now provide access to the secure resource for future direct access.
  • first device 235 whenever authenticated, have direct access to the secure resource on resource server 215.
  • This is a single device mode where first device 235 is being used for authentication, and, once authenticated, can then provide access to and display content from resource server 215 on first device 235.
  • Step 5 - Authentication server 230 communicates or passes 265 a redirect
  • Step 6 - Website browser on second device 210 uses the redirect URI and an authorization code and passes 270 them to the resource server 215.
  • Steps 7 and 8 - Authorization code is passed 275 from resource server 215 to authentication server 230. Then, authentication server 230 returns 280 an access token to resource server 215. In this way, resource server 215 exchanges an authorization code for an access token. Access tokens are credentials used to access protected resources.
  • Step 9 resource server 215 grants 285 second device 210 access to the secure resource (the web browser) on the second device 210.
  • An access token is a string representing an authorization issued to the client.
  • the string is usually opaque to the client.
  • Tokens represent specific scopes and durations of access, granted by the resource owner, and enforced by a resource server and an authorization server.
  • the resource server is also the authorization server, but in an alternative embodiment, the resource server and authorization server are distinct.
  • the token can denote an identifier used to retrieve the authorization information or can self-contain the authorization information in a verifiable manner (e.g., a token string consisting of some data and a signature). Additional authentication credentials, can be required in order for the client to use a token.
  • the access token provides an abstraction layer, replacing different authorization constructs (e.g., username and password) with a single token understood by a resource server.
  • This abstraction enables issuing access tokens more restrictive than the authorization grant used to obtain them, as well as removing a resource server's need to understand a wide range of authentication methods.
  • Access tokens can have different formats, structures, and methods of utilization (e.g., cryptographic properties) based on a resource server's security requirements.
  • This process can be used to provide access to multiple secure resources in addition to the resource that provides the initial login page in step 0.
  • the above processes and methods can include passing some credentials to a resource server for authentication (in Step 1) prior to authenticating a device via an authentication server.
  • Initially authenticating with a resource server for example, using a traditionally typed User ID and password, can grant a user access to a QR code that they can scan or a registration code that they can input on a first device.
  • the association of a resource server with the User ID or Device ID of a first device grants subsequent direct access from the first device to the resource.
  • FIG. 2 schematically shows a direct mode authentication binding using access code system 200 where a user is using, in addition to an authenticated first device 235, a second device 210 that is not authenticated.
  • FIG. 2 illustrates how an example authenticated first device 235 and a non-authenticated second device 210 may be used to gain access to a secure resource such as resource server 215. Access to a secure resource can be effected with an authentication application, such as a
  • TRAITWARETM application on a first device being used to gain access to a website or another application's resources.
  • the preexisting authorization credentials are located on a TRAITWARETM server, but can be located elsewhere.
  • a TRAITWARETM server is a server storing device information and user information and can compare that information against input information for the purpose of authenticating a device ( i.e. the dev ice requesting access is an authorized device). The methods illustrated by FIGS.
  • first device 235 is authenticated, preferably using the device trait characteristics, to determine if it has been registered such as with a TRAITWARETM server.
  • authentication it is meant that the device currently communicating is the actual registered device. This can be accomplished by comparing the device trait characteristics against saved device trait characteristics.
  • authentication method for the first device is not limited to use of device trait
  • OAuth 2.0 is an open standard for authorization.
  • OAuth provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end-user). It also provides a process for end-users to authorize third-party access to their server resources without sharing their credentials (typically, a username and password pair), using user-agent redirections.
  • TRAITWARETM server by a resource server, is generally performed prior to the processes described herein.
  • the resource server having the secure resource registers with the authentication server and provides a redirect uniform resource identifier ("URI") as well as receives a secret key and client identification from the authentication server.
  • URI uniform resource identifier
  • these processes can be adapted to be used with other authentication and authorization protocols such as SAML, SCIM, Open ID Connect, WS-Trust, WS- Federation, and other authentication and authorization protocols known in the art.
  • OAuth 2.0 and other commonly used protocols are useful in steps OA, OB, and 5-8 in the Figure
  • FIGS. 2, 5, 6, and 7 rely on using a resource server, also referred to as a client or third party server, to serve an initial web page to a browser.
  • a resource server also referred to as a client or third party server
  • a user can initiate a login such as by clicking a login button that invokes an application (single device mode) or by cl icking a login button to take the user to the authentication server page where the user is presented with tap to login or QR methods of logging in.
  • the client page is directed to an application
  • authentication server (tap to login or QR ), w hich uses the OAuth 2.0 spec as reference for providing authorization codes and token exchanges.
  • Single dev ice mode login contacts the authentication server directly through an installed application.
  • the authorization server and the resource server can be the same server.
  • TRA 1TWARETM server is not limited to TRA ITWARETM authorization and can be effected with any authorization server running any authorization process available to the art and thus is generically referred to herein as an authorization server.
  • the direct mode invention is a means to simpli fy multifactor
  • credentials are created that can be used to create a l ist of secure resources that can be accessed by a registered user once they are authenticated on a device which can be verified as something they have and one or more additional factors are used for the authentication such as something they know, such as password or picture sequence (e.g. PHOTOAUTH 1 M ), or something they are, such as a biometric feature, w hich can include a fingerprint, voice print, iris scan, or vein record.
  • the user opens the user's authentication application such as the
  • TRAITWARETM application and they can then go to the direct mode, clicking a button that then presents a list of resource that were previously accessed, and for which the user is approved to access.
  • FIG. 3 shows an example embodiment screen shot of a direct mode access button 300 and FIG. 4 shows a sample list of resources 400, which in this case are secure websites. They could also be secure applications that need approval to access and use.
  • the credential for creating the lists are created the first time the user accesses the resource. Once the link is created the user can simply open their
  • FIGS. 2 and 5 show the flows when the user accesses the resource on a second device using a first device as something they have to authenticate with.
  • FIG. 6 shows the flow for accessing the resource from a first device something they have.
  • FIG. 7 shows the flow for accessing the resource on the device that the user has registered as a device the user has from the authentication application on that device.
  • the features of the embodiment illustrated by FIG. 2 include a method for accessing a secure resource on a resource server, the method comprising the acts of: accessing a login page for the secure resource with a second device, the second device being a non-authenticated device, the login page providing an option to access an authentication server. Next, selecting the option to access the authentication server with the second device, then receiving on the second device an access code from the authentication server. Next, the access code is transferred to a first device, the first device being authenticated by the authentication server before or after receiv ing the access code. The first device access code is transferred to the authentication server for generation of an authorization code by the authentication server. Next, the authorization code is received on the second device for transfer to the resource server.
  • the inventive method describes a method for providing a user access to a secure resource on a resource server with a second device that is not authenticated, the method comprising the acts of: transmitting to the second device an access code from an authentication server. Next, authenticating a first device, and after authenticating the first device, receiving the access code on the authentication server from the first authenticated device. Lastly, an authorization code is generated on the authentication server and transmitted from the authentication server to the second device.
  • the inventive method includes the additional acts of: receiving on the resource server the authorization code from the second device; and then providing access to the second device to the secure resource.
  • the authorization code may be transferred from the resource server to the authentication server with a token being generated on the authentication server, and optionally transferred to the resource server.
  • the first device is authorized for access to the secure resource.
  • the resource server and authentication server are programmed to perform the acts specified in the inventive method.
  • FIG. 5 a conventional login page is used to obtain access rather than having an authenticated device receive an access code from a non- authenticated device.
  • a user can be provided with a single login page that includes both a QR code and conventional login access so that the user can proceed with either the system of FIG. 2 or FIG. 5.
  • FIG. 5 system of direct mode authentication binding using tap to login 500 features steps 0, OA, 1, 2, 4, 4A, and 5-9 that are substantially the same as FIG. 2. The steps that are different will be described now.
  • the web browser need not be a second device, which is generally a device that has not been registered for authentication, but can also be the first device that is authenticated in steps 1 and 2. That is why FIG. 5 refers to a web browser on a device 502 which can be the first device (a registered device) or device 2, a non-registered second device.
  • Step 0C - The authentication server 230 returns 505 a login page to the web browser on device 502.
  • the login page contains a field to enter a credential.
  • the credential can be the same as the user ID of step 1 or some other identification including a password, e-mail address, user name, or the like. It is possible to combine the systems by optionally providing a QR as an option to Device A, so the user can proceed as in FIG. 5 or as in FIG. 6 as described below.
  • Step 0D The user initiates 510 tap-to-login on web browser by entering credential, the information required by the login screen, wherein authentication server 230 transmits 515 a login request (step X in FIG. 5) to first device 235 if such a login request is not part of step 2.
  • First device 235 which was authenticated in steps 1 and 2, confirms 520 the login request to authentication server 230.
  • FIG. 5 describes a method for accessing a secure resource on a resource server, the method comprising the acts of: accessing a login page for the secure resource with a second device, the second device being a non-authenticated device, the login page providing an option to access an authentication server. Next, the second device is used to select the option to access the authentication server. Next, the second device receives a login page from the authentication server; a credential is entered to request login.
  • the login request is confirmed with the first device - the first device hav ing been authenticated to the authentication server for generating an authorization code by the authentication server.
  • the authorization code for transfer to the resource server is received on the second device, and after the code is received - the second device accesses the resource server.
  • the present invention discloses a method for accessing a secure resource on a resource server, including the steps of: accessing a login page for the secure resource with an authenticated device, the login page providing an option to access an
  • a method for providing a user access to a secure resource on a resource server with a second device that is not authenticated comprising the acts of transmitting to the second device an access code from an authentication server.
  • a first device is then authenticated, and after this authentication, the authenticated server receives the access code from the first authenticated device.
  • the authentication server generates an authorization code
  • the authentication server transmits the authorization code from the authentication server to the second device.
  • This inventive method may optionally include the additional acts of: receiving on the resource server the authorization code from the second device, and providing access to the second device to the secure resource.
  • the method may include the additional acts of transferring the authorization code from the resource server to the authentication server and generating a token on the authentication server.
  • the method may additionally include the additional act of transferring the token to the resource server.
  • the first device is authorized to access the secure resource.
  • the resource server and authentication server may be programmed to perform all the acts specified.
  • FIG. 6 shows single device login 600 where a user initiates a login into a website on a web browser of a first device with an authenticated device prior to login for access to a secure resource on a resource server. Upon authentication the user is logged into the website on the first device.
  • the device has loaded on it: (i) an authentication application 605, and (ii) a browser and/or access application 610, access application 610 is tailored for access to secure resource server 615.
  • the device browser and/or access application 610 is shown multiple times for illustrative purposes, however,
  • Steps 1, and 6-9 are substantially the same as in FIG. 5, and thus only the other steps will be discussed in detail.
  • Step 0 - To access a secure resource on the client server, the user has two choices. First, the user can use a browser on the user's device to access a login page that includes an option for access with an authenticated device, such as a TRAITWARETM button option. Second, the user can open an access application that provides the same option. Thus a client website login page is displayed 205 on the web browser of the user's device or the access application 610 installed on the device is opened. Step 0B - The user initiates a login attempt 618. The user can initiate login attempt 618 on the web browser by clicking a login button, or the user initiates login attempt 618 from the access application. Login attempt 618 is automatically redirected 605 to authentication server 230.
  • an authenticated device such as a TRAITWARETM button option.
  • Step 0B - Step 0C results in a login screen being presented 505 to the user with the option to authenticate using the authentication application previously installed on the first device.
  • step 0E the user chooses to authenticate using the authentication application on the first device, the access request being passed 619 to the device authentication application 608 on the same device.
  • the transaction request can include a session identifier and client id to the authentication application.
  • Step 2 - The authentication server in response to the authentication request 225 responds 620 with an authorization code if the authentication is successful.
  • Step 5 The authorization code is passed 625 from the authentication application on the device to the access application or web browser on the device.
  • the authentication server associates the User ID or Device ID from the device with the browser application that initially requested the login authentication via the website on the device web browser or the resource application on the device. This association acts as an authorization credential for subsequent login attempts (See Figure 8). If the authentication request is denied an association is not made.
  • Step 6 The device website browser or second access application on the device 610 passes 630 the authorization code to resource server 615 using a redirect URI and authorization code with the state (session) identifier. "State" is a unique value used by the application to prevent cross-site request forgery (CSRF) attacks on the
  • the value is typically a random unique string for a particular request, unguessable and kept secret.
  • Step 0B on FIG. 6, and Step OA in FIGS. 2, 5, and 8 the user initiates a transaction request (Step 0B on FIG. 6, and Step OA in FIGS. 2, 5, and 8), and the rest of the process is automatic, with the exception being that the user can be required to enter a credential in step 1.
  • opening an application in step 0 may automatically trigger 0B and the rest of the process is automatic, the exception being that the user can be required to enter a credential in step 1.
  • the above processes and methods described by FIGS. 2, 5, and 6 can include passing some initial credentials to the resource server for authentication prior to authenticating the device via the authentication server.
  • Initially authenticating with the resource server (also referred to as a client server), for example, using a traditionally typed User ID and password, can grant a user access to a QR code that they can scan or a registration code that they can input on the user's device.
  • This initial authentication can include entering a PIN, a password, a PHOTO AUTHTM sequence, a biometric, a biometric hash, a biometric feature set, hardware profile or other authentication methods known in the art.
  • the association of the resource server with the User ID or Device ID of the first device grants subsequent direct access from the user's device to the resource server. Alternatively, it can also allow the user to bypass traditional login screens of the resource server and use the methods and processes disclosed to authorize access to the resource server.
  • a resource authorization credential is created on the resource server.
  • the resource authorization credential can be stored on the resource server, the authentication server, or both. See FIG. 7 and corresponding description for an overview of the process.
  • FIG. 6 System include: a method to access a secure resource on a resource server comprising the acts of requesting access to the secure resource with a web site browser on a device and receiving a login page from an authentication server on the device.
  • the act of transmitting the access request to an authentication application on the device occurs automatically.
  • the acts of using the device authentication application, receiving the authentication code, and transmitting the authorization code occur automatically.
  • the inventive method includes the steps of requesting access to a secure resource on a resource server comprising the acts of: requesting access to the secure resource with an access application on a device and receiving a login page from an authentication server on the device. Next, using the login page, requesting access to the secure resource and transmitting the access request to an authentication application on the device. Next, authenticating the device with the authentication server. Next, receiving an
  • a method to access a secure resource on a resource server comprising the acts of: a) receiving on the resource server a request for access to the secure resource from a device and in response thereto transmitting a login page from an authentication server to the device; b) receiving from the device on the authentication server an authentication request and if the device is authenticated, in response thereto providing an authorization code; c) receiving from the device the authorization code on the resource server; d) granting to the device access to the secure resource.
  • steps (c) - (e) may occur automatically.
  • a system for performing the inventive method comprising the
  • authentication server and resource server programmed for performing their respective acts.
  • the authentication application performs the acts of: a) transmitting device trait characteristics and a user id to an authentication server and receiving an authentication response and authentication code from the authentication server; and b) passing the authorization code to a web site browser or access application on the device.
  • the authentication application may perform the acts of (a) transmitting device trait characteristics and a user id to an authentication server and receiving an authentication response and authentication code from the authentication server; and (b) pass the authorization code to a web site browser or access application on the device.
  • a user ID is generated and stored to allow access to the secure resource with the device.
  • FIG. 7 A method of direct mode login after binding 700 is illustrated by FIG. 7. Once a user has authenticated a device, and if the user's User ID or Device ID has been given authorization credentials to a client or third party application (FIGS. 2, 5, or 6), the user can quickly make login attempts from the device using the authentication application and web browser on the first device.
  • a client or third party application FIGS. 2, 5, or 6
  • Step 1 The device authentication application 705 passes 710 a User ID and device trait characteristics to authentication server 715 for authentication.
  • the device is also provided with a list of available applications for direct login attempts for which the device has already been provided access using the systems shown in FIGS. 2, 5, or 6. The user is allowed to use the functionality of the authentication application on the first device.
  • Step 3 The user can access the direct login application list on the device. An application is selected from the list and the login request is passed 725 to authentication server 715.
  • Step 4 - Authentication server (715) returns 732 an authorization code response appended to a redirect URI for the resource.
  • Step 5 - Device authentication application 705 passes 735 a redirect URI and authorization code to device website browser 740.
  • the device website browser 740 uses the redirect URI and authorization code and passes 745 them to resource server 730.
  • Step 7 - Resource server 730 passes 750 authorization code to authentication server 715, and in Step 8 the authentication server 715 returns 755 an access token to resource server 730. In this way, the resource server exchanges the authorization code for a token.
  • Step 9 - Resource server 730 grants 760 access to secure resources to the device web browser 740.
  • the direct mode method can also be used to login to a second (or more) applications and is not exclusive to using a web browser on the device to login to a secure resource.
  • the authorization code and redirect URI are passed to the second application.
  • the second application passes the authorization code and redirect URI to the resource server.
  • the client or third party server exchanges the authorization code for a token with the authentication server.
  • the resource server then grants access to the secure resource to the second application on the device.
  • the second application may require separate authentication in addition to the authentication of the first application. This could include entering a PIN, a password, a PHOTOAUTHTM sequence, a biometric, a TRAIT WARETM hardware profile, or other authentication method.
  • a list of available applications/websites is populated within the application.
  • a method accessing a secure resource on a resource server comprising the acts of: a) authenticating a device by transmitting device trait characteristics and a user identification to an authentication server; b) receiving from the authentication server on the authenticated device a list of secure resources; c) using the authenticated device to request from the authentication server access to at least one of the secure resources; d) receiving on the authenticated device from the authentication server an authorization code; e) transmitting to the resource server hosting the requested secure resource the authorization code; and f) after step (e), accessing the requested secure resource.
  • a method of providing to a device access to a secure resource on a resource server comprising the acts of: a) receiving on an authentication server from the device, device trait characteristics and a user identification; b) determining if the device is a registered device and if it is, transmitting to the device a list of accessible secure resources and an authorization code; c) receiving on the resource server from the device the authorization code; and d) providing to the device access to the secure resource.
  • a system for performing the method of the above method comprising the authentication server and the resource server programmed to perform the acts of feature 2.
  • Single device login is a process where a user initiates a login into a secure resource on a web browser of a device or an application on the device by authenticating the dev ice prior to login. Upon authentication the user is logged into the secure resource.
  • the single device mode simplifies the user experience when using multifactor authentication.
  • the user has a device that is registered with an authentication service. When the user access a resource that is set up to use the authentication service the user can connect seamlessly to an authenti cation application as if i t was part of the resource site.
  • single device login using web browser or access application system 800 has the following steps and features:
  • the user initiates 805 a login attempt on a device web browser or access application 810. This can be done, as illustrated in Step 1 A, by clicking a login button on a web browser or access application directed 812 to a TRAIT WARETM authentication server 830.
  • Step IB the login attempt on a device web browser or access application 810.
  • TRAITWARETM authentication server 830 automatically presents 816 a login screen, such as a TRAITWARETM login page, to device web browser or access application 810.
  • the login page can contain an access code such as a QR code and a field to enter a credential.
  • Step 2 Tapping the login button passes 815 a session identifier (State) and client id to the device authentication application 820.
  • Step 3 The device
  • authentication application 820 passes 825 a user identification and hardware
  • the device authentication application 820 receives 835 a successful authentication response. Included in the response is an OAuth type
  • Step 5 The redirect URI with the appended authorization code and state are passed 840 to device web browser or access application 810.
  • Step 6 The first device web browser 810 passes 845 an authorization code or call to resource server 855 using the redirect URI and authorization code with the state identifier.
  • Step 7 The resource server 855 exchanges 850 the authorization code for a token which is provided by authentication server 830.
  • Step 8 - Resource server 855 grants 860 access to the secure resource to the device web browser or access application 810.
  • the above processes and methods optionally can include passing some initial credentials to a resource server for authentication in Step 3 prior to authenticating the device via the authentication server.
  • Initially authenticating with a resource server can grant a user access to a QR code that the user can scan or a registration code that the user can input on the user's device.
  • This initial authentication can include entering a PIN, a password, a PHOTOAUTHTM sequence, a biometric, a biometric hash, a biometric feature set, a device trait characteristics or other authentication methods known in the art.
  • the access application can require separate authentication in addition to the authentication of the authentication application. This could include entering a PIN, a password, a
  • PHOTOAUTHTM sequence a biometric, a TRAITWARETM trait signature, or other authentication methods known in the art.
  • sample screen shot 900 provides an example of a version of the invention.
  • the user opens a website 905 that is set up for second factor
  • the user clicks on "login with TRAITWARETM " link 910 that takes the user to the authentication server's site and present (as illustrated by FIG. 1 0) a new page 1000.
  • the initial web server can also serve as the authentication site so everything can be done from the first page presented to the user. Stated another way, the user does not need to be redirected from a resource server to an authentication server because they are the same server.
  • the authentication server is providing the connection to the authentication application via embedded code in the "Login with TRAITWARETM App" button 1005. Clicking button 1005 launches the authentication application. When the user clicks button 1005, the authentication application is then opened to the
  • FIG. 1 1 which in this example is a PHOTOAUTHTM sign-in 1 100 as shown in
  • the user is prompted 1 105 to enter a PHOTOAUTHTM Key.
  • the authentication server verifies the correct key was entered and that the device is registered to a particular user and that the particular user has access rights to the resource that the user's trying to access.
  • the user checks that the digitally signed and sent packet of the device trait characteristics came from the user's registered device.
  • the user is granted access to the resources and the secure resource application or website opens 1200 (FIG. 12 ) on the user's dev ice when the user trait characteristics and user information are verified on the authentication server and when the digitally signed packet is verified with the users public key.
  • FIG. 13 shows an automatic login request redirected to the authentication server for a login attempt 1300 where a user first visits a website on a web browser or opens an access application on a device to login for access to a secure resource on a resource server. Upon authentication the user is logged into the website or access application.
  • the first device 1335 has loaded on it: (i) an authentication application 1308, and (ii) a browser and/or access application 1310; access application 1310 is tailored for access to secure resource server 1315.
  • the device browser and/or access application 1310 is shown multiple times for illustrative purposes, however, browser/access application 1310 is a single process.
  • the website browser and the access application 1310 may be installed on a second device.
  • the login page 1305 may contain elements, such as a visual QR code, provided from information returned from the authentication server. These elements may be displayed side-by-side with traditional login elements like username and password fields.
  • Steps 1, and 6-9 are substantially the same as in FIG. 5, and thus the other steps will be discussed in detail now.
  • Step 0 - client website login page is presented 1305 on the device web browser or access application 1310. (For an access application, the application installed on that device would be opened). Login request is automatically sent 1318 to block 1307. It should be noted that to access a secure resource on the client server, the user has two options. In a first option, the user can use a browser 1310 on a device to access a login page that automatically sends a login request 1318 to a specified login authentication server 1325, such as a TRAITWARETM authentication server. In a second option, the user can open an access application 1310 that performs the same login request 1318.
  • a specified login authentication server 1325 such as a TRAITWARETM authentication server.
  • Step OB - Step OC results in a login screen being presented to the user with the option to authenticate using the authentication application previously installed on the first device.
  • a QR code may be displayed for scanning by the first device 1335.
  • the access request is passed 1319 to the device authentication application 1308 on the same device.
  • the transaction request can include a session identifier and client id to the authentication application.
  • the first device 1335 sends an authentication request 1322 to the authentication server 1325.
  • the authentication server responds 1323 with an authorization code sent to first device 1335 (Step 2).
  • the process determines if authentication is successful, the authentication server 1325 associates (Step 4A) the User ID or Device ID from the device with the browser application that initially requested the login authentication via the website on the device web browser or the resource or access application on the device. This association acts as an authorization credential for subsequent login attempts (See Figure 8). If the
  • the authorization code is passed 1327 from the authentication application 1308 on first device 1335 to the access application or web browser 1310 on the device (Step 5).
  • Step 6 - Website browser or access application 1310 utilizes the redirect
  • Steps 7 and 8 - Authorization code is passed 1375 from resource server
  • Step 9 resource server 1315 grants 1385 device website browser or access application 1310 access to the secure resource.
  • steps 3-9 cover the process, where optionally a QR code may be scanned.
  • the act of authentication on the first device may also happen automatically so as to produce a seamless login experience for the user.
  • These processes may include: (i) the ability to scan a QR code to login to a website (FIG. 3), (ii) the ability to login to a website using a direct login button (FIG. 4), (iii) logging into a website or application on the same device that the authentication application is installed (FIG. 10), (iv) using tap-to-login where a notification for a login attempt is sent to an authentication application and the user has the ability to authenticate and allow the login attempt to proceed (FIG. 5), (v) the ability to request a code to add other devices to an existing authentication server user account (FIG. 1), and (vi) the ability to enter a code from an authenticated device into an authentication application on a second device, which on authentication adds that device to an account of the previously existing authentication server user account (FIG. 1).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)
  • User Interface Of Digital Computer (AREA)

Abstract

L'invention concerne un système et un procédé d'authentification d'au moins un dispositif, aux fins d'accès à une ressource sûre, à l'aide de caractéristiques de traits du dispositif et de l'identification de l'utilisateur. Selon des modes de réalisation, la présente invention concerne un système d'authentification (100) de multiples dispositifs, un système d'authentification en mode direct à l'aide d'un code d'accès (200), un système d'authentification en mode direct (300), une liaison en mode direct à l'aide d'une dérivation pour connexion (500), un système de liaison d'authentification en mode direct - connexion de dispositif unique (600), une liaison après connexion en mode direct (700) et une connexion de dispositif unique à l'aide d'un navigateur Internet ou d'une application d'accès (800). Des modes de réalisation donnés à titre d'exemples comprennent : l'obtention d'information d'utilisateur concernant l'utilisateur d'un matériel, l'authentification de l'utilisateur à partir de ces informations d'utilisateur, l'obtention d'un profil matériel du dispositif, le profil matériel comportant des données générées par l'utilisateur et enregistrées dans le dispositif, et le rattachement des informations d'utilisateur et du profil matériel sous forme d'identification électronique combinée.
PCT/US2015/011330 2012-03-16 2015-01-14 Système d'authentification WO2015108924A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US15/111,778 US20160337351A1 (en) 2012-03-16 2015-01-14 Authentication system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201461927936P 2014-01-15 2014-01-15
US61/927,936 2014-01-15

Publications (2)

Publication Number Publication Date
WO2015108924A2 true WO2015108924A2 (fr) 2015-07-23
WO2015108924A3 WO2015108924A3 (fr) 2015-11-19

Family

ID=53543606

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2015/011330 WO2015108924A2 (fr) 2012-03-16 2015-01-14 Système d'authentification

Country Status (1)

Country Link
WO (1) WO2015108924A2 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017058093A1 (fr) * 2015-09-29 2017-04-06 Sth Development & Design Ab Procédé et système d'identification
EP3362935A4 (fr) * 2015-10-12 2018-08-22 Telefonaktiebolaget LM Ericsson (PUBL) Procédés pour autoriser des dispositifs d'utilisateur secondaires pour des services de réseau et dispositifs d'utilisateur et systèmes dorsaux associés

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7548890B2 (en) * 2006-11-21 2009-06-16 Verient, Inc. Systems and methods for identification and authentication of a user
WO2009127984A1 (fr) * 2008-04-18 2009-10-22 International Business Machines Corporation Authentification des transmissions de données
EP2611096A1 (fr) * 2011-12-28 2013-07-03 Gemalto SA Procédé d'authentification d'utilisateur en utilisant un deuxième terminal mobile
WO2013138714A1 (fr) * 2012-03-16 2013-09-19 Acuity Systems, Inc. Système d'authentification

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017058093A1 (fr) * 2015-09-29 2017-04-06 Sth Development & Design Ab Procédé et système d'identification
EP3362935A4 (fr) * 2015-10-12 2018-08-22 Telefonaktiebolaget LM Ericsson (PUBL) Procédés pour autoriser des dispositifs d'utilisateur secondaires pour des services de réseau et dispositifs d'utilisateur et systèmes dorsaux associés
US10798096B2 (en) 2015-10-12 2020-10-06 Telefonaktiebolaget Lm Ericsson (Publ) Methods to authorizing secondary user devices for network services and related user devices and back-end systems
US11522861B2 (en) 2015-10-12 2022-12-06 Telefonaktiebolaget Lm Ericsson (Publ) Methods to authorizing secondary user devices for network services and related user devices and back-end systems

Also Published As

Publication number Publication date
WO2015108924A3 (fr) 2015-11-19

Similar Documents

Publication Publication Date Title
US20160337351A1 (en) Authentication system
US10929524B2 (en) Method and system for verifying an access request
US8499166B2 (en) Controlling access to a protected network
US8769655B2 (en) Shared registration multi-factor authentication tokens
EP2834959B1 (fr) Authentification sécurisée dans un système multipartite
US20230055282A1 (en) Multi-Factor Authentication with Increased Security
CN101453458B (zh) 基于多变量的动态密码口令双向认证的身份识别方法技术
CA3035817A1 (fr) Systeme et methode d'authentification decentralisee employant une machine d'etat fondee sur une transaction distribuee
KR101451359B1 (ko) 사용자 계정 회복
US20050021975A1 (en) Proxy based adaptive two factor authentication having automated enrollment
JP2009508189A (ja) 拡張ワンタイム・パスワード方法および装置
EP1290850A2 (fr) Systeme et procede d'authentification
WO2008067646A1 (fr) Procédé et système d'amorçage sécurisé de client
WO2020232336A1 (fr) Système et procédés d'utilisation d'un portail web unique de confiance pour accéder à de multiples services web
CN109716725B (zh) 数据安全系统及其操作方法和计算机可读存储介质
Oh et al. The security limitations of sso in openid
US20220116385A1 (en) Full-Duplex Password-less Authentication
CN109784024A (zh) 一种基于多认证器多因子的快速在线身份认证fido方法和系统
US20180232516A1 (en) System of device authentication
CN113569210A (zh) 分布式身份认证方法、设备访问方法及装置
WO2015108924A2 (fr) Système d'authentification

Legal Events

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

Ref document number: 15737875

Country of ref document: EP

Kind code of ref document: A2

WWE Wipo information: entry into national phase

Ref document number: 15111778

Country of ref document: US

NENP Non-entry into the national phase in:

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15737875

Country of ref document: EP

Kind code of ref document: A2