GB2531711A

GB2531711A - Authentication system and method of authentication

Info

Publication number: GB2531711A
Application number: GB1418937.7A
Authority: GB
Inventors: John Parks Benjamin
Original assignee: Canon Europa NV
Current assignee: Canon Europa NV
Priority date: 2014-10-24
Filing date: 2014-10-24
Publication date: 2016-05-04
Anticipated expiration: 2034-10-24
Also published as: GB201418937D0; GB2531711B

Abstract

Disclosed is an authentication system consisting of a wireless mobile device and a control device. The mobile device detects the proximity between it and the control apparatus. If the mobile device is proximate to the control apparatus, a local network between the mobile device and the control apparatus is established, and authentication information is sent from the mobile device to the control apparatus. The mobile device may detect how close it is to the control unit based on the beacon signal strength. The beacon may use the iBeacon protocol and the local network may be setup by the mobile device broadcasting address information request and the control device responding by sending its address. The authentication information may be a token generated by an authentication application. The control apparatus may be a multifunction printer, and the mobile device may be a smart phone.

Description

AUTHENTICATION SYSTEM AND METHOD OF AUTHENTICATION

BACKGROUND OF THE INVENTION Field of the Invention

[0001] The present invention relates to an authentication system including a mobile device and a control device, and a method of authenticating.

Description of the Related Art

[0002] It is known to authorise a user to a use a particular piece of apparatus, or allow access to a building or area, using an identification card. The piece of apparatus may be a control apparatus, a printing device, a scanning device, a multifunctional device, or any other device requiring authentication before use. Such an identification card may be a smart card, otherwise called a chip card or integrated circuit card (ICC). Such a smart card is any pocket- -2 -sized card with embedded integrated circuits. The identification card may also be a simple plastic, or paper card, with a magnetic stripe.

[0003] The identification card includes authentication information stored thereon. For example the authentication may be stored in an integrated chip included on the card, or stored as magnetic information in a magnetic stripe. The authentication information is pre-stored on the card and allows identification of a user. Generally the authentication information is unique to a particular user (person), but this is not always the case. For example a user may be part of a group that is allowed authentication/access and the identification information may simply identify the group.

[0004] When a user wishes to gain authentication to use an apparatus, or gain access to a building (for example), they present the identification card to a -3 -card reader. The card reader reads the identification information from the card, and based on the identification read, determines whether that user/person is authenticated or allowed access.

[0005] In order for the card reader to read the identification information a user needs to bring the identification card into contact with, or very close proximity with, the card reader. In some situations, for example if a user wishes to gain access to a car park, this requirement of contact or close Proximity can be an inconvenience to the user. As another inconvenience, a user is required to carry the identification card with them at all times.

[0006] Furthermore, the identification information stored on the identification card may not be particularly secure. For example, the identification information could be stolen or copied by a malicious person, allowing unauthorised access. -4 -

[0007] An aim of the present invention is to provide a secure authentication system that also reduces any inconvenience to a user.

SUMMARY OF THE INVENTION

[0008] According to a first aspect of the present invention there is provided an authentication system as set out in claims 1 to 11.

[0009] According to a second aspect of the present invention there is provided a method of authentication between a control apparatus and a mobile device as set out in claims 12 to 22.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Embodiments of the present invention will now be described, by way of example only, with reference to the accompanying figures. Each of the embodiments of the present invention described below can be -s -implemented solely or as a combination of a plurality of the embodiments or features thereof where necessary or where the combination of elements or features from individual embodiments in a single embodiment is beneficial.

[0011] Figure 1 shows the general arrangement of an authentication system in accordance with a first embodiment.

[0012] Figure 2 shows a block diagram of the components of a mobile device; [0013] Figure 3 shows a block diagram of the components of a multifunctional device; [0014] Figure 4 shows an example of a hierarchical structure defined by beacon information; [0015] Figure 5 shows a flow diagram of the operations carried out by the mobile device; [0016] Figure 6 shows a flow diagram of the operations carried out by the multifunction device. -6 -

DESCRIPTION OF THE EMBODIMENTS First Embodiment

