AU2014101079A4 - Secure communication method - Google Patents

Abstract

Abstract SECURE COMMUNICATION METHOD A computer-implemented method for communicating data from an originator to a collaborator is disclosed. The method comprises receiving a request from the originator to share data with the collaborator (202), and determining that the collaborator is not a registered user of a database. The method further comprises communicating a first URL to the collaborator as a notification of the request to share data (204); preparing a password upon receiving a response from the collaborator via the first URL, and associating at least one access restriction with the password. The method further comprises communicating a second URL to the collaborator (206), the second URL including the password; authenticating the collaborator using a response received via the second URL, the password and the at least one access restriction (208); and providing the collaborator access to the data where the collaborator is authenticated. 9116972_2

Description

1 SECURE COMMUNICATION METHOD Technical Field [0001] The present invention relates generally to secure communications and, in particular, to a secure communication method for an unregistered user of a file sharing 5 application. Background [0002] Methods for the open electronic sharing of documents and data are known. The secure sharing of documents and data typically requires users (i.e., senders and receivers) to be at least known to each other. However, many registered users of a file sharing 10 application often want to securely share data with an unregistered user of the file sharing application, or other server intermediary system. In some instances, the file sharing application, server or intermediary system is not user-friendly from the point of view of the unregistered recipient user. [0003] Some web-based data sharing applications, such as Google Drive T M , Dropbo

TM

