IDENTITY USE SERVER
An identity use server receives, from each of a plurality of identity owner devices i) identification information and ii) identity attributes specifying conditions under which an identity use request corresponding to the identification information shall be determined. Each device is associated with a separate identity owner. The identity use server receives, from one of a plurality of requesting computer systems over the network, each requesting computer system associated with a separate requesting entity, an identity use request. The server determines whether to allow or deny, in whole or in part, the request based on the attributes. The server notifies the requesting computer system of the determination.
The technology disclosed herein (the “present technology”) relates to an identity use server, methods of use of the identity use server, and computer program products of the identity use server.
BACKGROUNDIdentity information can be, and has been, exploited so as to cause an identity owner and other ancillary parties emotional and financial harm. Examples of misuse of identity include fraud. Tens of billions of dollars are lost each year in the United States alone due to identity theft, with estimates rising as of the writing of this application. This does not account for the additional cost of law enforcement efforts to capture and bring perpetrators to justice.
With the increased technical and Internet literacy of our culture, identity theft is no longer limited to instances where financial gain is the sole motive. Indeed, it has now become necessary not only to protect our most precious identification information from use by an unscrupulous stranger, but there must also be in place a system that allows an identity owner to protect his identification information from use by a known party such as a disgruntled employee, for purposes such as access to secured facilities. With the ability and ease that identification information can be used to commit fraud against an identity owner as well as the resulting added burden on courts and law enforcement, there is a need for a system to protect the identity of an entity from misuse at a more fundamental level.
Traditional responses to this problem have been inadequate. The most common response involves monitoring the use of identity resources and notifying a consumer after detection of an unusual use of the identity. For example, a credit card company can detect unusual activity and contact the account holder to determine whether the charges were authorized. While such monitoring mitigates against any continuing misuse of identity, responsive action is generally limited to apportion the burden of the harm between the victimized parties and seek prosecution of the offender. Such methods are thus reactive in that the damage has already been done, and otherwise lack the ability to prevent or undo the ill effects of the damage in the first place.
Some approaches to address these problems highlight a fundamental failing in the art. Some such approaches require the identity owner to either use a “smart instrument” or carry his own scanning device. While prior patents illustrate an attempt to address the issue of protecting and managing identity, the solutions they present lack broader application, practicability and/or simply substitute one flawed mechanism of protection and management for another. This is true in part because an identity owner has no means of proactively controlling use of his identity and identification information with a system designed specifically for such control.
SUMMARYVarious examples of the invention improve security of identification information by giving an individual or other entity increased control over implied or direct use of his identity.
In examples of the technology disclosed herein, methods, computer-readable media, and apparatuses are provided. In some examples, an identity use server receives, from each of a plurality of identity owner devices i) identification information and ii) identity attributes specifying conditions under which an identity use request corresponding to the identification information shall be determined. Each device is associated with a separate identity owner. The identity use server receives, from one of a plurality of requesting computer systems over the network, each requesting computer system associated with a separate requesting entity, an identity use request. The server determines whether to allow or deny, in whole or in part, the request based on the attributes. The server notifies the requesting computer system of the determination.
In some examples, the request is based on an identity use attempt at a source device associated with the requesting computer system. In some such examples, the use attempt is the presentation of a key to provide access to at least one entry of a building. In some such examples, the example further includes tracking the location of the use attempts for the identity over time.
In some examples, the request is based on an identity use attempt of a passport holder to use a passport. In some examples, the request is based on an identity use attempt to access medical information of the identity owner. In some examples, the request includes biometric data collected at the source device.
The details of one or more examples of the disclosure are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the disclosure will be apparent from the description and drawings, and from the claims.
The present technology is further described in the detailed description which follows, in reference to the drawings by way of non-limiting examples of the present technology, in which like numerals represent like elements throughout the several views of the drawings, and wherein
The particulars shown herein are by way of example and for purposes of illustrative discussion of the present technology only and are presented in the cause of providing what is believed to be the most useful and readily understood description of the principles and conceptual aspects of the present technology. In this regard, no attempt is made to show structural details of the present technology in more detail than is necessary for the fundamental understanding of the present technology, the description taken with the drawings making apparent to those skilled in the art how the several forms of the present technology may be embodied in practice.
Referring now to
At some later point in time, an attempt will be made at a source 27 to use the identity of identity owner device 30. The particulars of such attempt will be transmitted to requesting computer system 20 either directly or indirectly through one or more agents 24. Requesting computer system 20 then sends an identity state request 111 to identity use server 10, which requests authorization to complete the underlying transaction. Based on the information in identity state request 111 relative to information previously provided by identity owner device 30, identity use server 10 will determine whether to authorize, limit or deny the requested use. Identity use server 10 sends an appropriate response to requesting computer system 20 in an identity state response 112. Requesting computer system 20 in turn sends appropriate instructions to source 27 either directly or indirectly through one or more agents 24.
In some examples, identity state request 111 preferably includes at least enough information to allow identity use server 10 to locate the account information of the particular identity owner and to determine the corresponding user instructions. However, the information in identity state request 111 is preferably in and of itself insufficient to enable the use of the identity for its intended use, such that its capture or loss would not expose vital information. By way of non-limiting example, if the triggering event is use of a credit card, then the credit card company (requesting computer system 20) sends to identity use server 10 in identity state request 111 the name, address, and phone number of identity owner, as well as the last four digits of the credit card. From this information, identity use server 10 can determine whether use of the credit card is authorized at that time. Yet the information in identity state request 111 is either public (name, address, and phone number being in phone books) and/or useless (four digits of a credit card being insufficient for a transaction). This provides a layer of protection to the use of the identity of an entity that is not confined to identity use server 10.
Referring now to
Identity use server 10 is configured to allow identity owner device 30 to set up, manage, and edit identification information stored in the corresponding account profile 14. Access to the account profile 14 is preferably at least password protected to prevent unauthorized access to the identification information.
The information which identity owner device 30 provides to identity use server 10 reflects the identity of the identity owner to, by way of non-limiting example allow, deny, limit, secure, protect or otherwise control a type of use of the identity of an entity. The nature and scope of the control and management of identity use is essentially unlimited and based only on the parameters as may be defined by requesting computer system 20 and the identity owner via the identity owner device 30. By way of non-limiting example, identity owner could set up account profile 14 as follows:
(1) credit cards can only be used between 9 AM and 11 PM.
(2) medical information is available at all times but only to requesting computer systems 20 that are pre-authorized for health services (e.g., doctors, hospitals, pharmacies).
(3) applications for loans or new credit are never to be approved.
Limitations such as the above establish default and real-time use control over the identity of an identity owner. Attempts to use identity outside the authorized scope will be denied, preventing misuse before it takes place and identifying a possible fraud in progress for law enforcement response. If identity owner needs to use its identity in a manner inconsistent with the above limitations, then identity owner can use identity owner device 30 can modify account profile 14 in advance of such use and then return account profile 14 to its prior state (or any other desired state) after the need for the use concludes. It is also helpful for an identity owner device 30 to be capable of modifying identification information on a whim, creating a real-time, or near real-time system that is fluid and constantly capable of meeting the needs of identity owner while securing the identification information.
Based on use limitations in account profile 14, identity use server 10 will advise requesting computer system 20 as to whether or not the transaction is approved or not in identity state response 112. Preferably, identity state response 112 is similar to identity state request 111 in that the information sent in identity state response 112 is sufficient to communicate the decision of identity use server 10 but insufficient to enable the use of the identity for the intended use. Thus, capture or loss of identity state response 112 would not expose vital information. However, the contents of request 111 and response 112 may or may not overlap to varying degrees.
In certain circumstances, identity state response 112 may include actual identification information. Preferably, such a transfer would be limited to only those identification information attributes 13 that identity owner has allowed for release to that particular requesting computer system 20. In some cases identity state response 112 need only include the resulting identity state (e.g., “allow request” or “deny request”), without transmitting any other identification information of identity owner. The instruction to deny or allow a use under certain conditions is an example of an identity attribute 13. Such instructive identity attribute(s) 13 are referred to herein as the identity state 17 (shown in
Thus, in the above example where identity use server 10 decides to deny a request for use, identity state response 112 sent from identity use server 10 to the requesting computer system 20 includes content identity state 17, which represents the preexisting intent of identity owner device 30 to deny the particular transaction. Requesting computer system 20 preferably complies with the identity state 17 and sends an appropriate denial message to source 27, either directly or through agent(s) 24.
The circumstances under which identity owner elects to deny use of its identity are not limited to avoidance of fraud. Privacy and self-control considerations may also be a factor. For example, an identity owner who wants to maintain confidentiality of his medical records, but wants to preserve quick access in emergencies can set identity attributes 13 in account profile 14 to only approve identity state requests 111 from authorized health-care-related institutions. In another example, an identity owner who spends too much money at a certain store or type of store can set identity attributes 13 in account profile 14 to deny requests from that store or type of store.
Advantages of the present example with respect to the contents of identity state request 111 and identity state response 112 will now be discussed. As discussed above, the substantive contents of these communications is preferably enough to determine and communicate the intent of identity owner with respect to a particular use of identity. Particularly, identification information in identity state request 111 is insufficient in and of itself to facilitate the use intended by source 27, and identity state response 112 need include nothing more than identity state 17. As such, identity use server 10 can perform its function of permitting, limiting or denying transactions without receiving, storing, or sending identification information that enables the underlying use (“use-enabling information”).
Thus, identity use server 10 authorizes or denies requests without having access to sensitive identification information, such as, by way of non-limiting example, a full credit card number or Personal Identification Number (PIN). Identity use server 10 thus does not have enough information to take any action on its own. For example, identity use server 10 would not be able to misuse the credit card of identity owner because it would not have the credit card or the credit number. Thus, while identity use server 10 authorizes transactions, it cannot by acting alone misuse the underlying instruments that trigger the transactions. In theory, identity use server 10 may nonetheless have access to some of this information, although such information can be protected using passwords, encryption, or other known techniques.
Similarly, requesting computer system 20 will preferably know whether to authorize or deny a transaction without receiving any new identification information from identity use server 10 other than identity state 17. Since requesting computer system 20 does not have direct access to other information in account profile 14, requesting computer system 20 does not have information that could enable other undesired uses. By way of non-limiting example, if requesting computer system 20 is a operated by a credit card company, it would not have enough information to access the medical records of identity owner. Without possession of use-enabling information, identity use server 10 obviously cannot or cause requesting computer system 20 to divulge information to agent(s) 24 and/or source 27. The identity owner's identification information account profile 14 therefore need never pass beyond the protection of the identity use server 10.
The identity use server 10 may also be tasked with securing identification information so as to prevent unauthorized access to the identification information. In some examples, the security of identification information afforded by the identity use server 10 is far reaching, dynamic and may contain one or more layers. As a threshold issue, the identity use server 10 would preferably take the barest, directly identifying, raw data of an identity owner, if any, encrypt it and secure it preferably never to be used again.
In other examples, identity use server 10 acts as a centralized location relative to multiple requesting computer systems 20 for the storage of identification information of identity owners. That is, rather than disseminating identification information to every bank, credit agency, insurance company, or any other entity that requests identification information, an identity owner would disclose identification information to the identity use server 10 instead. In this example, these various requesting computer systems 20 would make identity state requests 111 to the identity use server 10, which would determine what, if any, identification information is disclosed to requesting computer systems 20. An example such as this that includes identity use server 10 can, at a minimum, reduce the number of institutions privy to sensitive identification information.
Identity use server 10 preferably is operated by a company that operates the necessary computer hardware and software to secure identification information and to communicate with identity owner devices 30 and requesting computer systems 20. In an alternative example, identity use server 10 is an automated combination of hardware and software that carries out the operations described herein. By way of non-limiting example, an identity owner device 30 can utilize either a computer identity use server 10 that is maintained by an outside party or a computer maintained by the identity owner to prevent unauthorized access to identification information (e.g., a human identity owner may, for the purpose of practicing this example, maintain and/or utilize a personal computer as an identity use server 10). In this example, the identity use server 10 is a computer, preferably a server, accessible to the identity owner device 30 and the requesting computer system 20 through a communication network that is maintained by the computer. The computer in this example would preferably be programmed to provide responses to requesting computer system 20 based on input from the requesting computer system 20 and the identity owner device 30.
Identity owner device 30 is a computer system. Preferably, the identity owner device 30 will contact identity use server 10 and request that the identity use server 10 secure the identity owner's identification information subject to provided constraints. Identity use server 10 might, for example, employ a layered technique where the identity owner's raw identification information, such as social security number or other primary identification data, biometric data, address, phone number(s), and other such information, is encrypted in a separately secure layer. With raw identification information secure in a fundamental layer, the identity use server 10 can then use an additional layer of security for protecting the encrypted identification information from misuse.
Operator of the requesting computer system 20 may be thought of as a credit lender who wants to access the records of repository 11. Requesting computer system 20 may belong to, by way of non-limiting example, a credit card company, credit reporting agency, merchant, banking institution, brokerage firm, insurance provider, hospital, medical caregiver, computer, corporation, or family member. Requesting computer system 20 may also in theory be an imposter. In some examples, the identity use server 10 will implement double-checks and safeguards so as to help protect the identification information from imposters.
Requesting computer system 20 sends identity state requests 111 in response to a triggering event at identity use source 27. Identity use source 27 sends desired transaction-based information, which preferably would include the identity of source 27 and the amount of the transaction (if a financial-based transaction). Identity use server 10 can then respond to requesting computer system 20 with information or instructions that will determine the next step in the transaction precipitated by the triggering identity use source 27. In some examples, the instructions received by requesting computer system 20 will properly control the transaction and provide the result desired by identity owner device 30 and requesting computer system 20.
A non-limiting example of an end-to-end exchange is as follows. For set up, requesting computer system 20, which in this example is a credit card company, will have previously given identity use server 10 an object template 16. Object template 16 defines the identification information that requesting computer system 20 needs in order to process a transaction by source 27. Identity owner device 30 provides identity use server 10 with the corresponding identification information through interface 300, such as a Web page.
At a later point in time, a credit card is offered to complete a transaction at source 27. Source 27 communicates the details of the transaction, as well as any desired details, to requesting computer system 20. Requesting computer system 20 forms an appropriate identity state request 111 and sends it to identity use server 10. Identity use server 10 compares the contents of the identity state request with the identity object(s) 12 which describe the intent of identity owner device 30 with regard to the particular transaction. Identity use server 10 determines whether the transaction is authorized or not, and then sends a corresponding identity state response 112 to requesting computer system 20. In addition, identity use server 10 may release other identification information to requesting computer system 20 as may be authorized by the identity object(s) 12 within account profile 14.
In a related example, object template 16 allows an identity owner device 30 to set the default status of the credit identification instrument (e.g., the credit card or underlying account) as on or off. In this example, identity owner device 30 sets the default of the credit card to “deny,” essentially placing the use of the credit card, in a lockdown state. If identity owner wants to use the credit card at a particular time, then identity owner device 30 can contact identity use server 10 via, e.g., the Internet to change identity state 17 at the appropriate time, such as between 12:30 PM and 2:30 PM that day. Identity owner makes the purchase, or not, secure in the knowledge that use of the credit instrument was permitted within that limited two-hour window. Before the window opens, and after it closes, the default state is “deny,” thus preventing any unauthorized (or even authorized) use outside that window.
Requesting computer system 20 sends identity state request 111 in response to a use of identity at source 27. By way of non-limiting example, source 27 can be initiated by a person, a credit instrument, an Internet transmission, the identity owner device 30, an imposter, requesting computer system 20, or agent 24. In a credit card example, source 27 may be the point-of-sale terminal through which the credit card is scanned.
In some examples, requesting computer system 20 is operated by a lending institution such as a bank, identity owner device 30 is operated by a person, and identity use server 10 is a server of a form of company that preferably would use, by way of non-limiting example, electronic methodology such as a computer server to provide a network through which all parties to the transaction can communicate. By way of non-limiting example, the identity use server 10 could be operated by a corporation or company whose sole purpose is directed to management of identification information; the identity use server 10 could just as well be a operated by a credit reporting agency, insurance agency, health agency, or any established entity that has been enabled to practice the present technology. Also, by way of non-limiting example, the network may take the form of electronic interconnection such as an Internet or intranet Web browser interface, or any wireless or direct interface assisted by a software component such as a client-side application.
In an example, the process may begin when the identity use server 10 sets up an object template 16 (e.g., a template that defines the options for an identity owner device 30 to establish an account profile 14 to contain its identification information). The process may also begin when a requesting computer system 20 (e.g., operated by a credit provider) contacts the identity use server 10 and sets up an object template 16 (e.g., criteria an identity owner must disclose for a particular transaction, or set of transactions, with that particular requesting computer system 20 type). Identity owner (Joe E. Patent) establishes an account profile 14 with an identity use server 10. For simplicity, assume that at the end of the process, the following information exists in the database, or repository 11, of identity use server 10. For example: Account profile 14 data; Account ID: CACTUS; Account password: flowersforalgernon; Name: Joe E. Patent; Address: 102 Brown Street; Primary identification number: 222-22-2222.
Next, the identity owner device 30 protects a credit instrument event. For example, suppose XYZ Corporation provides object template 16 that requires six information fields. Five of the fields are required to “query” the identity state 17 of the identity object 12 (if any), and one field contains the identity state 17 of the identity object 12 last set via the identity owner device 30. For example: Identity object 12 data; Identity object type: XYZPer; Identity object account suffix: 565787; Identity object account name: Joe E. Patent; Identity object account phone: (555) 716-5555; Identity object account zip: 55555; Identity object state: permit.
In the above example, the five data fields can replace the need for use-enabling information, such as, for example, the credit instrument number. However, the information in these fields alone is insufficient to enable the desired use of the identity of identify owner, such that identity use server 10 cannot misuse the identity. The sixth field, “permit”, is necessary to illustrate the role of the identity use server 10 as a gatekeeper so that an attempted use of the identity of identity owner must pass before requesting computer system 20 can follow through on the intended use.
If, for example, a credit instrument of identity owner is misplaced, then it is a simple matter for the identity owner device 30 to contact the identity use server 10 and change identity state 17 of the XYZPer identity object 12 to “deny” until certain that the instrument is not lost. By way of non-limiting example, this can be accomplished by the identity owner using identity owner device 30, accessing interface 300, and making the necessary changes. That layer of security, in addition to the preferred implementation of an outer shell of interface security 200, as shown in
Continuing the example, a thief attempts to use the XYZ instrument at a merchant agent 24. This is an attempted use of identity at source 27, a transaction that implies or directly uses identification information. The merchant communicates the transaction information to requesting computer system 20, in this case the XYZ transaction approval network. XYZ generates an appropriate identity state request 111 and sends it to identity use server 10. An example of the contents of the corresponding identity state request 111 is as follows: <Identity request> <Identity object type>XYZPer<Identity object type/> <Identity object account suffix>565787<Identity object account suffix/> <Identity object account name>Joe E. Patent<Identity object account name/> <Identity object account phone>5555555555<Identity object account phone/> <Identity object account zip>55555<Identity object account zip/> <Identity request/>.
In this example, with the exception of the primary identification data, nothing exists in the account profile 14 that has any security implication. Note that the primary identification data need not be alphanumeric. There may exist examples where it is preferable to include primary identification data that is biometric (fingerprint or retinal image). Once the primary identification data is entered at the time the account profile 14 is created (and indeed, if the data is numeric, it may not be necessary to store the full primary identification number in an implementation of the example), this information is preferably encrypted.
Preferably, the responsibility of sending identity state request 111 to identity use server 10 is allocated to the holder of record for account information related directly to the identity use by source 27. Typically this will be requesting computer system 20 (XYZ in this example) or a representative of requesting computer system 20. Either way, there must be sufficient information to supply data conforming to the identity object template 16 requirements and to positively match the identity objects 12 associated with the identity account profile 14.
An account profile 14 is accessible to the identity owner device 30 either directly with identity use server 10 or indirectly though recorder 38. Through access to the account profile 14, the identity owner device 30 is able to observe, add, delete, and modify its state identity information. Multiple identity objects 12 and/or account profiles 14 may exist for each identity owner.
Requesting computer system 20 establishes the types of identification information to be used in object template 16, but preferably does not have access to account profile(s) 14 that contain the information itself. Object templates 16 can streamline a transaction by providing advance notice to an identity owner device 30 of the specific identification information required by the requesting computer system 20. Furnishing an identity owner device 30 with an object template 16 is preferably accomplished either through one of the recorders 38 of the identity use server 10 or by direct input of the object template 16 into the repository 11.
Referring now to
Identity state 17 is the result of the comparison between identity state request 111 and identity objects 12 input by identity owner device 30. Whenever possible, it is preferable for identity use server 10 to provide identity state 17 while avoiding disclosure of extra identification information of an identity owner. In some examples of the present technology, the identity use server 10 accomplishes this through use of an interpreter 18. On instruction from, for example, requesting computer system 20, recorder 38, identity owner device 30, or a supplier 19 of identity use server 10, interpreter 18 will compare the identity state request 111 and at least one identity object 12 for a particular identity owner device 30. Preferably, interpreter 18 can also compare identity state requests 111 that are formulated based on requirements described by applicable object templates 16, as well as against criteria set by the identity owner device 30.
By way of non-limiting example, if a merchant requesting computer system 20 issues an identity state request 111 for a purchase at 3:00 AM and the corresponding identity owner has not authorized such transactions at that hour, then interpreter 18 transmits the identity state response 112 by informing the requesting computer system 20, either directly or indirectly through supplier 19, that the purchase is “denied.” Identity state 17 may be based on one or more identity objects 12; in this case, the identity object 12 must have contained identity attributes 13 such as “at 3:00 AM”, “off” or a time period that includes 3:00 AM, designated as “off” (e.g., 2:00 AM-4:00 AM).
Interpreter 18 thus evaluates identity state request 111 against the criteria, rules and requirements contained in the state identity object 12 of the identity owner. After evaluation, interpreter 18 preferably communicates the result of the analysis, either directly or indirectly, to requesting computer system 20 without disclosing sensitive identification information. Instead, the identity state response 112 only contains the status of a transaction (in this example, the status is the “identity state” 17) involving identification information. Interpreter 18 and supplier 19 are preferably the entities within identity use server 10 with access to state metadata 15. Interpreter 18 and supplier 19 may be people and/or electronic devices such as computers that implement algorithms designed to assess and interpret an identity state 17 as described herein. Non-limiting examples of potential identity state 17 responses 112 include: permit, deny, not enough information, and permit only for emergency use. By way of non-limiting example, the latter response would exist in an example of the present technology that included identification information that was medical in nature. An identity owner may authorize release of his medical history to known licensed caregivers only in the case of an emergency.
By way of further example, there may be a second object template 16 that defines the requirements for controlling identity relative to acquiring additional credit. In this example, a customer applies for a loan at a federal bank. Here, the customer triggers identity use source 27 (the bank) that initiates the steps described herein. As part of the loan application, the customer represents on the loan application that his primary identification data value is 555-55-5555. As a matter of course, the Federal Bank would contact a credit reporting agency to obtain a credit worthiness report for the loan applicant. The credit reporting agency (a requesting computer system 20) would determine if the loan applicant had an identity account profile 14. The identity use server 10 would have reported the fact that identity owner device 30 had such an account in the normal course of business. After discovering the presence of an identity account profile 14 in the credit information of the loan applicant, the credit reporting agency contacts supplier 19 and requests identity state 17, based on its “new credit” object template 16, for a customer having a primary identification data value of 555-55-5555. Interpreter 18, acting as an agent of identity use server 10 as opposed to the credit reporting agency as requesting computer system 20, determines identity state 17. Once found, the “new credit” object template 16 is compared to the corresponding identity object(s) 12. The interpreter 18 ensures that all fields match.
After noting the account profile number associated with the customer name provided by the bank (Account No. CACTUS), interpreter 18 accesses and confirms that the primary identification data value matches the one in the original identity state request 111. Further examination of identity objects 12 in account profile 14 shows that identity state 17 has been set to “Type—Identity Off”. Since no other identity objects 12 exist for this identity owner device 30 that supersede this identity state 17, interpreter 18 informs supplier 19 that identity state 17 is “deny” and, thus, any use of the identification information of identity owner device 30 should be denied. Supplier sends this identity state 17 to the credit reporting agency in the manner discussed herein. The credit reporting agency communicates this state to the Federal Bank that requested the loan applicant credit report.
At this point the federal bank knows that one of two situations exists. Either the person applying for the loan forgot to change their identity object 12 before applying for the loan, or the person making the application is trying to fraudulently obtain a loan. If the person is the legitimate identity owner, then the error can be corrected. If the person is an impostor, the fraud is revealed.
Using state metadata 15, it is possible to determine the identity attribute information 13 of identity owner device 30. The state metadata 15 represents identity attribute information 13 of identity owner device 30. State metadata 15 alteration by identity owner device 30 permits control over the state metadata 15 and, thus, bestows an identity owner device 30 with control over the use of its identity and identification information.
As seen in
In another example, identity owner device 30 decides to use a credit instrument for a vacation outside the United States, but notes that his account profile 14 prevents use of his identification information outside the United States (“USA Only”). Identity owner device 30 accordingly decides to modify his account profile 14 through a call to recorder 38. Recorder 38 will go through one or more security protocols, such as a password check, date of birth, the last four characters of a primary identification data value, etc. The recorder 38 is satisfied that the caller is identity owner device 30 of identity account profile 14 CACTUS. Identity owner device 30 communicates his intent for use of XYZ credit instrument's transactions to be enabled outside the United States. Identity owner device 30 is then asked to supply the last six digits of the account number and the phone number including the area code associated with this credit instrument account.
Identity use server 10, preferably by using an authorized interpreter 18, examines the existing identity objects 12 to make sure that none of the identity objects 12 already refers to this credit instrument. If no entries exist, recorder 38 inputs an identity object 12 into the repository 11, “Type—Credit Usage—permit globally, instrument type XYZ Corporation, account suffix 565787, phone 5555555555”. This allows usage of the instrument xxxxxx565787 outside the United States. As illustrated in the above example, an identity owner device 30 may record identity attributes 13 and transmit these by mail, courier, electronic transmission or voice to recorder(s) 38 acting on the behalf of identity owner device 30.
Storage, transmission, and disclosure of identity objects 12 are configured to resist compromise of the security of the identification information of the identity owner. The fact that identity attributes 13 are a partial representation of the identity object 12 is significant because it prevents the state metadata 15 from containing information that could jeopardize security of the identity if breached.
Referring to
An example of interface 300 is depicted in
The second area of workspace 303 is the control set 309. Control set 309 is where either identity owner device 30 or recorder 38 (at the behest of the identity owner device 30) can manipulate identity objects 12. By way of non-limiting example, the identity attribute 13 “Parking Space 3R” can be set to “deny Crystal McCity access to location information.” By way of further non-limiting example, this portion of workspace 303 is where identity objects 12 and identity attributes 13, such as “1 transaction per day”, can be added to, for example, identity attribute 13 “bank account withdrawals” to form an identity object 12 that places a limit on the number of transactions for a particular bank account per day.
The bottommost two sections 320, 330 consist of one section that has two distinct portions, and it may have a name such as Recent Activity Monitor or Transaction Notification 330. In this section, it is possible for identity owner device 30 or interpreter 18 (at the behest of identity owner), to monitor use of various identity-related activities such as credit instrument usage, or, as seen in
Another example of the present technology applies to brokerage firms and investors. Identity owner is again an entity, human or otherwise, capable of making investments in securities. Requesting computer system 20 is operated by a brokerage firm. Identity use server 10 maintains its function as an entity that can, but need not, encrypt and store the most fundamental and sensitive data in a separately secure layer. Similar to the steps disclosed above, this example affords preventative security against misuse of any investment account.
Although the above-mentioned examples have been predominantly described in terms of financial transactions, the present technology is not so limited. For example,
Another non-financial use is monitoring of an identifying building access key, key instrument, or any locating device and is not limited to building area entry and exit monitoring. Such use would allow the system to track the location of the occupants of a building based on where they last used their key. This could be lifesaving in an emergency or, on the other hand, help the security or management of a building discern likely suspects after discovery of an unscrupulous act.
Another non-financial use is the protection of data that is medical in nature. Food allergies and diseases such as diabetes are non-limiting examples of such medical information that an identity owner device 30 would not want accessed by anyone other than, for example, a licensed medical professional or licensed medical professional organization. Such systems provide, on a consistent, easily transferable basis, information as might be required as part of standard service industry entity (e.g., dentists, physicians, veterinarians, schools) registration procedures, such information and name, address, and contact information.
In a law enforcement example, identity owner device 30 is operating with the cooperation of or under the control of law enforcement. In this example, certain “zones” may be set up relative to the person's identity. For example, a sex offender may not be able to leave the local jurisdiction, or someone under house arrest cannot leave the home. Flags can be set up in object template 16 or related operations that monitor use of identity and alert law enforcement if the use is for a prescribed activity or in a prescribed area.
It is noted that the foregoing examples have been provided merely for the purpose of explanation and are in no way to be construed as limiting of the present technology. While the present technology has been described with reference to certain examples, it is understood that the words which have been used herein are words of description and illustration, rather than words of limitation. Changes may be made, within the purview of the appended claims, as presently stated and as amended, without departing from the scope and spirit of the present technology in its aspects. Although the present technology has been described herein with reference to particular means, materials and examples, the present technology is not intended to be limited to the particulars disclosed herein; rather, the present technology extends to all functionally equivalent structures, methods and uses, such as are within the scope of the appended claims
Claims
1. A method, comprising:
- in an identity use server: receiving, from each of a plurality of identity owner devices, each device associated with a separate identity owner, i) identification information and ii) identity attributes specifying conditions under which an identity use request corresponding to the identification information shall be determined; receiving, from one of a plurality of requesting computer systems, each requesting computer system associated with a separate requesting entity, an identity use request; determining whether to allow or deny, in whole or in part, the request based on the attributes; and notifying the requesting computer system of the determination.
2. The method of claim 1, wherein the request is based on an identity use attempt at a source device associated with the requesting computer system.
3. The method of claim 2, wherein the use attempt is a presentation of a key at least one source device to provide access to at least one entry of a building.
4. The method of claim 3 further comprising, tracking a location of the use attempts for the identity over time.
5. The method of claim 2, wherein the request is based on an identity use attempt of a passport holder to use a passport.
6. The method of claim 2, wherein the request is based on an identity use attempt to access medical information of the identity owner.
7. The method of claim 2, wherein the request includes biometric data collected at the source device.
8. The method of claim 2, wherein the request is based on an identity use attempt to access account information of the identity owner.
9. An apparatus, comprising:
- memory storing instructions executable by at least one processor; and
- at least one processor coupled to the memory and configured to execute the instructions to: receive, from each of a plurality of identity owner devices, each device associated with a separate identity owner, i) identification information and ii) identity attributes specifying conditions under which an identity use request corresponding to the identification information shall be determined; receive, from one of a plurality of requesting computer systems, each requesting computer system associated with a separate requesting entity, an identity use request; determine whether to allow or deny, in whole or in part, the request based on the attributes; and notify the requesting computer system of the determination.
10. The apparatus of claim 9, wherein the request is based on an identity use attempt at a source device associated with the requesting computer system.
11. The apparatus of claim 10, wherein the use attempt is a presentation of a key at at least one source device to provide access to at least one entry of a building.
12. The apparatus of claim 11, further comprising tracking a location of the use attempts for the identity over time.
13. The apparatus of claim 10, wherein the use attempt is a presentation of a key to at least one source device to provide access to that account.
14. The apparatus of claim 10, wherein the key presented at the source device may be replaced by a non-use-enabling alternate value representing that account.
15. The apparatus of claim 10, wherein the request is based on an identity use attempt of a passport holder to use a passport.
16. The apparatus of claim 10, wherein the request is based on an identity use attempt to access medical information of the identity owner.
17. The apparatus of claim 10, wherein the request includes biometric data collected at the source device.
18. A computer-readable medium storing computer executable code, the code when executed by a processor causes the processor to:
- receive, from each of a plurality of identity owner devices, each device associated with a separate identity owner, i) identification information and ii) identity attributes specifying conditions under which an identity use request corresponding to the identification information shall be determined;
- receive, from one of a plurality of requesting computer systems, each requesting computer system associated with a separate requesting entity, an identity use request;
- determine whether to allow or deny, in whole or in part, the request based on the attributes; and
- notify the requesting computer system of the determination.
19. The computer-readable medium of claim 18, wherein the request is based on an identity use attempt at a source device associated with the requesting computer system.
20. The computer-readable medium of claim 19, wherein the use attempt is a presentation of a key at least one source device to provide access to at least one entry of a building.
21. The computer-readable medium of claim 20, further comprising tracking a location of the use attempts for the identity over time.
22. The computer-readable medium of claim 19, wherein the request is based on an identity use attempt of a passport holder to use a passport.
23. The computer-readable medium of claim 18, wherein the request is based on an identity use attempt to access medical information of the identity owner.
Type: Application
Filed: Mar 12, 2021
Publication Date: Oct 21, 2021
Inventors: Gary M. DENNIS (Indian Springs, AL), Sharon D. DENNIS (Indian Springs, AL)
Application Number: 17/199,943
