EP3522061B1 - System for managing jointly accessible data - Google Patents
System for managing jointly accessible data Download PDFInfo
- Publication number
- EP3522061B1 EP3522061B1 EP18155395.9A EP18155395A EP3522061B1 EP 3522061 B1 EP3522061 B1 EP 3522061B1 EP 18155395 A EP18155395 A EP 18155395A EP 3522061 B1 EP3522061 B1 EP 3522061B1
- Authority
- EP
- European Patent Office
- Prior art keywords
- user
- request
- data
- secure data
- user device
- Prior art date
- Legal status (The legal status 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 status listed.)
- Active
Links
- 238000013475 authorization Methods 0.000 claims description 66
- 238000000034 method Methods 0.000 claims description 49
- 230000014759 maintenance of location Effects 0.000 claims description 29
- 230000004044 response Effects 0.000 claims description 22
- 238000013500 data storage Methods 0.000 claims description 19
- 238000013523 data management Methods 0.000 claims description 17
- 238000012545 processing Methods 0.000 claims description 10
- 230000005540 biological transmission Effects 0.000 claims description 6
- 238000004891 communication Methods 0.000 description 10
- 238000004590 computer program Methods 0.000 description 6
- 238000010586 diagram Methods 0.000 description 5
- 230000008901 benefit Effects 0.000 description 4
- 230000006870 function Effects 0.000 description 3
- 230000001413 cellular effect Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- RWSOTUBLDIXVET-UHFFFAOYSA-N Dihydrogen sulfide Chemical compound S RWSOTUBLDIXVET-UHFFFAOYSA-N 0.000 description 1
- XUIMIQQOPSSXEZ-UHFFFAOYSA-N Silicon Chemical compound [Si] XUIMIQQOPSSXEZ-UHFFFAOYSA-N 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000000644 propagated effect Effects 0.000 description 1
- 210000003813 thumb Anatomy 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- 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/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
- G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/95—Retrieval from the web
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/133—Protocols for remote procedure calls [RPC]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
- H04L9/3231—Biological data, e.g. fingerprint, voice or retina
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2137—Time limited access, e.g. to a computer or data
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
Definitions
- This disclosure relates to a system, a method and a computer program for managing data associated with a first user and a second user.
- an individual user In conventional digital communication systems it is common for an individual user to have access to an online account, which provides the user with the ability to store and access data via the Internet.
- an online user account hosted by a file hosting service to store electronic files such as image files, music files and word processing documents. These files may be used to store sensitive personal information about the user, which the user must keep private in order to avoid the likelihood of becoming a victim of fraud or identity theft.
- the user may use an online banking account to access their financial data, such as records of previous financial transactions that the user has made.
- two users may use a single online account operated by the file hosting service to store private data or documents that relate to both of the users, such as housing information, personal identity information and financial information.
- two users may have access to a single online banking account for storing sensitive financial data.
- each user is provided with login information that is specific to each user, so that the shared online account can determine which user is accessing the account at a particular time.
- a computer-implemented method for managing data associated with a first user having a first user device and a second user having a second user device comprising: storing, at a first system, a secure data item jointly accessible by the first user and the second user; receiving, at the first system from the first user device, a data request comprising an instruction to transmit the secure data item to a second system; identifying, at the first system, that the secure data item is jointly accessible by the first user and the second user; in response to identifying that the secure data item is jointly accessible by the first user and the second user, transmitting an authorisation request to the second user device, wherein the authorisation request comprises a prompt for the second user to authorise the data request; receiving, from the second user device, a grant message indicative of the second user granting the authorisation request; in response to receiving the grant message, transmitting the secure data item to the second system; and preventing the secure data item from being sent to the second system, if the grant message is not received.
- the second system is unable to receive the jointly accessible data item unless both of the users that have access to the data have provided authorisation for the data to be shared. This prevents a single user from unilaterally allowing the secure data item to be sent to the second system, which would compromise the security of the second user.
- the method provides a mechanism for jointly accessible data items to be shared in a more secure manner.
- data management system comprising: a data storage resource configured to store a secure data item jointly accessible by both a first user and a second user; and processing circuitry configured to: receive, from a first user device associated with the first user, a data request comprising an instruction to transmit the secure data item from the data storage resource to a remote system; identify that the secure data item is jointly accessible by the first user and the second user; transmit an authorisation request to a second user device associated with the second user, in response to identifying that the secure data item is jointly accessible by the first user and the second user, the authorisation request comprising a prompt for the second user to authorise the data request; receive, from the second user device, a grant message indicative of the second user granting the authorisation request; transmit the secure data item to the remote system in response to receiving the grant message; and prevent the secure data item from being sent to the remote system, if the grant message is not received.
- a data management system comprising: a data storage resource configured to store a secure data item jointly accessible by both a first user and a second user; a receiver configured to receive, from a first user device associated with the first user, a data request comprising an instruction to transmit the secure data item from the data storage resource to a remote system; an identification module arranged to identify that the secure data item is jointly accessible by the first user and the second user; a transmitter arranged to transmit an authorisation request to a second user device associated with the second user, in response to identifying that the secure data item is jointly accessible by the first user and the second user, the authorisation request comprising a prompt for the second user to authorise the data request; wherein the receiver is arranged to receive, from the second user device, a grant message indicative of the second user granting the authorisation request; wherein the transmitter is arranged to transmit the secure data item to the remote system in response to receiving the grant message; and wherein the transmitter is arranged to prevent the secure data item from being sent to the remote
- a computer-implemented method for managing data associated with a first user having a first user device comprising: storing, at a first system, a first data item accessible by the first user; receiving at the first system, from the first user device, a data retention request comprising an instruction not to transmit the first data item stored at the first system to a system distinct from the first system; in response to receiving the data retention request, setting a data retention flag at the first system in association with the first user; receiving a data request from a system distinct from the first system for access to the first data item; in response to the data request, identifying that the first user is associated with the data retention flag at the first system and preventing transmission of the first data item to the second system.
- the data retention flag allows a user to ensure that their data is not transmitted to any fraudulent or malicious third parties that may compromise their information security.
- a data management system for managing data associated with a first user having a first user device comprising: a data storage resource configured to store a first data item accessible by the first user; and processing circuitry configured to: receive at the data management system, from the first user device, a data retention request comprising an instruction not to transmit the first data item to a system distinct from the data management system; in response to receiving the data retention request, setting a data retention flag at the data management system in association with the first user; receiving a data request from a system distinct from the data management system for access to the first data item; in response to the data request, identifying that the first user is associated with the data retention flag at the data management system and preventing transmission of the first data item to the system distinct from the data management system.
- a data management system for managing data associated with a first user having a first user device comprising: a data storage resource configured to store a first data item accessible by the first user; a receiver arranged to receive, from the first user device, a data retention request comprising an instruction not to transmit the first data item to a system distinct from the data management system; a flag setting module arranged to set a data retention flag at the data management system in association with the first user, in response to receiving the data retention request; wherein the receiver is arranged to receive a data request from a system distinct from the data management system for access to the first data item; and an identification module arranged to identify that the first user is associated with the data retention flag and preventing transmission of the first data item to the system distinct from the data management system in response to the data request.
- a system 100 for managing access to data associated with a first user and a second user comprises a data management system (DMS) 102, a first user device 104, a second user device 106 and a remote system 108.
- DMS data management system
- the DMS 102 is arranged to store data relating to users of the system 100. Specifically, the DMS 102 stores data that is associated with the first user and the second user which may comprise one or more data items. Each one of these data items is indicative of private information relating to the first and second users. For instance, each data item may comprise financial data relating to the first and second users, such as details that enable the users to make payments or the details of previous financial transactions made by the users.
- data is referred to as being jointly accessible by the first and second users, and that data is associated with both the first user and the second user.
- the first user and the second user may have access to the same online user account, such as an online banking account, via an account interface.
- each one of the users may be assigned a unique username and a shared secret, such as a password, that can be used to access the user account via the account interface.
- a shared secret such as a password
- Data that is jointly accessible by a plurality of users is detected by the DMS 102 determining that more than user is associated with an account linked with the data.
- the secure data that is jointly accessible by the first and second users may be accessible by the DMS 102 itself.
- the jointly accessible data may be accessible by the first and second users only, unless otherwise authorised by both the first user and the second user.
- the jointly accessible data is prevented from being sent to a device or a system that is remote and distinct from the DMS 102, such as the remote system 108, without the first and second users providing authorisation to the DMS 102 for the jointly accessible data to be sent to a remote device or system.
- the system 100 comprises a first user device 104 which is operated by the first user and a second user device 106 which is operated by the second user.
- the system also comprises a remote system 108 to which the jointly accessible data can be sent.
- Each one of the DMS 102, remote system 108 and user devices 104, 106 are arranged to communicate with one another via a communications network 110.
- the communications network 110 in this example, is the Internet 110. However, it will be appreciated that any suitable form of communications network 110 could be used.
- Each one of the DMS 102, remote system 108 and user devices 104, 106 are web-enabled and may comprise a display, a user interface, a processor and memory.
- the devices and systems 102, 104, 106, 108 can be arranged to communicate data between one another via any suitable communications protocol or connection.
- the devices and systems 102, 104, 106, 108 may communicate with one another via a wired and/or a wireless connection.
- the first user device 104 and/or the second user device 106 may be any suitable type of personal computing device, such as a laptop computer, a desktop computer, a web-enabled telephone, such as a smartphone, or a tablet device.
- the DMS 102 and the remote system 108 may be any suitable type of computing system or collection of computing system, such as a server or a collection of servers.
- FIG. 2 there is a method for the first and second users to enable the remote system 108 to access the jointly accessible data stored at the DMS 102 using the first user device 104 and the second user device 106.
- step 1 the first user sends a message via the first user device 104 that is indicative of the first user providing their consent for the remote system 108 to access the jointly accessible data stored at the DMS 102.
- the message that provides the first user's consent for access to the jointly accessible data is sent from the first user device 104 to the remote system 108.
- step 2 the remote system 108 connects to the DMS 102.
- the remote system 108 creates an account request resource. This informs the DMS 102 that one of its users is granting the remote system 108 with access to data associated with the online account of that user.
- the DMS 102 responds with an identifier for the resource. This step is carried out by the remote system 108 making a POST request, which is supported by the Hypertext Transfer Protocol, to an endpoint at the DMS 102.
- an account request setup payload is sent from the remote system 108 to the DMS 102, which comprises fields describing the data that the first user has consented for the remote system 108 to access.
- the fields in the setup payload may comprise a permissions field, an expiration date field and a period field.
- the permissions field comprises an identifier for a data cluster or a list of identifiers for data clusters that the first user has consented for the remote system 108 to access.
- the expiration date field comprises an optional expiration time at which point the remote system 108 will be prevented from accessing the first user's data stored at the DMS 102.
- the period field comprises a date/time range which can be used to only provide access to data items stored at the DMS 102 that are associated with dates/times that fall within the date/time range.
- the period field may specify a transaction history period.
- the DMS 102 uses the transaction history period to determine that the remote system 108 is only to have access to the transactions that were made within the transaction history period.
- the remote system 108 may send multiple account requests for the same user, with different setup payloads in each request.
- step 3 once the account request has been completed, the remote system transmits a redirect message to the first user device 104 that instructs the device 104 to be redirected to the DMS 102.
- the redirect message includes an account request identifier associated with the account request established in step 2.
- the account request identifier allows the DMS 102 to correlate messages transmitted from the first user device 104 with the account request that was setup in step 2.
- the first user device 104 is redirected to the DMS 102.
- the first user is redirected to a web-page or an application through which the first user is able to access their online account.
- the first user device 104 provides the account request identifier to the DMS 102. This allows the DMS 102 to correlate messages from the first user device 104 with the account request of step 2.
- the DMS 102 authenticates the first user via the first user device 104. This can occur by the first user inputting their login information into the web-page or the application using the first user device 104. Once the user has been authenticated the user is able to provide their consent for the remote system 108 to access their data. Then, the DMS 102 updates the state of the account request resource to indicate that the account request has been authorised by the first user. This may involve setting a flag associated with the first user to indicate that the data is authorised to be shared with the remote system 108, where previously the flag was set to indicate that the data is not authorised to be shared with the remote system 108.
- the online user account may comprise a plurality of sub-accounts.
- the user's online banking account may comprise different sub-accounts, such as a current account and a savings account.
- the first user selects accounts that are authorised for the remote system 108 to access. This selection may be executed by the first user via a user interface at the first user device 104.
- the consent for data to be shared is managed in step 1 between the first user and the remote system 108.
- the first user cannot change the details of the account request by interacting with the DMS 102 in step 5.
- the first user will only be able to authorise or reject the account request details in its entirety in step 5.
- step 1 it is necessary for step 1 to be repeated with different consent parameters provided by the first user.
- the DMS 102 identifies the secure data item or items which the first user has provided consent for the remote system 108 to access.
- the DMS 102 identifies that the secure data item or items are jointly accessible by the first user and a second user.
- the jointly accessible data items may be data items that are accessible by the first and second users only, unless otherwise authorised by both the first user and the second user.
- the first user device 104 is redirected back to the remote system 108. However, at this point the remote system 108 is unable to access the data items for which consent was provided by the first user until consent has been provided by the second user. Thus, if the remote system 108 were to transmit a request for the data to the DMS 102 at this point, then the request would be rejected by the DMS 102.
- step 7 if the DMS 102 determines that the data item to which the remote system 108 has been granted access is jointly accessible by the first user and the second user, then the DMS 102 transmits an auxiliary authorisation request to the second user device.
- the DMS 102 may cause a Short Message Service (SMS) to be transmitted to the mobile telephone number of the second user comprising the authorisation request.
- SMS includes a prompt for the second user to authorise the data request.
- SMS Short Message Service
- the second user accesses the online account that is shared by the first user and the second user. This can occur by the second user inputting their login information into a web-page or an application via an account interface using the second user device 106. Once the second user has provided the login information, the second user is authenticated by the DMS 102. The second user is then presented with a main authorisation request which comprises a prompt for the second user to authorise the first user's consent for the data to be shared with the remote system. The second user provides their consent for the remote system 108 to access the data in response to the prompt via the online account. Then, the DMS 102 updates the state of the account request resource to indicate that the account request has been authorised by the first user and the second user. This may involve setting a flag associated with the second user to indicate that the data is authorised to be shared with the remote system 108, where previously the flag was set to indicate that the data is not authorised to be shared with the remote system 108.
- a notification is transmitted to the first user.
- This notification comprises a message indicting that the second user (and any other user) has provided authorisation for the data to be shared with the remote system 108.
- the notification may be sent via SMS, email or pre-recorded voice message via telephone.
- step 9 the first user from which the initial request for access to data was initiated reconnects with the remote system 108.
- step 10 the remote system 108 transmits a request for access to the secure data item that is jointly accessible by the first user and the second user. This is carried out by making a GET request, which is supported by the Hypertext Transfer Protocol, to the relevant resource at the DMS 102.
- step 11 since both the first and the second users have provided their consent, the secure data item that is jointly accessible by the first and second users is transmitted from the DMS 102 to the remote system 108.
- Fig. 3 shows a flow chart illustrating, at an overview level, a method of sharing the jointly accessible data stored at the DMS 102 with the remote system 108.
- At least one secure data item is stored at a data storage resource at the DMS 102.
- the at least one secure data item is indicative of the details of a financial transaction.
- the at least one secure data item may relate to any type of secure data for which access by unauthorised third parties is to be restricted.
- step 21 if the secure data item is jointly accessible by the first user and the second user, the DMS 102 sets a first flag associated with the first user and a second flag associated with the second user.
- the first flag indicates that the secure data item is not to be shared with a remote system
- the second flag indicates that the secure data items is not to be shared with a remote system. If the data item is not jointly accessible, and is accessible by the first user only without first being authorised to be accessed by third parties, the DMS 102 sets the first flag only.
- the DMS 102 receives a data request from the first user device 104.
- the data request comprises an instruction to transmit the secure data item to the remote system 108.
- Step 22 of Fig. 3 may be executed in a similar manner to steps 1 and 2 as described with reference to Fig. 2 , where the first user sends a request for the secure data item to be shared via the remote system.
- Step 22 of Fig. 3 may be executed in a similar manner to step 4 as described with reference to Fig. 2 , where the first user device 104 is redirected to the DMS 102 with the account request identifier.
- Step 22 of Fig. 3 may be executed in a similar manner to step 5 as described with reference to Fig. 2 , where the first user device 104 authorises the DMS 102 to transmit the data to the remote system 108.
- Step 22 of Fig. 3 may be executed as steps 1 to 5 in combination as described with reference to Fig. 2 .
- step 23 the first user provides authorisation to the DMS 102 for the secure data item to be sent to the remote system 108, as described with reference to step 5 in Fig. 2 .
- the first flag associated with the first user is set to indicate that the secure data item is to be shared with the remote system 108.
- step 24 the DMS 102 determines whether the secure data item is jointly accessible by a plurality of users. Step 24 may be executed in a similar manner to step 6 of Fig. 2 . In step 24, the DMS 102 may determine that the secure data items is jointly accessible by the first user and the second user. This may occur, for instance, by identifying that a first identification number associated with the first user and a second identification number associated with the second user are both associated with the secure data item.
- step 30 the secure data item is transmitted to the remote system 108.
- Step 30 may be executed in a similar manner to steps 10 and 11 of Fig. 2 .
- step 24 the DMS 102 may determine that the secure data item is jointly accessible by the first user and the second user. In this scenario the method proceeds to step 25 in which the DMS 102 seeks authorisation from the second user for the secure data item to be shared.
- the DMS 102 transmits an authorisation message to the second user via the account interface of the shared online data storage account of the first user and the second user, as in step 7 of Fig. 2 .
- the authorisation message comprises a prompt for the second user to authorise the data request previously authorised by the first user.
- the second user accesses the account interface by entering their login information into a web-page or application used for accessing the shared online data storage account, the second is presented with or can navigate to the authorisation message.
- the second user may access the online account using the second user device or any other suitable device.
- the authorisation message is not made available to the first user via the account interface, so that the first user is unable to provide authorisation on behalf of the second user.
- the DMS 102 recognises whether the first user or the second user is accessing the online account from the unique login information provided by either user.
- the authorisation message is not presented if the DMS 102 determines that the first user is accessing the online account. However, the authorisation message is presented if the DMS 102 determines that the second user is accessing the online account.
- step 26 which may occur at the same time, before, or after step 25, the DMS 102 transmits an auxiliary authorisation request to the second user.
- the auxiliary authorisation request provides a prompt for the second user to authorise the data request previously authorised by the first user. This prompt may comprise an instruction for the second user to access the online account in order to be presented with the authorisation request sent in step 25.
- the prompt provided by the auxiliary authorisation request may comprise a link to the web-page or application through which the account interface can be accessed. This may increase the ease and speed at which the second user is able to connect with the online account. However, providing a link in the auxiliary authorisation request may increase the likelihood of so-called "phishing" attacks. In order to avoid to avoid the risk of such attacks, the prompt may not comprise a link, and may only provide written or aural instructions for the user to login to their online account.
- the DMS 102 may transmit a Short Message Service (SMS) comprising the auxiliary authorisation request to a telephone number associated with the second user.
- SMS Short Message Service
- the DMS 102 may transmit an email comprising the auxiliary authorisation request to an email address associated with the second user.
- the auxiliary authorisation request is received via an email service operated at a device of the second user, which may be second user device 104 or any other suitable device.
- the DMS 102 may transmit a pre-recorded voice message comprising the auxiliary authorisation request to a telephone number associated with the second user.
- the auxiliary authorisation request is received at a telephone of the second user, which may be the second user device 104 or any other suitable device.
- step 27 the user chooses to authorise or reject the data request via the account interface. If the data request is authorised, a grant message is sent from the device operated by the second user to the DMS 102, as in step 8 of Fig. 2 . If the data request is rejected, the grant message is not sent and a rejection message may be sent instead. If the data request is rejected by the second user, the method proceeds to step 28 in which the secure data item is prevented from being sent to the remote system 108. In this situation the second flag associated with the second user is maintained to indicate that the secure data item is not to be transmitted to the remote system 108.
- step 29 the second flag associated with the second user is set to indicate that the secure data item is authorised to be shared with the remote system.
- step 30 the DMS 102 identifies that both the first flag and the second flag are set to indicate that the first and second users have provided authorisation for the secure data item to be shared with the remote system 108. In this situation, the DMS 102 transmits the secure data item to the remote system 108, as in step 11 of Fig. 2 .
- At least one data item is stored at the DMS 102.
- the at least one data item in this instance, is a secure data item that is accessible by the user via an account interface of an online data storage account associated with the first user.
- the secure data item may be a data item that is accessible by the first user only without prior consent for the data item to be accessed by a third party.
- the secure data is jointly accessible by at least two users as explained above.
- the first user may operate the account interface of the data storage account to transmit a data retention request to the DMS 102.
- the data retention request is indicative that the first user does not authorise the secure data item to be transmitted to a remote system 108 or any other such third party.
- the data retention request is received at the DMS 102, from the first user device 104.
- the DMS 102 In response to receiving the data retention request, the DMS 102 sets a data retention flag in association with the first user.
- the data retention flag indicates that the secure data of the first user is not to be shared outside of the DMS 102.
- the data retention flag overrides the first or the second flag described above, which can be used to indicate that the first or the second user has provided consent for the data to be shared. Therefore, the DMS 102 cannot transmit the secure data to the remote system 108 while the data retention flag is set to indicate that the data is not to be shared, even if the first or the second flag indicates that the user has provided consent.
- the DMS 102 may receive a data request from a system that is remote and distinct from the DMS 102 which requests access to the secure data item. In response to the data request, the DMS 102 identifies that the first user is associated with the data retention flag and thus prevents transmission of the secure data item to the remote system 108. The DMS 102 is only able to transmit the secure data item to the remote system 108 if the data retention flag is set to indicate that the data is authorised to be shared.
- Fig. 4 shows a protocol sequence diagram which illustrates the method described with reference to Fig. 2 in greater detail.
- the DMS 102 described above further comprises a trusted identity and attribute authority 102a (TIAA) and an identity provider 102b (IDP).
- TIAA trusted identity and attribute authority
- IDP identity provider
- the remote system 108 and the DMS 102 interact in order for an intent token to be transmitted to the remote system 108.
- the remote system 108 transmits a request for an access token to the TIAA 102a at the DMS 102.
- the access token being requested is a web token that is configured to enable the remote system 108 to send an intent application programming interface (API) to the DMS 102.
- API intent application programming interface
- the access token requested by the remote system 108 will be valid for a predetermined period of time.
- the access token can be used more than once by the remote system 108.
- the web token is a JavaScript Object Notation (JSON) web token.
- the request for the access token is transmitted directly to the TIAA 102a, and the request comprises a client identifier and a client secret.
- the client identifier and the client secret are previously assigned to the remote system 108, when the remote system 108 registers with the DMS 102.
- the TIAA 102a validates the client identifier and the client secret in order to authenticate the remote system 108.
- step 41 the TIAA 102a generates an intent access token and transmits the intent access token to the remote system 108.
- the first user transmits a message to the remote system 108 indicating that the first user has requested for the DMS 102 is to transmit a secure data item to the remote system 108.
- the secure data is a data item that is jointly accessible by the first user and the second via an account interface of a shared online data storage account.
- step 43 the remote system 108 transmits an external consent intent API, along with the intent access token provided previously in step 41.
- the remote system 108 also sends the details of the user's consent request, such as the account type, period of time, permissions, as described with reference to the account request setup payload in step 2 of Fig. 2 .
- the TIAA 102a receives the external consent intent API and validates the corresponding intent access token.
- the identity of the remote system 108 is authenticated in order to determine whether the remote system 108 is an authorised entity. If the remote system is not an authorised entity or the intent access token is not valid, the external consent intent API will be rejected, and an error code is returned to the remote system 108.
- the DMS 102 uses an internal consent intent API, which generates a unique consent identifier that corresponds with the request received from the remote system 108 and remains valid throughout the lifecycle of the request.
- the internal consent API stores the details of the intent in a consent database in association with the consent identifier.
- the DMS 102 returns the unique consent identifier to the remote system 108.
- step 45 once the remote system 108 has received the consent identifier from the consent intent API, the remote system 108 retrieves a redirect URL from a registry which points to the TIAA 102a. In this step, the remote system 108 redirects first user device 104 to the TIAA 102a with the client identifier, the unique consent identifier and the details of the user's consent request. This information is sent using OAuth 2.0.
- step 46 the first user device 104 is redirected to the TIAA 102a, which validates the client identifier and the details of the user's consent request.
- the TIAA 102a transmits a redirect uniform resource identifier (URI) to the first user device 104 and a first reference code. This redirects the first user device 104 to the IDP 102b.
- the IDP 102b transmits a request to the TIAA102a for the consent identifier and the details of the user's consent request. Then, it is necessary for the IDP 102b to obtain a linking identifier. The IDP 102b will then call an API for obtaining the linking identifier.
- a call to the TIAA 102b is required to translate the client identifier and the remote system 108 identifier into textual names.
- the first user is prompted to authenticate their identity. For instance, the first user is prompted to input their unique login information via a user interface. The first user then operates the user interface of the online account to navigate to a consent page or area. At that point, an internal authorisation API for obtaining the first user's consent is configured to match the request with the data previously received via the consent intent API to obtain the full consent that the customer is being asked to authorise. This is achieved via the linking identifier or via a direct deep link approach (for mobile devices only) using the consent identifier directly.
- the IDP 102b constructs a list of accounts that the first user can select. This will be constructed by generating a list of all accounts to which the first user has access to the data of, or the accounts from which the user can make a payment, or the accounts that are enabled for data sharing. For instance, certain account types may be enabled or disabled for sharing data. The enabled account types will appear in the list, while the disabled account types will not appear in the list.
- step 48 the first user is presented with the consent that they have requested and the list of accounts for the first user to choose from.
- the customer authorises the consent, and since the user has been authenticated, an identifier for the first user will be known.
- the authorisation received from the user will be digitally signed within the IDP 102b and will be stored in associated with the authorised consent.
- the DMS 102 determines whether the data to which the remote system 108 has been granted access by the first user is jointly accessible by another user. In this example, the DMS 102 determines that the data is jointly accessible by the second user. In this scenario, the DMS 102 interacts with the second user via the second user device 106 or another suitable device in order to obtain consent from the second user. This process may occur in a similar manner to that described above, but the DMS 102 interacts with the second user rather than the first user.
- step 50 the first user device is redirected back to the TIAA 102a.
- the TIAA 102a sends an authorisation code and a URI to the first user device.
- the URI is assigned to the remote system 108 when the remote system 108 registers with the DMS 102 initially and is used to redirect the first user device to the remote system 108.
- step 52 the first user device 10 is redirected to the remote system 108.
- step 53 the authorisation code is sent by the remote system 108 to the TIAA 102a which validates the authorisation code and the identity of the remote system 108.
- step 54 the TIAA 102a transmits an access token and a refresh token to the remote system 108.
- the remote system 108 will transmit the refresh token rather than the authorisation code.
- the TIAA 102a will issue a new access token and a new refresh token.
- step 55 the remote system 108 transmits an external execute API to the DMS 102, which matches the details held in the authorised consent.
- the consent identifier is passed to an internal execute API at the DMS 102, which will call an internal validate authorised consent API using the consent identifier along with any additional data required from the execute API to match against the Authorised Consent (such as the account number, and payment details).
- the validate authorised consent API will then check that the consent identifier exists and has not expired.
- the validate authorised consent API will also check that any details passed match the authorised consent. This may include checking that the API being executed within scope of the user's authorisation that have been authorised, that the account being requested within the accounts have been authorised.
- the secure data item that is jointly accessible by the first user and the second user is transmitted to the remote system 108. This is enabled because both the first user and the second user have provided their consent for the data to be shared with the remote system 108.
- the validate Authorised consent API will pass back a success or failure message to the calling execute API.
- the API will also pass back the translation from the consent customer identifier to the actual customer identifier as used by the IDP 102b, the consent account identifier to the actual account identifier, and any other data that was saved at the point of authorisation (e.g. a biometrics score for detecting fraud).
- the DMS 102 comprises a communication interface 501 comprising a receiver 502 and a transmitter 503.
- the DMS 102 also comprises an identification module 504, a flag setting module 505 and a storage resource 506.
- the receiver 502 and the transmitter 503 are configured to receive and transmit the messages to and from the DMS 102 as explained above.
- the identification module 504 is arranged to identify whether a secure data item is a jointly accessible data item.
- the flag setting module 505 is arranged to manage the setting of flags as described above.
- the storage resource is arranged to store the secure data items at the DMS 102.
- Fig. 6 shows an exemplary electronic device 401 according to any of the electronic devices or systems of this disclosure (such as the first user device 102, the second user device 104, the remote system 108, the DMS 102, the TIAA 102a or the IDP 102b).
- the electronic device 401 comprises processing circuitry 410 (such as a microprocessor) and a memory 412.
- Electronic device 401 may also comprise one or more of the following subsystems: a power supply 414, a display 416, a transceiver 420, and an input 426.
- Processing circuitry 410 may control the operation of the electronic device 401 and the connected subsystems to which the processing circuitry is communicatively coupled.
- Memory 412 may comprise one or more of random access memory (RAM), read only memory (ROM), non-volatile random access memory (NVRAM), flash memory, other volatile memory, and other non-volatile memory.
- Display 416 may be communicatively coupled with the processing circuitry 410, which may be configured to cause the display 416 to output images representative of the secure data shared between the entities in the system 100.
- the display 416 may comprise a touch sensitive interface, such as a touch screen display.
- the display 416 may be used to interact with software that runs on the processor 410 of the electronic device 401.
- the touch sensitive interface permits a user to provide input to the processing circuitry 410 via a discreet touch, touches, or one or more gestures for controlling the operation of the processing circuitry and the functions described herein. It will be appreciated that other forms of input interface may additionally or alternatively be employed for the same purpose, such as the input 426 which may comprise a keyboard or a mouse at the input device.
- the transceiver 420 may be one or more long-range RF transceivers that are configured to operate according to communication standard such as LTE, UMTS, 3G, EDGE, GPRS, GSM, and Wi-Fi.
- electronic device 401 may comprise a first wireless transceiver 421, such as a cellular transceiver, that is configured to communicate with a cell tower 403 via to a cellular data protocol such as LTE, UMTS, 3G, EDGE, GPRS, or GSM, and a second transceiver 428, such as a Wi-Fi transceiver, that is configured to communicate with a wireless access point 404 via to a Wi-Fi standard such as 802.11 ac/n/g/b/a.
- a Wi-Fi standard such as 802.11 ac/n/g/b/a.
- a long-range wireless protocol may be a protocol which is capable and designed for communication over 5, 10, 20, 30, 40, 50, or 100m. This is in contrast to short-range wireless protocol mentioned above.
- the long-range wireless protocol may communicate utilizing higher power than the short- range wireless protocol.
- the range (e.g. line of sight distance) between the long-range end nodes (electronic device and router or base station) for the long-range wireless protocol may be greater than the range (e.g. line of sight distance) between the short-range end nodes (e.g. electronic device and wireless beacon).
- Electronic device 401 may be configured to communicate via the transceiver 420 with a network 440.
- Network 440 may be a wide area network, such as the Internet, or a local area network.
- Electronic device 401 may be further configured to communicate via the transceiver 420 and network 440 with one or more systems 14 or user devices 11, 12, 13. These servers or user devices may be any one of those described herein.
- composition comprising X may consist exclusively of X or may include something additional e.g. X + Y.
- the methods described herein may be performed by software in machine readable form on a tangible storage medium e.g. in the form of a computer program comprising computer program code means adapted to perform all the steps of any of the methods described herein when the program is run on a computer and where the computer program may be embodied on a computer readable medium.
- tangible (or non-transitory) storage media include disks, thumb drives, memory cards etc. and do not include propagated signals.
- the software can be suitable for execution on a parallel processor or a serial processor such that the method steps may be carried out in any suitable order, or simultaneously. This acknowledges that firmware and software can be valuable, separately tradable commodities.
- modules described herein may be implemented in hardware or in software. Furthermore, the modules may be implemented at various locations throughout the system.
- a remote computer may store an example of the process described as software.
- a local or terminal computer may access the remote computer and download a part or all of the software to run the program.
- the local computer may download pieces of the software as needed, or execute some software instructions at the local terminal and some at the remote computer (or computer network).
- a dedicated circuit such as a DSP, programmable logic array, or the like.
- any reference to 'an' item refers to one or more of those items.
- the term 'comprising' is used herein to mean including the method blocks or elements identified, but that such blocks or elements do not comprise an exclusive list and a method or apparatus may contain additional blocks or elements.
Description
- This disclosure relates to a system, a method and a computer program for managing data associated with a first user and a second user.
- In conventional digital communication systems it is common for an individual user to have access to an online account, which provides the user with the ability to store and access data via the Internet. For example, one user may operate an online user account hosted by a file hosting service to store electronic files such as image files, music files and word processing documents. These files may be used to store sensitive personal information about the user, which the user must keep private in order to avoid the likelihood of becoming a victim of fraud or identity theft. In a specific example of an online user account, the user may use an online banking account to access their financial data, such as records of previous financial transactions that the user has made.
- In certain situations it is desirable for two or more users to have permission to access the same online account, so that data is jointly accessible by the two users via an interface for the shared online account. In this scenario it is assumed that the two users trust one another with the data that is accessible via the online account.
- Following on from the example of the file hosting service, two users may use a single online account operated by the file hosting service to store private data or documents that relate to both of the users, such as housing information, personal identity information and financial information. In a specific example, two users may have access to a single online banking account for storing sensitive financial data. In each of these examples, each user is provided with login information that is specific to each user, so that the shared online account can determine which user is accessing the account at a particular time.
- Users of shared accounts rely on the assumption that each of the users will not abuse their access to the data in such a way that would comprise any one of the other user's information security. However, this assumption may not be correct. For instance, one user may transmit private data of the shared online account to a third party, and another user of the online account may not wish for any third parties to have access to this private data. Thus, there exists a need for a system that enables users of joint online accounts to manage access to data in a secure manner.
- In
US 6,775,668 B1 , there is described a method and system for implementing a quorum based access control mechanism for modifying at least one database attribute in a database. - In
US 2012/117157 A1 , there is described a system for determining presence of and authorizing a quorum to transact business over a network including a first set of machine-readable instructions resident on a digital medium accessible to a computing machine, the instructions causing the machine to monitor a network for active presence of individual ones of communications devices associated with members of an authorized team of individuals from which the quorum may be determined, a second set of machine-readable instructions resident on the medium for causing the computing machine to make a confirmation of the quorum against a set of rules, and to authorize one or more of the individual communications devices making up the quorum to perform one or more tasks based on quorum consensus, and a user configuration, scheduling, and notification application resident on the digital medium for enabling a user to configure, schedule, and notify team members of a pending quorum event. - In one aspect of the invention, there is a computer-implemented method for managing data associated with a first user having a first user device and a second user having a second user device, the method comprising: storing, at a first system, a secure data item jointly accessible by the first user and the second user; receiving, at the first system from the first user device, a data request comprising an instruction to transmit the secure data item to a second system; identifying, at the first system, that the secure data item is jointly accessible by the first user and the second user; in response to identifying that the secure data item is jointly accessible by the first user and the second user, transmitting an authorisation request to the second user device, wherein the authorisation request comprises a prompt for the second user to authorise the data request; receiving, from the second user device, a grant message indicative of the second user granting the authorisation request; in response to receiving the grant message, transmitting the secure data item to the second system; and preventing the secure data item from being sent to the second system, if the grant message is not received.
- In this way, the second system is unable to receive the jointly accessible data item unless both of the users that have access to the data have provided authorisation for the data to be shared. This prevents a single user from unilaterally allowing the secure data item to be sent to the second system, which would compromise the security of the second user. Thus, the method provides a mechanism for jointly accessible data items to be shared in a more secure manner.
- In another aspect of the invention, there is data management system comprising: a data storage resource configured to store a secure data item jointly accessible by both a first user and a second user; and processing circuitry configured to: receive, from a first user device associated with the first user, a data request comprising an instruction to transmit the secure data item from the data storage resource to a remote system; identify that the secure data item is jointly accessible by the first user and the second user; transmit an authorisation request to a second user device associated with the second user, in response to identifying that the secure data item is jointly accessible by the first user and the second user, the authorisation request comprising a prompt for the second user to authorise the data request; receive, from the second user device, a grant message indicative of the second user granting the authorisation request; transmit the secure data item to the remote system in response to receiving the grant message; and prevent the secure data item from being sent to the remote system, if the grant message is not received.
- In another aspect of the invention, there is a data management system comprising: a data storage resource configured to store a secure data item jointly accessible by both a first user and a second user; a receiver configured to receive, from a first user device associated with the first user, a data request comprising an instruction to transmit the secure data item from the data storage resource to a remote system; an identification module arranged to identify that the secure data item is jointly accessible by the first user and the second user; a transmitter arranged to transmit an authorisation request to a second user device associated with the second user, in response to identifying that the secure data item is jointly accessible by the first user and the second user, the authorisation request comprising a prompt for the second user to authorise the data request; wherein the receiver is arranged to receive, from the second user device, a grant message indicative of the second user granting the authorisation request; wherein the transmitter is arranged to transmit the secure data item to the remote system in response to receiving the grant message; and wherein the transmitter is arranged to prevent the secure data item from being sent to the remote system, if the grant message is not received.
- In another aspect of the invention, there is a computer-implemented method for managing data associated with a first user having a first user device, the method comprising: storing, at a first system, a first data item accessible by the first user; receiving at the first system, from the first user device, a data retention request comprising an instruction not to transmit the first data item stored at the first system to a system distinct from the first system; in response to receiving the data retention request, setting a data retention flag at the first system in association with the first user; receiving a data request from a system distinct from the first system for access to the first data item; in response to the data request, identifying that the first user is associated with the data retention flag at the first system and preventing transmission of the first data item to the second system.
- In this way, it is possible for a user to set an indication for their data not to be shared to any third parties. This indication overrides any other indication of the user wishing for their data to be shared. Thus, it is possible for the user to prevent their secure data from being accidentally shared with third parties. This is particularly relevant in modern computing environments where users are presented with a large number of different requests, and in these situations a user may authorise their data to be shared when in fact the user does not wish for this to happen. In this scenario, the data retention flag allows a user to ensure that their data is not transmitted to any fraudulent or malicious third parties that may compromise their information security.
- In another aspect of the invention, there is a data management system for managing data associated with a first user having a first user device comprising: a data storage resource configured to store a first data item accessible by the first user; and processing circuitry configured to: receive at the data management system, from the first user device, a data retention request comprising an instruction not to transmit the first data item to a system distinct from the data management system; in response to receiving the data retention request, setting a data retention flag at the data management system in association with the first user; receiving a data request from a system distinct from the data management system for access to the first data item; in response to the data request, identifying that the first user is associated with the data retention flag at the data management system and preventing transmission of the first data item to the system distinct from the data management system.
- In another aspect of the invention, there is a data management system for managing data associated with a first user having a first user device comprising: a data storage resource configured to store a first data item accessible by the first user; a receiver arranged to receive, from the first user device, a data retention request comprising an instruction not to transmit the first data item to a system distinct from the data management system; a flag setting module arranged to set a data retention flag at the data management system in association with the first user, in response to receiving the data retention request; wherein the receiver is arranged to receive a data request from a system distinct from the data management system for access to the first data item; and an identification module arranged to identify that the first user is associated with the data retention flag and preventing transmission of the first data item to the system distinct from the data management system in response to the data request.
- In another aspect of the invention, there is a computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method described herein.
- In another aspect of the invention, there is a data carrier signal carrying the computer program described herein.
- In another aspect of the invention, there is a computer readable medium which, when the program is executed by a computer, cause the computer to carry out the method described herein.
- Embodiments of the invention will be described, by way of example, with reference to the following drawings, in which:
-
Fig. 1 illustrates the general architecture of a system for managing secure data that is jointly accessible by a first user and a second user; -
Fig. 2 illustrates a protocol sequence diagram of a computer-implemented method for managing access to the secure data; -
Fig. 3 illustrates a flow chart of a computer-implemented method performed by the system for managing secure data; -
Fig. 4 illustrates a protocol sequence diagram of the computer-implemented method for managing access to the secure data; -
Fig. 5 illustrates a schematic diagram of a data management system; and -
Fig. 6 illustrates a schematic diagram of an example device in the system. - Referring to
Fig. 1 , there is asystem 100 for managing access to data associated with a first user and a second user. The system comprises a data management system (DMS) 102, afirst user device 104, asecond user device 106 and aremote system 108. - The
DMS 102 is arranged to store data relating to users of thesystem 100. Specifically, theDMS 102 stores data that is associated with the first user and the second user which may comprise one or more data items. Each one of these data items is indicative of private information relating to the first and second users. For instance, each data item may comprise financial data relating to the first and second users, such as details that enable the users to make payments or the details of previous financial transactions made by the users. - The following systems and methods are described in the context of managing access to financial data. However, these systems and methods could be used to manage access to any type of secure data for which access by unauthorised third parties is to be restricted.
- In the following examples, data is referred to as being jointly accessible by the first and second users, and that data is associated with both the first user and the second user. For example, the first user and the second user may have access to the same online user account, such as an online banking account, via an account interface. In this scenario, each one of the users may be assigned a unique username and a shared secret, such as a password, that can be used to access the user account via the account interface. Once the first or the second user has accessed the user account, that user is able to access the data via the user account. Therefore, the data is jointly accessible by the first and second users via login information that is unique to each one of the users. In some situations the users may access the data at the same time, or each user may access the data at different times.
- Data that is jointly accessible by a plurality of users is detected by the
DMS 102 determining that more than user is associated with an account linked with the data. - The secure data that is jointly accessible by the first and second users may be accessible by the DMS 102 itself. The jointly accessible data may be accessible by the first and second users only, unless otherwise authorised by both the first user and the second user. In other words, the jointly accessible data is prevented from being sent to a device or a system that is remote and distinct from the
DMS 102, such as theremote system 108, without the first and second users providing authorisation to theDMS 102 for the jointly accessible data to be sent to a remote device or system. - The
system 100 comprises afirst user device 104 which is operated by the first user and asecond user device 106 which is operated by the second user. The system also comprises aremote system 108 to which the jointly accessible data can be sent. - Each one of the
DMS 102,remote system 108 anduser devices communications network 110. Thecommunications network 110, in this example, is theInternet 110. However, it will be appreciated that any suitable form ofcommunications network 110 could be used. - Each one of the
DMS 102,remote system 108 anduser devices systems systems - The
first user device 104 and/or thesecond user device 106 may be any suitable type of personal computing device, such as a laptop computer, a desktop computer, a web-enabled telephone, such as a smartphone, or a tablet device. TheDMS 102 and theremote system 108 may be any suitable type of computing system or collection of computing system, such as a server or a collection of servers. - Referring to
Fig. 2 , there is a method for the first and second users to enable theremote system 108 to access the jointly accessible data stored at theDMS 102 using thefirst user device 104 and thesecond user device 106. - In
step 1, the first user sends a message via thefirst user device 104 that is indicative of the first user providing their consent for theremote system 108 to access the jointly accessible data stored at theDMS 102. The message that provides the first user's consent for access to the jointly accessible data is sent from thefirst user device 104 to theremote system 108. - In
step 2, theremote system 108 connects to theDMS 102. In this step, theremote system 108 creates an account request resource. This informs theDMS 102 that one of its users is granting theremote system 108 with access to data associated with the online account of that user. In this step, theDMS 102 responds with an identifier for the resource. This step is carried out by theremote system 108 making a POST request, which is supported by the Hypertext Transfer Protocol, to an endpoint at theDMS 102. - In
step 2, an account request setup payload is sent from theremote system 108 to theDMS 102, which comprises fields describing the data that the first user has consented for theremote system 108 to access. The fields in the setup payload may comprise a permissions field, an expiration date field and a period field. The permissions field comprises an identifier for a data cluster or a list of identifiers for data clusters that the first user has consented for theremote system 108 to access. The expiration date field comprises an optional expiration time at which point theremote system 108 will be prevented from accessing the first user's data stored at theDMS 102. The period field comprises a date/time range which can be used to only provide access to data items stored at theDMS 102 that are associated with dates/times that fall within the date/time range. For example, the period field may specify a transaction history period. TheDMS 102 uses the transaction history period to determine that theremote system 108 is only to have access to the transactions that were made within the transaction history period. Theremote system 108 may send multiple account requests for the same user, with different setup payloads in each request. - In
step 3, once the account request has been completed, the remote system transmits a redirect message to thefirst user device 104 that instructs thedevice 104 to be redirected to theDMS 102. The redirect message includes an account request identifier associated with the account request established instep 2. The account request identifier allows theDMS 102 to correlate messages transmitted from thefirst user device 104 with the account request that was setup instep 2. - In
step 4, thefirst user device 104 is redirected to theDMS 102. For instance, the first user, is redirected to a web-page or an application through which the first user is able to access their online account. When thefirst user device 104 is redirected to theDMS 102, thefirst user device 104 provides the account request identifier to theDMS 102. This allows theDMS 102 to correlate messages from thefirst user device 104 with the account request ofstep 2. - In
step 5, theDMS 102 authenticates the first user via thefirst user device 104. This can occur by the first user inputting their login information into the web-page or the application using thefirst user device 104. Once the user has been authenticated the user is able to provide their consent for theremote system 108 to access their data. Then, theDMS 102 updates the state of the account request resource to indicate that the account request has been authorised by the first user. This may involve setting a flag associated with the first user to indicate that the data is authorised to be shared with theremote system 108, where previously the flag was set to indicate that the data is not authorised to be shared with theremote system 108. - The online user account may comprise a plurality of sub-accounts. For instance, the user's online banking account may comprise different sub-accounts, such as a current account and a savings account. During authorisation, the first user selects accounts that are authorised for the
remote system 108 to access. This selection may be executed by the first user via a user interface at thefirst user device 104. - In the method, the consent for data to be shared is managed in
step 1 between the first user and theremote system 108. Thus, the first user cannot change the details of the account request by interacting with theDMS 102 instep 5. The first user will only be able to authorise or reject the account request details in its entirety instep 5. In order for the first user to change the details of the account request, it is necessary forstep 1 to be repeated with different consent parameters provided by the first user. - In
step 6, theDMS 102 identifies the secure data item or items which the first user has provided consent for theremote system 108 to access. In this example, theDMS 102 identifies that the secure data item or items are jointly accessible by the first user and a second user. As explained above, the jointly accessible data items may be data items that are accessible by the first and second users only, unless otherwise authorised by both the first user and the second user. Insteps first user device 104 is redirected back to theremote system 108. However, at this point theremote system 108 is unable to access the data items for which consent was provided by the first user until consent has been provided by the second user. Thus, if theremote system 108 were to transmit a request for the data to theDMS 102 at this point, then the request would be rejected by theDMS 102. - In
step 7, if theDMS 102 determines that the data item to which theremote system 108 has been granted access is jointly accessible by the first user and the second user, then theDMS 102 transmits an auxiliary authorisation request to the second user device. For instance, theDMS 102 may cause a Short Message Service (SMS) to be transmitted to the mobile telephone number of the second user comprising the authorisation request. The SMS includes a prompt for the second user to authorise the data request. - In
step 8, the second user accesses the online account that is shared by the first user and the second user. This can occur by the second user inputting their login information into a web-page or an application via an account interface using thesecond user device 106. Once the second user has provided the login information, the second user is authenticated by theDMS 102. The second user is then presented with a main authorisation request which comprises a prompt for the second user to authorise the first user's consent for the data to be shared with the remote system. The second user provides their consent for theremote system 108 to access the data in response to the prompt via the online account. Then, theDMS 102 updates the state of the account request resource to indicate that the account request has been authorised by the first user and the second user. This may involve setting a flag associated with the second user to indicate that the data is authorised to be shared with theremote system 108, where previously the flag was set to indicate that the data is not authorised to be shared with theremote system 108. - Once the
DMS 102 has been updated to indicate that request has been authorised by the second user (and any other users that can jointly access the data), a notification is transmitted to the first user. This notification comprises a message indicting that the second user (and any other user) has provided authorisation for the data to be shared with theremote system 108. The notification may be sent via SMS, email or pre-recorded voice message via telephone. - In
step 9, the first user from which the initial request for access to data was initiated reconnects with theremote system 108. - In
step 10, theremote system 108 transmits a request for access to the secure data item that is jointly accessible by the first user and the second user. This is carried out by making a GET request, which is supported by the Hypertext Transfer Protocol, to the relevant resource at theDMS 102. - In
step 11, since both the first and the second users have provided their consent, the secure data item that is jointly accessible by the first and second users is transmitted from theDMS 102 to theremote system 108. -
Fig. 3 shows a flow chart illustrating, at an overview level, a method of sharing the jointly accessible data stored at theDMS 102 with theremote system 108. - In
step 20, at least one secure data item is stored at a data storage resource at theDMS 102. In this example, the at least one secure data item is indicative of the details of a financial transaction. However, in other examples the at least one secure data item may relate to any type of secure data for which access by unauthorised third parties is to be restricted. - In
step 21, if the secure data item is jointly accessible by the first user and the second user, theDMS 102 sets a first flag associated with the first user and a second flag associated with the second user. In this step, the first flag indicates that the secure data item is not to be shared with a remote system, and the second flag indicates that the secure data items is not to be shared with a remote system. If the data item is not jointly accessible, and is accessible by the first user only without first being authorised to be accessed by third parties, theDMS 102 sets the first flag only. - In
step 22, theDMS 102 receives a data request from thefirst user device 104. The data request comprises an instruction to transmit the secure data item to theremote system 108.Step 22 ofFig. 3 may be executed in a similar manner tosteps Fig. 2 , where the first user sends a request for the secure data item to be shared via the remote system.Step 22 ofFig. 3 may be executed in a similar manner to step 4 as described with reference toFig. 2 , where thefirst user device 104 is redirected to theDMS 102 with the account request identifier.Step 22 ofFig. 3 may be executed in a similar manner to step 5 as described with reference toFig. 2 , where thefirst user device 104 authorises theDMS 102 to transmit the data to theremote system 108.Step 22 ofFig. 3 may be executed assteps 1 to 5 in combination as described with reference toFig. 2 . - In
step 23, the first user provides authorisation to theDMS 102 for the secure data item to be sent to theremote system 108, as described with reference to step 5 inFig. 2 . Once the first user has provided their authorisation, the first flag associated with the first user is set to indicate that the secure data item is to be shared with theremote system 108. - In
step 24, theDMS 102 determines whether the secure data item is jointly accessible by a plurality of users.Step 24 may be executed in a similar manner to step 6 ofFig. 2 . Instep 24, theDMS 102 may determine that the secure data items is jointly accessible by the first user and the second user. This may occur, for instance, by identifying that a first identification number associated with the first user and a second identification number associated with the second user are both associated with the secure data item. - If the
DMS 102 determines that the secure data item is not jointly accessible, the method proceeds to step 30 in which the secure data item is transmitted to theremote system 108.Step 30 may be executed in a similar manner tosteps Fig. 2 . - In
step 24, theDMS 102 may determine that the secure data item is jointly accessible by the first user and the second user. In this scenario the method proceeds to step 25 in which theDMS 102 seeks authorisation from the second user for the secure data item to be shared. - In
step 25, theDMS 102 transmits an authorisation message to the second user via the account interface of the shared online data storage account of the first user and the second user, as instep 7 ofFig. 2 . The authorisation message comprises a prompt for the second user to authorise the data request previously authorised by the first user. Thus, when the second user accesses the account interface by entering their login information into a web-page or application used for accessing the shared online data storage account, the second is presented with or can navigate to the authorisation message. In this example, the second user may access the online account using the second user device or any other suitable device. - The authorisation message is not made available to the first user via the account interface, so that the first user is unable to provide authorisation on behalf of the second user. The
DMS 102 recognises whether the first user or the second user is accessing the online account from the unique login information provided by either user. The authorisation message is not presented if theDMS 102 determines that the first user is accessing the online account. However, the authorisation message is presented if theDMS 102 determines that the second user is accessing the online account. - In
step 26, which may occur at the same time, before, or afterstep 25, theDMS 102 transmits an auxiliary authorisation request to the second user. The auxiliary authorisation request provides a prompt for the second user to authorise the data request previously authorised by the first user. This prompt may comprise an instruction for the second user to access the online account in order to be presented with the authorisation request sent instep 25. - The prompt provided by the auxiliary authorisation request may comprise a link to the web-page or application through which the account interface can be accessed. This may increase the ease and speed at which the second user is able to connect with the online account. However, providing a link in the auxiliary authorisation request may increase the likelihood of so-called "phishing" attacks. In order to avoid to avoid the risk of such attacks, the prompt may not comprise a link, and may only provide written or aural instructions for the user to login to their online account.
- In
step 26, theDMS 102 may transmit a Short Message Service (SMS) comprising the auxiliary authorisation request to a telephone number associated with the second user. Thus, the auxiliary authorisation request is received at a telephone of the second user, which may be thesecond user device 104 or any other suitable device. TheDMS 102 may transmit an email comprising the auxiliary authorisation request to an email address associated with the second user. Thus, the auxiliary authorisation request is received via an email service operated at a device of the second user, which may besecond user device 104 or any other suitable device. TheDMS 102 may transmit a pre-recorded voice message comprising the auxiliary authorisation request to a telephone number associated with the second user. Thus, the auxiliary authorisation request is received at a telephone of the second user, which may be thesecond user device 104 or any other suitable device. - In
step 27, the user chooses to authorise or reject the data request via the account interface. If the data request is authorised, a grant message is sent from the device operated by the second user to theDMS 102, as instep 8 ofFig. 2 . If the data request is rejected, the grant message is not sent and a rejection message may be sent instead. If the data request is rejected by the second user, the method proceeds to step 28 in which the secure data item is prevented from being sent to theremote system 108. In this situation the second flag associated with the second user is maintained to indicate that the secure data item is not to be transmitted to theremote system 108. - If the data request is authorised and the grant message is sent, the method proceeds to step 29. In this step, the second flag associated with the second user is set to indicate that the secure data item is authorised to be shared with the remote system.
- In
step 30, theDMS 102 identifies that both the first flag and the second flag are set to indicate that the first and second users have provided authorisation for the secure data item to be shared with theremote system 108. In this situation, theDMS 102 transmits the secure data item to theremote system 108, as instep 11 ofFig. 2 . - In another example, there is a method that can enable a user to indicate to the
DMS 102 that none of their secure data is to be shared with any third parties or remote systems. In this method, at least one data item is stored at theDMS 102. The at least one data item, in this instance, is a secure data item that is accessible by the user via an account interface of an online data storage account associated with the first user. The secure data item may be a data item that is accessible by the first user only without prior consent for the data item to be accessed by a third party. Alternatively, the secure data is jointly accessible by at least two users as explained above. - The first user may operate the account interface of the data storage account to transmit a data retention request to the
DMS 102. The data retention request is indicative that the first user does not authorise the secure data item to be transmitted to aremote system 108 or any other such third party. The data retention request is received at theDMS 102, from thefirst user device 104. - In response to receiving the data retention request, the
DMS 102 sets a data retention flag in association with the first user. The data retention flag indicates that the secure data of the first user is not to be shared outside of theDMS 102. The data retention flag overrides the first or the second flag described above, which can be used to indicate that the first or the second user has provided consent for the data to be shared. Therefore, theDMS 102 cannot transmit the secure data to theremote system 108 while the data retention flag is set to indicate that the data is not to be shared, even if the first or the second flag indicates that the user has provided consent. - Once the data retention flag has been set, the
DMS 102 may receive a data request from a system that is remote and distinct from theDMS 102 which requests access to the secure data item. In response to the data request, theDMS 102 identifies that the first user is associated with the data retention flag and thus prevents transmission of the secure data item to theremote system 108. TheDMS 102 is only able to transmit the secure data item to theremote system 108 if the data retention flag is set to indicate that the data is authorised to be shared. -
Fig. 4 shows a protocol sequence diagram which illustrates the method described with reference toFig. 2 in greater detail. Referring theFig. 4 , theDMS 102 described above further comprises a trusted identity andattribute authority 102a (TIAA) and anidentity provider 102b (IDP). - In
steps remote system 108 and theDMS 102 interact in order for an intent token to be transmitted to theremote system 108. Specifically, instep 40 theremote system 108 transmits a request for an access token to theTIAA 102a at theDMS 102. The access token being requested is a web token that is configured to enable theremote system 108 to send an intent application programming interface (API) to theDMS 102. - The access token requested by the
remote system 108 will be valid for a predetermined period of time. Thus, the access token can be used more than once by theremote system 108. In this example, the web token is a JavaScript Object Notation (JSON) web token. - In
step 40, the request for the access token is transmitted directly to theTIAA 102a, and the request comprises a client identifier and a client secret. The client identifier and the client secret are previously assigned to theremote system 108, when theremote system 108 registers with theDMS 102. TheTIAA 102a validates the client identifier and the client secret in order to authenticate theremote system 108. - In
step 41, theTIAA 102a generates an intent access token and transmits the intent access token to theremote system 108. - In
step 42, the first user transmits a message to theremote system 108 indicating that the first user has requested for theDMS 102 is to transmit a secure data item to theremote system 108. In this example, the secure data is a data item that is jointly accessible by the first user and the second via an account interface of a shared online data storage account. - In
step 43, theremote system 108 transmits an external consent intent API, along with the intent access token provided previously instep 41. Theremote system 108 also sends the details of the user's consent request, such as the account type, period of time, permissions, as described with reference to the account request setup payload instep 2 ofFig. 2 . - In
step 43, theTIAA 102a receives the external consent intent API and validates the corresponding intent access token. In addition, the identity of theremote system 108 is authenticated in order to determine whether theremote system 108 is an authorised entity. If the remote system is not an authorised entity or the intent access token is not valid, the external consent intent API will be rejected, and an error code is returned to theremote system 108. - Further in
step 43, theDMS 102 uses an internal consent intent API, which generates a unique consent identifier that corresponds with the request received from theremote system 108 and remains valid throughout the lifecycle of the request. The internal consent API stores the details of the intent in a consent database in association with the consent identifier. Then instep 44 theDMS 102 returns the unique consent identifier to theremote system 108. - In
step 45, once theremote system 108 has received the consent identifier from the consent intent API, theremote system 108 retrieves a redirect URL from a registry which points to theTIAA 102a. In this step, theremote system 108 redirectsfirst user device 104 to theTIAA 102a with the client identifier, the unique consent identifier and the details of the user's consent request. This information is sent using OAuth 2.0. - In
step 46, thefirst user device 104 is redirected to theTIAA 102a, which validates the client identifier and the details of the user's consent request. - In
step 47, theTIAA 102a transmits a redirect uniform resource identifier (URI) to thefirst user device 104 and a first reference code. This redirects thefirst user device 104 to theIDP 102b. In turn, theIDP 102b transmits a request to the TIAA102a for the consent identifier and the details of the user's consent request. Then, it is necessary for theIDP 102b to obtain a linking identifier. TheIDP 102b will then call an API for obtaining the linking identifier. In addition, a call to theTIAA 102b is required to translate the client identifier and theremote system 108 identifier into textual names. - In step 48, the first user is prompted to authenticate their identity. For instance, the first user is prompted to input their unique login information via a user interface. The first user then operates the user interface of the online account to navigate to a consent page or area. At that point, an internal authorisation API for obtaining the first user's consent is configured to match the request with the data previously received via the consent intent API to obtain the full consent that the customer is being asked to authorise. This is achieved via the linking identifier or via a direct deep link approach (for mobile devices only) using the consent identifier directly.
- In step 48, the
IDP 102b constructs a list of accounts that the first user can select. This will be constructed by generating a list of all accounts to which the first user has access to the data of, or the accounts from which the user can make a payment, or the accounts that are enabled for data sharing. For instance, certain account types may be enabled or disabled for sharing data. The enabled account types will appear in the list, while the disabled account types will not appear in the list. - In step 48, the first user is presented with the consent that they have requested and the list of accounts for the first user to choose from. Next, the customer authorises the consent, and since the user has been authenticated, an identifier for the first user will be known. The authorisation received from the user will be digitally signed within the
IDP 102b and will be stored in associated with the authorised consent. - In this step 49, the
DMS 102 determines whether the data to which theremote system 108 has been granted access by the first user is jointly accessible by another user. In this example, theDMS 102 determines that the data is jointly accessible by the second user. In this scenario, theDMS 102 interacts with the second user via thesecond user device 106 or another suitable device in order to obtain consent from the second user. This process may occur in a similar manner to that described above, but theDMS 102 interacts with the second user rather than the first user. - In
step 50, the first user device is redirected back to theTIAA 102a. - In
step 51, theTIAA 102a sends an authorisation code and a URI to the first user device. The URI is assigned to theremote system 108 when theremote system 108 registers with theDMS 102 initially and is used to redirect the first user device to theremote system 108. - In
step 52, thefirst user device 10 is redirected to theremote system 108. - In
step 53, the authorisation code is sent by theremote system 108 to theTIAA 102a which validates the authorisation code and the identity of theremote system 108. - In
step 54, theTIAA 102a transmits an access token and a refresh token to theremote system 108. On subsequent requests, theremote system 108 will transmit the refresh token rather than the authorisation code. After validation, theTIAA 102a will issue a new access token and a new refresh token. - In
step 55, theremote system 108 transmits an external execute API to theDMS 102, which matches the details held in the authorised consent. - The consent identifier is passed to an internal execute API at the
DMS 102, which will call an internal validate authorised consent API using the consent identifier along with any additional data required from the execute API to match against the Authorised Consent (such as the account number, and payment details). - The validate authorised consent API will then check that the consent identifier exists and has not expired. The validate authorised consent API will also check that any details passed match the authorised consent. This may include checking that the API being executed within scope of the user's authorisation that have been authorised, that the account being requested within the accounts have been authorised.
- In this step, the secure data item that is jointly accessible by the first user and the second user is transmitted to the
remote system 108. This is enabled because both the first user and the second user have provided their consent for the data to be shared with theremote system 108. - The validate Authorised consent API will pass back a success or failure message to the calling execute API. For a success message, the API will also pass back the translation from the consent customer identifier to the actual customer identifier as used by the
IDP 102b, the consent account identifier to the actual account identifier, and any other data that was saved at the point of authorisation (e.g. a biometrics score for detecting fraud). - Referring to
Fig. 5 , theDMS 102 comprises acommunication interface 501 comprising areceiver 502 and atransmitter 503. TheDMS 102 also comprises anidentification module 504, aflag setting module 505 and astorage resource 506. - The
receiver 502 and thetransmitter 503 are configured to receive and transmit the messages to and from theDMS 102 as explained above. Theidentification module 504 is arranged to identify whether a secure data item is a jointly accessible data item. Theflag setting module 505 is arranged to manage the setting of flags as described above. The storage resource is arranged to store the secure data items at theDMS 102. -
Fig. 6 shows an exemplaryelectronic device 401 according to any of the electronic devices or systems of this disclosure (such as thefirst user device 102, thesecond user device 104, theremote system 108, theDMS 102, theTIAA 102a or theIDP 102b). Theelectronic device 401 comprises processing circuitry 410 (such as a microprocessor) and amemory 412.Electronic device 401 may also comprise one or more of the following subsystems: apower supply 414, adisplay 416, atransceiver 420, and aninput 426. - Processing circuitry 410 may control the operation of the
electronic device 401 and the connected subsystems to which the processing circuitry is communicatively coupled.Memory 412 may comprise one or more of random access memory (RAM), read only memory (ROM), non-volatile random access memory (NVRAM), flash memory, other volatile memory, and other non-volatile memory. -
Display 416 may be communicatively coupled with the processing circuitry 410, which may be configured to cause thedisplay 416 to output images representative of the secure data shared between the entities in thesystem 100. - The
display 416 may comprise a touch sensitive interface, such as a touch screen display. Thedisplay 416 may be used to interact with software that runs on the processor 410 of theelectronic device 401. The touch sensitive interface permits a user to provide input to the processing circuitry 410 via a discreet touch, touches, or one or more gestures for controlling the operation of the processing circuitry and the functions described herein. It will be appreciated that other forms of input interface may additionally or alternatively be employed for the same purpose, such as theinput 426 which may comprise a keyboard or a mouse at the input device. - The
transceiver 420 may be one or more long-range RF transceivers that are configured to operate according to communication standard such as LTE, UMTS, 3G, EDGE, GPRS, GSM, and Wi-Fi. For example,electronic device 401 may comprise afirst wireless transceiver 421, such as a cellular transceiver, that is configured to communicate with acell tower 403 via to a cellular data protocol such as LTE, UMTS, 3G, EDGE, GPRS, or GSM, and asecond transceiver 428, such as a Wi-Fi transceiver, that is configured to communicate with awireless access point 404 via to a Wi-Fi standard such as 802.11 ac/n/g/b/a. In this regard and for the purposes of all embodiments herein concerning a long-range wireless protocol, a long-range wireless protocol may be a protocol which is capable and designed for communication over 5, 10, 20, 30, 40, 50, or 100m. This is in contrast to short-range wireless protocol mentioned above. The long-range wireless protocol may communicate utilizing higher power than the short- range wireless protocol. The range (e.g. line of sight distance) between the long-range end nodes (electronic device and router or base station) for the long-range wireless protocol may be greater than the range (e.g. line of sight distance) between the short-range end nodes (e.g. electronic device and wireless beacon). -
Electronic device 401 may be configured to communicate via thetransceiver 420 with anetwork 440.Network 440 may be a wide area network, such as the Internet, or a local area network.Electronic device 401 may be further configured to communicate via thetransceiver 420 andnetwork 440 with one or more systems 14 oruser devices 11, 12, 13. These servers or user devices may be any one of those described herein. - The term "comprising" encompasses "including" as well as "consisting" e.g. a composition "comprising" X may consist exclusively of X or may include something additional e.g. X + Y.
- The word "substantially" does not exclude "completely" e.g. a composition which is "substantially free" from Y may be completely free from Y. Where necessary, the word "substantially" may be omitted from the definition of the invention.
- The term "about" in relation to a numerical value x is optional and means, for example, x± 10%.
- Unless otherwise indicated each embodiment as described herein may be combined with another embodiment as described herein.
- The methods described herein may be performed by software in machine readable form on a tangible storage medium e.g. in the form of a computer program comprising computer program code means adapted to perform all the steps of any of the methods described herein when the program is run on a computer and where the computer program may be embodied on a computer readable medium. Examples of tangible (or non-transitory) storage media include disks, thumb drives, memory cards etc. and do not include propagated signals. The software can be suitable for execution on a parallel processor or a serial processor such that the method steps may be carried out in any suitable order, or simultaneously. This acknowledges that firmware and software can be valuable, separately tradable commodities. It is intended to encompass software, which runs on or controls "dumb" or standard hardware, to carry out the desired functions. It is also intended to encompass software which "describes" or defines the configuration of hardware, such as HDL (hardware description language) software, as is used for designing silicon chips, or for configuring universal programmable chips, to carry out desired functions.
- It will be appreciated that the modules described herein may be implemented in hardware or in software. Furthermore, the modules may be implemented at various locations throughout the system.
- Those skilled in the art will realise that storage devices utilised to store program instructions can be distributed across a network. For example, a remote computer may store an example of the process described as software. A local or terminal computer may access the remote computer and download a part or all of the software to run the program. Alternatively, the local computer may download pieces of the software as needed, or execute some software instructions at the local terminal and some at the remote computer (or computer network). Those skilled in the art will also realise that by utilizing conventional techniques known to those skilled in the art that all, or a portion of the software instructions may be carried out by a dedicated circuit, such as a DSP, programmable logic array, or the like.
- Any range or device value given herein may be extended or altered without losing the effect sought, as will be apparent to the skilled person.
- It will be understood that the benefits and advantages described above may relate to one embodiment or may relate to several embodiments. The embodiments are not limited to those that solve any or all of the stated problems or those that have any or all of the stated benefits and advantages.
- Any reference to 'an' item refers to one or more of those items. The term 'comprising' is used herein to mean including the method blocks or elements identified, but that such blocks or elements do not comprise an exclusive list and a method or apparatus may contain additional blocks or elements.
- The steps of the methods described herein may be carried out in any suitable order, or simultaneously where appropriate. Additionally, individual blocks may be deleted from any of the methods without departing from the scope of the subject matter described herein. Aspects of any of the examples described above may be combined with aspects of any of the other examples described to form further examples without losing the effect sought. Any of the module described above may be implemented in hardware or software.
- It will be understood that the above description of a preferred embodiment is given by way of example only and that various modifications may be made by those skilled in the art. Although various embodiments have been described above with a certain degree of particularity, or with reference to one or more individual embodiments, those skilled in the art could make numerous alterations to the disclosed embodiments without departing from the scope of this invention.
Claims (15)
- A computer-implemented method for managing data associated with a first user having a first user device and a second user having a second user device, the method comprising:storing, at a first system, secure data items jointly accessible by the first user and the second user;sending, via the first user device to a second system, which is remote and distinct from the first system, a message that is indicative of the first user providing their consent for the second system to access the secure data items from the first system;connecting the second system to the first system via an account request resource;redirecting the first user device to the first system with an account request identifier so as to correlate the account request resource with the first user device;authenticating the first user of the first user device at the first system;once the first user has been authenticated, receiving, at the first system from the first user device, a data request comprising a consent instruction to transmit the secure data items to the second system;identifying, at the first system, that the secure data items are jointly accessible by the first user and the second user;in response to identifying that the secure data items are jointly accessible by the first user and the second user, transmitting an authorisation request to the second user device, wherein the authorisation request comprises a prompt for the second user to authorise the data request;receiving, from the second user device, a grant message indicative of the second user granting the authorisation request;in response to receiving the grant message, transmitting the secure data items to the second system; andpreventing the secure data items from being sent to the second system, if the grant message is not received.
- The computer-implemented method of claim 1, wherein the first user and the second user each have joint access to a shared online data storage account via an account interface, and the secure data item pertains to data of the shared online data storage account.
- The computer-implemented method of claim 2, wherein the authorisation request is transmitted to the second user device via the account interface.
- The computer-implemented method of claim 3, wherein the second user accesses the authorisation request via the account interface by inputting a security key into a browser or application at the second user device.
- The computer-implemented method of claim 4, wherein the security key comprises at least one of password data or biometric data.
- The computer-implemented method of claim 4 or claim 5, further comprising:in response to identifying that the secure data item is jointly accessible by the first user and the second user, transmitting an auxiliary authorisation request comprising an auxiliary prompt for the second user to authorise the data request;wherein the second user accesses the auxiliary authorisation request via an alternative means that is different to the shared online data storage account; andwherein the auxiliary authorisation request comprises a prompt for the second user to access the shared online data storage account to provide authorisation of the data request.
- The computer-implemented method of claim 6, wherein transmitting the auxiliary authorisation request comprises at least one of:transmitting a Short Message Service (SMS) comprising the auxiliary authorisation request to a telephone number associated with the second user;transmitting an email comprising the auxiliary authorisation request to an email address associated with the second user; andtransmitting a pre-recorded voice message comprising the auxiliary authorisation request to a telephone number associated with the second user.
- The computer-implemented method of claim 7 wherein the auxiliary authorisation request comprises a prompt for the second user to access the shared online data storage account.
- The computer-implement method of claim 8 wherein the auxiliary authorisation request does not comprise a link to a web-page or an application.
- The computer-implemented method of any one of claims 6 to 9, wherein the auxiliary authorisation request is transmitted to the second user device and/or another user device of the second user.
- The computer-implemented method of any one of the preceding claims, wherein storing the secure data item associated with the first user and the second user comprises:setting a first flag associated with the first user to indicate that the secure data item is not authorised to be shared with the second system; andsetting a second flag associated with the second user to indicate that the secure data item is not authorised to be shared with the second system;
wherein receiving, at the first system from the first user device, the data request comprising the instruction to transmit the secure data item to the second system comprises:setting the first flag to indicate that the secure data item is authorised to be shared with the second system;
wherein receiving, from the second user device, the grant message indicative of the second user granting the authorisation request comprises:
setting the second flag to indicate that the secure data item is authorised to be shared with the second system;
wherein the secure data item is transmitted to the second system only if both the first flag and the second flag indicate that the secure data item is authorised to be shared with the second system. - The computer-implemented method of any one of the preceding claims wherein the data request is received at the first system directly from the first user device or the data request is received at the first system indirectly via the second system.
- The computer-implemented method of any one of the preceding claims, the method further comprising:receiving at the first system, from the first user device, a data retention request comprising an instruction not to transmit the first data item stored at the first system to a system distinct from the first system;in response to receiving the data retention request, setting a data retention flag at the first system in association with the first user;receiving a data request from the second system for access to the first data item;in response to the data request, identifying that the first user is associated with the data retention flag at the first system and preventing transmission of the first data item to the second system.
- The computer-implemented method of claim 11 and 13 further comprising:identifying that the first flag is set to indicate that the secure data item is authorised to be shared with the second system;identifying that that the first user is associated with the data retention flag; andpreventing transmission of the first data item to the second system.
- A data management system comprising:a data storage resource configured to store secure data items jointly accessible by both a first user and a second user; andprocessing circuitry configured to:send, via the first user device to a remote system, which is remote and distinct from the first system, a message that is indicative of the first user providing their consent for the remote system to access the secure data items from the first system;connect the remote system to the first system via an account request resource;redirect the first user device to the first system with an account request identifier so as to correlate the account request resource with the first user device;authenticate the first user of the first user device at the first system;once the first user has been authenticated, receive, from a first user device associated with the first user, a data request comprising a consent instruction to transmit the secure data items from the data storage resource to the remote system;identify that the secure data items are jointly accessible by the first user and the second user;transmit an authorisation request to a second user device associated with the second user, in response to identifying that the secure data items are jointly accessible by the first user and the second user, the authorisation request comprising a prompt for the second user to authorise the data request;receive, from the second user device, a grant message indicative of the second user granting the authorisation request;transmit the secure data items to the remote system in response to receiving the grant message; andprevent the secure data items from being sent to the remote system, if the grant message is not received.
Priority Applications (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
ES18155395T ES2840064T3 (en) | 2018-02-06 | 2018-02-06 | System to manage accessible data jointly |
EP18155395.9A EP3522061B1 (en) | 2018-02-06 | 2018-02-06 | System for managing jointly accessible data |
PCT/EP2019/052915 WO2019154861A1 (en) | 2018-02-06 | 2019-02-06 | System for managing jointly accessible data |
US16/269,067 US11265360B2 (en) | 2018-02-06 | 2019-02-06 | System for managing jointly accessible data |
CA3032876A CA3032876A1 (en) | 2018-02-06 | 2019-02-06 | System for managing jointly accessible data |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP18155395.9A EP3522061B1 (en) | 2018-02-06 | 2018-02-06 | System for managing jointly accessible data |
Publications (2)
Publication Number | Publication Date |
---|---|
EP3522061A1 EP3522061A1 (en) | 2019-08-07 |
EP3522061B1 true EP3522061B1 (en) | 2020-09-30 |
Family
ID=61187106
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP18155395.9A Active EP3522061B1 (en) | 2018-02-06 | 2018-02-06 | System for managing jointly accessible data |
Country Status (5)
Country | Link |
---|---|
US (1) | US11265360B2 (en) |
EP (1) | EP3522061B1 (en) |
CA (1) | CA3032876A1 (en) |
ES (1) | ES2840064T3 (en) |
WO (1) | WO2019154861A1 (en) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP3553719B1 (en) * | 2018-04-11 | 2020-05-13 | Barclays Execution Services Limited | System for reliably accessing a protected resource |
US10789390B1 (en) * | 2019-12-19 | 2020-09-29 | Capital One Services, Llc | System and method for controlling access to account transaction information |
US11695822B2 (en) * | 2021-07-16 | 2023-07-04 | Adp, Inc. | Unified integration pattern protocol for centralized handling of data feeds |
EP4141712A1 (en) * | 2021-08-26 | 2023-03-01 | Sage Global Services Limited | Method and system for access authorisation |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6775668B1 (en) * | 2000-09-11 | 2004-08-10 | Novell, Inc. | Method and system for enhancing quorum based access control to a database |
US7917584B2 (en) * | 2007-10-22 | 2011-03-29 | Xcerion Aktiebolag | Gesture-based collaboration |
US7992183B1 (en) * | 2007-11-09 | 2011-08-02 | Google Inc. | Enabling users to create, to edit and/or to rate online video captions over the web |
US8910218B2 (en) * | 2010-07-15 | 2014-12-09 | Verizon Patent And Licensing Inc. | Method and apparatus for providing control of set-top boxes |
US8639758B2 (en) * | 2010-11-09 | 2014-01-28 | Genesys Telecommunications Laboratories, Inc. | System for determining presence of and authorizing a quorum to transact business over a network |
US8955149B1 (en) * | 2011-12-06 | 2015-02-10 | Amazon Technologies, Inc. | Impersonation authorizations |
CN104426656B (en) * | 2013-08-19 | 2019-04-05 | 中兴通讯股份有限公司 | Data receiving-transmitting method and system, the processing method and processing device of message |
US10592108B2 (en) * | 2014-09-30 | 2020-03-17 | Anthony Tan | Secured storage system with temporary external assignable memory |
KR102346630B1 (en) * | 2015-02-17 | 2022-01-03 | 삼성전자주식회사 | Method for recommending a content based on activitys of a plurality of users and apparatus thereof |
US20190227857A1 (en) * | 2018-01-25 | 2019-07-25 | salesforce com, inc | Smart clipboard for secure data transfer |
-
2018
- 2018-02-06 EP EP18155395.9A patent/EP3522061B1/en active Active
- 2018-02-06 ES ES18155395T patent/ES2840064T3/en active Active
-
2019
- 2019-02-06 US US16/269,067 patent/US11265360B2/en active Active
- 2019-02-06 CA CA3032876A patent/CA3032876A1/en active Pending
- 2019-02-06 WO PCT/EP2019/052915 patent/WO2019154861A1/en active Application Filing
Non-Patent Citations (1)
Title |
---|
None * |
Also Published As
Publication number | Publication date |
---|---|
US20190245909A1 (en) | 2019-08-08 |
EP3522061A1 (en) | 2019-08-07 |
CA3032876A1 (en) | 2019-08-06 |
US11265360B2 (en) | 2022-03-01 |
ES2840064T3 (en) | 2021-07-06 |
WO2019154861A1 (en) | 2019-08-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10572874B1 (en) | Dynamic authorization with adaptive levels of assurance | |
US11954674B1 (en) | Systems and methods for third party token based authentication | |
US9165291B1 (en) | Payment transaction by email | |
CN108351933B (en) | Method and system for end-user initiated access server plausibility check | |
US11265360B2 (en) | System for managing jointly accessible data | |
EP2756444B1 (en) | Resource access authorization | |
US20160308856A1 (en) | Two factor authentication using a one-time password | |
CN106716960B (en) | User authentication method and system | |
US20220188786A1 (en) | Systems and methods for user data management across multiple devices | |
US11132425B1 (en) | Systems and methods for location-binding authentication | |
US11128628B2 (en) | System for authorising data access | |
US9178874B2 (en) | Method, device and system for logging in through a browser application at a client terminal | |
US20170221059A1 (en) | System and method for generating a location specific token | |
US20170353451A1 (en) | Method and apparatus for issuing a credential for an incident area network | |
US11475139B2 (en) | System and method for providing secure data access | |
US20190306142A1 (en) | Account authorization without sharing confidential information | |
JP2020166601A (en) | Mediation server, program, and information processing method | |
US20220329581A1 (en) | Authentication of an untrusted user device | |
US20140006271A1 (en) | Cross-network electronic payment processing system and method | |
AU2022338171B2 (en) | System, method, and computer program product for consent management | |
US11483316B1 (en) | System and method for access using a circle of trust | |
US20230198981A1 (en) | Systems and methods for credentials sharing |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION HAS BEEN PUBLISHED |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
AX | Request for extension of the european patent |
Extension state: BA ME |
|
RAP1 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: BARCLAYS EXECUTION SERVICES LIMITED |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE |
|
17P | Request for examination filed |
Effective date: 20200207 |
|
RBV | Designated contracting states (corrected) |
Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
GRAP | Despatch of communication of intention to grant a patent |
Free format text: ORIGINAL CODE: EPIDOSNIGR1 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: GRANT OF PATENT IS INTENDED |
|
RIC1 | Information provided on ipc code assigned before grant |
Ipc: G06Q 10/10 20120101ALI20200331BHEP Ipc: H04L 29/06 20060101ALI20200331BHEP Ipc: G06F 21/62 20130101AFI20200331BHEP |
|
INTG | Intention to grant announced |
Effective date: 20200415 |
|
GRAS | Grant fee paid |
Free format text: ORIGINAL CODE: EPIDOSNIGR3 |
|
GRAA | (expected) grant |
Free format text: ORIGINAL CODE: 0009210 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE PATENT HAS BEEN GRANTED |
|
AK | Designated contracting states |
Kind code of ref document: B1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
REG | Reference to a national code |
Ref country code: GB Ref legal event code: FG4D Ref country code: CH Ref legal event code: EP |
|
REG | Reference to a national code |
Ref country code: AT Ref legal event code: REF Ref document number: 1319546 Country of ref document: AT Kind code of ref document: T Effective date: 20201015 Ref country code: CH Ref legal event code: NV Representative=s name: E. BLUM AND CO. AG PATENT- UND MARKENANWAELTE , CH |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R096 Ref document number: 602018008159 Country of ref document: DE |
|
REG | Reference to a national code |
Ref country code: IE Ref legal event code: FG4D |
|
REG | Reference to a national code |
Ref country code: NL Ref legal event code: FP |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: SE Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200930 Ref country code: FI Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200930 Ref country code: NO Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20201230 Ref country code: BG Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20201230 Ref country code: GR Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20201231 Ref country code: HR Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200930 |
|
REG | Reference to a national code |
Ref country code: AT Ref legal event code: MK05 Ref document number: 1319546 Country of ref document: AT Kind code of ref document: T Effective date: 20200930 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: LV Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200930 Ref country code: RS Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200930 |
|
REG | Reference to a national code |
Ref country code: LT Ref legal event code: MG4D |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: SM Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200930 Ref country code: PT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20210201 Ref country code: RO Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200930 Ref country code: CZ Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200930 Ref country code: EE Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200930 Ref country code: LT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200930 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: AL Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200930 Ref country code: AT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200930 Ref country code: IS Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20210130 Ref country code: PL Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200930 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: SK Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200930 |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R097 Ref document number: 602018008159 Country of ref document: DE |
|
REG | Reference to a national code |
Ref country code: ES Ref legal event code: FG2A Ref document number: 2840064 Country of ref document: ES Kind code of ref document: T3 Effective date: 20210706 |
|
PLBE | No opposition filed within time limit |
Free format text: ORIGINAL CODE: 0009261 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: DK Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200930 |
|
26N | No opposition filed |
Effective date: 20210701 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: MC Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200930 |
|
REG | Reference to a national code |
Ref country code: BE Ref legal event code: MM Effective date: 20210228 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: LU Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20210206 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: SI Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200930 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: IS Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20210130 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: BE Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20210228 |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: ES Payment date: 20230314 Year of fee payment: 6 Ref country code: CH Payment date: 20230307 Year of fee payment: 6 |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: IT Payment date: 20230110 Year of fee payment: 6 Ref country code: DE Payment date: 20221213 Year of fee payment: 6 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: CY Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200930 |
|
P01 | Opt-out of the competence of the unified patent court (upc) registered |
Effective date: 20230526 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: HU Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT; INVALID AB INITIO Effective date: 20180206 |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: GB Payment date: 20231214 Year of fee payment: 7 |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: NL Payment date: 20231215 Year of fee payment: 7 Ref country code: IE Payment date: 20231211 Year of fee payment: 7 Ref country code: FR Payment date: 20231222 Year of fee payment: 7 |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: ES Payment date: 20240305 Year of fee payment: 7 |