Claims:1. A processor-implemented method for managing data privacy, comprising:
generating, via one or more hardware processors, a privacy lineage tree by systematically storing privacy lineage data associated with one or more data subjects, the privacy lineage data comprising a plurality of versions of one or more access preferences modified over a time period, the access preferences comprises a plurality of levels of privacy associated with a plurality of data fields of the privacy lineage data associated with the one or more data subjects, the plurality of levels indicative of exposure of the plurality of data fields;
generating, via the one or more hardware processors, a model of a privacy policy using the privacy lineage data by traversing the privacy lineage tree, based on one or more of a plurality of privacy parameters, the plurality of privacy parameters comprising a purpose of exposure, the at least one data field to be exposed, a level of exposure, an information factor indicative of information contained in the at least one data field and respective weightage of the at least one data field, the respective weightage indicative of sensitivity of the at least one data fields; and
defining, via one or more hardware processors, at least one of, a strength of the privacy policy and recommended privacy levels for the at least one data field, based on the model of the privacy policy.

2. The method as claimed in claim 1, wherein systematically storing the privacy lineage data comprises storing, for each of the one or more data subjects, the privacy lineage data in a sub-tree corresponding to the data subject and rooted at a root node of the privacy lineage tree, and wherein the sub-tree stores a unique identifier associated with the data subject, date and time stamp of previous access preferences corresponding to the data subject, and respective access preferences set for a plurality of purposes for the plurality of data fields.

3. The method as claimed in claim 1, further comprising, prior to generating the model of the privacy policy, receiving a query for exposure to the at least one data field from amongst the plurality of data fields, the query comprising at least the purpose for exposure to the at least one data field.
4. The method as claimed in claim 1, wherein the privacy policy of a data subject is indicative of strength of privacy levels associated with access preferences of the data subject.

5. The method as claimed in claim 4, wherein modelling the privacy policy comprises:
defining functions of weights of a set of privacy parameters from the plurality of privacy parameters, the set of privacy parameters comprising purpose for exposure, the at least one data field to be exposed, and the level of exposure for the one or more data subjects; and
computing a weighted sum of the functions of the weights of the set of privacy parameters.

6. The method as claimed in claim 5, wherein defining the strength of the privacy policy for the one or more data subjects comprises comparing the weighted sum with one or more threshold values of the strength of the privacy policy.

7. The method as claimed in claim 6, further comprising comparing the strength corresponding to the privacy policy with at least one of a previous version of the plurality of versions to track an evolution of strength of privacy policy.

8. The method as claimed in claim 1, further comprising, prior to generating the model of the privacy policy:
receiving an update of the one or more access preferences associated with the at least one data field; and
appending the updated one or more access preferences to the privacy lineage tree.

9. The method as claimed in claim 1, wherein the privacy policy is indicative of privacy levels corresponding to the at least one data field, and wherein generating the model of the privacy policy comprises:
computing decision factor for the at least one data field, the decision factor corresponding to a data field obtained based on a product of the information factor and the weightage assigned to the data field, the weightage of the data field is configurable based the domain and time;
assigning a minimum and a maximum threshold value for the decision factor to define a decision region, the decision region indicative of a range of recommended privacy level for the at least one data field; and
associating the decision regions with a respective decision factors, wherein a decision region with a relatively higher decision factor value is associated with a relatively more stricter privacy policy and a decision region with a relatively lower exposure value is associated with a relatively less stricter privacy policy.

10. The method as claimed in claim 9, further comprising storing the priority values for the data field in the privacy lineage tree.

11. The method as claimed in claim 10, further comprising identifying a preferable version of access preference from amongst the plurality of versions for a data field, based on the plurality of priority values associated with the privacy levels.

12. A system for managing data policy comprising :
at least one memory; and
one or more hardware processors, the at least one memory coupled to the one or more hardware processors wherein the one or more hardware processors are capable of executing programmed instructions stored in the at least one memory to:
generate a privacy lineage tree by systematically storing privacy lineage data associated with one or more data subjects, the privacy lineage data comprising a plurality of versions of one or more access preferences modified over a time period, the access preferences comprises a plurality of levels of privacy associated with a plurality of data fields of the privacy lineage data associated with the one or more data subjects, the plurality of levels indicative of exposure of the plurality of data fields;
generate a model of a privacy policy using the privacy lineage data by traversing the privacy lineage tree, based on one or more of a plurality of privacy parameters, the plurality of privacy parameters comprising a purpose of exposure, the at least one data field to be exposed, a level of exposure, an information factor indicative of information contained in at least one data field and respective weightages of the at least one data field, the respective weightages indicative of sensitivity of the at least one data field; and
define at least one of, a strength of the privacy policy and recommended privacy levels for the at least one data field, based on the model of the privacy policy.

13. The system as claimed in claim 12, wherein to systematically store the privacy lineage data, the one or more hardware processors are further configured by the instructions to store, for each of the one or more data subjects, the privacy lineage data in a sub-tree corresponding to the data subject and rooted at a root node of the privacy lineage tree, and wherein the sub-tree stores an unique identifier associated with the data subject, date and time stamp of previous access preferences corresponding to the data subject, and respective access preferences set for a plurality of purposes for the plurality of data fields.

14. The system as claimed in claim 12, wherein one or more hardware processors are further configured by the instructions to receive a query for exposure to the at least one data field from amongst the plurality of data fields, prior to generating the model of the privacy policy, the query comprising at least the purpose for exposure to the at least one data field.
.
15. The system as claimed in claim 12, wherein the privacy policy of a data subject is indicative of strength of privacy levels associated with access preferences of the data subject.

16. The system as claimed in claim 15, wherein to model the privacy policy, the one or more hardware processors are further configured by the instructions to:
define functions of weights of a set of privacy parameters from the plurality of privacy parameters, the set of privacy parameters comprising purpose for exposure, the at least one data field to be exposed, and the level of exposure for the one or more data subjects; and
compute a weighted sum of the functions of the weights of the set of privacy parameters.

17. The system as claimed in claim 16, wherein to define the strength of the privacy policy for the one or more data subjects, the one or more hardware processors are further configured by the instructions to compare the weighted sum with one or more threshold values of the strength of the privacy policy.

18. The system as claimed in claim 17, wherein the one or more hardware processors are further configured by the instructions to compare the strength corresponding to the privacy policy with at one of a previous version of the plurality of versions to track an evolution of the strength of the privacy policy.

19. The system as claimed in claim 12, wherein the privacy policy is indicative of privacy levels corresponding to the at least one data field, and wherein to generate the model of the privacy policy, the one or more hardware processors are further configured by the instructions to:
compute decision factor for the at least one data field, the decision factor corresponding to a data field obtained based on a product of the information factor and the weightage assigned to the data field, the weightage of the data field is configurable based the domain and time;
assign a minimum and a maximum threshold value for the decision factor to define a decision region, the decision region indicative of a range of recommended privacy level for the at least one data field;
associate the decision regions with a respective decision factors, wherein a decision region with a relatively higher decision factor value is associated with a relatively more stricter privacy policy and a decision region with a relatively lower exposure value is associated with a relatively less stricter privacy policy ; and
identify a preferable version of access preference from amongst the plurality of versions for a data field, based on the plurality of priority values associated with the privacy levels.

20. The system as claimed in claim 19, wherein the one or more hardware processors are further configured by the instructions to store the priority values for the data field in the privacy lineage tree.
, Description:FORM 2

THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003

COMPLETE SPECIFICATION
(See section 10 and rule 13)

Title of invention:
METHOD AND SYSTEM FOR PRIVACY POLICY MANAGEMENT

Applicant:
Tata Consultancy Services Limited
A Company Incorporated in India under the Companies Act, 1956
Having address:
Nirmal Building, 9th Floor,
Nariman Point, Mumbai 400021,
Maharashtra, India

The following specification particularly describes the invention and the manner in which it is to be performed.
TECHNICAL FIELD
[001] The present subject matter relates, in general, to privacy policy management and, in particular, to providing method and systems for tracking changes in sensitive data available to various organizations and/or institutions to manage the privacy policy.

BACKGROUND
[002] Currently, with advancement in the internet technology, various products and services have been introduced and practiced. Examples of such products and/or services include, but are not limited, to, online transactions, social networking, e-commerce shopping websites, and so on. Such products and services allow users to conveniently transact online. Various organization providing such products and services includes banks, telecom operators, insurance companies, and other such organizations.
[003] The organizations enabling online provisioning of services and product to consumers acquires sensitive data of customers while the customers register with said organizations or accepts the services thereof. Such sensitive data may include, but are not limited to, name, address, date of birth, identity number, financial details like bank account details, credit card number, Card Verification Value (CVV) code, date of expiry of the credit card, and so on. The sensitive data of the customers that is available to the organizations may pose a risk of getting shared with other companies or third parties. In order to avoid such risks, the customers are advised to change privacy settings/preferences associated with the sensitive data over a period of time. The changes made to said privacy settings/preferences constituting privacy policies increase or decrease the risk of data sharing depending on result of said changes, thereby making the privacy policy weaker or stronger.