, is Mega T M and BoxTM provide solutions for sharing data with unregistered user. However, the solutions provided are often prone to security issues. Summary [0004] A first aspect of the present disclosure provides a computer-implemented method for communicating data from an originator to a collaborator, comprising: receiving a request 20 from the originator to share data with the collaborator; determining that the collaborator is not a registered user in a database; communicating a first URL to the collaborator as a notification of the request to share data; preparing a password upon receiving a response from the collaborator via the first URL, and associating at least one access restriction with the password; communicating a second URL to the collaborator, the second URL including 25 the password; authenticating the collaborator using a response received via the second 9116972_2 2 URL, the password and the at least one access restriction; and providing the collaborator access to the data where the collaborator is authenticated. [0005] A further aspect of the present disclosure provides a system for communicating data from an originator to a collaborator, comprising: an originator device; a server 5 computer; and a collaborator device; wherein, the originator device is configured to transmit a request to share data with a collaborator to the server computer via a network; the server computer is configured to: receive the request from the originator device to share data with the collaborator via the network; determine that the collaborator is not a registered user in a database; communicate a first URL to the collaborator device via the network; prepare a 10 password upon receiving a response from the collaborator device via the first URL, and associate at least one access restriction with the password; communicate a second URL to the collaborator device, the second URL including the password; authenticate the collaborator using a response received via the second URL, the password and the at least one access restriction; and provide the collaborator access to the data if the receiver is 15 authenticated; and the collaborator device is configured to transmit and receive communication from the server computer via the network. [0006] A further aspect of the present disclosure provides a computer readable storage medium comprising instructions executable on a processor to perform the method of the first aspect. 20 [0007] A yet further aspect of the present disclosure provides a server computer comprising the computer readable storage medium of the above aspect. [0008] A further aspect of the present disclosure provides a computer-implemented method for obtaining access to data; comprising: receiving a first email, the email including a first URL and notification of the data; receiving a user input selecting the first URL; 25 transmitting a first response to a server computer via the first URL; receiving a second email from the server computer in reply to the first response, the second email including a second 9116972_2 3 URL; receiving a user input selecting the second URL; transmitting a second response to a server computer via the second URL, the second response including the password; and receiving access to the data from the server computer if an access restriction associated with the password is satisfied. 5 [0009] Other aspects are also disclosed. Brief Description of the Drawings [0010] At least one embodiment of the present invention will now be described with reference to the drawings and appendices, in which: Fig. 1A shows a system for secure communication; 10 Fig. 1B forms a schematic block diagram of a general purpose computer system upon which arrangements described can be practiced; Fig. 2 is a high level flow diagram of a secure communication method; Fig. 3 is a flow diagram of a method for receiving a request to share data and notifying a recipient; 15 Fig. 4 is a flow diagram of a method for generating a password for a recipient; Fig. 5 is a flow diagram of a method for authenticating a collaborator; Fig. 6 shows a data flow of secure communication for a collaborator device; and Fig. 7 shows a sample email for notifying the collaborator of a data share. Detailed Description including Best Mode 20 [0011] Where reference is made in any one or more of the accompanying drawings to steps and/or features, which have the same reference numerals, those steps and/or features 9116972_2 4 have for the purposes of this description the same function(s) or operation(s), unless the contrary intention appears. [0012] Data can be shared between registered users of a file sharing system with a degree of confidence that the data will only be shared with the intended recipient(s).The present 5 disclosure relates to arrangements by which unregistered users can be authenticated in a secure and user-friendly way for web-based file sharing applications. As such, the presently disclosed arrangements verify that the intended recipient is who they claim to be before granting that person access to a document. A sender or sharer of the data (referred to as an "originator") can use the methods disclosed herein to communicate or share data with a 10 desired recipient (referred to as a "collaborator"), even if the collaborator is not registered with the originator's file sharing application. The methods described herein are suitable for use in conjunction with data sharing applications such as those provided by Covata TM Google Drive T M , and the like. The methods of the present disclosure are normally executed on a server computer via which the originator and one or more collaborators communicate. is Structural Environment [0013] Fig. 1A shows a system 150 for secure communication. The system 150 includes a server computer 160 upon which methods for secure communication of data are implemented by execution of an application 133. The server computer 160 is in communication with each of an originator device 170 and a collaborator device 190 via a 20 network 120. Each of the originator device 170 and the collaborator device 190 is a communications device such as a desktop computer, a laptop, a tablet, a smartphone, or the like, which operates in a manner generally similar to that of the server computer 160. The devices 170 and 190 are configured to perform the methods described herein by execution of applications 172 and 192 respectively. 25 [0014] The application 133 is stored on a storage medium of the server computer 160, such as a disk or Random Access Memory, as discussed hereafter. The application 133 9116972_2 5 executes on the server computer 160 in concert with a database 140. The database 140 stores information including, identification of the registered users of the database 140, the location of secure data on a storage medium or memory of the server 160, and also identities of users with whom secure data has been shared, passwords, and the time each 5 password was created. [0015] The application 172 is executable on the originator device 170 to communicate with the application 133. The application 192 is executable on the collaborator device 190 for communication with the application 133 via the network 120. The applications 172 and 192 are preferably each web scripting applications written in a language such as Javascript, 10 executable in conjunction with generic web communication applications 174 and 194 respectively. The generic web communication applications 174 and 194 may each be an email application, a browser, or a file sharing application, or the like. The applications 172 and 192 may be stored on the server computer 160 and downloaded to the device 170 and 190 respectively upon communications being established therebetween via the network 120. is In some embodiments, the applications 172 and 192 may be stored on the devices 170 and 190 respectively prior to communications with the server 160 being established. [0016] The server computer 160 operates in the manner of a general purpose computer system 100. As seen in Fig. 1B, the computer system 100 includes: a computer module 101; input devices such as a keyboard 102, a mouse pointer device 103, a scanner 126, a 20 camera 127, and a microphone 180; and output devices including a printer 115, a display device 114 and loudspeakers 117. An external Modulator-Demodulator (Modem) transceiver device 116 may be used by the computer module 101 for communicating to and from a communications network 120 via a connection 121. The communications network 120 may be a wide-area network (WAN), such as the Internet, a cellular 25 telecommunications network, or a private WAN. Where the connection 121 is a telephone line, the modem 116 may be a traditional "dial-up" modem. Alternatively, where the 9116972_2 6 connection 121 is a high capacity (e.g., cable) connection, the modem 116 may be a broadband modem. A wireless modem may also be used for wireless connection to the communications network 120. [0017] The computer module 101 typically includes at least one processor unit 105, and 5 a memory unit 106. For example, the memory unit 106 may have semiconductor random access memory (RAM) and semiconductor read only memory (ROM). The computer module 101 also includes an number of input/output (1/O) interfaces including: an audio video interface 107 that couples to the video display 114, loudspeakers 117 and microphone 180; an 1/O interface 113 that couples to the keyboard 102, mouse 103, 10 scanner 126, camera 127 and optionally a joystick or other human interface device (not illustrated); and an interface 108 for the external modem 116 and printer 115. In some implementations, the modem 116 may be incorporated within the computer module 101, for example within the interface 108. The computer module 101 also has a local network interface 111, which permits coupling of the computer system 100 via a connection 123 to a is local-area communications network 122, known as a Local Area Network (LAN). As illustrated in Fig. 1A, the local communications network 122 may also couple to the wide network 120 via a connection 124, which would typically include a so-called "firewall" device or device of similar functionality. The local network interface 111 may comprise an Ethernet circuit card, a Bluetooth* wireless arrangement or an IEEE 802.11 wireless arrangement; 20 however, numerous other types of interfaces may be practiced for the interface 111. [0018] The 1/O interfaces 108 and 113 may afford either or both of serial and parallel connectivity, the former typically being implemented according to the Universal Serial Bus (USB) standards and having corresponding USB connectors (not illustrated). Storage devices 109 are provided and typically include a hard disk drive (HDD) 110 and other known 25 storage devices. An optical disk drive 112 is typically provided to act as a non-volatile source of data. Portable memory devices, such optical disks (e.g., CD-ROM, DVD, Blu-ray 9116972_2 7 DiscTM), USB-RAM, portable, external hard drives, and floppy disks, for example, may be used as appropriate sources of data to the system 100. [0019] The components 105 to 113 of the computer module 101 typically communicate via an interconnected bus 104 and in a manner that results in a conventional mode of 5 operation of the computer system 100 known to those in the relevant art. Likewise, the memory 106 and optical disk drive 112 are coupled to the system bus 104 by connections 119. Examples of computers on which the described arrangements can be practised include IBM-PC's and compatibles, Sun Sparcstations, Apple MacTM or a like computer systems. 10 [0020] The methods relating to secure communication may be implemented using the computer system 100 operating as the server 160 wherein the processes of Figs. 2-5, to be described, may be implemented as one or more software application programs 133 executable within the computer system 100. The software may also be divided into a number of separate parts to separate tasks of the methods disclosed. 15 [0021] The software may be stored in a computer readable medium, including the storage devices described below, for example. The software is loaded into the computer system 100 from the computer readable medium, and then executed by the computer system 100. A computer readable medium having such software or computer program recorded on the computer readable medium is a computer program product. The use of the 20 computer program product in the computer system 100 preferably effects an advantageous apparatus for the methods of Figs. 2-5. [0022] The software 133 is typically stored in the HDD 110 or the memory 106. The software is loaded into the computer system 100 from a computer readable medium, e.g., a medium 125 read by the drive 112 and executed by the computer system 100. A computer 25 readable medium having such software or computer program recorded on it is a computer 9116972_2 8 program product. The use of the computer program product in the computer system 100 preferably effects an apparatus for implementing the methods of Figs. 2-5. [0023] In some instances, the application program 133 may be supplied to the user encoded on one or more CD-ROMs 125 and read via the corresponding drive 112, or 5 alternatively may be read by the user from the networks 120 or 122. Still further, the software can also be loaded into the computer system 100 from other computer readable media. [0024] Part of the application program 133 and corresponding code modules may be executed to implement one or more graphical user interfaces (GUls) to be rendered or 10 otherwise represented upon the display 114. Through manipulation of typically the keyboard 102 and the mouse 103, a user of the computer system 100 and the application may manipulate the interface in a functionally adaptable manner to provide controlling commands and/or input to the applications associated with the GUI(s). Other forms of functionally adaptable user interfaces may also be implemented, such as an audio interface is utilizing speech prompts output via the loudspeakers 117 and user voice commands input via the microphone 180. [0025] In some embodiments, the originator and/or the collaborator may directly operate the server computer 160 (e.g., using the keyboard 102 or the mouse 103) to access the database 140 rather than establishing communication via the devices 170 and 190. 20 Overview [0026] Figure 2 shows a high level representation of a secure communication method 200. The method 200 operates to communicate or share data from an originator to a desired collaborator using the server computer 160. The method 200 is preferably implemented as the application 133 executable on the server 160. The originator device 170 and the 25 collaborator device are included in Fig. 2 to show data flow of the method 200. 9116972_2 9 [0027] The secure communication method commences when an originator causes transmission of a share request from the originator device 170 to the server computer 160. The originator must be registered as user of the server computer 160 and the application 133 to submit the request. The originator is a registered user of a sharing application 145 for 5 example hosted on the server 160 and which is associated with the database 140. The registration may for example include an identifier of the originator stored in the database 140. The originator need not and typically is not a registered user of the database 140 and thus has no direct access to the database 140, such as may be afforded a system administrator of the server 160. The collaborator is typically completely unknown in the 10 database 140 and the applications 133 and 145. Not illustrated, the originator is initially identified as a registered user (authenticated) of the server 160 by typical methods, such as login with a username and password. [0028] The method 200 starts at step 202, when the application 133 of the server 160 receives a request from 201 to share data from an authenticated user. The share request is 201 identifies the data for sharing and the address of at least one collaborator with whom the data is to be shared. The data to be shared or communicated may be transmitted securely (e.g., by Secure Sockets Layer (SSL)) to the server computer 160 from the device 170 via the network 120 as a result of the authentication. Alternatively, data may be provided to the server 160 by originator operation of inputs of the server 160 (e.g., the microphone 180, the 20 keyboard 102, scanner 126 or camera 127). The data may be also transmitted to the server 160 via the LAN 22 or the disk drive 102, or may previously have been stored by the originator on the memory 106 or disk drive 110 of the server 160 associated with the database 140. Data is normally stored securely on the disk drive 110 using some form of encryption, e.g., as a CovataTM Secure Object, or the like. The collaborator is identified 25 normally by an email address. In other embodiments, the collaborator could be identified by another form of address, such as a mobile telephone number. This description relates to a 9116972_2 10 single unregistered collaborator, however more than one collaborator may be specified by the originator. [0029] Once the share request 201 has been received at step 202, the method 200 progresses to step 204. At step 204, the application 133 generates a first uniform resource 5 locator (URL). The first URL is structured to provide the collaborator with a means to request authentication of himself. The first URL includes a request to the server computer 160 to send a password to the collaborator. Step 204 also operates to communicate, as shown by arrow 214, a notification containing the first URL to the unregistered collaborator. The notification is normally in form of a first electronic message sent to the collaborator's 10 address, such as an email, containing the first URL. In other embodiments, the communication may be by other means, such as a Short Message Service (SMS) communicated via a cellular network. The first email contains no security information. In this fashion, a passing on (e.g., forwarding) the first email from the collaborator to another user does not give the other user the ability to access data stored on the server 160. 15 [0030] The collaborator receives the notification email 214 by way of the communication application 194 and operates the collaborator device 190. Selection of the first URL causes the application 194 to send a response to the server 160, indicated by arrow 215. The method 200 continues at step 206 to receive the collaborator's response 215 to the first URL. At step 206, the application 133 executes to generate (i) a password, and (ii) a second 20 URL, with the password being embedded in the second URL along with the collaborator's email address. [0031] The password has at least one access restriction associated therewith. In a preferred implementation the access restriction is that the password is a one-time-password (OTP), i.e., the password is valid only for a single use. Additionally, or alternatively, use of 25 the password may be valid for a specified time only. In one example, the password is valid for only a short period of time (example: 20 minutes) after creation. The password is stored 9116972_2 11 in the database 140 of the server computer 160 in association with the collaborator's email address. The access restriction(s) may be applied according to predetermined settings of the application 133, or according to preferred user settings of the originator. Other examples of access restrictions include limitations of a device which the collaborator may use to 5 access the data, a geographic location of the user, or the like. [0032] The application 133 further executes to communicate the second URL to the collaborator at step 206, as indicated by arrow 216. The second URL is typically communicated to the collaborator by a second email. [0033] The collaborator device 190 receives the second email 216 via the application 194 10 whereupon the collaborator can select the second URL to cause transmission of a response via the application 194 to the server computer 160, as indicated by arrow 217. Upon receiving the collaborator response to the second URL, the method 200 executes step 208. At step 208, the method 200 authenticates the identity of the collaborator using the password sent via the second URL and associated access restriction(s). Once 15 authenticated, the collaborator is provided access to the share data (arrow 218), and the method 200 ends. Implementation [0034] The steps involved in the method 200 are described in further detail in Figs. 3-5. In particular, Fig. 3 relates to steps 202 and 204, Fig. 4 to step 206, and Fig. 5 to step 208. 20 [0035] Fig. 3 shows a preferred method 300 executed by the application 133 to implement steps 202 and 204. The method 300 starts at step 302 where the server computer 160 receives the request 201 to share data. Upon receiving the request 201, the method 300 proceeds to step 304. At step 304, the application 133 executes to determine if the collaborator specified in the request 201 is a registered user in the database 140 or 25 unknown, and thereby unregistered. 9116972_2 12 [0036] The determination is made by comparing the collaborator's address to addresses stored in the database 140. If the collaborator's address is found in the database 140 and identified to be a registered user, the method 300 proceeds to step 306. At step 306 secure communications with the collaborator are conducted via known means, such as systems 5 provided by CovataTM , and the method 300 ends. [0037] Alternatively, the collaborator's email address may not be stored as a registered user on the database 140. In this instance, the collaborator is determined not to be a registered user of the server computer 160 at step 304, and the method 300 continues to step 308. The application 133 executes at step 308 to create an entry in a database 140 of 10 the server 160 for the collaborator, and labels the entry as an "ad hoc" user. The collaborator is now registered in the database 140, but without a password (an ad hoc entry). [0038] Once an ad hoc entry has been created for the collaborator, the method 300 proceeds to step 310. At step 310 the first URL is prepared. The first URL desirably has the following attributes: 15 . The protocol is https. * The domain name is that of the server computer 160 storing the originator's data. * The path is an endpoint on the server computer 160 that sends one-time-passwords to "ad hoc" users (OTP server endpoint). * The URL has a query string that includes the following information: the collaborator's 20 address and identification of the data to be shared. [0039] An example first URL is: "https://covata.io/api/va/notifications/send_otp?email=adhocuser@adhoc.com&objectid=4 37751213858418688" 9116972_2 13 [0040] In this instance, the collaborator's address is the email address "ad hocuser@adhoc.com" and the data to be shared is stored on the server computer 160 as item "437751213858418688". 5 [0041] The application 133 further operates to prepare a notification communication at step 310 for notifying the collaborator of the share and to provide the first URL. The notification is normally in email form and provides a means for the collaborator to get the OTP via single click of a mouse (or equivalent input device) of the user device 190, referred to as a "one click method". 10 [0042] There are different implementation options for how a one-click method is provided for the user to get a OTP. In one implementation, a notification URL is provided to the user as a selectable link in the notification email. In another implementation, the communication is an email in HTML format which contains an html form that presents a selectable button area within a display of the email. The collaborator can select the link or is button in the normal manner to request the OTP. Either option delivers the email address and information about the object the collaborator is trying to access to the server. However the link option does so via a query string and the html form option does so via the http message body. Fig. 7 shows a sample email 700 including both a selectable button 710 and a selectable link 720. 20 [0043] Returning to Fig. 3, once the first URL and the notification communication are prepared, the method 300 progresses to step 312. At step 312, the application 133 executes to communicate the notification 214 including the first URL to the collaborator as a notification of the request to share data. This is normally communicated securely via email using a protocol such as SSL, Transport Layer Security (TSL), or the like. The method 300 25 completes upon execution of step 312. 9116972_2 14 [0044] The collaborator receives the communication of step 312 of Fig. 3, and selects the link related to the first URL using an input of the collaborator device 190, e.g., the mouse 103. The communication application 194 executes to transmit a first response to the server computer 160. 5 [0045] Fig. 4 shows a method 405 executed by the application 133. The method 405 relates to step 206 of Fig. 2. The method 405 starts at step 410 where the server computer 160 receives the collaborator's (first) response 215 to the first URL. The first response 215 is essentially a request by the collaborator for a password to access the secured share data. [0046] Once the first response is received, the method 405 proceeds to step 412, at which 10 the application 133 determines whether the first response is of correct format. This is a validation that the request received from the collaborator is syntactically correct, containing a properly formatted collaborator email address and properly formatted data identification. If the request is not of correct format, the method 405 proceeds to step 414 and returns a http 400 error message to the collaborator device 190. The error message may include a text is string to provide a message for the collaborator device 190 to display, e.g. "access denied". [0047] If at step 412 the data format of the request 215 is found to be correct, the method 405 proceeds to step 416. At step 416, the application 133 executes to check to determine whether the collaborator identified in the request 215 is registered in the database 140 as an ad hoc user. In determining whether the collaborator is an ad hoc user, the application 133 20 determines if the collaborator's email address is stored in the database 140, as for example arising from step 308, and is labelled as an "ad hoc" user. If the email address is not stored in the database 140 and labelled as an ad hoc user, the method 405 proceeds to step 418, and returns a http 200 success response. A success response is preferably used for security reasons, so as not to reveal whether the user is valid or not to prevent of use by 25 hackers. However, the collaborator is not authorised or granted access to the shared data at 9116972_2 15 this stage. In other embodiments, an error response may be provided with or instead of the 200 success response at step 418. [0048] If the collaborator is found to be a valid ad hoc user at step 416, the method 405 proceeds to step 419. The application 133 operates at step 419 to determine if an OTP has 5 recently been sent to the collaborator. "Recent" is defined as sent within a predetermined time frame, for example, within the one minute. If an OTP has been sent in the predetermined time period, the method 405 progresses to step 418 and returns an http 200 success response. This adds an extra level of security by preventing a hacker setting up a script that selects the link a number of times per second which would result in a 10 corresponding number of emails per second being communicated to the collaborator device 190. Additionally, usability of the application 133 is improved - sometimes the collaborator may select the first URL multiple times due to time delays in email delivery systems. If step 419 were absent, the collaborator would receive multiple emails corresponding to the multiple clicks (selections), each having a new OTP. Without step 419, the user could is potentially receive multiple second emails with second URLs that don't work. Step 419 has the effect of "absorbing" multiple selections into a single one, so as to avoid the user receiving multiple OTPs. In other embodiment, step 419 may be omitted. [0049] If the application 133 determines at step 419 that an OTP has not been recently sent, the method 405 proceeds to step 420. At step 420, the new OTP is generated in a 20 secure manner, such as using a cryptographically secure pseudo random number generator. Once the OTP is generated, the method 405 progresses to step 422. [0050] At step 422, the application 133 operates to determine if an old OTP is stored on database 140 for this user. An old OTP is an OTP generated prior to the response of step 410 but that has not been used to authenticate the user. If such an old OTP is stored on the 25 database 140, the method 405 progresses to step 424 and deletes the old OTP from the database 140. The method 405 then continues to step 426. 9116972_2 16 [0051] If an old OTP is found not to exist, the method 405 proceeds from step 422 to step 426. At step 426, the newly generated OTP is stored on database 140 and associated with the collaborator, for example the collaborator's email address. Additionally, data relating to the access restriction(s) associated with the OTP (such as the time the OTP was generated 5 and a period for which the OTP is valid) are stored in a database 140. [0052] Once the new OTP and associated restrictions are stored. the method 405 proceeds to step 428. At step 428, the application 133 generates the second URL containing the OTP for sending to the collaborator. The second URL preferably has the following attributes: 10 0 The protocol is https. * The path is the authentication endpoint. * The query string has whatever information the authentication protocol requires to begin the authentication process (example: Oauth 2 requires a response-type, redirecturi, clientid, and potentially other information) 15 0 The Collaborator identity, normally the collaborator's email address, and OTP are in the url fragment. [0053] An example second URL is: "https://covata.io/api/oauth/authorize?responsetype=token&clientid=covataWebApp&redir ect_uri=https://covata. io/webapp/index&state={"path": "/secureObjects/43775121385841868 20 8}#username=adhocuser%40adhoc.com&otp=EZPU-LQCM-Q43N-4P2Z". [0054] In this example, the collaborator is "ad_hocuser@adhoc.com", and the OTP is "EZPU-LQCM-Q43N-4P2Z". [0055] Once the OTP and second URL are generated, method 405 moves to step 430. The application 133 executes to communicate the second URL to the collaborator at step 9116972_2 17 430. The password URL is communicated to the collaborator via email using a secure protocol such as SSL/TLS. Once the communication is complete, the method 405 proceeds to step 418 and returns the 200 success response to the collaborator device 190. 5 [0056] The steps above (e.g., format of the messages, recognition of an ad hoc user, generation of a password, and the format of the URL) and the sequence in which the steps are completed, may be varied, as will be appreciated by a person skilled in the art. [0057] The collaborator receives the communication 216 containing the second URL of step 430, and selects a link for the second URL using an input of the device 190 to access 10 the shared data. The application 194 executes on the Collaborator device 190 to send a second response in form of a "http GET" request to the server 160. The http GET request does not send the URL fragment containing the OTP to the server 160 but includes the query string. This GET request results in download of an html login page including a script that executes as the application 192. The login script executes to take the user identity and is OTP from the URL fragment and deliver the result securely to the server 160, as described below. [0058] Figure 5 shows a method 500 executed by the application 133 which relates to step 208 of Fig. 2. The method 500 begins at step 502 where the server computer 160 receives the response 217 from the collaborator via the second URL. Upon receiving the http GET 20 response, the method 500 proceeds to step 504. At step 504, the http GET request causes the application 133 to transmit the application 192 (the html login page and the login script) to the collaborator device 190. The login script is implemented in a client side scripting language such as Javascript. The login script is a sub-application of the application 133. [0059] The login script of the application 192 executes on the collaborator device 190 in 25 concert with the application 194 to copy the collaborator's address and OTP from the URL 9116972_2 18 fragment, paste the result in the html login page, and submit the completed login page to the server 160 on behalf of the collaborator. The server computer 160 receives the response from the executed login script at step 506. The method 500 continues to step 508, in which the application 133 identifies the collaborator's email address and OTP from the response 5 received at step 506. The application 133 next executes step 510. At step 510, the application 133 operates to determine if the identified email address and OTP match corresponding records stored in the database 140. The email address and OTP are checked against records stored in database 140. If the email address and OTP do not match those stored in the database 140, the method 500 continues to step 518. An error 10 message is returned to the collaborator device 190 at step 518 and the method 500 ends without granting the collaborator access to the share data. The error message will normally be a string indicating an outcome, such as "access denied". [0060] However, if at step 510 the email address and OTP are found to match those stored on the database 140, the method 500 continues to step 512. The application 133 15 determines at step 512 if the access restriction(s) associated with the OTP have been satisfied, i.e., has the OTP already been used, or has the OTP expired by being used too late. If the OTP is found invalid, i.e., fails to overcome (one of the) access restrictions, the method 500 proceeds to end at step 518 without granting the collaborator access to the share data. 20 [0061] If the OTP and access restrictions are found valid at step 512, the method continues to step 514. At step 514, the application 133 executes to remove the OTP from the database 140 so that the OTP cannot be used again. Once the OTP is removed, the method 500 continues to step 516. The application 133 authenticates the collaborator in the database 140 at step 516 as all requirements relating to the OTP and have been satisfied. 25 This process effects a validation of the ad hoc "registration" of the unregistered collaborator. 9116972_2 19 The collaborator is provided with access to the shared data at step 516. The method 500 ends at step 516 in this instance. Data Flow for Collaborator Device [0062] Fig. 6 shows a data flow 600 for secure communication in relation to the 5 collaborator device 190. The flow 600 begins at step 602 when the application 133 of the server computer communicates a first email to the collaborator's address, as per step 312 of Fig. 3. At step 602, the application 194 executes to receive and present the first email to the collaborator on a display of the device 190. [0063] The collaborator decides to select the link or button relating to the first URL. The 10 application 194 receives the collaborator input at step 604. The input is received by the collaborator operating an input of the device 190, e.g., a mouse or a touch screen. The flow 600 then progresses to step 606. At step 606, the application 194 operates to communicate the first response to the server 160 via the endpoint specified in the first URL. [0064] The server computer 160 receives the first response and executes the method 400 is of Fig. 4 to communicate the second email to the device 190 using the collaborator's email address. The email is received by the application 194 at step 608 of the flow 600. The application 194 executes to receive and present the second email to the collaborator on a display of the device 190. The second email contains the second URL, or, if the collaborator's request was found invalid, a response message. 20 [0065] The collaborator decides to select the link or button relating to the second URL. The application 194 receives the collaborator input at step 610. The input is received by the collaborator operating an input of the device 190, e.g., a mouse or a touch screen. [0066] The flow 600 then progresses to step 612. At step 612, the application 194 executes to send a second response in form of a http GET request to the server computer 25 160 via the network 120. The server computer 160 receives the response and 9116972_2 20 communicates an html page and login script of the application 192 to the collaborator device 190, as at step 504. At step 613, the device 190 receives the html page and login script. The flow 600 progresses to step 614, at which the login script of the application 192 is executed on the device 190 to copy the collaborator's address and OTP from the second URL, paste 5 the result in the received html page, and submit the completed login page to the server computer 160. [0067] The application 194 receives a response from the server computer 160 at step 616. If the requirements of the OTP and the associated restrictions were met, the collaborator is 10 provided access to the originator's shared data via the application 194 in the response. If the requirements of the OTP and the associated restrictions were met, the response contains an error message. Advantages [0068] The benefits of the methods described herein relate to both security and usability is of secure communication of data to an unregistered user. [0069] Some industry solutions, including GoogleTM, Mega T M , BOXTM and Drop BoxTM rely on a shared secret link for securely sharing data. That is, an originator is given a secret URL containing information about how to access a document they want to share, and that URL is provided, typically by email, to everybody with whom they want to share it. 20 Collaborators are recipients of the email and only need to click the link to get access to the secret document. However, these solutions may have security issues, as secrets tend to leak often accidentally, and the document is no longer secret. Part of the information, e.g. bank or medical records, may thus be leaked online. For example, with the above approach, there is nothing to present an intended collaborator forwarding the email (with the link) to an 25 unintended person. 9116972_2 21 [0070] To fully appreciate the methods described hereinbefore, it is helpful to understand some of the failures of the secret links solution. Below are three security failures of the shared links solution: 1. If the document being shared contains links, and if the user clicks the links within the 5 document while using the file sharing system, then the owners of the website provided in the link will be able to access the secret document. 2. If somebody with access to a shared document accidentally provides the shared link to a search engine, then advertisers whose names pop up as part of the search will get access to the shared document. 10 3. If accessing a shared file from a shared computer, then other people will also be able to access the same file by looking through the shared computer's browser history. [0071] The root of the problem with existing solutions is that ad hoc users are not authenticated before accessing data. [0072] The implementation described in relation to Figs. 2-5 is particularly effective for is the following reasons: Security: * No collaborator can get access to an object without first being authenticated at step 516. * Ad Hoc collaborators get OTP that can only be used once. After use, the same 20 password does not work again. * OTPs are time-limited (example: 20 minutes), so the window of opportunity for an attacker is extremely limited. 9116972_2 22 [0073] The first two threats enumerated above are mitigated by the requirement for authentication. The third threat (shared computers) is dealt with my making the one-time password usable only once and also the short validity period for the one-time-password in the odd event that the user requests the OTP but does not consume the OTP. 5 [0074] Moreover, the method disclosed mitigates additional threats. For example, an online hacker manages to capture a copy of an email file system. The hacker might find old emails containing already used one-time-passwords, but he is not able to re-use them to gain access to the file sharing system due to all three points above. If the hacker was extremely lucky to capture an OTP that has not yet been consumed, then the hacker would 10 still have to beat the legitimate user to accessing that OTP, and he would have to do so before the time limit of the OTP is expired. Thus, the hacker's window of opportunity is extremely limited. [0075] Usability is ensured because access a shared object requires only two quick operations from the ad hoc collaborator: 15 0 Clicking an email notification link to get the one-time-password sent. 0 Clicking the link in the newly received email (which automatically sends the email address and one-time-password to the server). [0076] The collaborator does not have to copy or paste data relating to the OTP. Further, the collaborator is not required to sign up for an account with the server 160 in order 20 to gain access to a shared document or data. Both collaborator and the originator are thus more likely to use the secure data server 160. Additionally, overhead relating to the collaborator creating a new account is reduced. Problems such as forgetting a password and resulting in overhead annoyance are also avoided. Furthermore, the originator does not have to wait until a recipient has created an account to send them the data. 9116972_2 23 [0077] In particular, the disclosed solution is both secure and user-friendly. User friendliness is often neglected in security solutions. When given a choice between a user friendly but less secure solution and a secure but not user-friendly solution, many people will take the former. This is evidenced by the popularity of Google Drive T M , DropboXTM, Mega T M 5 and BoxTM pfile sharing solutions. [0078] The disclosed method provides a secure and user-friendly way to solve the problem. The goal of user-friendliness is met by reducing authentication down to two clicks. There is no extra work that the collaborator or the originator needs to do in sharing the document: The application 133 handles security aspects internally. In contrast, other 10 systems require putting passwords on documents or require recipients to sign up for accounts if the sender wants security without relying on secret links: both of these are extra overhead that is not required in the disclosed solution. Variants [0079] Variations of the arrangements described above are possible, as will be understood is by a person skilled in the art. [0080] In one variant, the method for authenticating the collaborator can be reduced down to one click rather than two. In this instance, the notification communication (step 312) includes the user's email address and an OTP. This eliminates the need for the user to click a second link to authenticate himself, seemingly improving on the usability even further. 20 [0081] While effective, the notification can't be reasonably time-limited, because the collaborator needs to be able to access the object when is ready to do so. This means that if a hacker captures a snapshot of the email server's file system (which might happen due to insecure backups or perhaps a system hack), there is a much wider window of opportunity for the hacker to get to the shared data object. Including an access restriction such as a 25 time limit on the OTP for the two-click solution makes this threat much less likely. 9116972_2 24 [0082] Additionally, a collaborator can't just browse the document at one time and then access it again later without originator intervention. That is, if the collaborator opens a document and decides he does not have time to read it in detail, then he needs to ask the originator to grant him access again for later access. This is problematic or inconvenient to 5 both the originator and the collaborator. Similarly, one may attempt to put a time limit on one click notification solution, but this comes at a usability cost. Industrial Applicability 10 [0083] The arrangements described are applicable to the computer and data processing industries and particularly for the data sharing and security industries. [0084] The foregoing describes only some embodiments of the present invention, and modifications and/or changes can be made thereto without departing from the scope and spirit of the invention, the embodiments being illustrative and not restrictive. 15 [0085] In the context of this specification, the word "comprising" means "including principally but not necessarily solely" or "having" or "including", and not "consisting only of'. Variations of the word "comprising", such as "comprise" and "comprises" have correspondingly varied meanings. 9116972_2