[0017] Figure 1 shows a general arrangement of an authentication system according to a first embodiment. 5 The authentication system comprises a mobile device 10, a first multifunctional device (hereinafter referred to as "MFP") 20, and a second MFP 30. Mobile device 10 is shown as being a mobile telephone, and particularly a "smart"-type mobile telephone. Although a mobile 10 telephone 10 is described in this embodiment, other embodiments could make use of a laptop computer, tablet computer, FDA or other mobile device. Further, although the first MFP 20 and the second MFP 30 are described in this embodiment, other embodiments could make use of a single function printer or single function scanner, or other apparatus. The first MFP 20 and the second MFP 30, or any other apparatus, may be considered as a control apparatus. Any number of -7 -multifunction or control apparatuses may be provided.

[0018] Each MFP includes a beacon transmitter. As shown the first MFP 20 includes a first beacon transmitter 40 and the second MFP 30 includes a second beacon transmitter 50. The first and second beacon transmitters 40, 50 continually transmit, or broadcast, information. The broadcast information is in accordance with the iBeacon protocol, a TM of Apple Inc. [0019] Figure 2 shows a block diagram of the components of mobile device 10. As shown the mobile device includes a beacon reception means 12, a local network establishment means 14, an authentication means 16, a central processing unit (CPU) 18, and an input means 19. The CPU 18 is connected to the beacon reception means 12, the local network establishment means 14, the authentication means 16, and the input means 19, and performs overall control.

[0020] The beacon reception means 12 includes a -8 -Bluetooth receiver for receiving the broadcast information, or iBeacon signal, from the first beacon 40 and second beacon 50. The Bluetooth receiver is any standard Bluetooth receiver typically installed in mobile devices such as mobile telephones. The beacon reception means 12 may also include software for analysing the received iBeacon signal.

[0021] The local network establishment means 14 includes a transmitter and receiver, or transceiver, used for establishing a local network connection with the first MFP 20 or the second MFP 30. Any transmitter/receiver or transceiver may be used as long as is able to establish wireless two-way communication with a corresponding transmitter/receiver or transceiver in the first MFP 20 or the second MFP 30. For example, a Bluetooth transmitter and receiver could be used, and the same Bluetooth receiver as used in the beacon reception means 12 may be utilised. -9 -

Alternatively, a transmitter and receiver operating under the WIFI protocol may be provided (e.g. local area wireless -(IEEE) 802.11 standard). In the embodiment the local network establishment means 14 uses the mDNS protocol (multicast Domain Name System protocol) to establish the local network with the first MFP 20 or the second MFP 30.

[0022] The authentication means 16 includes software, or an application, for authenticating a user. The authentication software may take any form. For example, the user may be authenticated by a login application requiring a username and password to be entered using the input means 19 (such as a keypad). Alternatively, the user may be authenticated using a social media login as described in EP2765529. As another alternative, the user may be authenticated using DAuth, an open standard of authentication. As a further alternative, the authentication means 16 may include -10 -other means of authentication such as finger print recognition or retina recognition. In this case, input means 19 may include a finger print reader or a retina reader/scanner.

[0023] Figure 3 shows a block diagram of the components of the first MFP 20. Although the first MFP 20 and first beacon 40 are shown, the second MEP 30 and second beacon 50 are substantially the same, and to avoid duplication, any discussion below concerning the first MFP 20 and first beacon 40 applies equally to the second MFP 30 and second beacon 50.

[0024] The first MFP 20 includes a local network means 22, an authentication means 24, a central processing unit (CPU) 26, a printer/scanner means 28, and a user interface 29. The CPU 26 is connected to the local network means 22, the authentication means 24, the printer/scanner means 28, and the user interface 29, and performs overall control.

[0025] The local network means 22 includes a transmitter and receiver, or transceiver, used for establishing a local network connection with the mobile device 10. Any transmitter/receiver or transceiver may 5 be used as long as it is able to establish wireless two-way communication with mobile device 10. For example, a Bluetooth transmitter and receiver could be used. Alternatively, a transmitter and receiver operating under the WIFI protocol may be provided (e.g. 10 local area wireless -(IEEE) 802.11 standard). However, it should be noted that local network means 22 is separate from the beacon 40. In the embodiment the local network means 22 uses the mDNS protocol (multicast Domain Name System protocol) to establish a 15 local network with the mobile device 10.

[0026] The authentication means 24 is provided to authorise use of the first MFP 20. In particular, until authentication means 24 determines that a user is -12 -authenticated, the user interface 29 is disabled. The authentication means 24 determines whether a user is authenticated based on authentication information received at the local network means 22 from the mobile device 10.

[0027] The printer/scanner means 28 includes standard printing and scanning functions typically provided in a multifunctional device. The printer/scanning means 28 is not limited to these functions and may include other functions, such as a facsimile function and a copy function. The various functions are controlled via the user interface 29.