SUMMARY
[004] The following presents a simplified summary of some embodiments of the disclosure in order to provide a basic understanding of the embodiments. This summary is not an extensive overview of the embodiments. It is not intended to identify key/critical elements of the embodiments or to delineate the scope of the embodiments. Its sole purpose is to present some embodiments in a simplified form as a prelude to the more detailed description that is presented below.
[005] In view of the foregoing, an embodiment herein provides a method and system for managing privacy of data. In one aspect, a processor-implemented method for managing privacy policy is provided. The method includes generating, via one or more hardware processors, a privacy lineage tree by systematically storing privacy lineage data associated with one or more data subjects. The privacy lineage data includes a plurality of versions of one or more access preferences modified over a time period. The access preferences includes a plurality of levels of privacy associated with a plurality of data fields of the privacy lineage data associated with the one or more data subjects. The plurality of levels are indicative of exposure of the plurality of data fields. Further, the method includes generating, via the one or more hardware processors, a model of a privacy policy using the privacy lineage data by traversing the privacy lineage tree, based on one or more of a plurality of privacy parameters. The plurality of privacy parameters includes the purpose of exposure, the at least one data field to be exposed, a level of exposure, an information factor indicative of information contained in the at least one data field and respective weightages of the at least one data field. The respective weightages are indicative of sensitivity of the at least one data field. Furthermore, the method includes defining, via the one or more hardware processors, at least one of, a strength of the privacy policy and recommended privacy levels for the at least one data field, based on the model of the privacy policy
[006] In another aspect, a system for managing privacy policy is provided. The system includes at least one memory; and one or more hardware processors, the at least one memory coupled to the one or more hardware processors wherein the one or more hardware processors are capable of executing programmed instructions stored in the at least one memory to generate a privacy lineage tree by systematically storing privacy lineage data associated with one or more data subjects. The privacy lineage data includes a plurality of versions of one or more access preferences modified over a time period. The access preferences includes a plurality of levels of privacy associated with a plurality of data fields of the privacy lineage data associated with the one or more data subjects. The plurality of levels are indicative of exposure of the plurality of data fields. Further the one or more hardware processors are capable of executing programmed instructions to generate a model of a privacy policy using the privacy lineage data by traversing the privacy lineage tree, based on one or more of a plurality of privacy parameters. The plurality of privacy parameters includes the purpose of exposure, the at least one data field to be exposed, a level of exposure, an information factor indicative of information contained in the at least one data field and respective weightages of the at least one data field. The respective weightages are indicative of sensitivity of the at least one data field. Furthermore, the one or more hardware processors are capable of executing programmed instructions to define at least one of, a strength of the privacy policy and recommended privacy levels for the at least one data field, based on the model of the privacy policy
[007] In yet another aspect, a non-transitory computer-readable medium having embodied thereon a computer program for executing a method for managing privacy policy is provided. The method includes generating a privacy lineage tree by systematically storing privacy lineage data associated with one or more data subjects. The privacy lineage data includes a plurality of versions of one or more access preferences modified over a time period. The access preferences includes a plurality of levels of privacy associated with a plurality of data fields of the privacy lineage data associated with the one or more data subjects. The plurality of levels are indicative of exposure of the plurality of data fields. Further the method includes generating a model of a privacy policy using the privacy lineage data by traversing the privacy lineage tree, based on one or more of a plurality of privacy parameters. The plurality of privacy parameters includes the purpose of exposure, the at least one data field to be exposed, a level of exposure, an information factor indicative of information contained in the at least one data field and respective weightages of the at least one data field. The respective weightages are indicative of sensitivity of the at least one data field. Furthermore, the method includes defining at least one of, a strength of the privacy policy and recommended privacy levels for the at least one data field, based on the model of the privacy policy.
BRIEF DESCRIPTION OF THE FIGURES
[008] The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the drawings to reference like features and modules.
[009] FIG. 1 illustrates example network implementation for managing privacy policy, in accordance with an example embodiment;
[0010] FIG. 2 illustrates a block diagram of a system for managing privacy policy, in accordance with an example embodiment;
[0011] FIG. 3 is an example representing access preferences arranged in various levels for managing privacy policy, in accordance with an example embodiment;
[0012] FIGS. 4A and 4B illustrate example screenshots of display to view privacy preferences and/or levels in accordance with an example embodiment;
[0013] FIG. 5 illustrates an example of generating privacy lineage tree using privacy lineage data belonging to one or more data subjects, in accordance with an example embodiment;
[0014] FIGS. 6A and 6B represent an example evolution of privacy policy of a data subject, in accordance with an example embodiment;
[0015] FIG. 7 is a flow diagram depicting an example method for managing privacy policy, in accordance with an example embodiment;
[0016] FIG. 8 is a flow diagram depicting an example method for managing privacy policy, in accordance with another example embodiment;
[0017] FIG. 9 is a flow diagram depicting an example method for managing privacy policy, in accordance with another example embodiment; and
[0018] FIG. 10 illustrates example architecture of a scenario for management of privacy policy of a data subject, in accordance with an example scenario.
[0019] It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative systems and devices embodying the principles of the present subject matter. Similarly, it will be appreciated that any flow charts, flow diagrams, and the like represent various processes which may be substantially represented in computer readable medium and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.

