This patent claims priority to Indian Patent Application Serial Number 202011056259, which was filed on Dec. 24, 2020, and is hereby incorporated herein by reference in its entirety.
This disclosure relates generally to network transactions, to methods and apparatus for managing and online transactions involving personal data.
With the rapid growth in digitization of services in the recent years, the need for transfer of personal information (e.g., home address, bank account numbers, social security number, etc.) to service providers for transactions via the Internet has increased tremendously. Users of online services often visit service providers (e.g., websites) and input (e.g., by typing on a keyboard) their personal information. Some software tools provide tools for storing user personal information
The figures are not to scale. Instead, the thickness of the layers or regions may be enlarged in the drawings. Although the figures show layers and regions with clean lines and boundaries, some or all of these lines and/or boundaries may be idealized. In reality, the boundaries and/or lines may be unobservable, blended, and/or irregular. In general, the same reference numbers will be used throughout the drawing(s) and accompanying written description to refer to the same or like parts. As used herein, connection references (e.g., attached, coupled, connected, and joined) may include intermediate members between the elements referenced by the connection reference and/or relative movement between those elements unless otherwise indicated. As such, connection references do not necessarily infer that two elements are directly connected and/or in fixed relation to each other. As used herein, stating that any part is in “contact” with another part is defined to mean that there is no intermediate part between the two parts.
Unless specifically stated otherwise, descriptors such as “first,” “second,” “third,” etc. are used herein without imputing or otherwise indicating any meaning of priority, physical order, arrangement in a list, and/or ordering in any way, but are merely used as labels and/or arbitrary names to distinguish elements for ease of understanding the disclosed examples. In some examples, the descriptor “first” may be used to refer to an element in the detailed description, while the same element may be referred to in a claim with a different descriptor such as “second” or “third.” In such instances, it should be understood that such descriptors are used merely for identifying those elements distinctly that might, for example, otherwise share a same name.
When an Internet user visits a service provider website (for at least the first time), they are prompted to enter their personal details (e.g. home address, bank account numbers, social security number, etc.) in exchange for a service. After visiting a few different service provider websites and providing a variety of personal information to each site, the average Internet user begins to lose track of which service providers have received what sensitive information. Being able to identify and keep track of information distribution is important because user personal information could easily be used for fraudulent and/or unwanted activity.
Internet users currently have limited options for verifying the reputation of a service provider before providing personal information, and each service provider has their own version of a lengthy privacy policy written in complicated legal terms that the average Internet user cannot understand. Therefore, when sensitive information is divulged to these service providers, Internet users have little control over how their personal data is handled and for how long the data is retained by each service provider. Internet users often struggle with understanding the terms of a service provider's lengthy privacy policy. In these privacy policies, service providers lay out the details of how they will be handling user personal information and for how long they are entitled to retain a user's sensitive information. Users should be provided the opportunity to fully understand the terms of a service provider's privacy policy before agreeing to it and distributing any personal information to that service provider. However, the complicated and lengthy nature of these service provider privacy policies make it very difficult to do so, resulting in unwanted activity with a user's personal information once it is sent to a service provider.
In addition to carefully reviewing a service provider's privacy policy before sending personal information, it is important for a user to consider the service provider's reputation to ensure that they are trustworthy. If sensitive information is transmitted to an untrustworthy service provider, the user may face fraudulent and/or unwanted activity in relation to their personal data.
Some approaches to prevent malicious, fraudulent, and/or unwanted uses of personal information involve the use of encryption tools to allow for the secure transmission of data from a user to a service provider website. However, this type of secure data transport only refers to the transmission of user information across a secure channel but does not account for the fact that the service provider receiving the data might not be trustworthy. Thus, failure to account for a service provider's ability to misuse a user's personal information may still result in fraudulent and/or unwanted use of data.
Another approach to prevent unwanted uses of user personal information involves using at-risk analysis to determine the locations of vulnerable personal data. However, the ability to simply identify potential weaknesses in data security does not protect a user from unwanted and/or fraudulent uses of personal data. Such an approach of alerting the user to potential vulnerability needs to be paired with an approach to mitigate the concern of fraudulent use(s) of personal information.
Examples disclosed herein include methods and apparatus to manage and protect users' online transactions involving personal data. Examples disclosed herein utilize privacy orchestration techniques such as, for example, encryption, secure data transfer, document object model (DOM) parsing, API management, etc. to manage secure online transactions involving user personal data. As used herein, fraudulent use of data may refer to any unwanted uses of personal information. In some examples, user personal information is encrypted and stored within a database at a privacy orchestration engine. The privacy orchestration engine may interact with a privacy orchestration agent at a client device (e.g., operating within a browser at the client device). In some examples, a reputation score of a service provider is determined by the privacy orchestration engine and/or the privacy orchestration agent using reputation data stored in a service reputation database. The reputation score may be compared with a threshold to determine if the privacy orchestration agent should provide the user personal information to a service provider. If information is presented to a service provider by the privacy orchestration agent, an indication of such presentation is recorded and a list is maintained. Accordingly, at a later time a user may determine that information that the information previously presented is to be revoked.
The example user browser 110 is software executing on a computing device that is operated by a user to access one or more service provider websites 120 (e.g., the first service provider website 121 and/or the second service provider website 122) via the Internet 150. The user browser 110 is in communication with the Internet 150 via a network interface (e.g., an ethernet network Interface, a wireless network interface, etc.).
The example privacy orchestration agent 101 is a browser extension that operates in connection with the example privacy orchestration engine 130 to facilitate collection of user data, input of user data into service provider interfaces, and revocation of user information from service providers. The privacy orchestration agent 101 may be implemented as a standalone application (e.g., executing on the same computing device on which the example user browser 110 executes), a mobile application, and/or any type of plugin, extension, add on, etc.
The example DOM 102 is a software interface that represents a document (e.g., a webpage from a service provider) as a logical tree of nodes corresponding to the objects in a webpage. The DOM 102 facilitates the privacy orchestration agent 101 to parse a webpage and recognize components of the webpage (e.g., input fields, form fields, privacy policy information, etc.).
The example privacy orchestration engine 130 manages the collection, storage, and removal of user information and the distribution of user information to and revocation from the service providers 120. The example privacy orchestration engine is a service hosted with in a cloud coupled to the Internet 150. Alternatively, the privacy orchestration engine may be hosted locally to the user browser 110, may be implemented on a same computing device as the user browser 110, or any or location at which the privacy orchestration agent 101 may communicate with the privacy orchestration engine 130.
The example per service periodic cleaner 131 of
The example engine user notifier 132 of
The example privacy policy interpreter 133 is parses a service provider's 120 privacy policy and returns the parsed privacy policy to the privacy orchestration agent 101 for further analysis. The privacy policy interpreter 133 may be implemented by first tokenizing each line of the input, then scanning the tokens and producing a parsed file to send to the privacy policy analyzer 230 for further analysis. The privacy policy analyzer is described in further detail in conjunction with
The example service reputation checker 134 verifies a service provider's reputation when the privacy orchestration engine 130 receives a request from the privacy orchestration agent 101 for a service reputation check for an indicated service provider 121, 122. The service reputation checker 134 retrieves the compiled reputation details for that service provider from the service reputation database 140, analyzes those details, and returns a reputation score for that service provider 121, 122. In the examples disclosed herein, the analysis of the reputation of a service provider 121, 122 is broken down into categories including range of device permissions, distribution of personal user data to third party advertisers, cross-website tracking of users, etc. Once a score is compiled for each category affecting reputability, the service reputation checker 134 generates a cumulative reputation score based on the category results. That score and the according details for each category of reputability are then sent to a user via the graphical user interface.
The example federated identity linker 135 manages shared information between multiple unrelated sources, allowing for the easy distribution and revocation of user personal data to and/or from service providers 121, 122. The federated identity linker 135 recognizes stored user credentials and applies those credentials, when requested by the user, to a service provider's (e.g., the services providers 121, 122) website if the website is compatible with identity federation. This process allows for the secure distribution of user personal information while eliminating the need for a user to re-enter information across different service provider websites.
The example API orchestrator 136 maintains identification of how the privacy orchestration engine 130 communicates with service provider websites 120. Some service provider websites utilize an API framework to allow for the easy transfer of data between multiple websites, but not all service provider websites use an API. In the examples disclosed herein, the API orchestrator 136 identifies when an API is in use by a service provider website to allow for simple distribution of user personal information, when requested by the user.
The example user data database 137 stores collected user data in a database. Alternatively, the user data database 137 may be any type of datastore such as a file(s), a storage disk, a directory, etc. The example service reputation database 140 stores information about service providers and service provider reputation information in a database. Alternatively, the service reputation database 140 may be any type of datastore such as a file(s), a storage disk, a directory, etc. While the illustrated example, includes a separate user data database 137 and service reputation database 140, the databases may be combined in a single database or datastore.
While the example of
The example agent user notifier 205 informs the user of a service provider's reputation before distributing any personal information via, for example, presenting to the user a simplified version of a service provider's privacy policy. The agent user notifier 205 may provide a notice in the form of a popup, alert, banner, window, etc. on a user's computing device to notify the user of a service provider's reputation.
The example user interface 210 displays to the user the aggregate information regarding which service providers have been presented with (e.g., sent) personal information and/or requests for approval for the transmission of information, warnings about the reputability of a service provider, etc. In the examples disclosed herein, the user interface 210 may be implemented in the form of a dashboard showing the name of each service provider with current access to user personal information, the types of information each service provider has received (e.g., addresses, credit card numbers, emails, etc.), the credibility details of each service provider, and an option to request the revocation of data from any service provider.
The example DOM parser 215 analyzes form field(s) in the service provider websites 120 to determine the types of personal information required by the service providers 120. In the examples disclosed herein, the DOM parser 215 breaks down each element of a form field by traversing an input file and creating an object graph in memory to map each corresponding element of the input file. Once this is one, the DOM parser 215 auto-fills the relevant user personal information in a service provider's 120 website, with approval from the user.
The example context handler 220 is to identify the current context of the user (e.g., state of the user actions including data input, submission, etc.). In some examples, the context handler 220 identifies that the user is now entering their social security information in a form field, determines that the user is on a login page and needs to enter some personal information, concludes if providing certain information to a service provider is mandatory, and/or identifies each individual element of a form field (e.g., email, phone number, credit card, etc. fields).
The example per service personal information tracer 225 records the details of personal information transmission to a service provider including at least when a user grants permission for transmission, which service provider is gaining access to personal information, and/or what information was sent to a service provider. In the examples disclosed herein, the per service personal information tracer 225 records the information that is collected and sent to the per service personal information tracer 225 by the privacy orchestrator 235 from
The example privacy policy analyzer 230 is to receive a parsed privacy policy from the privacy policy interpreter 133 of
The example privacy orchestrator 235 relays data and information between the privacy orchestration agent 101 of
While an example manner of implementing the privacy orchestration agent 101 of
A flowchart representative of example hardware logic, machine readable instructions, hardware implemented state machines, and/or any combination thereof for implementing the privacy orchestration agent 101 of
A flowchart representative of example hardware logic, machine readable instructions, hardware implemented state machines, and/or any combination thereof for implementing the privacy orchestration engine 130 of
The machine readable instructions described herein may be stored in one or more of a compressed format, an encrypted format, a fragmented format, a compiled format, an executable format, a packaged format, etc. Machine readable instructions as described herein may be stored as data or a data structure (e.g., portions of instructions, code, representations of code, etc.) that may be utilized to create, manufacture, and/or produce machine executable instructions. For example, the machine readable instructions may be fragmented and stored on one or more storage devices and/or computing devices (e.g., servers) located at the same or different locations of a network or collection of networks (e.g., in the cloud, in edge devices, etc.). The machine readable instructions may require one or more of installation, modification, adaptation, updating, combining, supplementing, configuring, decryption, decompression, unpacking, distribution, reassignment, compilation, etc. in order to make them directly readable, interpretable, and/or executable by a computing device and/or another machine. For example, the machine readable instructions may be stored in multiple parts, which are individually compressed, encrypted, and stored on separate computing devices, wherein the parts when decrypted, decompressed, and combined form a set of executable instructions that implement one or more functions that may together form a program such as that described herein.
In another example, the machine readable instructions may be stored in a state in which they may be read by processor circuitry, but require addition of a library (e.g., a dynamic link library (DLL)), a software development kit (SDK), an application programming interface (API), etc. in order to execute the instructions on a particular computing device or other device. In another example, the machine readable instructions may need to be configured (e.g., settings stored, data input, network addresses recorded, etc.) before the machine readable instructions and/or the corresponding program(s) can be executed in whole or in part. Thus, machine readable media, as used herein, may include machine readable instructions and/or program(s) regardless of the particular format or state of the machine readable instructions and/or program(s) when stored or otherwise at rest or in transit.
The machine readable instructions described herein can be represented by any past, present, or future instruction language, scripting language, programming language, etc. For example, the machine readable instructions may be represented using any of the following languages: C, C++, Java, C#, Perl, Python, JavaScript, HyperText Markup Language (HTML), Structured Query Language (SQL), Swift, etc.
As mentioned above, the example processes of
“Including” and “comprising” (and all forms and tenses thereof) are used herein to be open ended terms. Thus, whenever a claim employs any form of “include” or “comprise” (e.g., comprises, includes, comprising, including, having, etc.) as a preamble or within a claim recitation of any kind, it is to be understood that additional elements, terms, etc. may be present without falling outside the scope of the corresponding claim or recitation. As used herein, when the phrase “at least” is used as the transition term in, for example, a preamble of a claim, it is open-ended in the same manner as the term “comprising” and “including” are open ended. The term “and/or” when used, for example, in a form such as A, B, and/or C refers to any combination or subset of A, B, C such as (1) A alone, (2) B alone, (3) C alone, (4) A with B, (5) A with C, (6) B with C, and (7) A with B and with C. As used herein in the context of describing structures, components, items, objects and/or things, the phrase “at least one of A and B” is intended to refer to implementations including any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B. Similarly, as used herein in the context of describing structures, components, items, objects and/or things, the phrase “at least one of A or B” is intended to refer to implementations including any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B. As used herein in the context of describing the performance or execution of processes, instructions, actions, activities and/or steps, the phrase “at least one of A and B” is intended to refer to implementations including any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B. Similarly, as used herein in the context of describing the performance or execution of processes, instructions, actions, activities and/or steps, the phrase “at least one of A or B” is intended to refer to implementations including any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B.
As used herein, singular references (e.g., “a”, “an”, “first”, “second”, etc.) do not exclude a plurality. The term “a” or “an” entity, as used herein, refers to one or more of that entity. The terms “a” (or “an”), “one or more”, and “at least one” can be used interchangeably herein. Furthermore, although individually listed, a plurality of means, elements or method actions may be implemented by, e.g., a single unit or processor. Additionally, although individual features may be included in different examples or claims, these may possibly be combined, and the inclusion in different examples or claims does not imply that a combination of features is not feasible and/or advantageous.
As illustrated in
At block 310, the example context handler 220 identifies a request for personal information requested by the service provider(s) 120. For example, the context handler 220 may detect a form field of a webpage that requests user personal information such as (e.g., username, name, address, etc.).
At block 315, the privacy orchestrator 235 sends a request for a service reputation check to the service reputation checker 134 of
At block 320, the privacy orchestrator 235 analyzes whether the service provider's reputation meets and/or is above a threshold for reputability. In examples disclosed herein, the threshold for reputability is preset by the privacy orchestration engine 130 of
If the service providers reputation does not meet the threshold (block 320), the agent user notifier 205 warns the user (block 325). In examples disclosed herein, the user is warned of an inadequate reputation via the user interface 210. The agent user notifier 205 determines if a user wishes to proceed with sharing their sensitive information despite the warning (e.g., the user provides an input asking to proceed) (block 330). If the user does not wish to proceed, control returns to block 305, and no personal information will be sent to the service provider.
In the event the user wishes to proceed with providing their personal information to the service provider despite the warning (e.g., yes at block 330) or the reputation met the threshold for reputability (e.g., yes at block 320), control moves to block 335.
At block 335, the privacy policy analyzer 230 gathers a service provider's privacy policy from their website, sends the full privacy policy to the privacy policy interpreter 133 of
At block 340, the agent user notifier 205 presents a request for approval to send personal information to the indicated service provider. In examples disclosed herein, this request for approval is presented to the user via the user interface 210.
At block 345, the user interface 210 determines whether the user has granted approval for the transmission of personal data to the service provider. In the event that approval is granted via the user interface 210 (e.g., the control of block 345 returns a result of YES), the process moves on to block 347.
Alternatively, in the event the user interface 210 determines that approval is not granted via the user interface 210 (e.g., the control of block 345 returns a result of NO), the process returns to block 310.
At block 347, the context handler 220 determines the personal information to be sent to the service provider 120 in exchange for a service (e.g., the information required and/or requested by the service provider 120 in exchange for providing a service).
At block 350, the privacy orchestrator 235 determines whether all of the required information has already been stored in the user data database 137 of
Alternatively, in the event that the privacy orchestrator 235 determines that all of the information required by the service provider is not stored (e.g., the control of block 350 returns a result of NO), the process moves on to block 355.
At block 355, the user interface 210 prompts the user to enter the required data that has not already been collected and stored. The user interface 210 may additionally display the previously stored information to allow the user to edit the existing information.
The collected information is transmitted to the user data database 137 by the privacy orchestrator 235 for storage in the user data database 137 of the privacy orchestration engine 130 (block 360).
After the needed information is collected and stored (block 360) or if the required information was already stored (block 350), the DOM parser 215 analyzes the form field(s) of the service provider's website to determine what type (e.g., a user name field, a password field, an address field, etc.) of information each portion of the form is requesting.
The DOM parser 215 auto-fills each portion of the form field with user personal information (Block 370).
At block 375, the privacy orchestrator 235 informs the per service periodic cleaner 131 of
As
At block 420, the privacy orchestration engine 130 of
Alternatively, in the event that the privacy orchestration engine 130 determines that the user did not initiate a request for the revocation of personal information from a service provider (e.g., the control of block 420 returns a result of NO), the process moves on to block 430.
At block 430, the user notifier sends a reminder to the user to request the revocation of personal information from a service provider. In examples disclosed herein, the reminder to the user to prompt revocation of personal information is sent via the engine user notifier 132 of
Responsive to the execution of the instructions represented in block 430, the per service periodic cleaner 131 of
Alternatively, in the event that the per service periodic cleaner 131 of
At block 450, the per service periodic cleaner 131 revokes a service provider's access to a user's personal information, and the process stops.
As illustrated in
At block 520, the engine user notifier 132 determines whether the user wishes to revoke a service provider's access to personal information. In the event that the engine user notifier 132 determines that the user does wish to revoke a service provider's access to their personal information (e.g., the control of block 520 returns a result of YES), the process moves on to block 530.
Alternatively, in the event that the engine user notifier 132 determines that the user does not wish to revoke a service provider's access to their personal information (e.g., the control of block 520 returns a result of NO), the process returns to block 510.
At block 530, the per service periodic cleaner 131 revokes a service provider's access to a user's personal information. The process is then stopped.
As illustrated in
Subsection 610 begins at block 611, where the user data database 137 encrypts the user personal data that was received.
Responsive to the instructions executed in block 611, at block 612, the user data database 137 stores the encrypted version of the user personal information. Process 600 is then stopped.
Subsection 620 begins at block 621, where the service reputation checker 134 receives a request for a service reputation check for a service provider. In the example disclosed herein, the request for a service reputation check is sent to the service reputation checker 134 by the privacy orchestration agent 101 of
At block 622, the service reputation checker 134 retrieves a service provider's reputation details. In the example disclosed herein, the service reputation checker 134 retrieves the reputability information from the service reputation database 140 of
At block 623, the service reputation checker 134 analyzes the retrieved service reputation data and compiles an overall reputation score for the service provider.
Responsive to the instructions executed in block 623, at block 624, the user notifier 132 sends the reputability details and overall reputation score of the service provider to the user. In the example disclosed herein, the reputation details and score are presented to the user via a user interface (e.g., a graphical user interface). Process 600 is then stopped.
Subsection 630 begins at block 631, where the privacy policy interpreter 133 receives a request for a service provider's policy interpretation, along with the full privacy policy of the service provider. In the example disclosed herein, the privacy policy interpreter 133 receives both the request for interpretation and the full privacy policy of the service provider from the privacy orchestration agent 101 of
At block 632, the privacy policy interpreter 133 parses the full privacy policy of the service provider by reading in a data stream from the provided text and producing a memory model of the conceptual content of the text.
Responsive to the instructions executed at block 632, the privacy policy interpreter 133 sends the parsed privacy policy of the service provider to the privacy orchestration agent 101 be analyzed and broken down into actionable items to present to the user (Block 633). In the example disclosed herein, the parsed privacy policy of the service provider is sent to the privacy policy analyzer 230 of
Subsection 637 begins at block 640, wherein the privacy orchestration engine 130 receives a request for the transmittal of user personal information to a service provider. In the examples disclosed herein, this request is sent to the privacy orchestration engine 130 by the privacy orchestrator 235 of
At block 645, the API orchestrator 136 assesses the framework of the service provider website to determine whether an API is in use. In the event that the API orchestrator 136 determines that an API is in use by the service provider website (e.g., the control of block 645 returns a result of YES), the process moves on to block 655.
Alternatively, in the event that the API orchestrator 136 determines that an API is not in use by the service provider website (e.g., the control of block 645 returns a result of NO), the process moves onto block 650.
At block 650, the API orchestrator 136 notifies the privacy orchestration agent 101 that an API is not in use by the service provider.
At block 655, the federated identity linker 135 uses shared authentication to link information across multiple different service provider websites to allow for the secure transmission of data to another service provider website without user entry.
At block 660, the per service periodic cleaner 131 adds the user personal information (e.g., sent by the per service personal information racer 225) to the comprehensive list of service providers with access to user personal information. Process 635 is then stopped.
Subsection 662 begins at block 665, where the per service periodic cleaner 131 of
At block 670, the per service periodic cleaner 131 of
Responsive to the instructions executed at block 670, the per service periodic cleaner 131 updates the internal list of service providers with access to user personal information. Process 635 is then stopped.
The processor platform 700 of the illustrated example includes a processor 712. The processor 712 of the illustrated example is hardware. For example, the processor 712 can be implemented by one or more integrated circuits, logic circuits, microprocessors, GPUs, DSPs, or controllers from any desired family or manufacturer. The hardware processor may be a semiconductor based (e.g., silicon based) device. In this example, the processor 712 implements the user notifier 205, the user interface 210, the DOM parser 215, the context handler 220, the per service personal information tracer 225, the privacy policy analyzer 230, and the privacy orchestrator 235.
The processor 712 of the illustrated example includes a local memory 713 (e.g., a cache). The processor 712 of the illustrated example is in communication with a main memory including a volatile memory 714 and a non-volatile memory 716 via a bus 718. The volatile memory 714 may be implemented by Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUS® Dynamic Random Access Memory (RDRAM®) and/or any other type of random access memory device. The non-volatile memory 716 may be implemented by flash memory and/or any other desired type of memory device. Access to the main memory 714, 716 is controlled by a memory controller.
The processor platform 700 of the illustrated example also includes an interface circuit 720. The interface circuit 720 may be implemented by any type of interface standard, such as an Ethernet interface, a universal serial bus (USB), a Bluetooth® interface, a near field communication (NFC) interface, and/or a PCI express interface.
In the illustrated example, one or more input devices 722 are connected to the interface circuit 720. The input device(s) 722 permit(s) a user to enter data and/or commands into the processor 712. The input device(s) can be implemented by, for example, an audio sensor, a microphone, a camera (still or video), a keyboard ,a button, a mouse, a touchscreen, a track-pad, a trackball, isopoint, and/or a voice recognition system.
One or more output devices 724 are also connected to the interface circuit 720 of the illustrated example. The output devices 724 can be implemented, for example, by display devices (e.g., a light emitting diode (LED), an organic light emitting diode (OLED), a liquid crystal display (LCD), a cathode ray tube display (CRT), an in-place switching (IPS) display, a touchscreen, etc.), a tactile output device, a printer and/or speaker. The interface circuit 720 of the illustrated example, thus, typically includes a graphics driver card, a graphics driver chip and/or a graphics driver processor.
The interface circuit 720 of the illustrated example also includes a communication device such as a transmitter, a receiver, a transceiver, a modem, a residential gateway, a wireless access point, and/or a network interface to facilitate exchange of data with external machines (e.g., computing devices of any kind) via a network 726. The communication can be via, for example, an Ethernet connection, a digital subscriber line (DSL) connection, a telephone line connection, a coaxial cable system, a satellite system, a line-of-site wireless system, a cellular telephone system, etc.
The processor platform 700 of the illustrated example also includes one or more mass storage devices 728 for storing software and/or data. Example of such mass storage devices 728 include floppy disk drives, hard drive disks, compact disk drives, Blu-ray disk drives, redundant array of independent disks (RAID) systems, and digital versatile disk (DVD) drives.
The machine executable instructions 732 of
The processor platform 800 of the illustrated example includes a processor 812. The processor 812 of the illustrated example is hardware. For example, the processor 812 can be implemented by one or more integrated circuits, logic circuits, microprocessors, GPUs, DSPs, or controllers from any desired family or manufacturer. The hardware processor may be a semiconductor based (e.g., silicon based) device. In this example, the processor 812 implements the per service periodic cleaner 131, the engine user notifier 132, the privacy policy interpreter 133, the service reputation checker 134, the federated identity linker 135, and the API orchestrator 136.
The processor 812 of the illustrated example includes a local memory 813 (e.g., a cache). The processor 812 of the illustrated example is in communication with a main memory including a volatile memory 814 and a non-volatile memory 816 via a bus 818. The volatile memory 814 may be implemented by Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUS® Dynamic Random Access Memory (RDRAM®) and/or any other type of random access memory device. The non-volatile memory 816 may be implemented by flash memory and/or any other desired type of memory device. Access to the main memory 814, 816 is controlled by a memory controller.
The processor platform 800 of the illustrated example also includes an interface circuit 820. The interface circuit 820 may be implemented by any type of interface standard, such as an Ethernet interface, a universal serial bus (USB), a Bluetooth® interface, a near field communication (NFC) interface, and/or a PCI express interface.
In the illustrated example, one or more input devices 822 are connected to the interface circuit 820. The input device(s) 822 permit(s) a user to enter data and/or commands into the processor 812. The input device(s) can be implemented by, for example, an audio sensor, a microphone, a camera (still or video), a keyboard ,a button, a mouse, a touchscreen, a track-pad, a trackball, isopoint, and/or a voice recognition system.
One or more output devices 824 are also connected to the interface circuit 820 of the illustrated example. The output devices 824 can be implemented, for example, by display devices (e.g., a light emitting diode (LED), an organic light emitting diode (OLED), a liquid crystal display (LCD), a cathode ray tube display (CRT), an in-place switching (IPS) display, a touchscreen, etc.), a tactile output device, a printer and/or speaker. The interface circuit 820 of the illustrated example, thus, typically includes a graphics driver card, a graphics driver chip, and/or a graphics driver processor.
The interface circuit 820 of the illustrated example also includes a communication device such as a transmitter, a receiver, a transceiver, a modem, a residential gateway, a wireless access point, and/or a network interface to facilitate exchange of data with external machines (e.g., computing devices of any kind) via a network 826. The communication can be via, for example, an Ethernet connection, a digital subscriber line (DSL) connection, a telephone line connection, a coaxial cable system, a satellite system, a line-of-site wireless system, a cellular telephone system, etc.
The processor platform 800 of the illustrate example also includes one or more mass storage devices 828 for storing software and/or data. Example of such mass storage devices 828 include floppy disk drives, hard drive disks, compact disk drives, Blu-ray disk drives, redundant array of independent disks (RAID) systems, and digital versatile disk (DVD) drives. The example mass storage device 828 includes the user data database 137 and the service reputation database 140.
The machine executable instructions 832 of
A block diagram illustrated an example software distribution platform 905 to distribute software such as the example readable instructions 732 of
A block diagram illustrated an example software distribution platform 1005 to distribute software such as the example readable instructions 832 of
From the foregoing, it will be appreciated that example methods, apparatus, and articles of manufacture have been disclosed that improve the management and protection of data transactions between a user and multiple service provider(s) by providing a single interface containing information about at least user data distribution, data security, and/or service provider reputation, giving users the ability to revoke data from any service provider at any time, allowing for single data entry across multiple service provider websites, and/or prescreening all service providers to ensure data security.
Although certain example methods, apparatus, and articles of manufacture have been disclosed herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all methods, apparatus, and articles of manufacture fairly falling within the scope of the claims of this patent.
The following claims are hereby incorporated into this Detailed Description by this reference, with each claim standing on its own as a separate embodiment of the present disclosure.
Number | Date | Country | Kind |
---|---|---|---|
202011056259 | Dec 2020 | IN | national |