[0028] The user interface 29 typically includes a touch sensitive display, or a hard key-pad/buttons.

The user interface 29 allows a user to access functions on the first MFP 20 by selecting various buttons and menus displayed on the touch sensitive display. Before a user is authenticated for use of the first MFP 20, -13 -the user interface 29 is disabled and the touch sensitive display may display a blank screen, or a screen indicating that access to the first MFP 20 is not possible at that time.

[0029] Figure 3 shows the first beacon 40 connected to the CPU 26 by a dotted line. The dotted line represents the possibility of the first beacon 40 being either independent from the first MFP 20, or being dependent on the first MFP 20 in some form. In the case where the first beacon 40 is independent from the first MFP 40, the first beacon 40 is not connected to the CPU 26 or any other part of the first MFP 20 electrically or wirelessly. In this case, the first beacon 40 includes its own power supply 42 and a Bluetooth transmitter 44 that continuously transmits the broadcasts information (iBeacon) no matter what the status of the first MFP 20. The first beacon 40 may include an on/off-switch (now shown) allowing the first -14 -beacon 40 to be turned off (for example allowing servicing/maintenance).

[0030] In the case where the first beacon 40 is not independent from the first MFP 20, the first beacon is connected to the CPU 26 and may optionally be supplied power from the first MFP 20 (not shown). In this case the first MFP 20, via the CPU 26, may turn off or disable the first beacon, or otherwise stop it from transmitting the broadcast information (iBeacon) at certain times. For example, the CPU 26 may disable the first beacon 40 when the first MFP 20 is in a power saving or sleep mode. In another example, where the first MFP 20 may only be used during certain times of the day, the first beacon may be activated at only times when the first MFP 20 can be used.

[0031] In both cases described above, the transmitter 44 is a Bluetooth low energy transmitter that transmits the broadcast information -15 -omnidirectionally. As mentioned above the information broadcast by the first beacon 40 is in accordance with the iBeacon protocol. The iBeacon protocol uses Bluetooth Low Energy (BLE) to transmit the broadcast information.

[0032] In accordance with the iBeacon protocol the broadcast information includes three fields: a unique identifier field (WM), a Major field and a Minor field. The UUID field has a size of 16 bytes whereas the Major and Minor fields are each 2 bytes. The UUID field and the Major and Minor fields provide unique identification information of the first beacon 40. The three fields of the broadcast information may be used hierarchically to provide location information. For example, the unique identifier field (UUID) may be unique to a company building, the Major field may identify a floor within the company building, and the Minor field may identify a department within a -16 -particular floor of the building. Figure 4 shows an example of such a hierarchy. As shown, a head office and a sub-office are identified using different UUID's. The head office is shown having three floors and the sub-office having two floors, and these are indicated by the Major field. Example departments for the first floors in each building are shown indicated by different Minor fields. Figure 4 is only one example of a possible hierarchy. The QUID, Major and Minor fields can be used in any suitable manner to identify different apparatuses.

[0033] The three fields, QUID, Major and Minor may

be programmed and recorded in transmitter 44 at the time of, or after, manufacture. If programmed and recorded after manufacture, a means of receiving and recording the appropriate UUID, Major and Minor fields is provided in the first beacon 40 (not shown).

[0034] A feature of the iBeacon protocol is that by -17 -transmitting the broadcast information the first beacon 40 is able to establish a region around itself, and a device, such as the mobile device 10, running appropriate software is able to determine when it has entered the region around the first beacon 40, and is able to estimate its proximity to the first beacon 40. In other words, it is possible for the mobile device 10 receiving the broadcast information from the first beacon 40 to determine when it is proximate to the first beacon 40. The mobile device 10 will also be able to determine when it is proximate to the second beacon 50. By using the iBeacon protocol, no two way communication between the first beacon 40 and the mobile device 10 is necessary to determine proximity.

[0035] The iBeacon protocol allows for four different proximity states to be estimated. The four states are summarised in Table 1 below.

-18 -

Table 1

Proximity state Distance Immediate Very close, e.g. within a few centimetres.

Near Within about 1 to 3 metres.

Far Greater than about 10 metres.

Unknown Proximity cannot be determined.