DETAILED DESCRIPTION
[0020] The present disclosure relates to methods and systems for managing privacy policy associated with data of organizations and/or enterprises. The methods and systems are not limited to the specific embodiments described herein. In addition, the method and system can be practiced independently and separately from other modules and methods described herein. Each device element/module and method can be used in combination with other elements/modules and other methods.
[0021] Unless specifically stated otherwise as apparent from the following discussions, it is to be appreciated that throughout the present disclosure, discussions utilizing terms such as “determining” or “generating” or “comparing” or the like, refer to the action and processes of a computer system, or similar electronic activity detection device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.
[0022] The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.
[0023] Throughout the description and claims of this complete specification, the word “comprise” and variations of the word, such as “comprising” and “comprises,” means “including but not limited to,” and is not intended to exclude, for example, other additives, components, integers or steps. “Exemplary” means “an example of” and is not intended to convey an indication of a preferred or ideal embodiment. “Such as” is not used in a restrictive sense, but for explanatory purposes.
[0024] For a firmware and/or software implementation, the methodologies can be implemented with modules (e.g., procedures, functions, and so on) that perform the functions described herein. Any machine readable medium tangibly embodying instructions can be used in implementing the methodologies described herein. For example, software codes and programs can be stored in a memory and executed by a processing unit.
[0025] It should be noted that the description merely illustrates the principles of the present subject matter. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described herein, embody the principles of the present subject matter and are included within its spirit and scope. Furthermore, all examples recited herein are principally intended expressly to be only for pedagogical purposes to aid the reader in understanding the principles of the invention and the concepts contributed by the inventor(s) to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions. Moreover, all statements herein reciting principles, aspects, and embodiments of the invention, as well as specific examples thereof, are intended to encompass equivalents thereof.
[0026] The manner, in which the system and method for managing privacy policy shall be implemented, has been explained in details with respect to the FIGS. 1 through 10, while aspects of described methods and systems for managing privacy policy can be implemented in any number of different systems, utility environments, and/or configurations, the embodiments are described in the context of the following exemplary system(s).
[0027] FIG. 1 illustrates example architecture 100 for managing privacy policy, in accordance with an example embodiment. The embodiments are directed to managing privacy policy using an electronic device. The example architecture 100 is shown to include an organization or an institution 102 providing product or services, a computing device 104, a plurality of electronic devices such as devices 106, 108, 110, and communication network such as communication network 112.
[0028] In an embodiment, the communication network 112 may comprise any combination of Local Area Networks (LANs), Wide Area Networks (WANs), Internet Protocol (IP) networks, phone networks, Public Switched Telephone Networks (PSTN), wireless networks, cellular networks, Wi-Fi networks, Bluetooth networks, cable networks, data buses, or the like, or any combination thereof used for transferring information and/or data between the devices 106, 108, 110, the computing device 104, and the organization 102.
[0029] In an example embodiment, the electronic devices 106, 108, 110 may include a mobile device or a fixed electronic device. Examples of a mobile device may include a mobile phone, a laptop, a sensitive digital assistant (PDA), a tablet, a workstation, and so on. Example of a fixed electronic device may include a workstation computer. In an embodiment, the electronic devices 106, 108, 110 belong to customers of organization 102, and may facilitate the customers of the organization 102 to access the products and/or services provided by the organization 102. For instance, the organization 102 may represent a bank, and the bank may provide services such as account opening, balance checking, online transfer, investments, bill pay options and numerous other services involving usage of internet for complete transactions. Herein, the customers of the electronic devices 106, 108, 110 may access the products and services provided by the institution by accessing an application of the institution on the electronic device (for example, electronic device (106, 108, 110) thereof. It will be understood that the customers may be provided an access to the organization 102 only upon being authenticated by the organization 102.
[0030] The organization 102 can authenticate the customers using customers’ sensitive data that may be provided to the organization 102 by the customer at the time of registering with the organization or otherwise. For instance, in case of availing of banking products and/or services, the customers provides various sensitive data including, but not limited to, permanent account number (PAN), date of birth, e-mail address, residential address, and contact details, and so on. The customers also provide various preferences to the bank such as interest in receiving information regarding various products offered by the bank. In case, a customer is using a credit card or a debit card issued by the bank, the bank may be able to view the spending pattern of the customer. The data pertaining to information such as spending patterns, account balance, loans, sensitive details and any other such data is customer’s sensitive data, and is mostly available to the personnel employed at the bank. Herein, the customers provide their personal data to organizations and/or institutions. Such individuals who are subject of the personal data are referred to as ‘data subjects’. Accordingly the terms ‘customer’ and ‘data subject’ shall be used interchangeably throughout the description.
[0031] Data subjects changes their privacy preferences multiple times over a period of time and thereby, moving to stronger or weaker privacy policies, as per their choice of privacy preferences. Herein, the term ‘Privacy policy’ refers to set of pairs containing sensitive data field or personally identifiable information (PII) and corresponding preference for that data field. Such PII may be shared by the data subject with an organization and/or institution. Additionally or alternatively, the privacy policy may include sensitive data fields across multiple data subjects. Typically, the strength of privacy policy is difficult to determine, particularly since tracking history of changes in the data subjects' privacy preferences over a period of time is a challenging task. Herein, strength of privacy policy refers to an indication of leniency or strictness of a privacy policy.
[0032] A history of changes in the data subjects' privacy preferences may be useful in deducing strength of privacy policies of data subjects and sensitive field specific policies across a number of data subjects. Herein, the “history of changes in the data subjects' privacy preferences” may be referred to as “lineage of data subjects’ privacy preference”. Moreover, information on evolution of privacy policies across the data subjects may help organization in knowing the policies regarding individual sensitive fields. The current data privacy management systems lack capability of providing information regarding the evolution of privacy policies of data subjects, and the sensitive data fields across data subjects.
[0033] In addition, typically information regarding privacy policies of data subjects is managed by storing privacy preferences for each sensitive field and purpose defined by organization, in a database. Organizations have applications which do not employ relational databases. If organizations want to track the evolution of privacy policies for NoSQL database driven applications, there is a need of an alternative approach to handle large scale data generated as the result of a need to track said evolution. The data related to privacy preferences grow every time a data subject updates his/her privacy preferences. Said vertical growth in data could be huge if data subjects update their privacy preferences frequently. Thus, the database used for storage should be scalable and efficient in terms of storage and retrieval. Storing each update of data subjects in non-relational databases may be convenient, but such databases lack mature and well developed query optimization techniques unlike relational databases. For example, if a data subject queries for specific versions of data, such as 2nd version of privacy level for a field (1) and/or 3rd version of privacy level for a field (2) and/or 5th version of privacy level for a field (10), then databases may not be able to implement joins or index selection, and fetch the results efficiently.
[0034] Various embodiments of the present disclosure allow management of privacy policy for large scale data (belonging to data subjects) to be stored and retrieved efficiently so that the complex queries could be answered. For example, as will be explained in detail further in the description, in one embodiment, the disclosed system stores data subjects’ privacy data in a hierarchical tree format for efficient storage and retrieval. The system also answers complex queries related to privacy lineage such as, getting frequency of changes done to any field over a period of time or finding privacy level set for a field on a specified version of update, by using the suggested tree structure that is storing the privacy preference history in system. Additionally, the disclosure discloses embodiments including systems and methods for managing data privacy by tracking data subject's privacy policy and field specific privacy policy. In an embodiment, the system evaluates strictness of a data subject's privacy policy. For calculating strictness of a privacy policy, the system computes a metric which takes into account various dimensions related to privacy such as fields, purposes, privacy levels and their corresponding weightage. The system is capable of recommending most suitable privacy level for the individual data fields by evaluating information contained in said data fields. The system is also capable of identifying the most suitable privacy preference, set by the data subject till date. In an implementation, the system may be implemented as an application on a computing device such as the computing device 104. The data privacy management system may include hardware and software that may be collectively configured to host an IT application for performing various functions pertaining to management of data privacy. The data privacy management system and implementation thereof is explained further in detail with reference to FIGS. 2 till 10.
[0035] In an embodiment, the computing device 104 embodying the data privacy management system can be a server communicably coupled to the organization 102 (in particular, server of the organization 102). It may however be understood that the system 102 may also be implemented in a variety of computing systems, such as a laptop computer, a desktop computer, a notebook, a workstation, a mainframe computer, a server, a network server, and the like. In an embodiment, the computing device 104 may be one or more servers for example a farm of networked servers, a clustered server environment, or a cloud network of computing devices, that may be included in, or otherwise, in communication with the organization 102. In another embodiment, the computing device 104 may be a mobile electronic device capable of communicating with the organization 102, and implementing the system for managing privacy policy of data subjects of the organization 102. In particular, the computing device 104 may include the privacy policy management system for tracking evolution of privacy policy of data subjects, and deriving meaningful analysis therefrom. The computing device 104 (or the system 104 embodied in the computing device) may allow the data subjects to view/modify access preferences for sensitive and personal data thereof, and save the said access preferences for various data fields. A system for managing privacy policies of data subjects is described further with reference to FIG. 2.
[0036] FIG. 2 illustrates a block diagram of a system 200 for managing data privacy in accordance with an example embodiment. As discussed with reference to FIG. 1, the data subject can access the products and/or services offered by the organization. The organization may retrieve and/or store data subject’s sensitive data so as to allow the data subject to access the products and/or services offered by the organization. The data subject can set and modify/update privacy preferences or settings for various fields of sensitive data thereof over a period of time. The sensitive data may include personally identifiable information (PII) data and domain specific data. Herein, the PII data may refer to the data that may be utilized for determining identity of the data subject. Examples of data fields including the PII data in case of a finance application may include PAN number, date of birth, e-mail address, residential address, mobile number, and so on. The domain specific data includes the data that can pose a risk or affect the data subject financially or otherwise, if disclosed in public. In an embodiment, the domain specific data may include domain specific fields, and can be generated by the organization. Examples of said domain specific data for a financial institution such as a bank may include financial information such as debit and/or credit card numbers, CVV number, account balance, card expiry date, and other such fields. Examples of domain specific data for a medical institution may include medical records of data subjects having disease and allergy details, treatment history, consulting medical practitioners, and so on. As will be understood, the domain specific data and PII data may be collectively utilized for defining the privacy policy. Alternatively, in some implementations either of the domain specific data and PII data may individually be utilized for defining the privacy policy.
[0037] Data privacy involves protection of data subject's information. Huge data collected by organizations calls for an efficient privacy system, which is capable of enforcing and observing data subject's privacy. The system 200 tracks and records data subject's privacy policy set over time. For instance, the system 200 monitors data subject's privacy preferences and based on monitored privacy preference, indicate strength of data subject's privacy policy. In turn, the determined strengths can be used to indicate privacy policy evolution for data subjects. The system 200 is further recommends favourable privacy levels to the data subjects, taking into account the information value of data fields, and displays best preferences set previously for data fields. The details of computing data policy strength and recommendation of favourable privacy levels are described further in detail in the following description.
[0038] In an example embodiment, the system 200 may be embodied in, or is in direct communication with a computing device, for example the computing device 104 (FIG. 1). The system 200 includes or is otherwise in communication with one or more hardware processors such as a processor 202, at least one memory such as a memory 204, and a communication interface 206. The processor 202, memory 204, and the communication interface 206 may be coupled by a system bus such as a system bus 208 or a similar mechanism.
[0039] The memory 204 may include any computer-readable medium known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. In an embodiment, the memory 204 includes a plurality of modules 220 and a repository 240 for storing data processed, received, and generated by one or more of the modules 220. The modules 220 may include routines, programs, objects, components, data structures, and so on, which perform particular tasks or implement particular abstract data types. In one implementation, the modules 220 may include programs or coded instructions that supplement applications and functions of the system 200.
[0040] In one implementation, the modules 220 may include a privacy preferences viewer module 222, a privacy settings recorder module 224, and a privacy lineage tree generator module 226, privacy strength calculator module 228, a privacy level recommender module 230, a privacy level viewer module 232 and other modules 234. The repository 240, amongst other things, includes a system database 242 and other data 244. The other data 244 may include data generated as a result of the execution of one or more modules 220. The repository 240 is further configured to store privacy lineage data 246 and priority scores 248 (as will be discussed later in the description).
[0041] The one or more hardware processors such as the processor 202 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that facilitates in managing privacy policies. Further, the processor 202 may comprise a multi-core architecture. Among other capabilities, the processor 202 is configured to fetch and execute computer-readable instructions or modules stored in the memory 204. The processor 202 may include circuitry implementing, among others, audio and logic functions associated with the communication. For example, the processor 202 may include, but are not limited to, one or more digital signal processors (DSPs), one or more microprocessor, one or more special-purpose computer chips, one or more field-programmable gate arrays (FPGAs), one or more application-specific integrated circuits (ASICs), one or more computer(s), various analog to digital converters, digital to analog converters, and/or other support circuits. The processor 202 thus may also include the functionality to encode messages and/or data or information. The processor 202 may include, among other things, a clock, an arithmetic logic unit (ALU) and logic gates configured to support operation of the processor 202. Further, the processor 202 may include functionality to execute one or more software programs, which may be stored in the memory 204 or otherwise accessible to the processor 202.
[0042] The communication interface 206 is configured to facilitate communication between an organization (for example, the organization 102), the system 200 (or the computing device 104 embodying the system 200), and at least one electronic device (for example, the electronic devices 106, 108, and 110). The communication interface 206 may be in form of a wireless connection or a wired connection. Examples of wireless communication interface 206 may include, but are not limited to, IEEE 802.11 (Wifi), BLUETOOTH®, or a wide-area wireless connection. Example of wired communication interface 206 includes, but is not limited to Ethernet.
[0043] In an example embodiment, a user interface 210 may be in communication with the processor 202. Examples of the user interface 210 may include but are not limited to, input interface and/or output user interface. The input interface is configured to receive an indication of a data subject’s input. The output user interface provides an audible, visual, mechanical or other output and/or feedback to the data subject. Examples of the input interface may include, but are not limited to, a keyboard, a mouse, a joystick, a keypad, a touch screen, soft keys, and the like. Examples of the output interface may include, but are not limited to, a display such as light emitting diode display, thin-film transistor (TFT) display, liquid crystal displays, active-matrix organic light-emitting diode (AMOLED) display, a microphone, a speaker, ringers, vibrators, and the like. In an example embodiment, the user interface 210 may include, among other devices or elements, any or all of a speaker, a microphone, a display, and a keyboard, touch screen, or the like. In this regard, for example, the processor 202 may comprise user interface circuitry configured to control at least some functions of one or more elements of the user interface 210, such as, for example, a speaker, ringer, microphone, display, and/or the like. The processor 202 and/or user interface circuitry comprising the processor 202 may be configured to control one or more functions of one or more elements of the user interface 210 through computer program instructions, for example, software and/or firmware, stored on a memory, for example, the at least one memory 204, and/or the like, accessible to the processor 202.
[0044] In an embodiment, the user interface 210 allows a data subject to manage one or more access preferences for personal and sensitive (domain) fields. Herein managing the one or more access preferences may refer to defining and/or modifying said access preferences for the sensitive data. Examples of access preferences that may be defined for accessing at least one data field of the sensitive data may include access-time preference and access-type preference. The access-type preference may include at least one of allowing an access to the one or more fields, denying an access, allowing access upon consent from the data subject, a notification generation upon access, and various other preferences. In an embodiment, the access-time preference may include defining preferred time to call, preferred date of communication, Do-Not-Disturb (DND) options, and other scheduled preferences. Herein, it will be understood that the above defined preferences are mentioned for example purposes and should not be considered as limiting to various embodiments of the disclosure. Additionally, the system 200 can allow configuration of various other preferences based on various other parameters and/or attributes of the organization and/or data subjects. For instance, the preferences may be defined based on parameters including, but not limited to, time, date, geography, role, IP address, and so on. As an example, for a security related data field, authentication and authorization may be provided as a preference, meaning thereby that for accessing a security related data, the intended party may be required to provide authentication details, and once authenticated, the intended party may be allowed to access said data. Herein, it will be understood that the privacy levels associated with the access preferences facilitate in identifying a level of exposure of data subjects' data. Said levels may be configurable and may be changed according to the environment in which the system is working. Other variation of levels could be Private view, Group view, Public view. An example of access preferences arranged in various levels is represented and described with reference to an example in FIG. 3.
[0045] Based on the access preferences set for various fields of the sensitive data, the system may cause exposure of said fields. In an embodiment, the exposure of data fields to an intended party may also be configurable based on ‘purpose’ of exposure or data access. The purpose of data access is an important factor for data subject's decision for selective information exposure. Said purpose provides information regarding an organization trying to access data subject’s data. The system 200 is capable of setting different privacy levels for different purposes based on data subject’s inputs. Said purposes may be configurable and may be customized as per the organization trying to access data subject's data. For example, for a hospital or some medical institution, the purpose could be set as: “To create protected health information”, “For treatment”, and so on. For some other organizations, the purpose may be generalized as well, for instance, “To improve internal products and services”, “To share data with third parties”, and so on. In an embodiment, the data subjects may define access levels (or access preferences that are indicative of exposure of sensitive and/or personal data) for various purposes corresponding to the data fields of privacy data. In an embodiment, the system 200 may include a privacy preference viewer module 222 that may allow data subjects to manage preferences for personal and sensitive (domain) data fields. An example of set-up to view privacy preferences is described with reference to FIG. 4.
[0046] In an embodiment, the system 200 tracks evolution of access preferences over a period of time to manage privacy policy. Herein, ‘managing the privacy policy’ may include evaluating strictness of a data subject's privacy policy. In order to evaluate the strictness of data subject’s privacy policy, the system 200 computes a metric that takes into account various dimensions related to privacy such as data fields, purposes of access, privacy levels and their corresponding weightage. In another embodiment, the system 200 manages the privacy policy by recommending privacy levels for the data fields. For instance, the system 200 recommends most suitable privacy level for a field by evaluating information contained in said data field. The system 200 may also identify best privacy preference, set by data subject till date. The management of privacy policy for evaluating strictness of a data subject's privacy policy and recommending privacy levels for the data fields is explained further in detail in the description below.
[0047] In an embodiment, the system 200 manages the privacy policy by utilizing the data subjects' privacy lineage data. The privacy lineage data corresponding to a data subject includes a plurality of versions of one or more access preferences of the data subjects modified over a time period. As previously discussed, the access preferences includes a plurality of levels of privacy of the data fields of the privacy lineage data associated with the one or more data subjects. The plurality of levels are indicative of exposure of the plurality of data fields, as will be explained further by way of an example in FIG. 4.
[0048] The system 200 systematically stores the privacy lineage data and generates a privacy lineage tree. Herein, systematically storing the privacy lineage data includes storing, for each of the one or more data subjects, the privacy lineage data in a sub-tree corresponding to the data subject and rooted at a root node of the privacy lineage tree. The sub-tree stores a unique identifier (ID) associated with the data subject, date and time stamp of previous access preferences corresponding to the data subject, and respective settings for settings done for a plurality of purposes for the data fields. An example of generating the privacy lineage tree using the privacy lineage data is described further with reference to FIG. 5. The system 200 captures information on every update made to the privacy preferences, to the database. Said data is retrieved to the system and modulated to a tree structure for fast processing. In an embodiment, the system 200 receives an update of the one or more access preferences associated with the one or more data fields, and appends the updated one or more access preferences to the privacy lineage tree. The tree is built in such a way that most of the data is encoded to save space on system and also can answer the queries related to privacy settings lineage efficiently.
[0049] In an embodiment, the system 200 stores the privacy preferences history details (or the privacy policy data) obtained from the database files in internal memory for better performance in answering complex queries such as determining evolution of data subject's privacy policy or getting frequency of changes done on a field by data. In an embodiment, the results for these queries are viewed in privacy preference viewer module 224.
[0050] The system 200 generates a model of the privacy policy using the privacy lineage data by traversing the privacy lineage tree. In an embodiment, the system 200 traverses the privacy lineage tree to determine plurality of privacy parameters associated with data subject’s sensitive data therefrom. Examples of said privacy parameters may include but are not limited to at least one of the purpose of exposure, the data field to be exposed, a level of exposure, an information factor indicative of information contained in the at least one data field and respective weightages of the at least one data field. Herein, the respective weightages are indicative of sensitivity of the at least one data field.
[0051] In an embodiment, the system 200 receives a query prior to generating the model of the privacy policy. The query may be for exposure to the at least one data field from amongst the plurality of data fields. In an embodiment, the query may include at least a purpose for exposure to the at least one data field. Upon receipt of the query, the system 200 may traverse through the privacy lineage tree, and generate a response to said query.
[0052] In an example scenario, the query may be related to the privacy lineage. For instance, the data subject may input a query to the system 200 to provide privacy policy evolution thereof. Herein, the term ‘privacy policy evolution’ may include tracking of various privacy levels corresponding to the access preferences of the data subjects for a period of time, and deriving meaningful analysis therefrom. Said analysis may be in terms of evolution of strength of the privacy policy over the period of time. For example, based on changes in levels of privacy preferences, the system may determine that a current version of the privacy policy has become stricter or more lenient as compared previous versions of privacy policy. In order to determine strength of the privacy policy, the system computes a metric to determine the strength of data subject’s privacy policy so that he can view this evolution. In an embodiment, the system includes a privacy strength calculator module 228 that is used to calculate the strength of the privacy policy of the data subject based on the traversal of the privacy lineage tree. In the present example scenario, the system 200 computes weighted sum of the purpose for exposure, the at least one data field to be exposed, and the level of exposure for the one or more data subjects. The weighted sums with one or more threshold values of strength of the privacy policies are compared to define the strength of the privacy policy for the one or more data subjects.
[0053] Herein the system 200 generates the model of the privacy policy of the data subject using the privacy parameters including the purpose for exposure, the at least one data field to be exposed, and the level of exposure for the one or more data subjects. The system 200 defines strength as a function of weights of said parameters, as shown below.
Purposes P = {P1, P2, P3, ---------, Px}
Fields F = {F1, F2, F3, ----------, Fy}
Levels of privacy L = {L1, L2, L3, -----------, Lz}
[0054] The system assigns weights to the privacy parameters. For example, the system 200 may determine the function for weight W(F) of the privacy parameter ‘field’, based on the domain of the organization and time. For example, for financial institutions such as banks, financial details are of much more importance, hence the related fields may be weighed more, while for hospital fields related to data subject's medical history possess higher importance. Additionally, the weight of data fields are also time dependent. Herein, time may refer to time with respect to market conditions. For instance, in certain time, the data subjects may wish to share data to avail certain discounts. In an embodiment, the system 200 determines the function for weight W(L) of the privacy level. In an example embodiment, where the system 200 is assumed to have four levels of privacy. Said privacy levels may be assigned weights according to the levels of strictness thereof. In an embodiment, the system 200 may assign weight to the ‘purpose’ field. In an embodiment, the purposes mentioned in the purpose field may be assigned respective weights according to their importance for the related domain.
[0055] In an embodiment, the strength for individual purpose is given as below:
Si = [V1, V2, V3 -----------, Vy] * [W(F1), W(F2), W(F3), -------, W(Fy)]T
where, Vi is value of the privacy level set for corresponding data field for given purpose
[0056] Total strength can be given by adding strengths of individual purposes
S = S(Si * W(P))
The maximum strength could be obtained if data subjects set strictest level of privacy for all the fields for every purpose
i.e. Mstrength = S(SM * W(P))
where, SM = [Vmax, Vmax, Vmax, -----------, Vmax] * [W(F1), W(F2), W(F3), -------, W(Fy)]T
The strength of the privacy policy can be evaluated by normalizing the above level strength on the scale of 100 by following formula:
(S / Mstrength) * 100
Based on the score computed for the privacy policy strength, system can determine the strict-ness of data subject's privacy policy. In an embodiment, the system 200 defines the strength of the privacy policy for the one or more data subjects based on comparison of the scores ob-tained from the weighted sum with one or more threshold values of strength of the privacy policy. In an embodiment, the system 200 compares the strength corresponding to the privacy policy with at least one of a previous version of the plurality of versions to track an evolution of strength of privacy policy. An example of the strictness of data subject's privacy policy based on the scores (computed above), and evolution of the privacy policy is described fur-ther with reference to an example scenario illustrated and described with reference to FIGS. 6A and 6B.
[0057] In another example scenario, the query may be related to values for all the fields, for all the purposes on a given date, for a particular data subject. In order to determine the response to said query, the system 200 traverses the privacy lineage tree and get to the root of the data subject subtree. From there, the system 200 may traverse to subtree for each of the fields and perform a search for the given date, in the string in nodes of history subtree for each field. If the date is present in the tree, then the encoded values for purposes are collected, and if the date is not present in the tree, then privacy level values in nodes having latest previous date may be considered to be the values set on that date. Also, if two or more nodes are present in the tree for same date, then privacy level values for all of the nodes may be enlisted and provided as output data. Said output data may be collected for all of the fields for data subject and finally complete data may be sent as result for the query to privacy preference lineage viewer module 232.
[0058] In still another example scenario, the query may be related to fetching latest privacy policy for a single sensitive field. In order to respond to said query, the system 200 may traverse the field subtree for each data subject and get the latest privacy level by accessing the node with largest ID i.e. right most node. The system 200 may generate the privacy policy for the field by enlisting percentage of data subjects having corresponding levels of privacy set for field, and send the result for query to the privacy preference lineage viewer module 232.
[0059] In yet another scenario, the query may be data subjects asking for particular version of a specific field. For example, the data subject may request for a 3rd version of “DOB” field. For responding to the query, system 200 may get in order traversal of the history subtree for the specific field, here “DOB”, for the data subject. The system may discard the repeated values, just count the changed values and return value corresponding to count 3 to the privacy preference lineage viewer module 232.
[0060] In still another scenario, the query may include fetching the frequency of changes of field over the selected period of time, for single data subject. For example, to get frequency of change of field “DOB”, in the month of December 2016, for a data subject ID 79, from the root, subtree for data subject ID 79 may be selected. Said subtree may then be traversed to get another subtree for required field “DOB”. Once subtree of selected field is available, it is traversed and only those nodes whose time stamp matches the given period of time are selected. It is checked whether there are any changes in preferences by comparing the values with its predecessor nodes. A count (say, c79) is maintained, incremented for every change and returned to privacy preference lineage viewer module 232.
[0061] In still another embodiment, the system fetches the frequency of change of field over the selected period of time for multiple data subjects. The system determines a count for individual data subject, which may be added to get overall count, and then returned to privacy lineage viewer module 232, as computed below:
Count = c1+c2+....+c79+c80+....
[0062] In an embodiment, the system 200 provides or recommends suitable privacy levels for the at least one data field, based on the privacy policy. In an embodiment, the system 200 includes a privacy level recommender module 230 for defining the recommended privacy levels corresponding to the data fields. The privacy level recommender module 230 recommends favourable privacy levels to the data subjects, taking into account the information value of data fields and displays best preferences set previously for data fields. The privacy level recommender module 230 takes into account the frequency of access and sensitivity of data fields. The privacy level recommender module 230 identifies the best privacy preference for data fields, among previous versions and recommends the most favourable privacy levels for data subject. The best privacy preferences are identified using a decision factor which takes into account, the information contained in data field and its weight. As is described further in description, the data fields may be provided weights as per their sensitivity, to calculate appropriate privacy level to be set.
[0063] Herein, it will be understood that the information contained in a data field is dependent on inverse of probability of access to that data field. Thus, lesser the probability more the information contained in the data field i.e. more uncertain the access to data field, more the information it contains and lesser the uncertainty, lesser the information it contains. The privacy level recommender module 230 evaluates the information contained in a data field which covers the frequency of access aspect of the data fields. The information contained in data field Fi with probability of access Pi is given by:
I(Fi) = log2(1/Pi)
[0064] It may be inferred that more the information in a data field, the privacy preferences for corresponding data field tends towards stricter privacy level, and lesser the information in a data field, the privacy preferences for that data field tends towards looser (or lenient) privacy level.
The data fields may be defined as:
Field F = {F1, F2, F3, ----------, Fy}
[0065] The system assigns weights to data fields based on the domain and time i.e. the weight if the data field varies from domain to domain and can vary w.r.t. time period.
W(F) = f(domain, time)
[0066] The system 200 utilizes a decision factor which represents a value indicative of amount of exposure of the data field. Decision factor with a relatively higher value is associated with a relatively stricter privacy policy and a decision factor with a relatively lower value is associated with a relatively less stricter privacy policy. The decision factor may be obtained based on a multiplication of information contained in data field Fi and weight W(Fi) of that data field Fi.
Decision Factor (Di)= I(Fi) * W(Fi)
[0067] The decision factor is utilized to determine decision regions which are further used to obtain favorable privacy preferences for said data field. The decision regions are used to identify the privacy preferences, with their priority values, which are assigned to the data fields. The priority value is a function which considers decision regions and recommends a new privacy level for the given sensitive field. The thresholds for decision regions are evaluated using maximum and minimum decision factors as following:
Maximum value of decision factor: Dmax
Minimum value of decision factor: Dmin
Herein, number of decision regions = number of levels of privacy(L)
A step size is used to calculate decision region as outlined in the following formulae
If a Step size ? is considered, then the Step size ? = (Dmax – Dmin)/(L-1)
Decision regions (considering uniform distribution):
Decision region 1: 0 to Dmin+ ?/2
Decision region 2: Dmin+ ?/2 to Dmin+ 3?/2
Decision region 3: Dmin+ 3?/2 to Dmin+ 5?/2
Decision region L: Dmin+ (L - 1/2)? to Dmax
[0068] Moving towards the decision region L from decision region 1, the privacy pol-icy increases to stricter level i.e. Decision region 1 implies 'lenient privacy policy' and Decision region L implies 'Strict privacy policy' and intermediate regions implies gradually increasing privacy from 'no privacy' to 'strict privacy' policy.
[0069] There are L Level of privacy as {L1, L2, L3, -----------, LL}. L1 being the most loose privacy level and LL being the most strict. For each decision region, these levels are given priority values which are then used to suggest the best version of privacy preference selected by the data subject for a data field. It also recommends the favorable privacy levels along with their priority values.
[0070] For the decision region 1, 'no privacy' is suggested. In this decision region, for each privacy level, a value is given suggesting its priority. In this region, L1 (most loose) is having highest priority meaning more data is shared.
priority value of L1 = LL
priority value of L2 = LL – 1
priority value of L3 = LL – 2
priority value of L4 = LL – 3
priority value of Ll = L1
[0071] For the decision region L, 'Strict privacy' is suggested. In this region, Ll (most strict) is having highest priority meaning least data is shared.
priority value of Ll = LL
priority value of LL-1 = LL – 1
priority value of LL-2= Ll – 2
priority value of LL-3= LL – 3
priority value of L1 = L1
[0072] For other decision regions, which lie between 1 and L, let say, decision region “k”. Privacy suggested for this decision region is more than that of decision region 1 and less than that of decision level L. In this region, the priority values are set as given:
priority value of Lk = LL
priority value of Lk-1 = LL – 1
priority value of Lk+1= LL – 2
priority value of Lk-2= LL – 3
priority value of Lk+2= LL – 4 if Lk <= L/2;
and
priority value of Lk = LL
priority value of Lk+1 = LL – 1
priority value of Lk-1= LL – 2
priority value of Lk+2= LL – 3
priority value of Lk-2= LL – 4 if Lk > L/2
[0073] If either L1 or LL is reached while setting the priority values then, the system 200 continues to assign priority from left out levels on the scale. Decision regions for a data field are known from the probability of access of that data field for each purpose. When data subject saves the privacy preferences, the level wise priority values for each region is decided as above and saved in the tree in below format:
'preference of data field for that purpose: priority value of privacy level'
Thus, the format for the string in the node to store a saved value is updated to “3@07:02:17:16:10:58@0:1,3:3”, refer to history node in FIG. 5.
[0074] Tree is traversed to get priority value corresponding to required purpose. Now, to recommend which version is the best for a given data field, privacy lineage tree of the data subject for that data field is traversed. In one implementation, a variable may be initialized to keep track of the best version. While traversing, for the first time, if ith version has maximum priority value (which is equal to total number of privacy levels Ll) then variable = 'i' is re-turned by the system 200.
[0075] If there is no node with priority value Ll , then the version of the node for pri-ority level Ll-1 , if present, is returned and so on. i.e. versions with maximum priority level available in tree is returned.
Following are the decisions taken in critical scenarios:
1. If version with only priority 0 is available, then the preferred privacy level is suggested us-ing priority values for the region.
2. If probability of access of data field is 0, then the privacy preferences for most strict level i.e. Ll is recommended.
Similarly, the best versions for all the fields are found and recommended to the data subject.
[0076] An example scenario of determining recommended privacy levels for various data fields associated with a banking domain is described further. Consider a scenario for bank asking for details of five fields (F1 = Date of birth, F2 = PAN number, F3 = Debit card number, F4 = Debit card expiry date, F5 = Mobile number) to data subjects for a purpose (P1 = To share data with third party)
Let, four privacy levels are Always Allow, Send Notice, Ask Consent, Always Deny and weight of each data field is as given below:
W(F1 = Date of birth) = 1
W(F2 = PAN number) = 2
W(F3 = Debit card number) = 3
W(F4 = Debit card expiry date) = 4
W(F5 = Mobile number) = 1
All of these weights are configurable according to different domain in which system is used.
Let, for a data subject “ABC” with ID 79, probability of access for data fields is given as:
P(F1 = Date of birth) = 32 / 64
P(F2 = PAN number) = 16 / 64
P(F3 = Debit card number) = 8/ 64
P(F4 = Debit card expiry date) = 4 / 64
P(F5 = Mobile number) = 4 / 64

[0077] Information in each data field is given as:
I1 = log2(1 / P(F1)) = log2(2) = 1
I2 = log2(1 / P(F2)) = log2(4) = 2
I3 = log2(1 / P(F3)) = log2(8) = 3
I4 = log2(1 / P(F4)) = log2(16) = 4
I5 = log2(1 / P(F5)) = log2(16) = 4
Then, decision factor (Di) = I(Fi) * W(Fi) is given as:
D1 = I(F1) * W(F1) = 1 * 1 = 1
D2 = I(F2) * W(F2) = 2 * 2 = 4
D3 = I(F3) * W(F3) = 3 * 3 = 9
D4 = I(F4) * W(F4) = 4 * 4 = 16
D5 = I(F5) * W(F5) = 4 * 1 = 4
Decision regions:
Maximum value of decision factor: Dmax = 16
Minimum value of decision factor: Dmin = 1
Number of decision regions = Number of levels of privacy: L = 4
Step size ? = (Dmax – Dmin)/(L-1) = (16 – 1) / 3 = 5
Decision regions:
Decision region 1: 0 to Dmin+ ?/2 = 0 to 3.5 (Most data sharing)
Decision region 2: Dmin+ ?/2 to Dmin+ 3?/2 = 3.5 to 8.5 (Moderate data sharing)
Decision region 3: Dmin+ 3?/2 to Dmin+ 5?/2 = 8.5 to 13.5 (Less data sharing)
Decision region 4: Dmin+ 5?/2 to Dmax = 13.5 to 16 (Least data sharing)
[0078] Case 1: If decision factor, D1, for the field F1 is between 0 to 3.5, which is range of first decision region, then it is safe to say that field F1 has less information and there-fore it is access frequently, Priority values for privacy levels (or preferences) corresponding to the field F1 are given as follows:
Always Allow: priority value = 3
Send Notice: priority value =2
Ask Consent: priority value =1
Always Deny: priority value =0
[0079] Case 2: If decision factor, D1, for the field F1 is between 3.5 to 8.5, which is range of second decision region, then it is safe to say that field F1 has less information and therefore it is accessed frequently but at lesser rate than in case 1. Priority values for privacy levels (or preferences) corresponding to the field F1 are given as follows:
Send Notice: priority value =3
Always Allow: priority value =2
Ask Consent: priority value =1
Always Deny: priority value =0
[0080] Case 3: If decision factor, D1, for the field F1 is between 8.5 to 13.5, which is range of third decision region, then it is safe to say that the field F1 is being accessed less fre-quently i.e. having more information content. Priority values for privacy levels (or prefer-ences) corresponding to the field F1 are given as follows
Ask Consent: priority value =3
Always Deny: priority value =2
Send Notice: priority value =1
Always Allow: priority value =0
[0081] Case 4: If decision factor, D1, for the field F1 is between 13.5 to 16, which is range of fourth decision region, then it is safe to say that the field F1 is being accessed rarely, it contains maximum information. Priority values for privacy levels (or preferences) corre-sponding to the field F1 are given as follows:
Always Deny: priority value =3
Ask Consent: priority value =2
Send Notice: priority value =1
Always Allow: priority value =0
It will be understood that above mentioned priority values are consider for exemplary purpos-es, and these values are configurable according to the application. Now, consider above men-tioned data subject “ABC” has preference history as follows for the five fields, one purpose P1 as:
Mapping of data fields to decision regions using decision factor is given as following:
F1 = Date of birth: Decision region 1
F2 = PAN number: Decision region 2
F3 = Debit card number: Decision region 3
F4 = Debit card expiry date: Decision region 4
F5 = Mobile number: Decision region 2
[0082] Let, data subject ABC's preference history for above mentioned five fields (F1, F2, F3, F4, F5) and one purpose P1 is given as following:
[0083] F1 = Date of birth:
Following are the versions saved by data subject:
Version 1: 1@13:12:16:05:12:03@2:1
Version 2: 2@15:12:16:04:03:54@1:2
Version 3: 3@07:02:17:16:10:58@0:3
Decision region for F1 = Decision region 1
The recommended levels are
Always Allow: priority value =3;
Send Notice: priority value = 2;
Ask Consent: priority value =1;
Always Deny: priority value =0
Here, version 3 is most favorable to data subject in his history since it has the maximum priori-ty value
for field F1.
[0084] F2 = PAN number
Following are the versions saved by data subject:
Version 1: 1@13:12:16:05:12:03@0:2
Version 2: 2@15:12:16:04:03:54@0:2
Version 3: 3@07:02:17:16:10:58@2:1
Decision region for F2 = Decision region 2
The recommended levels are:
Send Notice: priority value =3;
Always Allow: priority value =2;
Ask Consent: priority value =1;
Always Deny: priority value =0
Here, version 1 is most favorable to data subject in his history since it has the maximum priori-ty value for field F2.
[0085] F3 = Debit Card number:
Following are the versions saved by data subject:
Version 1: 1@13:12:16:05:12:03@1:1
Version 2: 2@15:12:16:04:03:54@0:0
Version 3: 3@07:02:17:16:10:58@2:3
Decision region for F3 = Decision region 3
The recommended levels are
Ask Consent: priority value =3;
Always Deny: priority value =2;
Send Notice: priority value =1;
Always Allow: priority value =0;
Here, version 3 is most favorable to data subject in his history since it has the maximum priori-ty value for field F3.
[0086] F4 = Debit card expiry date:
Following are the versions saved by data subject:
Version 1: 1@13:12:16:05:12:03@3:3
Version 2: 2@15:12:16:04:03:54@2:2
Version 3: 3@07:02:17:16:10:58@0:0
Decision region for F4 = Decision region 4
The recommended levels are
Always Deny: priority value =3;
Ask Consent: priority value=2;
Send Notice: priority value =1;
Always Allow: priority value =0
Here, version 1 is most favorable to data subject in his history since it has the maximum priori-ty value for field F4.
[0087] F5 = Mobile number
Following are the versions saved by data subject:
Version 1: 1@13:12:16:05:12:03@1:3
Version 2: 2@15:12:16:04:03:54@3:0
Version 3: 3@07:02:17:16:10:58@0:2
Decision region for F5 = Decision region 2
The recommended levels are
Send Notice: priority value =3;
Always Allow: priority value=2;
Ask Consent: priority value=1;
Always Deny: priority value=0
Here, Version 1 is most favorable to data subject in his history since it has the maximum prior-ity value for field F5.
[0088] Following are the favorable versions of the data fields for data subject ABC:
DOB: Version 3: 3@07:02:17:16:10:58@0:3
PAN: Version 1: 1@13:12:16:05:12:03@0:2
Debit card number: Version 3: 3@07:02:17:16:10:58@2:3
Debit card expiry date: Version 1: 1@13:12:16:05:12:03@3:3
Mobile number: Version 1: 1@13:12:16:05:12:03@1:3
[0089] FIG. 3 illustrates an example representation 300 of arranging access preferences in multiple levels, in accordance with an example embodiment. As discussed previously, the access preferences may be arranged into various privacy levels, where the privacy levels are indicative of an extent of exposure of said field. Referring to FIG. 3, various privacy levels 310 are indicates as always allow at 312, send notice at 314, ask consent at 316 and always deny at 318. Herein, it will be understood that the depicted privacy levels are exemplary. In different applications and domains, more or lesser number of privacy levels may be defined. For example, in one example, said levels of access preferences can be extended to include time and date to suit data subjects’ working/busy and idle hours. Additional or alternative examples of said levels may include Single view, Group view, Public view, and so on. Said levels may be configurable and be altered according to the environment of operation of the system.
[0090] The data subject can set each of the individual data fields to the privacy levels configured in the system 200. FIG. 3 illustrates interpretation of said levels. The privacy level ‘Always allow’ indicates that the organization can always view data subject's data. The privacy level ‘Send Notice’ indicates that the data subject be notified about their data exposure. The privacy level ‘Ask Consent’ indicates that the data subject is asked for an approval every time data subject’s sensitive data is being viewed by organization. The data subject may be required to approve/reject the request for access of said sensitive data. The privacy level ‘Always Deny’ indicates that the data subject's data is not exposed to organization. Said levels helps in determining the extent of data subjects' data exposure. The system allows the data subjects to manage preferences for personal and sensitive data by using a privacy preferences viewer module 222. The privacy preference module facilitates in managing and displaying the privacy preferences and levels set by the data subject, as is described further with reference to FIGS. 4A and 4B.
[0091] FIGS. 4A and 4B illustrate example screenshots of display to view privacy preferences and/or levels in accordance with an example embodiment. Data subject can set their privacy preferences for each of the fields as per above levels using a Privacy Preferences Viewer module. The Privacy Preferences Viewer module allows data subject to manage preferences for personal and sensitive (domain) fields thereof. There are four levels of preferences used by system: 1) Always allow 2) Notice 3) Consent and 4) Always Deny. However, these levels of preferences can be extended to include time and date to suit data subjects’ working/busy and idle hours. The data subjects can switch between different purposes to update the respective privacy preferences. The system allows data subjects to set preferences (allow/notify/consent/deny) and enforce them at run time. For example, referring to screen-shot 410 of FIG. 4A, the data subject has set above-mentioned privacy levels for PII fields (including, for example, PAN number, DOB, email id, address, mobile number) and sensitive fields (debit card number, total balance, debit card expiry date). As is noted the privacy levels presented in FIG. 4A correspond to purpose “To share data with third parties”. Further for a different purpose such as “To improve internal products and services”, the privacy levels are set as shown in a snapshot 420 of FIG. 4B.
[0092] For instance, if an intended user (for example, an employee of an organization) wishes to access the PAN number of the data subject, then the system 200 may prompt the intended user to provide purpose defining the need to access the PAN number of the data subject. The intended user may provide the purpose, for example, “Need to access the PAN number for verifying loan documents of the data subject”. The purpose provided by the intended user can be communicated to the data subject along with the notification, that the intended user is trying access the sensitive data associated with the field “PAN number”. In response to the notification, the data subject may either deny the access request or may allow the access request. In case, the data subject replies with a positive response, the system 200 enable the unmasking of the data associated with the field, thereby allowing the intended user to access the PAN number. In another scenario, for instance in case of a negative response, the system 200 may not allow the intended user to view the PAN number, the system may continue to disable the unmasking of the data associated with the field, thereby restricting the intended user to access the sensitive data. Herein, it will be understood that the system 200 disables the access of all the sensitive data, and may enable access based on the preference defined for respective fields of the sensitive data. In an embodiment, the system 200 may disable the access of the sensitive data by masking the data. For enabling the access, the system 200 may unmask the previously masked data based on the preferences defined for said data. For example, in an example embodiment, where the access preference for a field is defined as “always allow”, the system 200 may unmask said field without user intervention to display the data associated with the field. In case, the access preference for a field is defined as “always deny”, the system 200 may prevent unmasking of said field and may generate a notification to that effect. For example, the system 200 may generate a notification “You are not authorized to view the data”. In an embodiment, where the access preference for a data field is defined as “Generate notification upon access”, the system 200 may allow access to the data field by unmasking the data and simultaneously send a notification along with the contextual information informing the data subject regarding the access to the sensitive data and the contextual information citing the purpose of access.
[0093] In an embodiment, the data subjects are provided recommendations for their privacy preferences by a recommendation module (for example, recommendation module of FIG. 2). The data subject's privacy policy is updated accordingly and data is exposed to organizations as per the preferences set by him. A data masker does the job of hiding the data at organization. Any changes made by data subjects are reflected immediately in privacy policy thereof and the latest setting of preferences decide the exposure of data to organization.
[0094] FIG. 5 illustrates an example of generating privacy lineage tree 500 using privacy lineage data belonging to one or more data subjects, in accordance with an example embodiment. Data subject's privacy preferences history details obtained from the database files, are stored in internal memory of the system for better performance in answering complex queries such as determining evolution of data subject's privacy policy, getting frequency of changes done on a field by data subject, and so on. Examples of such queries are already discussed with reference to FIG. 2. The results for said queries are viewed by using a privacy lineage viewer module (such as privacy preference viewer module 222 of FIG. 2). The data is read for each data subject from files in database and is organized in a privacy lineage tree, such as the privacy lineage tree 500 in the system. The root of said privacy lineage tree (hereinafter, referred to as ‘tree’) is a “Root Node” 502 with each child node holding a single data subject ID. For example, the child nodes 512, 514, 516 are shown to hold data subject IDs 79, 80, 81, respectively. Thus, all the data related to a particular data subject is in the subtree rooted in the node with respective data subject ID, this node is referred as “Data Subject Node” as shown in FIG. 5.
[0095] Each of the data subject node has a child node for each of the sensitive data fields. For example, the data subject node 512 has child nodes 522, 524, 526, 528 for each of the sensitive data fields such as DOB, PAN number, Debit card number, and Expiry date, respectively. Said child nodes are parents of subtrees holding complete history for the fields they represent, they are referred as “Field Nodes”. Each of said Field Nodes has under them, a subtree with nodes having details about privacy preferences history, for the field they represent. For example, the child node 522 is parent of subtree holding complete history for the DOB field. The nodes in field history subtree have id followed by “@”, followed by date and time stamp of previous preferences in string format, again followed by “@”, followed by a comma separated string representing the settings done for various purposes for that field. For example, if a data subject saved a field “DOB” with privacy preference levels “Always Allow”, for any purpose “To improve internal services” and “Always Deny” for another purpose “To share with 3rd party” on 7th Feb, 2017, at 16:10:58, then this would be represented by node having a string “3@07:02:17:16:10:58@0,3” (as shown in FIG. 5), which fully describes the state of data subject's preference for the mentioned field. Here the first substring before @ is ID of the node and 2nd substring which is between @s i.e. “07:02:17:16:10:58” represents time stamp when the privacy preferences were changed and last substring after “@” i.e. 0,3 represents the privacy preferences for purposes in encoded form. This encoding facilitates in saving space required for tree to be stored in system.
[0096] In an example embodiment, there may be few restrictions to generate the said string. For example, the string (new node) is to be generated for every field of the data subject saving preferences, irrespective of whether the field is changed in update or not. Every node is provided an ID which is the first substring before “@” character. Said ID may be generated as total number of nodes in tree + 1. The total number of nodes could in turn be obtained from ID of latest node. Also, the sub string before “@“ may always be the time stamp in “DD:MM:YY:HH:MM:SS” format. In addition, the sub string after “@” may represents the values of privacy levels for all purposes, in encoded format (i.e. 0 – Always Allow, 1 – Send Notice, 2 – Ask Consent, 3 – Always Deny) at the time mentioned in first substring. Said substring may be a comma separated list of values for privacy levels, for various purposes, for the field. The order of privacy preference for purposes in the string, may be same for each field of each of the data subjects. If any new purpose is to be added, then substrings for new nodes may include an additional value in this list for the latest purpose added. This subtree containing these history nodes, are arranged in form of a red black tree, so that the data retrieval is efficient. The nodes in red black tree are compared on the basis of IDs in the node strings for their arrangement. Since the timestamps are long to compare, IDs are provided to the nodes, so that the comparison could be faster and insertion process in the tree could be more efficient. These IDs represent the order in which the nodes are added to the tree. Hence, the node with latest time stamp will be having largest ID and is the rightmost leaf of the field history subtree.
[0097] FIGS. 6A and 6B represent an example evolution of privacy policy of a data subject, in accordance with an example embodiment. Particularly, FIG. 6A illustrates threshold values corresponding to the privacy level scores for various privacy levels. Herein, the privacy levels are indicative of strictness or strength of privacy policy. In the present example, a strength score between threshold scores of 0 to 24 percent may be associated with privacy policy strength of “No privacy”. Similarly, the strength score between threshold scores of 25 to 49 percent may be associated with privacy policy strength of “Loose privacy”. Moreover, the strength score between threshold scores of 50 to 74 percent may be associated with privacy policy strength “Moderate privacy”. Also, the strength score between threshold scores of 75 to 100 percent may be associated with privacy policy strength of “Strict privacy”.
[0098] In an example scenario, for instance in case of a bank, the bank may request (by way of a query) for details of four fields, namely, Date of birth, PAN number, Debit card number, and Debit card expiry date, from data subjects. The query may include two purposes, namely, to share data with third party, and for internal use. In the present example, the weightage of each field and purpose may be considered to be '1', and weight of the privacy levels may be considered as below:
Always Allow = 0
Send Notice = 1
Ask Consent = 2
Always Deny = 3
All of these weights may be configurable according to different domains of operation of system.
[0099] Example access preferences provided by the data subjects may be as follows:

