WO2012139629A1 - Procédé et appareil de partage de données d'utilisateur - Google Patents

Procédé et appareil de partage de données d'utilisateur Download PDF

Info

Publication number
WO2012139629A1
WO2012139629A1 PCT/EP2011/055652 EP2011055652W WO2012139629A1 WO 2012139629 A1 WO2012139629 A1 WO 2012139629A1 EP 2011055652 W EP2011055652 W EP 2011055652W WO 2012139629 A1 WO2012139629 A1 WO 2012139629A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
list
attributes
user attributes
communication
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.)
Ceased
Application number
PCT/EP2011/055652
Other languages
English (en)
Inventor
Michael Marhoefer
Robert Seidl
Markus Bauer-Hermann
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Solutions and Networks Oy
Original Assignee
Nokia Siemens Networks Oy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Siemens Networks Oy filed Critical Nokia Siemens Networks Oy
Priority to PCT/EP2011/055652 priority Critical patent/WO2012139629A1/fr
Publication of WO2012139629A1 publication Critical patent/WO2012139629A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/6209—Protecting access to data via a platform, e.g. using keys or access control rules to a single file or object, e.g. in a secure envelope, encrypted and accessed using a key, or with access control rules appended to the object itself
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload

Definitions

  • the present invention is directed to a method and apparatus for sharing user data, such as identity data and user
  • the present invention enables a user to be involved in the process of sharing at least some of his/her user data.
  • FIG. 1 is a block diagram of a system, indicated generally by the reference numeral 1.
  • the system 1 comprises a user 2 and a service provider 4.
  • the user is in two-way
  • the service provider 4 needs to know information regarding the user 2 in order to function correctly.
  • the service provider may be an
  • the user 2 may provide the information required by the service provider 4 directly to the service provider. This is a simple procedure, but it requires the user 2 to provide this information each time the service provider 4 is used.
  • the service provider 4 may store data relating to the user 2 (such as name, address and credit card details) so that the user only needs to provide such data once. This is more convenient for the user, but the storing of user data at the service provider 4 represents a potential security concern. Many users may not be willing to make use of a service provider that stores potentially sensitive user data. Furthermore, data stored at the service provider 4 may become obsolete. By way of example, in the Internet-shop example considered above, an order may be made but incorrectly completed due to obsolete data.
  • FIG 2 is a block diagram of a system, indicated generally by the reference numeral 10.
  • the system 10 comprises a user 12, a service provider 14 and an identity management (IDM) system 16.
  • the user 12 is in two-way communication with both the service provider 14 and the IDM 16.
  • the service provider 14 is additionally in two-way communication with the IDM 16.
  • User attributes for the user 12 are stored at the IDM 16. Accordingly, when the service provider 14 needs to know information regarding the user 12 in order to function correctly, the service provider requests this information from the IDM 16.
  • the service provider 14 requests this information from the IDM 16.
  • the IDM 16 trusts the service provider 14, that data may be provided. Importantly, this data will be provided by the IDM as required and so will always be up-to-date and does not need to be stored at the service provider, thereby overcoming two of the problems outlined above with respect of the system 1.
  • a dialogue is carried out between the service provider 14 and the IDM 16.
  • a privacy policy for the user 12 may be stored at the IDM 16 to enable the IDM to determine whether (and to what extent) potentially sensitive user data can be shared with the service provider 14.
  • privacy policies can be inflexible. Furthermore, such privacy policies risk either being too restrictive
  • the present invention seeks to address at least some of the problems outlined above.
  • the invention provides a method comprising: receiving
  • the said personal data portal is typically provided as part of an identity management system.
  • the invention also provides an apparatus (e.g. a data portal and/or an IDM or some other central point for the management of communication cards) comprising: a first input for
  • the present invention provides a mechanism for storing user attributes for the first user from which the subset is selected.
  • the apparatus may have access to an external database of such data.
  • the user attributes can typically be triggered and tailored by the user for a specific purpose and then optionally sent to a communication partner.
  • the user attributes can be provided in a form that enables the communication partner to obtain the user attributes included in said list.
  • the communication card of the present can therefore provide fine-grained enforcement of each user's privacy preferences, but can also provide enhanced user convenience, since, for example, no unwanted or outdated or redundant information need be stored at a communication partner.
  • the first user selects at least some of said user attributes for inclusion in said list.
  • at least some of said instructions may be received using a check-box input.
  • At least some of said instructions may include details of how to modify an existing list of user attributes. For example, a list may be generated (or previously stored) and the first user may be able to add attributes to the list and/or to remove attributes from the list. Thus, a simple user- interface can be provided that enables a user to easily make use of the principles of the present invention.
  • the first user selects one or more recipients of said list.
  • a list may be generated specifically for a particular recipient or purpose.
  • the first user defines validity conditions for one or more of said user attributes included in said list.
  • the said validity conditions may include a time period during which a selected user attribute is available to be viewed.
  • the said validity conditions may include a level of abstraction of a user attribute. Other validity conditions could readily be provided.
  • the user attributes are not themselves included in the list (but a means for obtaining those user attributes is included) .
  • the said user attributes may be obtainable from an identity management system.
  • the said user attributes are included in said list in encrypted form.
  • the principles of digital rights management may be used to control access to user data.
  • the invention also provides a communication card comprising a list of user attributes for a first user, wherein the list of user attributes is a subset of the user attributes for the first user, wherein said the user attributes included in (or omitted from) said subset is controlled by the first user, wherein the list is provided in a form that enables a
  • a communication card can be provided that can be used to dynamically generate a set of personal attributes/data of one user, possibly triggered and tailored by the subject of these personal data for a specific purpose, and then optionally sent to his/her communication partner. That communication partner may have the option of sending his specific
  • At least some of the user attributes included in said list may have limited validity. For example, said validity may be limited in duration. Alternatively, or in addition, at least some of said attributes may be abstracted.
  • the user attributes are not themselves included in the list (but a means for obtaining those user attributes is included) .
  • the said user attributes may be obtainable from an identity management system.
  • the said user attributes are included in said list in encrypted form.
  • the invention yet further provides an apparatus (e.g. a user device) for generating a communication card (or a list of user attributes) comprising: a first interface for generating a communication card (or a list of user attributes) comprising: a first interface for generating a communication card (or a list of user attributes) comprising: a first interface for generating a communication card (or a list of user attributes) comprising: a first interface for generating a communication card (or a list of user attributes) comprising: a first interface for generating a communication card (or a list of user attributes) comprising: a first interface for generating a communication card (or a list of user attributes) comprising: a first interface for generating a communication card (or a list of user attributes) comprising: a first interface for generating a communication card (or a list of user attributes) comprising: a first interface for generating a communication card (or a list of user attributes) comprising: a first interface for generating a communication card
  • a third interface may be provided for communicating with the said communication partner.
  • the said third interface may be configured to receive a
  • the invention yet further provides a method comprising:
  • the method may further comprise providing a list of user attributes of a user of said first user device to said communication partner.
  • the invention also provides a computer program comprising: code (or some other means) for receiving instructions (e.g.
  • the computer program may be a computer program product comprising a computer-readable medium bearing computer program code embodied therein for use with a computer.
  • the invention yet further provides a computer program
  • code for receiving, at a first user device, a list of attributes from a communication partner, wherein the list is provided in a form that enables the obtaining of the user attributes included in the list and wherein the user attributes are a subset of the user
  • the computer program may be a computer program product comprising a computer-readable medium bearing computer program code embodied therein for use with a computer. Exemplary embodiments of the invention are described below, by way of example only, with reference to the following numbered drawings .
  • Figure 1 is a block diagram of a known system for providing user data
  • Figure 2 is a block diagram of a known system for providing user data
  • FIG. 3 is a block diagram of a system in accordance with an aspect of the present invention.
  • Figure 4 is a flow chart showing an algorithm in
  • FIG. 5 is a flow chart showing an algorithm in accordance with an aspect of the present invention.
  • Figure 6 is a flow chart showing an algorithm in accordance with an aspect of the present invention.
  • Figure 7 is a flow chart showing an algorithm in accordance with an aspect of the present invention
  • Figure 8 is a block diagram of a system in accordance with an aspect of the present invention
  • Figure 9 is a flow chart showing an algorithm in accordance with an aspect of the present invention.
  • Figure 10 is a block diagram of a system in accordance with an aspect of the present invention.
  • FIG. 3 is a block diagram, indicated generally by the reference numeral 20, of a system in accordance with an aspect of the present invention.
  • the system 20 comprises a first user 22 (typically in the form of a user device, such as a mobile communication device) , a second user 24 and an identity management (IDM) system 26.
  • the first user 22 is in two-way communication with both the second user 24 and the IDM 26.
  • the second user 24 may, in some embodiments, be in two-way communication with the IDM 26.
  • the first user 22 is similar to the user 12 described above.
  • the second user 24 may be a service provider (similar to the service provider 14 described above) , but this is not
  • the second user 24 may be another user, and may therefore be similar to the first user 22 (and may be in the form of a user device, such as a mobile communication device) .
  • Figure 4 is a flow chart showing an algorithm, indicated generally by the reference numeral 30, showing, in broad terms, an exemplary use of the system 20.
  • the algorithm 30 starts at step 32, where the user 22
  • communication card is used herein to refer to a dynamically generated set of personal attributes/data of one user (such as the first user 22), triggered and tailored by the subject of these personal data for a specific purpose, and then optionally sent to his/her communication partner (such as the second user 24) .
  • the second user may have the option of sending his specific communication card to the first user as another contribution to build a trusted
  • the communication card could be stored in XML format
  • the communication card may be digitally signed by the IDM 26 to be secure against tampering.
  • the card would also contain the values of the attributes, encrypted by a digital rights management (DRM) key or other similar method.
  • DRM digital rights management
  • step 34 the communication card is transferred to a communication partner of the first user (the second user 24 in this example) .
  • step 36 the second user receives the
  • the communication card uses the communication card to obtain attributes or other user data concerning the first user 22.
  • the attributes may not be limited to
  • the attributes may be included in the communication card, but in encrypted form.
  • FIG. 5 is a flow chart showing an algorithm, indicated generally by the reference numeral 40, showing further details of how the communication card may be generated in step 32 of the algorithm 30.
  • the algorithm 40 starts at step 42, where the first user 22 logs into the IDM 26.
  • the IDM 26 may provide a personal data portal that the first user 22 needs to login to in order to generate communication cards.
  • the personal data portal may, for example, be used to store both the user's personal identity attributes (e.g. address, photos, etc.) and the user's privacy preferences (e.g.
  • the profile data for the user 22 may be viewable at the personal data portal.
  • the first user 22 selects a sub-set of the user attributes to be included in a particular communication card.
  • the subset may, for example, be selected by activating one or more checkboxes at the personal data portal of the IDM 26.
  • this step could be implemented in many other ways; for example, the user could modify an existing communication card or the subset of attributes could be selected automatically, perhaps based on a generic set of attributes which is filtered by the user' s pre-defined privacy preferences or some other policy regarding the communication cards.
  • the personal data portal may generate a communication card and then enable the first user 22 to edit the card according to his/her personal preferences in this moment and situation, e.g. by removing/adding or abstracting or otherwise generalizing certain personal data.
  • the first user 22 may now define one or more validity conditions for the card at step 46 of the algorithm 40.
  • the first user 22 may define that the user attributes should only be made available to the second user for a limited period of time.
  • the communication card could contain attributes with varying viewing policies and access
  • the first user 22 could determine that the second user 24 should be able to see his mobile telephone number for one year, but see his current location (which would be an on-demand fetchable attribute) for one month. After one month the second user 24 should be able to see his location for another five months in an abstracted way (e.g. just the town) and then the location attribute should no longer be visible to the second user.
  • the first user 22 selects one or more recipients of that communication card (step 48 of the algorithm 40) . This may be done, for example, by moving to a new page at the IDM 26, where group of persons (given the case that his IDM offers to sort his contacts to groups) that should be allowed to see the communication card can be selected.
  • the recipient (s) of the communication card could be selected earlier in the process.
  • one or more of the steps could be omitted; for example, validity conditions (step 46 of the algorithm) may not be required in all circumstances.
  • communication card could be implemented in other ways; for example, the communication card could be generated
  • the first user 22 could now download the communication card first to his device or directly forward it to another service or person (such as the second user 24), thereby implementing step 34 of the algorithm 30.
  • the communication card does not generally include the user attributes for the first user, but includes information required to enable the second user to obtain those details. In order for the second user to view
  • the second user may obtain the
  • the second user needs to decrypt the values that were already stored in the card (as described below with reference to Figure 7), for example using DRM technology.
  • Figure 6 is a flow chart showing an algorithm, indicated generally by the reference numeral 50, showing an exemplary implementation of step 36 of the algorithm 30.
  • the algorithm 50 starts at step 52, where the second user 24 receives the communication card, for example from the first user 22.
  • the communication card includes information
  • the second user 24 fetches the required attributes from the IDM 26 in
  • FIG. 7 is a flow chart showing an algorithm, indicated generally by the reference numeral 60, showing an alternative implementation of step 36 of the algorithm 30.
  • the algorithm 60 starts at step 62, where the second user 24 receives the communication card, for example from the first user 22.
  • the second user obtains the information required to decode the user data included in the
  • the second user may need to acquire and validate his DRM key (or similar technique) to be able to decrypt the values that were already stored in the card. This can be done e.g. by applying WS-* protocols or a SAML AttributeQuery . For the authorization of the access there could be included within the card a special access token.
  • step 64 could be implemented before step 62 in the algorithm 60.
  • the second user 24 decodes the data included in the communication card to extract the user data.
  • the card generated at step 32 of the algorithm 30 may be an XML file containing an encrypted block.
  • the step 66 of the algorithm 60 may be implemented using a communication card viewer. Such a viewer might typically be implemented as a piece of software and/or hardware. The viewer understands the encryption algorithm used, but needs to acquire the keys necessary to decrypt the data included in the encrypted block of the XML file, initialize the decoding algorithm and perform the decryption. In order to do so, the communication card viewer may retrieve some data from external sources and authorize itself against the external sources.
  • Figure 8 is a block diagram of a system, indicated generally by the reference numeral 80, in accordance with an aspect of the present invention.
  • the system 70 comprises a first user 72 (similar to the first user 22 described above) , a second user 74 (similar to the second user 24 described above), a first IDM system 76
  • the first user 72 is in two-way communication with the second user 74, the first IDM system 76 and the second IDM system 78.
  • the second user 74 is in two-way communication with the first user 72, the first IDM system 76 and the second IDM system 78.
  • Figure 9 is a flow chart showing an algorithm, indicated generally by the reference numeral 80, showing an exemplary use of the system 70.
  • the algorithm 80 starts at step 82, where the first user 72 generates a communication card.
  • the communication card may be generated for the purpose of sending the communication card to the second user 74, for example using the algorithm 40 described above.
  • the communication card generated in step 82 is sent to the second user 74 at step 84 of the algorithm 80.
  • the second user uses the communication card to obtain attributes
  • the first user for example by obtaining the attributes from the first IDM 76 (step 86 of the algorithm 80) .
  • the algorithm 80 then moves to step 88, where the second user 74 generates a communication card for the purpose of sending the communication card to the first user 72.
  • the second user may, for example, use an algorithm similar to the algorithm 40 for this purpose.
  • the communication card generated by the second user 74 is sent to the first user 72 (step 90) .
  • the first user uses the communication card to obtain attributes regarding the second user, for example by obtaining the attributes from the second IDM 78.
  • each user is potentially aware of a customized selection of ID attributes of his/her communication partner.
  • the invention allows asymmetric exchange of personal data, under the individual governance of the two communication partners.
  • each individual user may be able to disable the communication card sent to his/her communication partner remotely. For example, in the event that the
  • communication cards enable only a copy-protected display of the communication card to be streamed to the communication partner, driven by the real data stored only in a user' s personal data portal, then the communication card can be disabled by relying on technology from Digital Rights
  • DRM Dynamic Remote Management
  • the receiver of such protected information is able to "see” it for a certain period of validity (as mentioned above with reference to step 46 of the algorithm 40), and is unable to forward it to third parties.
  • This usage right can be extended periodically, e.g. for another day, as long as there is a relationship between the two users. As soon as the relationship is deemed by one partner as deteriorating, this partner can stop the periodic extension of the usage right. Consequently, his/her partner is no longer able to read the information .
  • Figure 10 is a block diagram of a block diagram of a system, indicated generally by the reference numeral 100, in
  • the system 100 comprises the first user device 72, second user device 74, first IDM 76 and second IDM 78 of the system 70 described above.
  • the first user device 72 comprises a processor 110, a memory 112 and a user interface 114.
  • the processor is configured, for example, to implement the algorithms described above.
  • the user interface 114 enables the user of the user device 72 to interact with the device 72, and hence provide the input required to select the content for inclusion in a particular communication card.
  • the second user device 74 comprises a processor 116, which is similar to the processor 110, a memory 118, which is similar to the memory 112, and a user interface 120, which is similar to the user interface 114.
  • the first IDM 76 comprises a processor 102 and a memory 104.
  • the processor is configured, for example, to implement the algorithms described above.
  • the code required for implementing those algorithms may be stored within the memory 104.
  • the memory 104 may also store the user attributes that are selectively included in the
  • the second IDM 78 comprises a processor 106, which is similar to the processor 102, and a memory 108, which is similar to the memory 104.
  • the system 100 is provided by way of example only. The skilled person will be aware of many alternatives possible implementations of the principles of the present invention. For example, a similar system implementing the system 20 described above could readily be implemented using the user devices 72 and 74 to provide the user devices 22 and 24 of the system 20 and the IDM 76 to provide the IDM 26 of the system 20, but omitting the IDM 78.
  • the communication card not only provides fine-grained enforcement of each user's privacy preferences, but also enhanced user convenience, since, for example, no unwanted or outdated or redundant information need be stored at a communication partner (such as the second user 24) . Indeed, in many implementations of the invention, it would not be possible for the second user to store such data. Moreover, the information stored on a communication card can be tailored by individual and/or group/company privacy policies. Communication cards can also be tailored

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Tourism & Hospitality (AREA)
  • Health & Medical Sciences (AREA)
  • Operations Research (AREA)
  • Marketing (AREA)
  • General Business, Economics & Management (AREA)
  • Economics (AREA)
  • Data Mining & Analysis (AREA)
  • Quality & Reliability (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention porte sur un procédé et un appareil de partage de données d'utilisateur. Un mécanisme pour générer de manière dynamique un ensemble d'attributs d'utilisateur est décrit. Les attributs d'utilisateur sont déclenchés et personnalisés par l'utilisateur dans un but spécifique, puis envoyés éventuellement à un partenaire de communication. Les attributs d'utilisateur sont fournis sous une forme qui permet au partenaire de communication d'obtenir les attributs d'utilisateur compris dans ladite liste.
PCT/EP2011/055652 2011-04-12 2011-04-12 Procédé et appareil de partage de données d'utilisateur Ceased WO2012139629A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2011/055652 WO2012139629A1 (fr) 2011-04-12 2011-04-12 Procédé et appareil de partage de données d'utilisateur

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2011/055652 WO2012139629A1 (fr) 2011-04-12 2011-04-12 Procédé et appareil de partage de données d'utilisateur

Publications (1)

Publication Number Publication Date
WO2012139629A1 true WO2012139629A1 (fr) 2012-10-18

Family

ID=44625780

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2011/055652 Ceased WO2012139629A1 (fr) 2011-04-12 2011-04-12 Procédé et appareil de partage de données d'utilisateur

Country Status (1)

Country Link
WO (1) WO2012139629A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030023726A1 (en) * 2001-02-16 2003-01-30 Rice Christopher R. Method and system for managing location information for wireless communications devices
WO2009127239A1 (fr) * 2008-04-17 2009-10-22 Sony Ericsson Mobile Communications Ab Procédé et appareil permettant d’accéder à des informations de contact

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030023726A1 (en) * 2001-02-16 2003-01-30 Rice Christopher R. Method and system for managing location information for wireless communications devices
WO2009127239A1 (fr) * 2008-04-17 2009-10-22 Sony Ericsson Mobile Communications Ab Procédé et appareil permettant d’accéder à des informations de contact

Similar Documents

Publication Publication Date Title
US12572629B2 (en) Secure messaging service with digital rights management using blockchain technology
US11470054B2 (en) Key rotation techniques
CN104662870B (zh) 数据安全管理系统
US10769287B2 (en) Forced data transformation policy
EP2761804B1 (fr) Chiffrement différentiel côté client sur des informations provenant d'un client
KR101769282B1 (ko) 데이터 보안 서비스
EP2856735B1 (fr) Procédé et système pour une génération automatique d'un message de couverture approprié au contexte
JP6430968B2 (ja) 遅延データアクセス
CN111277573B (zh) 具有密钥的资源定位符
US20130275765A1 (en) Secure digital document distribution with real-time sender control of recipient document content access rights
JP2017069988A (ja) 複数許可データセキュリティ及びアクセス
CN105191207A (zh) 联合密钥管理
EP3585023A1 (fr) Procédé et système de protection de données
US10095848B2 (en) System, method and apparatus for securely distributing content
US11095620B1 (en) Secure method, system, and computer program product for exchange of data
CN107332666A (zh) 终端文件加密方法
US9455961B2 (en) System, method and apparatus for securely distributing content
CN107205080B (zh) 一种带独立金融交易系统的智能手机
WO2012139629A1 (fr) Procédé et appareil de partage de données d'utilisateur
KR101980432B1 (ko) 개인 정보 처리를 위한 장치 및 방법
KR100753829B1 (ko) 콘텐츠 보호 기능을 갖는 모바일 리더 및 콘텐츠 서버와 그방법
Friedman PGP & Encrypted Communication
JP2003318888A (ja) リマインダサービス方法

Legal Events

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

Ref document number: 11713794

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11713794

Country of ref document: EP

Kind code of ref document: A1