[0036] In the present embodiment, the mobile device is determined to be proximate to the first beacon 40 5 or second beacon 50 when the iBeacon proximity state is Immediate or Near. However, in other embodiments proximity may be determined when the iBeacon proximity state is Immediate. In further embodiments Far may also be used to determine when the iBeacon is Proximate. 10 The choice of Immediate, Near or Far, or a combination of these, may be pre-set or may be user configurable.

[0037] The operation of the authentication system -19 -will now be described with the assistance of figures 5 and 6. Figure 5 shows a flow diagram of the operations carried out by the mobile device 10, and figure 6 shows a flow diagram of the operations carried out by the first MFP 20 (or second MFP 30).

[0038] with reference to figure 5 the processing performed in the mobile device 10 will be described. In step S101 the beacon reception means 12 of the mobile device 10 receives the broadcast information (iBeacon) from the first beacon 40 (assuming that it is close enough to receive the broadcast information). Although, the reception of the broadcast information from the first beacon 40 is described, reception from the second beacon 50 applies equally.

[0039] In step 5102 the beacon reception means 12 determines whether the mobile device 10 is proximate to the first beacon 40. This is determined based on the iBeacon protocol using software included on the mobile -20 -device 10 (the beacon reception means 12). If the proximity state, determined from the iBeacon protocol, is found to be Immediate or Near, the mobile device 10 is judged to be proximate the first beacon 40 (YES in step S102). On the other hand if the proximity state is found to be Far or Unknown the mobile device 10 is determined not to be proximate the first beacon 40 (NO in step 5102). In another embodiment, the proximity state of Far (and Immediate and Near) may be used to indicate that the mobile device 10 is proximate, and the Unknown proximity state may be used to indicate that the mobile device 10 is not proximate to the first beacon 40.

[0040] In the case where the determination is NO in step 5102, no further action is taken and the flow returns to step 5101. In other words, the mobile device 10 continually monitors for broadcast information (iBeacon signals), and only when it is -21 -determined that the mobile device 10 is proximate to the first beacon 40 in step 5102 does it continue to the remaining steps of figure 5.

[0041] In the case where the determination is YES in step S102, the flow proceeds to step S103. In step S103 the local network establishment means 14 of the mobile device 10 transmits a request, or query, for address information from a MFP according the mDNS protocol. At this stage the mobile device 10 has no knowledge of the address (e.g. IP address) of the MFP it is trying to contact as the broadcast information from the first beacon 40 (or second beacon 50) does not include this information.

[0042] In the mDNS protocol, when a client such as mobile device 10 wishes to connect with a host such as the first MFP 20, the client broadcasts, or transmits, a multicast query message (request) that asks for a host to provide its network address details (such as IP -22 -address) so that a local network can be established. The query message includes an indication of the host to which the client is trying to connect. If a host receives the query message to which it is directed, it replies by multicast transmitting a response message that includes its address information (such as its IP address). The client receiving the response message, which includes the address information, from the host then allows for a local network to be established between the client and host. A feature of mDNS is that ad-hoc local networks can be established without the use, or need, of a local server.

[0043] In the embodiment, the Major and Mincr fields from the broadcast information (iBeacon) are used in the mDNS query message, transmitted by the mobile device 10, to indicate the first MFP 20 (or second MFP 30) to which the mobile device 10 wishes to connect. The first MFP 20 keeps a record of the Major and Minor -23 -fields of the beacon 40 in, for example, the local network means 22. Similarly, the second MFP 30 also keeps a record of the Major and Minor fields of beacon 50. Upon reception of the query message from the mobile device 10, the local network means 22 determines whether the Major and Minor fields included in the query message from the mobile device 10 correspond to its own. If the Major and Minor fields match, the local network means 22 transmits the response message that includes its address information (such as its IP address). If the Major and Minor fields do not match, no further action is taken. In other embodiments the HUED together with the Major and Minor fields, or any combination thereof, may be used in the query message.

[0044] In step 5104 the local network establishment means 14 of the mobile device 10 receives the response message from the first MFP 20. Using the address information contained within the response message, in -24 -step 5105 the local network establishment means 14 of the mobile device 10 is able to establish a local network with the first MFP 20.

[0045] In step 5106 the authentication means 16 of the mobile device sends authentication information to the first MFP 20 using the established local network. If the authentication means 16 authenticates a user using Oath, the authorisation information may be a token, and more particularly an OAuth token.