Purpose \ Field Date of birth PAN number Card number Card expiry date
To share data
with third parties AlwaysAllow (0) Send Notice (1) Ask Consent (2) Ask Consent (2)
Internal use Always Deny (3) Always Allow (0) Ask Consent (2) Send Notice (1)

[00100] Strength of data policy for purpose “To share data with third party” is given as:
S1 = [0, 1, 2, 2] * [1, 1, 1, 1]T = 5
Strength of data policy for purpose “For internal use” is given as:
S2 = [3, 0, 2, 1] * [1, 1, 1, 1]T= 6
Total strength is S = S1 * 1 + S2 * 1 = 11
Here Mstrength = (3 * 1 + 3 * 1 + 3 * 1 + 3 * 1) + (3 * 1 + 3 * 1 + 3 * 1 + 3 * 1) = 24;
(S / Mstrength) * 100 = (11 / 24) * 100 = 45.83 %
To observe evolution of privacy policy, consider a data subject “ABC”
[00101] On 16/01/17 - Privacy preferences were as below
Purpose \ Field Date of birth PAN number Card number Card expiry date
To share data
with third parties Always Allow (0) Always Allow (0) Always Allow (0) Always Allow (0)
Internal use Always Allow (0) Always Allow (0) Always Allow (0) Always Allow (0)