Claims (10)

1. A computer-implemented method for communicating data from an originator to a collaborator, comprising: receiving a request from the originator to share data with the collaborator; determining that the collaborator is not a registered user in a database; communicating a first URL to the collaborator as a notification of the request to share data; preparing a password upon receiving a response from the collaborator via the first URL, and associating at least one access restriction with the password; communicating a second URL to the collaborator, the second URL including the password; authenticating the collaborator using a response received via the second URL, the password and the at least one access restriction; and providing the collaborator access to the data where the collaborator is authenticated.

2. The computer-implemented method according to claim 1, where in the at least one access restriction comprises the password being a one-time-password.

3. The computer-implemented method according to claim 1 or claim 2, wherein the at least one access restriction includes a time restriction for use of the password.

4. The computer-implemented method according to any one of the above claims, wherein each of the first URL and the second URL is communicated to the collaborator in an email.

5. The computer-implemented method according to claim 4, wherein the email is communicated using Secure Sockets Layer (SSL) or Transport Security Layer (TSL). 9116972_2 26

6. The computer-implemented method according to any one of the above claims, wherein the response received via the second URL is a http GET response.

7. A system for communicating data from an originator to a collaborator, comprising: an originator device; a server computer; and a collaborator device; wherein, the originator device is configured to transmit a request to share data with a collaborator to the server computer via a network; the server computer is configured to: receive the request from the originator device to share data with the collaborator via the network; determine that the collaborator is not a registered user in a database; communicate a first URL to the collaborator device via the network; prepare a password upon receiving a response from the collaborator device via the first URL, and associate at least one access restriction with the password; communicate a second URL to the collaborator device, the second URL including the password; authenticate the collaborator using a response received via the second URL, the password and the at least one access restriction; and provide the collaborator access to the data if the receiver is authenticated; and the collaborator device is configured to transmit and receive communication from the server computer via the network.

8. A computer readable storage medium comprising instructions executable on a processor to perform the method of any one of claims 1-6.

9. A server computer comprising the computer readable storage medium of claim 8. 9116972_2 27

10. A computer-implemented method for obtaining access to data; comprising: receiving a first email, the email including a first URL and notification of the data; receiving a user input selecting the first URL; transmitting a first response to a server computer via the first URL; receiving a second email from the server computer in reply to the first response, the second email including a second URL; receiving a user input selecting the second URL; transmitting a second response to a server computer via the second URL, the second response including the password; and receiving access to the data from the server computer if an access restriction associated with the password is satisfied. Cocoon Data Holdings Limited Patent Attorneys for the Applicant/Nominated Person SPRUSON & FERGUSON 9116972_2