[0046] The process carried out in the first MFP 20 (or second MFP 30) will now be described referring to figure 6. In step 5201 the first beacon 40 transmits the broadcast information (iBeacon). In step 5202 it is determined whether the local network means 22 of the first MFP 20 receives a request message from the local network establishment means 14 of the mobile device 10. If no request message is received (NO in step 5202) the flow returns to step 5201. In this manner the local -25 -network means 22 of the first MFP 20 takes no action until a request message from the mobile device is received, and the first beacon 40 continually transmits the broadcast information (iBeacon). In this state the user interface 29 of the first MFP 20 is disabled and no access to, or use of, the first MFP 20 is possible. It should be noted that even if a request message is received (YES in step 5202), the first beacon 40 may continue to transmit the broadcast information (iBeacon).

[0047] If it is determined that the local network means 22 of the first MFP 20 has received a request message from the mobile device 10 (YES in step 5202), and the Major and Minor fields in the Request message match its own records, the flow proceeds to step 5203.

[0048] In step 5203 the local network means 22 transmits a multicast response message that includes address information (such as its IP address). Once the -26 -local network establishment means 14 of the mobile device 10 receives the response message, in step 5204 a local network is established between the first MFP 20 and the mobile device 10.

[0049] In step 5205 the authentication means 24 of the first MFP 20 receives the authentication information from the mobile device 10 over the established local network. In step S206 the authentication means 24 checks the authentication information from the mobile device 10 to see if the user (of the mobile device 10) is authenticated. If the user is not authenticated the process returns to step S205. In this manner a user may be given the opportunity of retrying authentication on the mobile device 10. Until a user is authenticated, as indicated by the authentication information from the authentication means 16 of the mobile device 10, the flow does not proceed further than step S206 and the -27 -user interface 29 of the first MFP 20 remains disabled.

[0050] If the authentication information indicates that a user (or mobile device 10) is authenticated for use of the first MFP 20, the flow proceeds to step S207.

[0051] In step 5207 the user interface 29 is enabled allowing a user to access the functions, such as printer/scanner means 28, of the first MFP 20. For example, the user may use buttons and menu items, displayed on the touch sensitive display of the user interface 29, to select documents to print using the printer/scanner means 29.

[0052] In the above described embodiment, authentication of a user is performed on mobile device 10. When mobile device 10 is brought into proximity with first beacon 40 (and also MFP 20), its proximity is detected and a local network is established between the mobile device 10 and the first MFP 20. Using the established local network, authentication information -28 -is transmitted to the first MFP 20 allowing the user to access the functions of the first MFP (or second MFP 30).

[0053] Because the authentication is carried out in the mobile device it is possible to use sophisticated authentication techniques. For example a user may need to login or sign-in to certain software using a unique user name and password to verify their identity. As another example, already existing authentication software may be used, such a social media or 0Auth. Furthermore, even more sophisticated authentication techniques may be used such as finger print recognition, or retina recognition. Thus, the embodiment provides a very secure method of authenticating a user (or mobile device 10) wishing to use of the first MFP 20 or second MFP 30.

[0054] In the example, the mobile device 10 is a mobile telephone. Typically, most people carry a -29 -mobile telephone with them wherever they go, and so allowing authentication to use the first MFP 20 or second MFP 30 using their mobile telephone means that a separate identification/authentication means does not need to be carried by a user. Furthermore, the mobile device 10 does not need to be brought into contact or close proximity with the first beacon 40 (and/or the first MFP 20) to provide authorisation, rather the mobile device 10 only needs to be Near or Immediate (e.g. within a few metres). This reduces the burden on a user, and allows for a very convenient method of authentication for a user.

[0055] In the above described embodiment, the user interface 29 of the first MFP 20 is described as being disabled until authenticated access is determined by authentication means 24. In an alternative arrangement, although the user interface 29 is disabled in terms of not allowing access to the functions of the first MFP -30 - 20, it can allow manual, or local, authentication of a user. For example, the user interface 29 may display on its touch sensitive display buttons and menu items allowing a user to input their authentication details (such as user name and password) into the first MFP 20. Once authenticated a user may be able to access the same functions as a user authenticated by mobile device 10. Alternatively, the manual authentication could allow access to more, or less, functions than are available to a user authenticated by mobile device 10. For example, manual authentication may be used by service and maintenance personnel, allowing them greater access to the first MFP 20.

Other embodiments [0056] In the described first embodiment the authentication system relates to authentication of use of multifunctional devices, such as in an office environment. In another embodiment, the authentication -31 -system relates to access to a building, or area of a building.