Strength of data policy is 4*0 + 4*0 = 0
Normalized Strength of data policy = 0% (No privacy policy)
[00102] On 26/01/17 - Privacy preferences were as below:
Purpose \ Field Date of birth PAN number Card number Card expiry date
To share data
with third parties Always Allow (0) Send Notice (1) Send Notice (1) Send Notice (1)
Internal use Send Notice (1) Send Notice (1) Send Notice (1) Send Notice (1)

Strength of data policy 1*(0) + 7*(1) = 7
Normalized Strength of data policy = 29.16% (Loose privacy policy)
[00103] On 2/02/17 Privacy preferences were as below
Purpose \ Field Date of birth PAN number Card number Card expiry date
To share data
with third parties Always Allow (0) Send Notice (1) Ask Consent (2) Ask Consent (2)
Internal use Ask Consent (2) Ask Consent (2) Ask Consent (2) Ask Consent (2)
Strength of data policy 1*(0) + 1*(1) + 6*(2) =13
Normalized Strength of data policy = 54.16% (Moderate privacy as most of the fields are kept ask consent)
[00104] On 3/02/17 - Privacy preferences were as below
Purpose \ Field Date of birth PAN number Card number Card expiry date
To share data
with third parties Always Allow (0) Send Notice (1) Send Notice (1) Send Notice (1)
Internal use Always Allow (0) Send Notice (1) Send Notice (1) Send Notice (1)
Privacy Strength 2*(0) +6*(1) = 6
Normalized Privacy Strength = 25% (Loose privacy policy)
[00105] On 5/02/17 - Privacy preferences were as below
Purpose \ Field Date of birth PAN number Card number Card expiry date
To share data
with third parties Always Deny (3) Send Notice (1) Ask Consent (2) Always Deny (3)
Internal use Always Deny (3) Always Deny (3) Ask Consent (2) Always Deny (3)
Strength of data policy 0*(0) +1*(1)+2*(2)+5*(3)=20
Normalized Strength of data policy = 83.33% (Strict privacy as most of the fields are kept always deny)
[00106] Based on above privacy policies of data subject, the privacy lineage could be given as illustrated in FIG. 6B.
[00107] FIG. 7 is a flow diagram depicting an example method 700 for managing data privacy, in accordance with an example embodiment. The method 700 depicted in the flow chart may be executed by a system, for example, the system 200 of FIG. 2. In an example embodiment, the system 200 may be embodied in a computing device, for example, the computing device 108 (FIG. 1).
[00108] Operations of the flowchart, and combinations of operation in the flowchart, may be implemented by various means, such as hardware, firmware, processor, circuitry and/or other device associated with execution of software including one or more computer program instructions. For example, one or more of the procedures described in various embodiments may be embodied by computer program instructions. In an example embodiment, the computer program instructions, which embody the procedures, described in various embodiments may be stored by at least one memory device of a system and executed by at least one processor in the system. Any such computer program instructions may be loaded onto a computer or other programmable system (for example, hardware) to produce a machine, such that the resulting computer or other programmable system embody means for implementing the operations specified in the flowchart. It will be noted herein that the operations of the method 700 are described with help of system 200. However, the operations of the method 700 can be described and/or practiced by using any other system.
[00109] At 702, the method 700 includes generating a privacy lineage tree by systematically storing privacy lineage data associated with one or more data subjects. An example of a privacy lineage tree is described with reference to FIG. 5. The privacy lineage data includes a plurality of versions of one or more access preferences modified over a time period. The access preferences includes a plurality of levels of privacy associated with a plurality of data fields of the privacy lineage data associated with the one or more data subjects. Herein, the plurality of levels are indicative of exposure of the plurality of data fields.
[00110] At 704, the method 700 includes generating a model of a privacy policy using the privacy lineage data by traversing the privacy lineage tree, based on one or more of a plurality of privacy parameters. The plurality of privacy parameters includes the purpose of exposure, the at least one data field to be exposed, a level of exposure, an information factor indicative of information contained in the at least one data field and respective weightages of the at least one data field, the respective weightages indicative of sensitivity of the at least one data field. At 706, the method 700 includes defining at least one of, a strength of the privacy policy and recommended privacy levels for the at least one data field, based on the privacy policy. The defining of the strength of the privacy policy is described with reference to FIGS. 6A and 6B. An example of defining strength of privacy policy is further described with reference to FIG. 8. An example of defining recommended privacy levels for the at least one data field is further described with reference to FIG. 9.
[00111] FIG. 8 illustrates a flow chart 800 illustrating a method for managing privacy policy, in accordance with another embodiment of present disclosure. The method 800 depicted in the flow chart may be executed by a system, for example, the system 200 of FIG. 2. In an example embodiment, the system 200 may be embodied in a computing device, for example, the computing device 108 (FIG. 1). As previously described, the privacy lineage data can be utilized for defining strength of privacy policy of data subject.
[00112] At 802, the method 800 is initiated. At 804, the method 800 includes retrieving data subject’s privacy preferences. At 806, the method 800 includes logging privacy preferences with saved time stamp to a non-relational database. At 808, the method 800 includes reading files from the database. The files may include various versions of privacy preferences modified over a period of time. At 810, a preference lineage tree is generated from the files stored in the database. At 812, a lineage query is received, for example from a data subject. At 814, the method 800 includes traversing a subtree corresponding to the data subject’s unique identifier and collecting information. At 816, it is determined whether the query is related to privacy strength. If it is determined at 816 that the query is related to privacy strength, then privacy strength is computed at 818. Further, a query result is built at 820. If however, it is determined at 816 that the query is not related to the privacy strength, a result of the query is built directly at 820. Various such queries not related to the privacy strength may include determination of values for all the fields, for all the purposes on a given date, for a particular data subject; getting latest privacy policy for a single sensitive field, determination of particular version of a specific field, frequency of changes of field over the selected period of time, for single data subject, and so on. At 822, the result obtained in response to the query is displayed via a privacy lineage viewer module, for example, the privacy lineage viewer module 232 of FIG. 2. At 824, it is determined whether another query is to be input. If it is determined, that another query is to be input, then at 812 the query is received, and steps 814-824 are repeated until all the queries are responded. If however it is determined at 824 that no additional query is to be input, the method terminates at 826.FIG. 9 illustrates a flow chart 900 illustrating a method for managing privacy policy, in accordance with another embodiment of present disclosure. The method 900 depicted in the flow chart may be executed by a system, for example, the system 200 of FIG. 2. In an example embodiment, the system 200 may be embodied in a computing device, for example, the computing device 108 (FIG. 1).
[00113] At 902, the method 900 includes determining whether access preferences have been updated for a data subject, If it is determined at 902 that the access preferences have been updated, then data subject’s specific values for data fields are retrieved at 906, and decision factor is computed at 908. Further, decision region for data fields is computed at 910. Based on the decision region, a best version of preference settings (set so far) for data fields is displayed at 912. At 914, favourable privacy levels for data fields are recommended by the system, and the method terminates at 916. If at 904, it is determined that there is no update of preferences for data subject, then the method automatically terminates at 916. It will be noted that in an alternative embodiment, the system may not check for any new update to recommend favourable privacy levels, instead the system may propose recommended privacy levels based on queries from users (such as data subjects and/or employee of an organization).
[00114] FIG. 10 illustrates example architecture 1000 of a scenario for management of privacy policy of a data subject in accordance with an example scenario. The example architecture 1000 is embodied in a privacy policy management system, for example the privacy policy management system 200 (FIG. 2). The privacy policy may define data exposure in an organization. Herein, the data subject may get a full view of privacy lineage data thereof.
[00115] As previously described, the data subjects can set privacy preferences thereof using a privacy settings viewer module, for example the privacy preference viewer module 222 (FIG. 2). The data subjects are provided with recommendations for privacy preferences for various fields from privacy level recommender module, for example the privacy level recommender module 230 (FIG. 2), and they can also view the best preference set by them previously for the data fields, this helps them to set new privacy preferences. These settings done by customers are recorded and a “Data Masker” enforces these privacy levels for various data fields at organization. The data is hidden or exposed to the organization based on the settings done by the customers. These privacy preferences of customers are recorded using a privacy settings recorder module, for example the privacy settings recorder module (FIG. 2). Now, all of the privacy related data is collected in the system and privacy lineage tree is further generated using privacy lineage tree generator module, for example the privacy lineage tree generator module 226. The data related to data subject collected from tree and his privacy strength is calculated for each of his previous settings. This privacy lineage is viewed using privacy lineage viewer module, for example, the privacy lineage viewer module 232.
[00116] The privacy lineage evolution information provides an insight to data subjects about the trends in their privacy preferences. For data subjects, said trends may be helpful to set new privacy preferences after deducing what is the most suitable privacy preference for them in current scenario. Such lineage information may be used by organizations to track the data subject’s privacy preference policies, which can give an insight about how much a cus-tomer has exposed his data over time period. Said information may also help in analyzing data subject’s trust for an organization and even improving it. In an example scenario said infor-mation may be utilized for developing a system to track privacy preference of data subjects and rewarding them for their data shared with organization to improve trust and credibility.
[00117] Various embodiments of the present disclosure provide methods and system for privacy policy management pertaining to sensitive and personal data of data subjects. The disclosed system is capable of keeping track of changes in privacy preferences of data sub-jects, and accordingly captures evolution of an individual's privacy policy. In addition, the system also captures the privacy policy for particular field which may help organizations in analyzing their data subjects' privacy policy evolution and accordingly update their business policies. Along with this, system recommends the privacy levels for data fields, with their pri-ority values, that are favorable for data subjects. An important contribution of the disclosed embodiments is identification of the best version, from among the privacy preferences set till date. Additionally the system is capable of employing storage and retrieval mechanism to get the results from data subjects' huge privacy preferences and their variants.
[00118] The written description describes the subject matter herein to enable any person skilled in the art to make and use the embodiments. The scope of the subject matter embodiments is defined by the claims and may include other modifications that occur to those skilled in the art. Such other modifications are intended to be within the scope of the claims if they have similar elements that do not differ from the literal language of the claims or if they include equivalent elements with insubstantial differences from the literal language of the claims.
[00119] It is, however to be understood that the scope of the protection is extended to such a program and in addition to a computer-readable means having a message therein; such computer-readable storage means contain program-code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device. The hardware device can be any kind of device which can be programmed including e.g. any kind of computer like a server or a personal computer, or the like, or any combination thereof. The device may also include means which could be e.g. hardware means like e.g. an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a combination of hardware and software means, e.g. an ASIC and an FPGA, or at least one microprocessor and at least one memory with software modules located therein. Thus, the means can include both hardware means and software means. The method embodiments described herein could be implemented in hardware and software. The device may also include software means. Alternatively, the embodiments may be implemented on different hardware devices, e.g. using a plurality of CPUs.
[00120] The embodiments herein can comprise hardware and software elements. The embodiments that are implemented in software include but are not limited to, firmware, resident software, microcode, etc. The functions performed by various modules described herein may be implemented in other modules or combinations of other modules. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can comprise, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
[00121] The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk-read only memory (CD-ROM), compact disk-read/write (CD-R/W) and DVD.
[00122] The foregoing description of the specific implementations and embodiments will so fully reveal the general nature of the implementations and embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the embodiments as described herein.