[0057] In this embodiment an access control device as a control apparatus, including a beacon, is provided near an access door. The beacon transmits broadcast information as in the first embodiment, and the access control device includes a local network means, authentication means and CPU as the first MFP 20 (and second MFP 30) of the first embodiment. The access control device further includes a locking means for keeping the access door locked until a user is authenticated. Access or authentication is determined by a mobile device (such as shown in figure 2) and its proximity to the beacon. A user is allowed access through the access door when their mobile device is judged to be Near or Immediate to the beacon, and they have been authenticated by software running on the mobile device. When the mobile device is judged to be -32 -Near or Immediate, a local network is established, using the mDNS protocol, between the mobile local network establishment means of the mobile device and the local network means of the access control device. 5 Authentication information is transmitted from the mobile device to the access control device over the established local network. If the user is authenticated, as judged by the authentication means of the access control device, the locking means is released and the user is allowed access through the access door.

[0058] In a further embodiment, instead of an authentication system for accessing a building, or area of a building, the authentication system may relate to 15 access to a car park through a barrier means.

[0059] While the present invention has been described with reference to embodiments, it is to be understood that the invention is not limited to the -33 -disclosed embodiments.

Claims

-34 -CLAIMS1. An authentication system comprising a control apparatus and a mobile device, wherein the mobile device is arranged to detect its proximity to the control apparatus, and in response to detecting that the mobile device is proximate, the mobile device is further arranged to establish a local network with the control apparatus and send authentication information to the control apparatus via the local network.
2. An authentication system according to claim 1, wherein the mobile device detects whether it is proximate to the control apparatus based on a beacon signal received from the control apparatus.
3. An authentication system according to claim 2, wherein the beacon signal is in accordance with -35 -the iBeacon protocol, and the mobile device determines it is proximate when the iBeacon proximity state is determined to be Near or Immediate or Far.
4. An authentication system according to any preceding claim, wherein the local network is established by the mobile device broadcasting an address information request, and the control apparatus responding to the address information request by sending its address information to the mobile device.
5. An authentication system according to claim 4, wherein the address information request broadcast by the mobile device includes information based on the beacon signal.
6. An authentication system according to any -36 -preceding claim, wherein the authentication information is information instructing the control apparatus to allow access to a user.
7. An authentication system according to any preceding claim, wherein the authentication information is generated on the mobile device using an authentication application running on the mobile device.
8. An authentication system according to any preceding claim, wherein the authentication information is a token.
9. An authentication system according to claim 8, wherein the token is an 0Auth token.
10. An authentication system according to any preceding claim, wherein the local network is -37 -established using the mDNS protocol.
11. An authentication system according to any preceding claim, wherein the control apparatus is a multifunctional apparatus.
12. An authentication system according to any one of claims 1 to 10, wherein the control apparatus is an access control apparatus.
13. A method of authentication between a control apparatus and a mobile device, the method comprising the step: detecting the proximity between the mobile device and the control apparatus, wherein in response to detecting that the mobile device is proximate to the control apparatus, the method further comprising the steps: -38 -establishing a local network between the mobile device and the control apparatus; and sending authentication information from the mobile device to the control apparatus via the local network.
14. A method according to claim 13, wherein the proximity of the mobile device and control apparatus is detected based on a beacon signal received at the mobile device from the control apparatus.
15. A method according to claim 14, wherein the beacon signal is in accordance with the iBeacon protocol, and it is determined that the mobile device and control apparatus are proximate when the iBeacon proximity state is determined to be Near or Immediate or Far.

-39 -
16. A method according to any one of claims 13 to 15, wherein the local network is established by the mobile device broadcasting an address information request, and the control apparatus responding to the address information request by sending its address information to the mobile device.
17. A method according to claim 16, wherein the address information request broadcast by the mobile device includes information based on the beacon signal.
18. A method according to any one of claims 13 to 17, wherein the authentication information is information instructing the control apparatus to allow access to a user.
19. A method according to any one of claims 13 to -40 - 18, wherein the authentication information is generated on the mobile device using an authentication application running on the mobile device.
20. An authentication system according to any one of claims 13 to 19, wherein the authentication information is a token.
21. An authentication system according to claim 20, wherein the token is an 0Auth token.
22. A method according to any one of claims 13 to 21, wherein the local network is established using the mDNS protocol.
23. A method according to any one of claims 13 to 22, wherein the control apparatus is a multifunctional apparatus.-41 -
24. A method according to any one of claims 13 to 22, wherein the control apparatus is an access control apparatus.