US20130179988A1 - Secure Profile System And Method - Google Patents

Abstract

A computer implemented method for a secure profile system for an identity management system having: on a computer device having one or more processors and a memory storing one or more programs for execution by the one or more processors, the one or more programs including instructions for: defining a structure; storing data associated with a profile, where the profile contains an object; securely granting access to the profile and a subject; configuring an audit log to provide an account of an access to data housed within the profile; implementing a security-related algorithm and protocol; exchanging data between two or more subjects; and providing secured, externalized content. Also, a computer system and non-transitory computer-readable storage medium adapted for the same.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• This application claims the benefit of, and priority to, U.S. Provisional Patent Application Ser. No. 61/584,745, filed on Jan. 9, 2012, entitled “IDENTITY MANAGEMENT SYSTEM AND METHOD,” the entire disclosure of which is hereby incorporated herein by reference.
TECHNICAL FIELD
• An identity management system and method is provided. More specifically, an identity management system and method is provided comprising aspects of identity management including but not limited to identity theft protection.
BRIEF SUMMARY
• In one embodiment, an identity management system and method is provided that uses human knowledge and experience and computer software programs and databases to anticipate forms of identity-related fraud. The identity management system facilitates the provision of affordable and effective products and services that help protect a customer's identity, on multiple fronts, on an ongoing basis. (The term “customer” can include a person, a group of people, a family, an organization, a corporation or any potential person or entity requiring identity management services.) The identity management system provides protection services that extend well beyond credit monitoring to address the entire spectrum of identity fraud sources including online hacking, mail fraud, credit cards, checks, public records, memberships and several others.
• The identity management system monitors activity associated with a customer's identity and makes available to the customer a set of reports and alerts about activity that can indicate identity theft or misrepresentation. In performing and displaying an identity theft protection service, the identity management system securely reviews and stores at least one or more of the following Protected Identity Elements: individual name(s), street address(es), e-mail address(es), telephone number(s), Social Security Number(s) and bank account or credit card number(s).
• The identity management system employs Internet Monitoring, which searches certain data and records available on the Internet to identify any known risks involving the customer's Protected Identity Elements. The identity management system can include Credit Monitoring, which provides credit report monitoring using one or more bureaus and monitors “pay day” loans. The identity management system can include Public Records Monitoring, which monitors U.S. Postal Service (USPS) Changes of Address, Court Records, and Sex Offender Registries. The identity management system can include Name and Address Monitoring, which monitors a Customized Name, an Alias List and Customized Known Address List.
• The service sends immediate email notifications when a change is reported on any of the monitors to which the customer subscribes. In addition, if the customer has no changes during the month, the identity management system can be adapted to send a courtesy email reminding the customer that the service is still active on behalf of the customer and pointing the customer to educational information about Identity Theft prevention and trends.
• The identity management system performs its functions without a need for access to a customer's credit information. The customer is sent updates when there are changes in credit information but the identity management system will not be notified of the nature of such changes.
• The identity management system permits customers to report any activity that is of concern through an Internet-based reporting system or by calling a Resolution Specialist via telephone.
• To facilitate understanding of the identity theft protection system in its full context, the present specification includes the following:
• • I. Identity Management System Architecture
  • II. Glossary of Terms
• The identity management system can comprise one or more of the following subsystems:
• • III. Core Gateway (CGW)
  • IV. Data Processing Engine (DPE)
  • V. Subscriber Database (SDB)
  • VI. Secure Profile
  • VII. Secure Port Secure Sockets Layer (SSL)
  • VIII. URL Matcher
  • IX. Breach Solutions
  • X. Identity Alert Management (Interaction with Client Alert to Resolution Specialist)
  • XI. Provisional Subscriber System (PSS)
• In some embodiments, an identity management system is provided comprising: a core gateway system, wherein the core gateway is configured to provide support for special offer codes and source codes that enable special pricing or promotional discounts, offer promotional trial periods on certain products, or identify a marketing channel used to attract the customer.
• In some embodiments, an identity management system is provided comprising: a core gateway including: a self-service system; a core function system; a content and skinning; a product and catalog system; a partner integration system; a central manager; and an affiliate management system, wherein the core gateway is configured to provide support for special offer codes and source codes that enable special pricing or promotional discounts, offer promotional trial periods on certain products, or identify a marketing channel used to attract the customer.
• In some embodiments, an identity management system is provided comprising: An identity management system comprising: a core gateway; a data processing engine; and a subscriber database.
• In some embodiments, an identity management system is provided comprising a secure profile system. In some embodiments an identity management system is provided comprising a system for binding multiple SSL certificates to a single Microsoft IIS site.
• In some embodiments an identity management system is provided comprising a URL matcher to support vanity URLs on the core gateway.
• In some embodiments an identity management system is provided comprising a breach prevention system.
• In some embodiments an identity management system is provided comprising an identity alert management system for interaction between a customer and a resolution specialist.
• In another aspect, a core gateway system is provided comprising: a customer tools system; a self-service system; a core function system; a content and skinning system; a product and catalog system; a partner integration system; a central manager; and an affiliate management system.
• In a further aspect, a data processing engine is provided comprising: a file retrieval system; a file parsing and staging system; a business rule processing system; and a record extract, transform and load system linked to the subscriber database.
• In some embodiments, a data processing engine is provided comprising: a first server; a file retrieval system connected to the first server; a second server connected to the file retrieval system; a file extract, transform and load system connected to the second server; a staging data system connected to the file extract, transform and load system; a business rule processing system connected to the staging data system; and a system for importing records that pass through the business rule processing system into the subscriber database.
• In another aspect a breach solutions system is provided comprising the breach prevention system comprising: an assist module; and a prepare module. In some embodiments, the assist module comprises: a self-assessment system; and a score system. The self-assessment system can comprise a series of questions pertaining to policies and procedures based on customer's industry and the personally identifiable information collected by the customer. In some embodiments the score system comprises: a system for assigning weights for each of the questions; a system for calculating a risk score based on the weights for each of the questions and the answers provided by the customer; and a system for assigning the calculated risk score to a tiered scoring system. The prepare module can comprise: a customer assist system; a system for identifying a data breach victim's contact information and data transfer protocol; a system for notifying breach victims or others of the subject data breach by a communication means that conforms with laws applicable to the customer's jurisdiction; a system for providing recommendations of notification based on current state and federal incident response regulations; a system for providing assistance with notification messaging and customer call center scripting; a system for managing the breach response; a system for providing breach victims customer-sponsored access to a heightened level of service; and a defined system for notification of costs.
• In a further aspect, a method of identity alert management for interaction between a customer and a resolution specialist is provided, comprising the steps of: identifying personally identifiable information against elements of a customer's identity; automatically sending a communication to the customer within a specified time period; authenticating the customer through a secure identity management dashboard; permitting the customer to review a source of an identity alert and details associated with the alert; prompting the customer to mark the alert as a threat or not a threat; sending a record of the threat to an approved records system if the customer marks the alert as not a threat; creating a case if the customer marks the alert as a threat; permitting the user to execute a power of attorney prior to, during or after the threat has been detected; ascertaining whether the customer has executed the power of attorney; providing a first response system for customers that have executed the power of attorney; providing a second response system for customers that have not executed the power of attorney; and permitting the customer or the resolution specialist to reopen a previously approved record.
BRIEF DESCRIPTION OF THE DRAWINGS
• The accompanying drawings, which are incorporated into this specification, illustrate one or more exemplary embodiments of the inventions disclosed herein and, together with the detailed description, serve to explain the principles and exemplary implementations of these inventions. One of skill in the art will understand that the drawings are illustrative only, and that what is depicted therein can be adapted based on the text of the specification and the spirit and scope of the teachings herein.
• In the drawings, where like reference numerals refer to like reference in the specification:
• FIG. 1 illustrates one example of the architecture of an identity management system according to some embodiments of the present disclosure, whereFIG. 1.A is the left side of the figure and whereFIG. 1.B is the right side of the figure;
• FIG. 2 shows one example of a Data Processing Engine (DPE) of an identity management system according to some embodiments of the present disclosure, whereFIG. 2.A is the left side of the figure and whereFIG. 2.B is the right side of the figure;
• FIG. 3 illustrates one example of meta data associated with a DPE feed;
• FIG. 4 illustrates one example of entities used for file processing for DPE according to some embodiments of the present disclosure, whereFIG. 4A is the top portion of the figure, and whereFIG. 4B is the bottom portion of the figure;
• FIG. 5 illustrates one example of an SDB Schema of an identity management system according to some embodiments of the present disclosure, whereFIG. 5.A is the top portion of the figure, and whereFIG. 5.B is the bottom portion of the figure;
• FIG. 6.A depicts one example of the overall system design of a Secure Profile system of an identity management system according to some embodiments of the present disclosure;
• FIG. 6.B shows Primary Entity Definitions for one example of the Secure Profile system according to some embodiments of the present disclosure;
• FIG. 6.C illustrates one example of Applied Encryption for the Secure Profile system of an identity management system according to some embodiments of the present disclosure;
• FIGS. 7.A,7.B and7.C are screenshots illustrating various aspects of a Security Assist Assessment of an identity management system according to some embodiments of the present disclosure;
• FIG. 7.D illustrates one example of a Data Diagram for Score Calculation using the Security Assist system according to some embodiments;
• FIG. 7.E shows one example of a Data Diagram for Action Plan Associations using the Security Assist system according to some embodiments;
• FIG. 8 is an overview illustrating an example of User Flow of Fraud Solution process according to the Identity Alert Management system of some embodiments of the present disclosure, whereFIGS. 8.A,8.B,8.C,8.D and8.E are various expanded views ofFIG. 8;
• FIG. 9.A shows one example of a potential threat email notification according to some embodiments of the Identity Alert Management system;
• FIG. 9.B is one example of a dashboard including an alert according to some embodiments of the Identity Alert Management system;
• FIG. 9.C illustrates one example of a screenshot including a review of a new potential threat according to some embodiments of the Identity Alert Management system;
• FIG. 9.D shows one example of a popup window where a potential threat is marked as approved according to some embodiments of the Identity Alert Management system;
• FIG. 9.E illustrates one example of a popup window where a potential threat is marked as an actual threat according to some embodiments of the Identity Alert Management system;
• FIG. 9.F is one example of a screenshot indicating that a case has been created in the Identity Alert Management system according to some embodiments;
• FIG. 9.G shows one example of a screenshot that can appear when the customer has signed a power of attorney according to some embodiments of the Identity Alert Management system;
• FIG. 9.H illustrates one example of a screenshot that can appear when the customer has not signed a power of attorney according to some embodiments of the Identity Alert Management system;
• FIG. 9.I shows one example of a screenshot that can appear prompting the user to close a case or keep the case active according to some embodiments of the Identity Alert Management system;
• FIG. 9.J illustrates one example of a screenshot that can appear showing verified records according to some embodiments of the Identity Alert Management system;
• FIG. 9.K illustrates an example of a popup window that can appear prompting a user to confirm reopening of a threat.
• FIG. 10 illustrates one example of basic web interaction between client and server hosts;
• FIG. 11 illustrates one example of virtual hosting and HTTPS complications associated with the same;
• FIG. 12 illustrates one example of request filtering and a SecurePort module;
• FIG. 13 is a symbol key forFIGS. 10-12;
• FIG. 14 is a flow chart illustrating one example of a URL matcher request processing system and method;
• FIG. 15 illustrates two examples of implementation in ASP.NET utilizing an HTTP module or an HTTP handler;
• FIG. 16 illustrates a sample configuration of Rules that can be used in the URL matcher request processing system and method;
• FIG. 17 shows an example of a generic screenshot for the provisional subscriber system (PSS1) according to some embodiments of the present invention;
• FIG. 18 shows an example of a Partner-specific screenshot for the provisional subscriber system (PSS2) according to some embodiments of the present invention;
• FIG. 19 shows an example of a generic screenshot for the provisional subscriber system (PSS2) according to some embodiments of the present invention;
• FIG. 20 shows an example of a generic screenshot for the provisional subscriber system (PSS3) according to some embodiments of the present invention;
• FIG. 21 shows an example of a component diagram for the Provisional Subscriber System, whereFIG. 21.A is the left side of the figure andFIG. 21.B is the right side of the figure;
• FIG. 22 is a flow chart forUse Case #1;
• FIG. 23 is a flow chart forUse Case #2;
• FIG. 24 is a flow chart forUse Case #3;
• FIG. 25 is a flow chart forUse Case #4; and
• FIG. 26 is a flow chart for a Provisional Subscriber Login process.
DETAILED DESCRIPTION
• It should be understood that this invention is not limited to the particular methodology, protocols, etc., described herein and as such may vary. The terminology used herein is for the purpose of describing particular embodiments only, and is not intended to limit the scope of the present invention, which is defined solely by the claims.
• As used herein and in the claims, the singular forms include the plural reference and vice versa unless the context clearly indicates otherwise. Other than in the operating examples, or where otherwise indicated, all numbers expressing quantities used herein should be understood as modified in all instances by the term “about.”
• All publications identified are expressly incorporated herein by reference for the purpose of describing and disclosing, for example, the methodologies described in such publications that might be used in connection with the present invention. These publications are provided solely for their disclosure prior to the filing date of the present application. Nothing in this regard should be construed as an admission that the inventors are not entitled to antedate such disclosure by virtue of prior invention or for any other reason. All statements as to the date or representation as to the contents of these documents is based on the information available to the applicants and does not constitute any admission as to the correctness of the dates or contents of these documents.
• Unless defined otherwise, all technical and scientific terms used herein have the same meaning as those commonly understood to one of ordinary skill in the art to which this invention pertains. Although any known methods, devices, and materials may be used in the practice or testing of the invention, the methods, devices, and materials in this regard are described herein.
• Some Selected Definitions
• Unless stated otherwise, or implicit from context, the following terms and phrases include the meanings provided below. Unless explicitly stated otherwise, or apparent from context, the terms and phrases below do not exclude the meaning that the term or phrase has acquired in the art to which it pertains. The definitions are provided to aid in describing particular embodiments of the aspects described herein, and are not intended to limit the claimed invention, because the scope of the invention is limited only by the claims. Further, unless otherwise required by context, singular terms shall include pluralities and plural terms shall include the singular.
• As used herein the term “comprising” or “comprises” is used in reference to compositions, methods, and respective component(s) thereof, that are essential to the invention, yet open to the inclusion of unspecified elements, whether essential or not.
• As used herein the term “consisting essentially of” refers to those elements required for a given embodiment. The term permits the presence of additional elements that do not materially affect the basic and novel or functional characteristic(s) of that embodiment of the invention.
• The term “consisting of” refers to compositions, methods, and respective components thereof as described herein, which are exclusive of any element not recited in that description of the embodiment.
• Other than in the operating examples, or where otherwise indicated, all numbers expressing quantities used herein should be understood as modified in all instances by the term “about.” The term “about” when used in connection with percentages may mean±1%.
• The singular terms “a,” “an,” and “the” include plural referents unless context clearly indicates otherwise. Similarly, the word “or” is intended to include “and” unless the context clearly indicates otherwise. Thus for example, references to “the method” includes one or more methods, and/or steps of the type described herein and/or which will become apparent to those persons skilled in the art upon reading this disclosure and so forth.
• Although methods and materials similar or equivalent to those described herein can be used in the practice or testing of this disclosure, suitable methods and materials are described below. The term “comprises” means “includes.” The abbreviation, “e.g.” is derived from the Latin exempli gratia, and is used herein to indicate a non-limiting example. Thus, the abbreviation “e.g.” is synonymous with the term “for example.”
• To the extent not already indicated, it will be understood by those of ordinary skill in the art that any one of the various embodiments herein described and illustrated may be further modified to incorporate features shown in any of the other embodiments disclosed herein.
• The following examples illustrate some embodiments and aspects of the invention. It will be apparent to those skilled in the relevant art that various modifications, additions, substitutions, and the like can be performed without altering the spirit or scope of the invention, and such modifications and variations are encompassed within the scope of the invention as defined in the claims which follow. The following examples do not in any way limit the invention.
I. IDENTITY MANAGEMENT SYSTEM ARCHITECTURE
• FIG. 1 illustrates an example of a high level functional description of asystem100 in accordance with some embodiments of the present disclosure. Theidentity management system100 interacts with one or moreexternal service providers160,subscribers170 andpartners180.Subscribers170 can include platforms suitable forindividual users172,mobile users174 andpartner portals176. Thesystem100 is adapted to accommodate future systems. For eachpartner180, there can be provided one or more partner integration systems180-1 . . .180-n. Theidentity management system100 can comprise a three-tier system, which can include adata tier110, an integration/application services tier120 and a public/web tier130, such as that shown inFIG. 1, which illustrates one example of the architecture of theidentity management system100. Thedata tier110 can comprise one or more of aresponse center112, a content management system (CMS)database10, an online transaction processing (OLTP)database11 and an online analytics processing (OLAP)database12. The integration/application services tier120 can comprise one or more of internal tools and sites5a, a Maestro tool5b, internal web services and application programming interfaces (APIs)6a, aSecureProfile Service6b(see Section VI below),partner integration services7,business intelligence8, customer relationship management (CRM) and/or case management (CM)systems122, andprovider integration services9. The public/web tier130 can comprise one or more of SecurePort SSL1 (see Section VII below), URL Matcher2 (see Section VIII below), Dynamic BrandedSites3, Public API (Web Services)4 and public transfer (XFER)13. Thepublic API4 can be representational state transfer (REST)-based API, user-oriented or partner-oriented.
• As seen best inFIG. 1A, twomajor systems140, i.e., a Core Gateway (CGW)142 (see Section III below) and a Data Processing Engine (DPE)144 (see Section IV below), can be configured to operate with one or more components of thedata tier110, integration/application services tier120 and the public/web tier130. For example, in one embodiment,CGW142 can be configured to operate withSecurePort SSL1,URL Matcher2, Dynamic BrandedSites3, Public API (Web Services)4 andPublic XFER13, andDPE144 can be configured to operate withPublic XFER13,Partner Integration Services7,Business Intelligence8,Partner Integration Services9,OLTP11 andOLAP12.
• As seen best inFIG. 1A, theidentity management system100 can comprise one ormore product modules150 including check fraud protection (CFP)151, identity restoration (IDR)152,Public Records153,Credit Data154,Internet Monitoring155 andSYCURITY Score156.
• It is noted that the like numbers inFIG. 1 represent logical or functional areas and, within those areas, there can be a number of components. In the case of numbers that are shared by both DPE and CGW, there are components from both systems that fall under those areas. In most cases, the integration between CGW and DPE can be made via data in the OLTP database. As such, the links between various systems are functional and can be direct or indirect.
• There can be real-time integrations between CGW and DPE, for example, a DPE process can call upon a service exposed by CGW. In this example, the component being called upon would be the one identified in the boxes, which is CGW.
• As seen best inFIG. 1B, theservice providers160 can be compliant, in one example, with the Statement on Auditing Standards (SAS) 70 Type II standard and the Payment Card Industry (PCI) standard. (SAS 70 II is an auditing standard that describes the internal controls an organization (such as a hosted data center, application service provider or credit processing company) must employ to protect sensitive data. Payment Card Industry (PCI) Compliance refers to a set of standards that mandate the secure storage, processing and transmission of customer credit card data.)Service providers160 can include one or more ofcampaign management161,payment processing162, credit bureau data feed163, independent security scanning andtesting164, and web trends andanalytics165.
• According to an embodiment of the present invention, an identity management system can comprise: a core gateway; a data processing engine; and a subscriber database.
• The identity management system can further comprise: a secure profile system.
• The identity management system can further comprise: a system for binding multiple SSL certificates to a single Microsoft IIS site.
• The identity management system can further comprise: a URL matcher to support vanity URLs on the core gateway.
• The identity management system can further comprise: a breach prevention system.
• The identity management system can further comprise: an identity alert management system for interaction between a customer and a resolution specialist.
• The core gateway can further comprise: a customer tools system; a self-service system; a core function system; a content and skinning system; a product and catalog system; a partner integration system; a central manager; and an affiliate management system.
• The data processing engine can further comprise: file retrieval system; file parsing and staging system; business rule processing system; and a record extract, transform and load system linked to the subscriber database.
• The data processing engine can further comprise: a first server; a file retrieval system connected to the first server; a second server connected to the file retrieval system; a file extract, transform and load system connected to the second server; a staging data system connected to the file extract, transform and load system; a business rule processing system connected to the staging data system; and a system for importing records that pass through the business rule processing system into the subscriber database.
• The subscriber database can further comprise: centralized data storage for identity management system customer data; a synchronization system linked to the core gateway; an integration system linked to the core gateway configured to allow customers to validate partner paid services during activation; a support and reporting system; an identity management system schema; an anonymous subscriber system; a provisional enrollment system; a system for synchronization between the subscriber database and the core gateway; and a schema extension system.
• The secure profile system can further comprise: a system for defining structures; multiple containers of data that are associated with profiles; a system for securely granting access to the profiles and subjects; an audit log configured to provide an account of all accesses to data housed within the profiles; security-related algorithms and protocols; a system for exchanging data between subjects; a support system for shared-secret access to data; and a support system for secured, externalized content.
• The secure profile system can further comprise: a database system; a data access system configured to access the database system; a controller system configured to access the data access system; a context system configured to access the controller system; and a service system configured to access the context system.
• The system for binding multiple SSL certificates to a single Microsoft IIS site can further comprise: an SSL accelerator for hosting the SSL certificates integrated with a custom ASP.NET HTTP module, wherein the ASP.NET HTTP module intercepts all incoming requests relayed from the SSL accelerator to the core gateway, wherein the SSL certificates associated with the core gateway partner sites are installed in a load balancer, and wherein traffic associated with each of the SSL certificates is directed to the same core gateway web server end-point.
• The URL matcher to support vanity URLs on the core gateway can further comprise: an ASP.NET HttpModule/HttpHandler; a system for inspecting incoming requests; a system for matching different elements of the request against pre-defined patterns; and a system for executing a URL rewrite, a client redirect or transfer to another page within the current site.
• The breach prevention system can further comprise: an assist module; and a prepare module.
• The assist module can further comprise: a self-assessment system; and a score system.
• The self-assessment system can further comprise: a series of questions pertaining to policies and procedures based on customer's industry and the personally identifiable information collected by the customer.
• The questions can be yes-no questions.
• The score system can further comprise: a system for assigning weights for each of the questions; a system for calculating a risk score based on the weights for each of the questions and the answers provided by the customer; and a system for assigning the calculated risk score to a tiered scoring system.
• The tiered scoring system can have five tiers.
• Each tier can have a 20% range.
• The prepare module can further comprise: a customer assist system; a system for identifying a data breach victim's contact information and data transfer protocol; a system for notifying breach victims or others of the subject data breach by a communication means that conforms with laws applicable to the customer's jurisdiction; a system for providing recommendations of notification based on current state and federal incident response regulations; a system for providing assistance with notification messaging and customer call center scripting; a system for managing the breach response; a system for providing breach victims customer-sponsored access to a heightened level of service; and a defined system for notification of costs.
• The customer assist system can further comprise: a system for allowing a dedicated breach specialist to communicate with a customer in a response process.
• The system for managing the breach response can utilize a web-site or a toll-free call-in number.
• The system for managing the breach response can utilize a web-site and a toll-free call-in number.
• The identity alert management system for interaction between a customer and a resolution specialist can further comprise the steps of: identifying personally identifiable information against elements of a customer's identity; automatically sending a communication to the customer within a specified time period; authenticating the customer through a secure identity management dashboard; permitting the customer to review a source of an identity alert and details associated with the alert; prompting the customer to mark the alert as a threat or not a threat; sending a record of the threat to an approved records system if the customer marks the alert as not a threat; creating a case if the customer marks the alert as a threat; permitting the user to execute a power of attorney prior to, during or after the threat has been detected; ascertaining whether the customer has executed the power of attorney; providing a first response system for customers that have executed the power of attorney; providing a second response system for customers that have not executed the power of attorney; and permitting the customer or the resolution specialist to reopen a previously approved record.
• The specified time period can be less than 24 hours.
• The step of providing a first response system for customers that have executed the power of attorney can further comprise the steps of: performing a customized restoration plan on behalf of the customer, who takes on a support role, by a resolution specialist, who takes on the role of a case owner; resolution of the threat by the resolution specialist; after resolution of the threat by the resolution specialist, permitting the customer to approve the response to the threat and perform a final sign off; if the customer approves of the response, moving the record to the approved records system; and if the customer does not approve of the response, repeating the step of ascertaining whether the customer has executed the power of attorney.
• The step of providing a second response system for customers that have not executed the power of attorney can further comprise the steps of: providing preplanned restoration plans to the customer with support from a resolution specialist; resolution of the threat by the customer; after resolution of the threat by the customer, permitting the resolution specialist to approve the response to the threat and perform a final sign off; if the resolution specialist approves of the response, moving the record to the approved records system; and if the resolution specialist does not approve of the response, repeating the step of ascertaining whether the customer has executed the power of attorney.
• The customer tools system can further comprise: a means for allowing a customer to browse products and services from a suite of identity management products and services; a means for allowing a customer to gather information about the identity management products and services; and a means for allowing a customer to complete purchase and enrollment of one or more identity management products and services.
• The self-service system can further comprise: a means for requesting additional information regarding one or more identity management products and services; and a means for reporting fraud-related activity.
• The core function system can further comprise: a language and runtime environment; an application framework and service including a content management system; an object/relational persistence layer; and a configuration and dependency injection system.
• The content and skinning system can further comprise: a cascading stylesheet; a dynamic content system; and a custom page override system.
• The partner integration system can further comprise: a bulk data load system; an on-demand data push system; and an on-demand data pull system.
• The partner integration system is configured to deliver a custom-branded uniform experience consistent with a partner's brand identity and online presence.
• The core gateway can be configured to provide support for special offer codes and source codes that enable special pricing or promotional discounts, offer promotional trial periods on certain products, or identify a marketing channel used to attract the customer.
• The central manager can further comprise: identity protection services; and secure web based storage inventory of subscriber documents.
• The affiliate management system can further comprise: the partner integration system; and a form-fill-based tool that allows designated agents of an affiliate to create and define a new partner-branded site under the core gateway.
• The form-fill-based tool that allows designated agents of an affiliate to create and define a new partner-branded site under the core gateway can further comprise: logo management; partner-identifying textual information; primary theme and color selections; and default product catalog.
• The centralized data storage for identity management system customer data can further comprise: transactional data from partner sales files; subscription data from partner sales files; and subscription data from customers who access the core gateway.
• The support and reporting system can further comprise: a system for tracking customer obligations for fulfillment; a partner billing system; a customer billing system; an email communications system; and a performance analysis system configured to analyze the performance of services and partners.
• The identity management system schema can further comprise: service term; pricing; billing frequency; volume discounts; step pricing; and package requirements.
• The anonymous subscriber system can further comprise a means for re-associating an anonymous record with a newly created profile record.
• The provisional enrollment system can further comprise: a partner sales file receiving and processing system; a customer communication system configured to direct the customer to activate services via the core gateway; a provisional lookup process; and a real time customer verification system.
• The customer communication system configured to direct the customer to activate services via the core gateway can further comprise a validating system configured to allow the core gateway to validate the customer against a record in the subscriber database.
• The system for synchronization between the subscriber database and the core gateway can further comprise a unique identity management system identification for each customer.
• The unique identity management system identification can be a primary key across the core gateway and subscriber database.
• The profile can contain records which have an associated structure.
• The database system can be configured to be isolated from all other systems with more restricted access, and wherein all profile data is layer encrypted.
• The data access system configured to access the database system can further comprise atomic primitives providing fundamental data operations for all system entities.
• The controller system configured to access the data access system can be configured to assemble and orchestrate data access primitives into higher level system functions.
• The context system configured to access the controller system can be configured to provide a stateful security context with a known acting principal for all requested operations.
• The service system can be configured to access the context system is configured to expose all client-accessible functionality over a supported remote-access technology.
• The ASP.NET HTTP module can be configured to detect certain characteristics of an incoming request connection.
• The certain characteristics can include a special port or local interface IP address.
• When the incoming request connection matches the certain characteristics, the ASP.NET HTTP module can alter the current state of the request context to indicate that the connection is secure.
• The load balancer for each partner site can be configured with a dedicated unique IP address listening endpoint.
• The dedicated SSL certificate can be associated with the unique IP address listening endpoint on the load balancer.
• The unique IP address listening endpoint can be directed from the load balancer to the core gateway.
• The elements of the request can include one or more of the URL, cookies, params and client IP.
• The pre-defined patterns can be static values or regex patterns.
II. GLOSSARY OF TERMS

• Type	Owner	Term	Description
  Entities	Marketing	Broker Partner	Enterprises or individuals
  			who represent the
  			identity management
  			system to potential
  			channel partners
  			and retailers. A broker
  			cannot be a retailer.
  	Marketing	Channel Partner	Partner responsible for
  			bringing in additional
  			business. There can be n
  			levels of channel partners
  			above a retail partner.
  			A channel partner
  			can also be a retailer.
  	Marketing	Retail Partner	Enterprises that directly
  			sell or package
  			identity management
  			system consumer services to
  			consumers. A retailer can
  			also be a channel partner.
  	Engineering	Provider	Enterprises that provide
  			one or more prevent, detect,
  			restore type services for
  			consumers and/or
  			enterprises. Can also include
  			providers of systems that
  			extend the features of
  			the identity management
  			services.
  Service	Engineering	Service	Services aimed at providing
  			prevention, breach,
  			notification services,
  			detection or restoration to
  			consumers or enterprises.
  	Engineering	Component	Provider defined products
  			that the identity management
  			system aggregates into a
  			service. In one embodiment,
  			subscribers never purchase
  			components.
  	Engineering	Partner Service	The costs, terms and other
  			details about a service
  			being sold by a specific
  			retail partner.
  	Engineering	Convenience	A grouping of services sold
  		Package	to a subscriber. Only
  			relevant at the time of
  			selection by the customer.
  			Not tracked after the sale.
  	Engineering	Partner Package	A grouping of services sold
  			to a subscriber. Package
  			to partner service relation-
  			ship is maintained through-
  			out the life of the contract.
  Order	Finance	Order	When a subscriber
  			purchases service(s)
  			and/or package(s).
  	Finance	Order Date	Date a subscriber purchases
  			a service or package.
  	Finance	Offer Code	Subscriber entered code
  			that can modify pricing,
  			terms and other partner
  			service attributes. Can also
  			be used to track order sourcing
  			by partner and/or channel.
  	Finance	Units	Quantity of a service sold
  			during an order.
  Contract	Engineering	Contract	An obligation to provide
  			a service to a subscriber.
  	Engineering	Contract Status	Identifies the current state
  			of a contract (ACTIVE,
  			EXPIRED, CANCELLED,
  			FULFILLED).
  	Finance	Contract Term	Length of time a partner
  			service is in effect.
  	Engineering	Effective Date	Date that a purchased
  			service is effective.
  	Engineering	Import Date	Date a purchased service is
  			introduced into the SDB.
  	Engineering	Check Quantity	Number of checks covered
  			by a service in an order.
  	Engineering	Reissue	Flag to determine if a
  			service has been reissued
  			to a subscriber. (i.e., Check
  			Reprint)
  	Finance	Retail Cost	What the subscriber pays
  			for a partner service.
  	Finance	Wholesale Cost	What a retailer pays for
  			a partner service.
  Subscriber	Engineering	Subscriber	End-user of identity
  			management system
  			services, restoration
  			“victim”, named party
  			whose personal infor-
  			mation is being moni-
  			tored, party who uses the
  			VAULT Safety Deposit,
  			and the like. Could be an
  			individual or a small
  			business.
  	Engineering	Subscriber	Identifies whether the sub-
  		Type	scriber is a business or person.
  Systems	Engineering	Core Gateway	Web portal for subscriber,
  		(CGW)	partner and internal
  			interactions.
  	Engineering	Fraud Trac	Case and relationship
  			management tool.
  	Engineering	Subscriber	Centralized database storing
  		Database	subscriber contracts.
  		(SDB)	Gold source of subscriber
  			and contract data.
  	Engineering	Data Processing	System used to extract,
  		Engine (DPE)	validate and load sales
  			data into the SDB.
  	Engineering	EZSHIELD	Secure web based
  		VAULT	storage inventory of
  			subscriber documents.
  	Engineering	Management	Extension of CGW
  		Gateway	providing partner and
  		(MGW)	internal administration.
  	Engineering	Sentry	Event driven, rules based
  			engine for subscriber
  			notifications and system
  			triggers.

• In the present application, each client can include a client application. The client can be any number of devices (e.g., computer, internet kiosk, personal digital assistant, cell phone, gaming device, desktop computer, laptop computer, tablet computer, a television with one or more processors embedded therein or attached thereto, or a set-top box) which can be used to connect to a communication network. The communication network can be a wireless, optical, wired or other type of network that facilitates the passage of information. It can include the Internet, one or more local area networks (LANs), one or more wide area networks (WANs), other types of networks, or a combination of such networks. The client application is an application that is executed by the client (e.g., browser, e-mail client, word processor) and that displays or presents information to a user of the client (the client application can also perform other tasks not relevant to the present discussion). Client can also include a location determiner for reporting a geolocation of the client.
• A customer client system can include one or more processing units (CPUs), one or more network or other communications interfaces, memory, and one or more communication buses for interconnecting these components. The customer client system can include a user interface, for instance a display and a keyboard. The memory can include high speed random access memory and can also include non-volatile memory, such as one or more magnetic or optical storage disks. The memory can include mass storage that is remotely located from CPUs. The memory can store the following elements, or a subset or superset of such elements: an operating system that includes procedures for handling various basic system services and for performing hardware dependent tasks; a network communication module (or instructions) that is used for connecting the customer client system to other computers via the one or more communications interfaces (wired or wireless), such as the Internet, other wide area networks, local area networks, metropolitan area networks, and so on; a client application as described above; a client assistant as described above; optionally, a cache of downloaded and a cache downloaded, as well as other information for viewing using the client application, and information retrieved by user selection of one or more items.
III. CORE GATEWAY (CGW)
• DotNetNuke is an example of a known, open source content management system (CMS) framework. CMS frameworks allow a user to develop a web site. Out-of-the-box, DotNetNuke has modules with basic functionality. For example, DotNetNuke has a limited commerce component, blogs, wikipages and news feeds. In a limited way, DotNetNuke supports multiple sites, but the sites are completely segregated; that is, using DotNetNuke, each portal is separately managed and configured.
• DotNetNuke is not easily configured for a large number of partners. DotNetNuke does not lend itself towards white labeling of core content (such as products or core applications) for different partners. Using DotNetNuke's out-of-the-box capabilities, the only way to configure websites for different partners involves setting up separate DotNetNuke configurations for each partner, copying the DotNetNuke configuration for a given site, and then customizing the copy for a new partner. If there are multiple copies of the original version, then any changes would have to be made multiple times.
• In order to solve the shortcomings in the known art, the present inventors developed a common portal whose default behavior and appearance is defined but is configurable to enable very rapid stand up of new personalities (by default would inherit attributes and appearance of the default), individual pages, or modules within the page, and to enable overrides of behavior or content that is presented.
Identity Management System Core Gateway (CGW)
• The identity management system can include a Core Gateway, which is an end-user portal for consumers to browse the various products in the identity management system suite, gather product information and complete the purchase and enrollment of various products. The site also provides various self-service functions such as requesting additional information on any identity management system product and reporting fraud-related activity. Finally, for certain products such as Identity Protection and a secure web based storage inventory of subscriber documents such as, for example, EZSHIELD VAULT, the Core Gateway serves as a central launching pad for additional product-specific services.
• In this way the CGW is a Consumer Hub for items related to the identity management system. From a technical and architectural view-point, CGW is also a content delivery and commerce platform. As banks and other financial institutions (also known as Partners) adopt the identity management system product suite, the Core Gateway can be used by these Partners to deliver a custom-branded uniform experience consistent with the Partner's own brand identity and online presence.
• CGW can be a core content management system (CMS) piece built on DotNetNuke. CGW can define additional dimensions, and content can be customized based on the dimensions. For example, CGW can be used to create a catalog system. Dimensions can be on a global level, can be override-able and are highly configurable. CGW integrates across three levels: public/web tier, integration/app services tier and data tier.
• Specifically, CGW allows customization of content across other dimensions, specifically, partners and retailers, which allows one to build a default site with default content, which can be tailored on a per partner or per retailer basis by specifying details such as content and navigation. The customization can be performed in any suitable content management system including but not limited to the DotNetNuke framework. CGW can be adapted to support subsystems for supporting commerce, order entry, vendors, service fulfillment, alert system, enrollment methods for different user segments and the like. Using CGW, sites can be skinned based on attributes. CGW operates outside of enrollment and other functions.
• Using CGW, deltas (or changes) can be defined against a baseline. For example, deviations can be defined at the page, component or navigation level to white label the experience. CGW allows a business to quickly stand up a new partner site with customization and flexibility while retaining the core of the platform.
• The commerce system of CGW includes defining a catalog, entering orders and other common aspects of a commerce system. CGW integrates commerce functions with a multiple-dimension CMS.
Tools and Technologies
• The Core Gateway facilitates rapid development and a stable and scalable platform. The Core Gateway comprises four core functions, as follows: language(s) and runtime environment (for example, in one embodiment, .NET Framework and ASP.NET); application framework and services, content management (for example, in one embodiment, DotNetNuke); object/relational persistence layer (for example, in one embodiment, NHibernate); and configuration and dependency injection; additional app framework and services (for example, in one embodiment, Spring.NET).
Content and Skinning
• The CGW implements a platform that can deliver a Partner-branded experience. In one embodiment, a basic site structure is defined that encompasses all of the site's features: delivery of information, product-specific services and launch pads, enrollment and self-service features. This generic structure can be easily applied to any Partner by default. To achieve a branded-look, several mechanisms can be utilized to tailor the content that is rendered and delivered to the end-user:
• • Cascading Style Sheets (CSS) Stylesheets—the Web site design of the CGW site has been carefully crafted by the design team to make heavy use of CSS styles to control the coloring, positioning, art-work and general look and feel. CSS stylesheets are delivered and applied in layers:
    • Begin with sensible site-wide default styles
    • Layer page- and component-specific styles
    • Apply Partner-specific style overrides
  • Dynamic Content—various areas of the site and pages within the site present content describing the Partner, the overall site and services, and the individual products. Many of these areas dynamically pull their content from the underlying CMS and can be overridden on a per-Partner basis. This includes textual and graphic content as well as content meta-data (logos, page banners, button text and sizes, and the like).
  • Custom Page Overrides—For any page within the basic site structure, a user of the identity management system can completely override the page that is delivered for a given Partner's experience, as well as add additional pages to add custom content and page flows that are not easily supported in the basic structure.
• This approach enables achievement of several goals. Firstly, because the default structure and styles are fairly generic, using the identity management system, one can get a minimal Partner-branded site up and running very rapidly just by uploading a few Partner logo images and specifying a handful of Partner-specific style settings. Indeed a tool called the Partner JumpStart Toolkit does just that by providing a quick form-fill approach to defining a new Partner. (See below for a more detailed discussion of the Partner JumpStart Toolkit.)
• Secondly, it allows the freedom to completely replace a subset of pages when a Partner requests a particular look for a set of pages if that look does not easily fit into the default structure and style.
• Lastly, it facilitates a rapid response to specialized needs for Partners who can choose to include content that compliments but does not directly relate to the identity management system's site or products. In these cases, using the identity management system, one can add Partner-specific products to that Partner's catalog and define product detailed pages which can be navigated to via the product links or from a set of custom pages.
Products and Catalogs
• The CGW implements a specialized product and catalog model dubbed the “mini-catalog” which is specially tailored to the service-oriented product selections of the identity management system suite. The catalog is also has special support for Partner-specific requirements. A Partner's catalog can define a subset of the identity management system's products the partner wishes to offer as well as the subset of the variations of those products. Variations allow defining pricing, price classes, product-specific content and even tax-related information on a per Partner+product combination.
Partner Integrations
• The normal page flow for user enrollment has the user come to the CGW site (either the identity management system default site or the Partner-branded site), browse around the site to learn about the identity management system products, then begin the Enrollment process. The user selects one or more products to subscribe to, provides their contact and billing information and any product-specific options. The enrollment is submitted at which point a user account is created, billing information is process and any recurring billing is validated and scheduled.
• For some Partners this normal process can be altered. For starters, instead of having users fill out their contact and personal information, a Partner can choose to integrate their user data into the identity management system.
• The Partner can define data elements known as “PartnerUserKeys” which can be used to uniquely verify a user's identity. Some examples would be a customer account number, the last four digits of their checking account number, a special offer code that can have been sent to the customer by the Partner, or the customer's account name. Any one of these or any combination (for example, three) of these data elements can be used.
• There are three approaches that the Partner can use to integrate user data with the CGW.
• Bulk data load—For this approach the Partner sends and initial load of customer data and then agrees to send updates on a regular periodic basis. The data load defines the customer information that the identity management system would typically capture through the normal enrollment process along with the identifying information corresponding to the PartnerUserKey elements. The data can also identify the products that the user is eligible for and can also identify if a user's information has been updated or if their eligibility has expired, for example if a customer closes a checking account and is no longer eligible for Check Fraud Protection.
• On-demand Data Push—For this approach a Partner's customer typically would navigate directly from their own account on the Partner's own site (e.g., the user is logged into a Bank's account and billing services) and would follow a link to the Partner's branded CGW site. The Partner would need to track whether the customer is already enrolled in the identity management system's service, and if not, would need to send the necessary information to the CGW using the “Integration API”, a collection of securely accessible Web Services. A one-time session token is generated from the API call and is used to identify the customer as she is forwarded from the Partner site to the CGW.
• On-demand Data Pull—For this approach the Partner has to expose a mechanism for the CGW to query back to the Partner the necessary information. The CGW supports most standard Simple Object Access Protocol (SOAP) Web Service calls as well as some forms of REST-based service requests. (For this integration approach, some additional configuration and integration work on the CGW can be required for each Partner.) With this approach, the customer can either be forwarded from the Partner's site or can land on the CGW directly (e.g., following a Web link from an e-mail announcement, entering a URL from a mail campaign, performing an Internet search or simply by word of mouth). Again the customer would need to enter some qualifying information to identify themselves. The CGW would use this information to make a request back to the Partner to confirm their eligibility as well as retrieve necessary enrollment data.
Alter Codes
• Most commerce sites have support for special offer codes and source codes that enable special pricing or promotional discounts, offer promotional trial periods on certain products, or simply help identify marketing channel used to attract the customer. In one embodiment, CGW offers a mechanism known as “Alter Codes” which offers these features and more. When a user first lands at the CGW, a session is constructed for that user and that session includes various state information including the originating site, which Partner they are affiliated with, and what Catalog of products are available to the user. As the user navigates through the site, their session is updated to reflect any changes in that state. For example, logging into the site updates the session with an authenticated user account that includes their enrollment history and account details.
• An Alter Code is a generated code or word (generated by an Alter Code Generator) that finds its way to the user and then allows the user to enter that code during the enrollment process. If the Alter Code is of a valid form and not expired, understood for the given Partner, and applicable for the user's current session state, then the Alter Code's associated Processor has the ability to make some alteration in the user's session. This can include altering the effective product catalog which could adjust product pricing, give away items for promotional periods or enable products which would normally be hidden.
• It can also be used to track the source location that a customer was referred from or import customer data from some external data source. In this way the Alter Code is complimentary with the Partner Integration mechanisms already mentioned.
• Alter Codes can be durable meaning they are persistent in CGW's data store which is typical for a shared offer code that is blasted to many users, for example, during a marketing campaign that offers a 30 trial period on a subscription service. They can also be sparse meaning that they are not initially stored in the data store. Sparse codes are ones where many thousands of codes can be generated and a unique code is sent to individual users, who can or cannot act on them. When a user redeems an Alter Code that is sparsely stored, then that Alter Code is then captured and stored and becomes effectively used-up such that it cannot be used again. A sparse code is good for targeting specific individuals. A good example would be the Partner Integration example above where an Alter Code is generated for each Partner customer and redeeming that Alter Code pre-populates the users contact information for enrollment.
Affiliates and the Partner JumpStart Toolkit
• The Core Gateway supports the concept of an Affiliate—a special Partner entity that itself has customers who are Partners, essentially a Partner of Partners. An Affiliate's customers are themselves banks, credit unions or other financial institutions and CGW has special support for this arrangement where an Affiliate has a large number of financial institution customers that the Affiliate wishes to target the identity management system's products for resale under the financial institution customer's identity.
• In addition to specialized reporting and analysis tools (via EZTrac), the CGW offers the Partner JumpStart Toolkit as briefly mentioned before. JumpStart is a very basic form-fill-based tool that allows designated agents of an Affiliate (such as sales staff) to create and define a new Partner-branded site under the CGW. The JumpStart tool allows a handful of elements to be provided such as uploaded logos, Partner-identifying textual information, primary theme and color selections and default product catalog.
• Within minutes of defining this information, the Affiliate agent can preview a working site. Once satisfied with the initial result the affiliate can request that the Partner be published. After completing a QA process by authorized identity management system agents, the site can be released to the public. Additional customizations and configurations, such as Partner Integration parameters, custom catalogs and specialized page flows, can be performed by identity management system agents and can be added at a later time, or can be added before the new Partner site goes live.
• An example of the CGW system and method according to the present invention is provided below.
• CGW can be configured to run on DotNetNuke as a CMS framework. CGW handles language and manages Modules. A Module can be, for example, a collection of ASCX components. Metadata can be associated with each Module. CGW can define single or multi instance behaviors. CGW can define cooperating components. CGW can manage attributes. Modules can be plugin oriented and can be specific to content. A user can develop components in the DotNetNuke framework. The core functions and/or services of DotNetNuke can be security (authentication and authorization), application logging and alias management. At the Framework level, CGW adds a feature that can be called a Dimension, which, in one embodiment, can be “Partners” and/or “Retailers,” which can be pervasive across all Modules. CGW looks at the context of user (a set of attributes) and handles display of content according to the attributes. CGW expands the context and adds more elements for work with Partners and Retailers. The default modules from DotNetNuke are not “Dimension-aware.” CGW adds Modules that are Dimension-aware. A Dimension-aware Module reviews the default content, and provides an override for a particular Partner, as desired.
• The URL can be the start of establishing the context for the user. CGW can be configured so that one URL is used for communication with all Partners.
• CGW can include an API that exposes functionality for systematic access.
• A Message can contain an attribute with a partner identifier and key. CGW adds additional context for additional Dimensions. Default modules ignore Partner specific instructions. CGW can be configured so that a user can choose to remove a default module for a specific Partner. CGW can include custom modules to work with Partner-specific instructions (“Partner aware”).
• CGW can have a Dashboard consisting of Modules.
• Sales personnel can use a configuration guide to add a new Partner. Deeper customization can be achieved through a separate set of tools. For example, a PartnerToolKit and CGWAdmin can be used for these functions.
• CGW can incorporate additional context, modules programmed based on the new context, and customization beyond appearance and behavior.
• CGW can have a collection of commerce-related modules that show different catalogs, products, families and packages but always operating in the context of the current Partner. CGW resolves the effective set of products against the current partner and the associated catalog, which can also depend on the user's state.
• CGW can have modules that are configured for certain marketing campaigns including, for example, upsell capabilities.
• CGW can define module behavior (how CGW renders or how CGW responds to user interaction). A user can configure some modules on a per instance basis. For example, a user can configure an instance of a product iterator so that one can display, for example, certain types of products; the module is reusable. In addition to an instance-specific configuration, a user can have context-awareness (Partner-awareness).
• In CGW, instance-specific behaviors, which are part of the DotNetNuke framework, are extended to be Partner-aware and can be over-ridden by Partner context.
• Context information (session specific) is also made Partner-aware.
• For example, a partner can be a Bank. If a new customer creates an account through the Bank, and if the new customer logs in through a portal other than that provided by the Bank, the present system can authorize the new customer, can check the context for the new customer, can identify that the new customer originated with the Bank (as a valid Partner) and can redirect the new customer to a site that is specific to the Bank.
• CGW can be adapted to display a site with different attributes based on a URL, a Partner, a Retailer or any other desired common reference point.
• CGW can be further customized so that a Partner can have different Retailers and a different website experience can be delivered for each Partner/Retailer combination.
• CGW can be adapted, for example, for use by a Service Provider that provides a service to a Customer, a Partner that is engaged with Customers in the marketplace, and, optionally, a Retailer that contracts with the Partner to provide services to the Customer. Using CGW, the Customer and Partner can offer branded experiences hosted on URLs such as, e.g., [company].[service provider].[tld]. CGW allows the Service Provider to very rapidly stand up new personalities that have the common core required to deliver the Service Provider's services while allowing a Partner and/or Partner/Retailer to customize the experience in a manner that is desirable to the Partner and/or Partner/Retailer.
• According to an embodiment of the present invention, a computer implemented method for a core gateway for an identity management system, can comprise: on a computer device having one or more processors and a memory storing one or more programs for execution by the one or more processors, the one or more programs can include instructions for: utilizing a content management system comprising a Framework and a Module; adding a Dimension at the Framework level of the content management system, wherein the Dimension is pervasive across all Modules of the content management system; and displaying content based on the Dimension of each Module.
• The content management system can be DotNetNuke.
• Each Module can comprise one or more ASCX components.
• Each Module can be adapted to operate in a default mode and a Dimension-override mode.
• The computer implemented can further comprise instructions for adding a Dimension-override mode to instance-specific behaviors of the content management system.
• The computer implemented method can further comprise instructions for adding a Dimension-override mode to session-specific parameters of the content management system.
• The computer implemented method can further comprise instructions for: adding a sub-Dimension at the Framework level of the content management system, wherein the sub-Dimension is pervasive across all Modules of the content management system; and displaying content based on the sub-Dimension of each Module.
• The core gateway can be configured to provide support for special offer codes and source codes that enable special pricing or promotional discounts, offer promotional trial periods on certain products, or identify a marketing channel used to attract the customer.
• The core gateway can comprise: a customer tools system; a self-service system; a core function system; a content and skinning system; a product and catalog system; a partner integration system; a central manager system; and an affiliate management system.
• The customer tools system can comprise: a browsing system for allowing a customer to browse products and services from a suite of identity management products and services; an information gathering system for allowing a customer to gather information about the identity management products and services; and a purchase and enrollment system for allowing a customer to complete purchase and enrollment of one or more identity management products and services.
• The self-service system can comprise: an additional information requesting system for requesting additional information regarding one or more identity management products and services; and a fraud-related activity reporting system.
• The core function system can comprise: a language and runtime environment; an application framework and service including a content management system; an object/relational persistence layer; and a configuration and dependency injection system.
• The content and skinning system can comprise: a cascading stylesheet; a dynamic content system; and a custom page override system.
• The partner integration system can comprise: a bulk data load system; an on-demand data push system; and an on-demand data pull system.
• The partner integration system can be configured to deliver a custom-branded uniform experience consistent with a partner's brand identity and online presence.
• The central manager system can comprise: identity protection services; and secure web based storage inventory of subscriber documents.
• The affiliate management system can comprise: the partner integration system; and a form-fill-based tool that allows designated agents of an affiliate to create and define a new partner-branded site under the core gateway.
• The form-fill-based tool can comprise: logo management; partner-identifying textual information; primary theme and color selections; and default product catalog.
• According to an embodiment of the present invention, a computer system for a core gateway for an identity management system, can comprise: one or more processors; and memory to store: one or more programs, the one or more programs can comprise instructions for: utilizing a content management system comprising a Framework and a Module; adding a Dimension at the Framework level of the content management system, wherein the Dimension is pervasive across all Modules of the content management system; and displaying content based on the Dimension of each Module.
• According to an embodiment of the present invention, a non-transitory computer-readable storage medium storing one or more programs configured to be executed by one or more processing units at a computer for a core gateway for an identity management system can comprise instructions for: utilizing a content management system comprising a Framework and a Module; adding a Dimension at the Framework level of the content management system, wherein the Dimension is pervasive across all Modules of the content management system; and displaying content based on the Dimension of each Module.
IV. DATA PROCESSING ENGINE (DPE)Overview
• The identity management system processes pieces of information (referred to as feeds) inbound and outbound with each feed potentially being in a different format. Some examples of these feeds include billing, alert, payment, event, email and synchronization data but the most common type is sales. A standard way to process these feeds is by means of a custom piece of code, or package, to process each feed. With this prior art method, dozens, if not hundreds, of packages are managed to verify that each works properly and interdependencies are maintained.
• One problem with known methods of processing feeds relates, for example, to inbound integrations for sales files from different Partners (there can be, for example, dozens, if not more, of Partners). Each feed requires custom development including a custom destination to make each feed usable. There is no commonality across the feeds. Known, off-the-shelf products are unable to integrate the multiple feeds.
• Another problem with known methods of processing feeds relates, for example, to maintaining and monitoring code pieces, and conducting an ongoing process for the feeds. Prior systems require custom components for each function. As the number of feeds to be integrated increases, manual processing of the feeds makes it difficult or impossible to perform the integration task.
• A further problem with known methods of processing feeds relates, for example, to performance and scalability. Integrations must be made to ensure timeliness, accuracy, controls, security, oversight, workflow and consistency.
• As an alternative solution, the identity management system includes a Data Processing Engine (DPE). The DPE is a central platform to implement, manage and monitor the inbound and outbound feeds. The DPE automates the manual processes of known methods of data integration. Feeds are controlled and processed through pieces of meta data that define the feed settings. The advantages to this approach include code reusability, integration step reusability, lower feed implementation times, central logging, shared business rules and consistent processing. As a result of these improvements, DPE delivers a time-is-of-the-essence data integration. That is, once a Partnership is made, data integration occurs in a relatively short amount of time without the need for custom configuration or rework for the particular integration at hand. DPE quickly and accurately integrates data from a provider, which enables the rapid launch of products or services and facilitates the attraction and retention of customers.
• In one embodiment, DPE can be used with Microsoft SQL Server Integration Services (SSIS). Traditionally, SSIS works by building packages, a mini workflow, and/or a set of instructions. Using SSIS, one defines a source (such as a database or files) and a destination (such as a database or files); a specific package is written for moving data from the source to the destination; and the data is moved. These tasks can be scheduled using, for example, a SQL server agent. One can perform relatively simplistic pass/fail testing. However, such simplistic pass/fail testing does not provide details as to why a particular process failed.
• If one were to follow normal SSIS procedure, a programmer would create X numbers of packages for X number of source-to-destination data movements. One would format the data, validate the data, and send the data to a proper destination in order to accomplish business objectives. However, out of the box, with SSIS, there is no commonality across multiple packages and agents. That is, one uses a custom agent for each package. Using SSIS, each agent can be coded to act in a similar manner.
• In contrast, DPE utilizes reusable components. DPE does not require data providers to format the data in any particular format. As long as the data is present and readable, DPE can adapt to the data.
• A typical process can involve a demand that a data provider provide data in a specific format; whereas, DPE is configured to permit flexibility and make it easy for providers to provide data. This flexibility is attractive to Partners and attracts new sales.
• Another advantage of the present system and method is the ability to add a new capability to the system, and immediately make that new capability configurable for all Partners.
• Further advantages of the present system and method include that one integration adapts to the incoming data and the integration is driven by metadata outside that integration. That is, DPE is not changed for a particular Partner, and everything for the Partners is metadata driven outside of DPE.
DPE Process Flow
• FIG. 2 illustrates an example of a high level functional description of asystem200 in accordance with some embodiments of the present disclosure, in which the DPE processes a feed by executing fundamental tasks shown.
File Retrieval
• TheDPE200 has been designed to support flexible transmission settings that are defined in the meta data associated with a feed. An FTP Server Remote orinternal Server205 can be functionally connected to aFile Retrieval system210. TheFile Retrieval system210 can comprise a Data Feed, TransmissionDetail and Data FeedJob. The Data Feed can define a feed including Partner name, number of files and schedule information. The TransmissionDetail can define FTP location, encryption information and directory location. The DataFeedJob can log each execution of the datafeed for reporting and operations management. The meta data defines the following information about the feed transmission.

• 	Setting	Description
  	Type	Feeds can be configured to pull from alocal
  		server
  215 where files can be “dropped off” or
  		the system can poll aremote server 205 for the data.
  	Server Name	Name of the server to poll for the files.
  	Username	Login information to the server to pull the files
  		(if required).
  	Password	Login information to the server to pull the files
  		(if required).
  	Port	The port to use to connect to the server.
  	Directory	Location of the files once server connection
  	Location	has been created.
  	Transfer	The protocol of the file transmission.
  	Protocol

• ALocal File Server215 can be provided between theFile Retrieval system210 and a File Parsing/File ETL system220. The File Parsing/File ETL system220 can comprise FeedDetail, FieldMapping and FeedDetailLog. FeedDetail can define data relevant to the specific file, which can include filename, delimiter, file type and the like. FieldMapping can define the fields contained in the file, which can include Field Name, Position, Data Transformation Rules and Target filed in the SDB. FieldDetailLog can log each file processed as part of the datafeed for reporting and operations management.
• During the parsing step of the DPE workflow, the system decrypts, opens and processes records in the file to the staging tables. AStagingData system225 can be provided between the File Parsing/File ETL system220 and a BusinessRule Processing system230. The StagingData system can comprise a database and can be adapted to store data that contains parsed but unprocessed data. Those steps are configured with the following settings.

• 	Setting	Description
  	Name	A friendly name for a specific data feed. This is the
  		value that will show up in associated reporting.
  	Description	The description of the feed.
  	Schedule	The schedule defines the expected frequency the
  		files should be received on. This data can be used
  		for proactive polling or to for notifications if a files
  		isn't processed within a defined variance of this value.
  	Encrypted	This defines if the file has been encrypted and how
  		to process the decryption prior to parsing.
  	Prefix	Defines what static prefix is associated with the file.
  	Suffix	Defines what static suffix is associated with the file.
  	Extension	Defines the extension of the file.
  	Character	Defines what character set is associated with the file.
  	Set
  	Field	Field Delimiter
  	Delimiter
  	Line	Line Delimiter
  	Delimiter
  	File Type	File Type
  	Header	This is a true/false setting that indicated whether a
  		header record is present in the file.
  	Ignore First	Optional setting that can be used to skip the first n
  	n	rows from a file.
  	Ignore Last	Optional setting that can be used to skip the last n
  	n	rows from a file.

• A BusinessRule Processing system230 can be provided between theStagingData system225 and an ETL intoSDB system240. The BusinessRule Processing system230 can validate records in theStagingData system225 by Partner specific business rules. Each record can be coded for processing and reporting.
• Once the records have been processed to the staging tables, the DPE goes through each record again and checks it against a list of business rules. Business rules can be defined as needed and run against one or more feeds. The rules check for feed specific verifications like duplicate sales records or malformed data elements. The status of the staging data record is updated after it has been processed to define its final disposition.
• An ETL intoDestination system240 can be provided between the BusinessRule Processing system230 and aDestination system250 such as SDB. The ETL intoDestination system240 can send records that pass all business rules into theDestination system250. After business rule processing has completed, the final step in the DPE workflow is the insert the staging records into the destination tables. As most feeds processed through DPE are sales related, the most frequent destination is the Subscriber Database (SDB). In this step, the system looks for staging data records that have a positive disposition and have not been yet transferred to the destination. If both of those conditions are met, the system inserts the data into the destination system and the staging data row's status is updated to reflect the end result of the processing.
• A Data Model300 can be provided for the Data Processing Engine (DPE).FIG. 3 illustrates an exemplary table300 in a database, which is used in some embodiments to store information about meta data associated with a DPE feed. The following entities are used to define the meta data associated with a DPE feed.
• TransmissionDetail310—Server and transmission settings, which can include one or more of TransmissionID, ServerName, Username, Password, Port, DirectoryLocation, TransferProtocol, CreatedOn, CreatedBy, UpdatedOn and UpdatedBy fields.TransmissionDetail310 can be functionally connected toDataFeed320. For example,TransmissionDetail310 can have a one-to-many relationship withDataFeed320.
• DataFeed320—Top level feed describing purpose and component files, which can include one or more of FeedID, Name, Description, PartnerID, NoOfFiles, IfInbound, TransmissionID, NotificationID, ScheduleID, Status, CreatedOn, CreatedBy, UpdatedOn and UpdatedBy fields.DataFeed320 can be functionally connected to one or more ofTransmissionDetail310,FeedDetail330,Notification350 andSchedule360. For example,TransmissionDetail310,Notification350 andSchedule360 each can have a one-to-many relationship withDataFeed320, andDataFeed320 can have a one-to-many relationship withFeedDetail330.
• FeedDetail330—Specific file(s) associated withDataFeed320; Multiple files can be associated with one DataFeed.FeedDetail330 can include one or more of FeedDetailID, FeedID, Prefix, Suffix, Extension, CharacterSet, FieldDelimiter, LineDelimiter, File Type, HeaderLinePresent, IgnoreFirstNRecs, IgnoreLastNRecs, Encrypted, ScheduleID, CreatedOn, CreatedBy, UpdatedOn, UpdatedBy and TextQualifier fields.FeedDetail330 can be functionally connected to one or more ofDataFeed320 andFieldMapping340. For example,DataFeed320 can have a one-to-many relationship withFeedDetail330 andFeedDetail330 can have a one-to-many relationship withFieldMapping340.
• FieldMapping340—Mapping data for source file to staging data target, which can include one or more of FieldMappingID, FeedDetailID, FieldName, TargetTableName, UniqueKeyColumn, DataType, DataLength, FieldPosition, NullAllowed, TransformationRule, FieldValidationID, CreatedOn, CreatedBy, UpdatedOn, UpdatedBy and IsPII fields.FieldMapping340 can be functionally connected toFeedDetail330. For example,FeedDetail330 can have a one-to-many relationship withFieldMapping340.
• Notification350—Notification information to use pre/post feed processing, which can include one or more of NotificationID, EventID, NotificationEmail, NotificationEmailTo, NotificationEmailCC, Subject, Body, CreatedOn, CreatedBy, UpdatedOn and UpdatedBy fields.Notification350 can be functionally connected toDataFeed320. For example,Notification350 can have a one-to-many relationship withDataFeed320.
• Schedule360—Scheduling information associated with aspecific DataFeed320, which can include one or more of ScheduleID, ScheduleDetails, CreatedOn, CreatedBy, UpdatedOn and UpdatedBy fields.Schedule360 can be functionally connected toDataFeed320. For example,Schedule360 can have a one-to-many relationship withDataFeed320.
• FIG. 4 illustrates an exemplary table400 in a database, which is used in some embodiments to store information about entities used for file processing.DataFeedJob410—Log information about a specific processing instance of a DataFeed (group of files), which can include one or more of JobID, RunDate, Status, StatusReason, FeedID, CreatedOn, CreatedBy, UpdatedOn and UpdatedBy fields.DataFeedJob410 can be functionally connected toFeedDetailLog420. For example,DataFeedJob410 can have a one-to-many relationship withFeedDetailLog420.
• FeedDetailLog420—Log information about a specific processing instance of a FeedDetail (individual file), which can include one or more of FeedDetailLogID, JobID, FeedDetailID, Status, StatusReason, Filename, FileSize, FileReceivedDate, RecordCount, CreatedOn, CreatedBy, UpdatedOn and UpdatedBy fields.FeedDetailLog420 can be functionally connected to one or more ofDataFeedJob410 andStagingData430. For example,DataFeedJob410 can have a one-to-many relationship withFeedDetailLog420, andFeedDetailLog420 can have a one-to-many relationship withStagingData430.
• StagingData430—Destination for data from files, which can include one or more of ID, FeedDetailLogID, Status, Destination_PrimaryKey, Destination_TableName, RoutingNumber, AccountNumber, PartnerCode, PartnerOrderID, ShipDate, UnitsShipped, StartNumber, UnitQuantity, Parts, PersonalLine, ProtectType, ReprintFlag, PartnerName, ImportDate, IsDuplicate, SubscriberID, EventDate, Message, FirstName, MiddleName, LastName, AddressLine1, AddressLine2, City, State, Country, PostalCode, TelephoneNumber, EmailAddress, MemberID (such as EZShieldMemberID), StatusCode, EffectiveDate, Secret, SecretType, BC, Retailer, Personalize, Transit, VendorCode, OrderID, OrderShipDate, NumUnits, StartNum, UnitQuantity, Persltext, FPSCode, RemakeReason, CustomerID, CompanyName, Address1, Address2, Zip, Plus4, County, CountryCode, PhoneNum, PhoneExt, Email, NoEmail, NoRent, Gender, PaymentMethod, OrderChannel, Pers2text, Pers3text, Pers4text, Persltext, Pers6text, ContactName, CCName, CCAddr, CCCity, CCState, CCZip, CCPhone, CCPhone, CCNum, CCExpDate and ProductCode fields.StagingData430 can be functionally connected to FeedDetailLog420. For example,FeedDetailLog420 can have a one-to-many relationship withStagingData430.
• ErrorLog440—Error logging, which can include one or more of LogID, ErrorID, ErrorMessage, CreatedDate and TranID
• An example of the DPE system and method according to the present invention is provided below.
• 1. Configure inbound or outbound feed
• • a. Define theTransmissionDetail310
    • i. Define TransferProtocol
      • 1. e.g., FTP
    • ii. Define ServerName
    • iii. Define Port
    • iv. Define Credentialing
      • 1. e.g., Username/Password
  • b. DefineDataFeed320
    • i. Define topic of information/pre-defined category
      • 1. e.g., Sales
      • 2. e.g., User Registration
      • 3. e.g., Alerts
      • 4. e.g., Email activity from external marketing system
    • ii. Define direction, i.e., inbound versus outbound
    • iii. Define optional features
      • 1. When the file is expected (expected cadence, frequency), occurring on the SQL side
      • 2. In response, alerting
  • c. DefineFeedDetail330
    • i. Define the source details (source-specific)
      • 1. Location
      • 2. File Type and Delimiters
        • a. Need not be limited to Files, can be other sources such as databases, etc.
      • 3. Extension
      • 4. Filename mask
      • 5. Header/footer information
      • 6. Encryption
    • ii. System for proactively monitoring attributes
      • 1. Cadency
      • 2. Frequency
      • 3. Seek anomalies
        • a. Send alerts when “expected” behaviors are out of a “normal” range
      • 4. Quality
      • 5. Traceability
  • d. Define FieldMapping340 (many FieldMappings to one FeedDetail)
    • i. Data type, length, position
  • e. Define the destination details
  • f. Define the business rule processing
  • g. Configuration can be iterated
• 2. Execute inbound data feeds
• • a. Obtain a list of all data feeds to be executed
    • i. Look at the status of the data feeds
    • ii. Execution run at least as often as the shortest cadence
      • 1. Option: add detailed scheduling information/tasks, different feeds could be associated with different scheduling categories
        • a. Hourly
        • b. Daily
        • c. Weekly
        • d. Custom
        • e. etc.
  • b. For eachDataFeed320 . . .
    • i. Connect toTransmissionDetail310
    • ii. Retrieve all associatedFeedDetail330
      • 1. Execute process for eachFeedDetail330 in the data feed
        • a. Get a file
        • b. Potentially decrypt (inbound)
        • c. Validate the source to ensure that the source meets expected specifications
        •  i. For example, a .csv file with 7 columns, conditions
        • d. Process file according toFieldMapping340 with a destination ofStagingData430
        •  i. Common through all the sales files
        •  ii. Process file to a staging table based on type of data
        •  1. Example: If sales, then sales data
        •  a. What are the common fields in a sales file
        •  b. Defining the temporary location (higher level configuration)
      • 2. Insert execution results intoFeedDetailLog420
    • iii. Iterate back to ii (Retrieve all associated FeedDetail330)
    • iv.Insert DataFeed320 execution results intoDataFeedJob410
  • c. Iterate back to b (For eachDataFeed320 . . . )
  • d. For eachDataFeed320, all records in a staging area (for example, stored in StagingData430 (first three elements are critical, i.e., ID, FeedDetailLogID, Status), perform business rule processing
    • i. Evaluate each record against defined business rules and disposition that record accordingly
      • 1. Business rules examples
        • a. Data validation
        • b. Reference validation
        • c. Sanitization of data
        •  i. e.g., One retailer means another retailer
        • d. If duplicate, flag
        • e. If missing data, flag
        • f. If invalid product, flag
        • g. If data sequences, flag
        • h. If invalid partner, flag
        • i. Activation status
        • j. Identify valid records for future processing
      • 2. (Report can be generated back to data provider)
    • ii. Insert or update profiles and/or contracts into the final destination database, e.g., Subscriber Database (SDB)
• 3. Execute outbound data feeds
• • a. Schedule SQLServer job to call DPE specifying which outbound integration to run and the location of the configuration data
    • i. Can be scheduled at a specific time, for example
  • b. Pull all configuration information, e.g., fromDataFeed320,FeedDetail330
    • i. Tells us what to run, SQL object to run in defined database
  • c. Construct an execution string based on the SQL object and parameter fields
  • d. Execute the execution string
  • e. Returns a data set
  • f. Transform the data set into file specification based on field mappings, e.g.,FieldMapping340, and store in temporary local location
  • g.Log FieldMapping340 construct results toDataFeedJob410,FeedDetailLog420
  • h. Based on details inTransmissionDetail310, transmit the file from local source to destination
  • i. Log transmission results toDataFeedJob410
• 4. Finish
• Numerous advantages are achieved when practicing DPE as described above. For example, integration can be completed in hours (or days) instead of weeks. Standup and initial integration can be completed in hours. The bulk of the time is spent testing of business rules processing instead of writing new code. As a direct result of DPE, a new integration can be performed without writing new code. Outbound data feeds can be completed in a day instead of a week. Updates can be applied in hours instead of days. DPE is adaptable to changing business needs, specifically, e.g., changing business rules. Standard components that do not change a lot are integrated into the DPE process. Fast-changing configuration items can be attacked in a customized manner or in an automated manner. The system promotes the ability to find where errors occurred and highlight areas for improvement.
• According to an embodiment of the present invention, a computer implemented method for a data processing engine for an identity management system, can comprise: on a computer device having one or more processors and a memory storing one or more programs for execution by the one or more processors, the one or more programs can include instructions for: configuring an inbound or outbound feed; executing the inbound feed; and executing the outbound feed.
• Configuring the inbound or outbound feed can comprise: defining a transmission detail; defining a data feed; defining a feed detail; and defining a field mapping.
• Defining the transmission detail can comprise: defining a transfer protocol; defining a server name; defining a port; and defining a credential.
• Defining the data feed can comprise: defining a topic of information or a pre-defined category; and defining a direction of data flow.
• Defining the feed detail can comprise: defining source details; and monitoring attributes.
• Defining the source details can comprises: defining a location; defining a file type and a delimiter; defining an extension; defining a filename mask; defining header or footer information; and encrypting the data.
• Monitoring attributes can comprise: monitoring cadency; monitoring frequency; monitoring anomalies; monitoring quality; and monitoring traceability.
• Defining the field mapping can comprise defining data type, data length and data position.
• Configuring the inbound or outbound feed can further comprise: defining a destination detail; defining business rule processing; and repeating the step of configuring the inbound or outbound feed.
• Executing the inbound feed can comprise: obtaining a list of all data feeds to be executed; and for each data feed to be executed; connecting the data feed to the transmission detail; retrieving the feed detail for the data feed; inserting execution results for the data feed into a data feed job; and performing business rule processing for the data feed.
• Obtaining a list of all data feeds to be executed can comprise: looking at a status of the data feed; and executing a run at least as often as a shortest cadence.
• Retrieving the feed detail for the data feed can comprise: obtaining a file; decrypting the file; validating a source to ensure that the source meets expected specifications; processing the file according to the field mapping; and storing the results of the processing in a staging database.
• Performing business rule processing for the data feed can comprise: evaluating each record against defined business rules; disposing each record according to the evaluating step; and inserting or updating a profile or a contract into a final destination database based on the evaluating and disposing steps.
• Executing the outbound feed can comprise: scheduling a job to call the data processing engine; specifying an outbound integration to run; setting a location of configuration data; obtaining configuration information from the data feed and the feed detail; constructing an execution string based on an object field and a parameter field; executing the execution string; returning a data set; transforming the data set into a file specification based on the field mapping; storing the data set with the file specification into a temporary local location; logging the field mapping construct results to the data feed job and the feed detail log; transmitting the file from a local source to a destination based on details in the transmission detail; and logging the transmission results into the data feed job.
• According to an embodiment of the present invention, a computer system for a data processing engine for an identity management system, can comprise: one or more processors; and memory to store: one or more programs, the one or more programs can comprise instructions for: configuring an inbound or outbound feed; executing the inbound feed; and executing the outbound feed.
• According to an embodiment of the present invention, a non-transitory computer-readable storage medium storing one or more programs can be configured to be executed by one or more processing units at a computer for a data processing engine for an identity management system, can comprise instructions for: configuring an inbound or outbound feed; executing the inbound feed; and executing the outbound feed.
V. SUBSCRIBER DATABASE (SDB)
• Embodiments of the identity management system can be adapted to maintain customized sales data tables for each partner. While this solution provides a vast amount of flexibility to store different customer attributes, it did not allow for a consolidated view of the customer. Relatively simple tasks like reporting, customer lookup and fulfillment were very cumbersome to support. When the business asked a simple question such as “How many active customers are there right now?”, the technology team was not able to answer with ease. To exacerbate the problems, a common set of customer attributes and common taxonomy were not present.
• In order to address these concerns, the identity management system can be adapted to include a consolidated data store to hold this information. The key success requirements for the project included:
• • Define a common taxonomy that has business and technology buy in
  • Centralized subscriber data storage for identity management system customer data
    • Transactional data from partner sales files
    • Subscription (i.e., monitoring) data from partner sales files
    • Subscription data from customers who come directly to the CGW portal
  • Synchronization of key data elements from CGW customer portal
  • Integration with CGW portal for customers to validate their partner paid services during the activation (provisional lookup)
  • Support for reporting on the identity management system's
    • customer obligations (outstanding contracts) for fulfillment
    • partner billing
    • customer billing
    • email communications
    • performance analysis of services and partners
Solution Overview
• To solve the defined problems and meet the projects requirements, the team decided to leverage its existing expertise in a relational database management system (for example, in one embodiment, Microsoft SQL Server) to develop a customized schema tailored to an identity management system's business needs. The development was broken into several design, development, and release iterations as laid out below. Design development followed the Data Services Design Best Practices.
Partner Services
• Using the Glossary of Terms above to establish terminology embodiments of the system and method create a schema to represent the identity management system's business. A need arose to develop a way to represent the attributes for a combination of a generic identity management system service, a package and a partner. Attributes that are unique to this combination are service term, pricing, billing frequency, volume discounts, step pricing and package requirements. To represent this, the concept of the Partner Service was developed. The Partner Service maintains referential integrity to the generic services offered but allows for partner and package specific customizations of attributes associated with that service.
Anonymous Subscribers
• The next challenge identified relates to the management of anonymous subscribers. Some identity management system partner data feeds contain detailed demographic information (i.e., name, address, phone, and the like) while others contain only sales data (i.e., service X, date soId, and the like). In order to maintain referential integrity within the data model and fit both business cases, a null profile record (−1) is implemented that is referenced for anonymous subscribers. If the identity management system collects additional demographic information about a specific anonymous customer during the course of normal business, the associated records can be re-associated with a newly created profile record representing that additional data.
Provisional Enrollment Support
• The identity management system's most common sales process involves a partner selling services to their customer. The partner then sends sales files to the identity management system, which is processed into SDB. The identity management system then sends an email to the customer directing them to activate their services via the CGW portal. During the activation process, CGW needs to validate the customer against the SDB record. This validation process is referred to as the provisional enrollment process.
• To support the provisional lookup process (PSS, see Section XI below), SDB needed to extend a validation mechanism to the CGW web site for real time customer verification. This was accomplished by creating a series of stored procedures which offer flexible validation options. Validation can be executed based on different combinations of customer information:
• • Provisional ID
  • First Name
  • Last Name
  • Zip Code
  • Secret Value (i.e., last 4 of the social security number (SSN))
• Once a customer is validated by CGW using these procedures, the customer can continue through the enrollment process.
CGW Synchronization
• After creating customer records in SDB and CGW, a mechanism is identified to keep these systems in sync. When accounts are created in CGW, the system generates a unique identity management system ID for that customer. That ID becomes the primary key across CGW and SDB for the purposes of system synchronization. This occurs both during the provisional enrollment process and when a walk up customer is enrolled (a walk up customer goes directly to the CGW portal and purchases services).
• Please refer to CGW documentation for information on how CGW flags records for synchronization. Flagged records are processed via DPE for synchronization with SDB on a daily basis.
Schema Extension
• Since SDB's original development, the system has been extended to store data about outbound email triggers and the deliverability (sent, bounce, open, click, and the like) information about that message.
• FIG. 5 illustrates one example ofSDB Schema500 of the identity management system, which can be a table in a database. TheSDB Shema500 can include one or more of the following systems:SDBNotificationEvents510,SDBEvents520,SDBNotificationCampaigns530, SDB Campaigns540,SubscriberProfile550,SDBPricing560,SDB Service565,SDBPartnerService570,SDB Package575,Contract580 andSDBPartner590.
• InFIG. 5, the abbreviations Primary Key (PK), Foreign Key (FK), Instance (I) and Update (U) are used and can be numbered, for example, FK1, FK2, I1, I2 and the like.
• SDBNotificationEvents510 can comprise one or more of EventID, which can function as PK and FK2, NotificationEventID, which can function as PK, NotificationCampaignID, which can function as FK1, EventDate, Type, Reason, Code, OfferName, OfferURL, CreatedOn, CreatedBy, UpdatedOn and UpdatedBy fields.SDBNotificationEvents510 can be functionally connected to one or more ofSDBEvents520 andSDBNotificationCampaigns530.
• SDBEvents520 can comprise one or more of EventID, which can function as PK, EventName, PartnerEventID, CreatedOn, CreatedBy, UpdatedOn and UpdatedBy fields.SDBNotificationEvents510 can be functionally connected toSDBEvents520.
• SDBNotificationCampaigns530 can comprise one or more of NotificationCampaignID, which can function as PK, LaunchID, SubscriberProfileID, which can function as FK2, SourceCampaignID, SourceContactID, ContactAddress, ContactFormat, SourceSystem, CreatedOn, CreatedBy, UpdatedOn, UpdatedBy and SDBCampaignID, which can function as FK1, fields.SDBNotificationCampaigns530 can be functionally connected to one or more ofSDBNotificationEvents510, SDB Campaigns540 andSubscriberProfile550.
• SDB Campaigns540 can comprise one or more of SDBCampaignID, which can function as PK, CampaignName, SourceSystem, SourceCampaignID, CreatedOn, CreatedBy, UpdatedOn, UpdatedBy fields. SDB Campaigns540 can be functionally connected toSDBNotificationCampaigns530.
• SubscriberProfile550 can comprise one or more of SubscriberProfileID, which can function as PK, SubscriberId, ContractDetailId, which can function as I5, FirstName, which can function as I8, MiddleName, LastName, which can function as I9, Email, which can function as I6, UniqueCustomerID, which can function as I15, [company name]ID, such as EZShieldID, which can function as I7, Last4SSN, PartnerCode, Suffix, Address, which can function as I17, Address2, City, State, Zip, Telephone, Extension, County, Country, Gender, Secret, which can function as I12, SecretQuestion, ActivationStatus, ProvisionalID, which can function as I11, SubscriberStatus, SubscriberStatusDate, ActivationDate, EmailOptOutDate, RentOptOutDate, PreferredMethodofContact, CompanyContactName, which can be I4, IsProvisional, Partner ID, which can function as I10, Status, which can function as I14, CreatedOn, CreatedBy, UpdatedOn, which can function as I16, UpdatedBy, CheckSumID, cgw_FirstName, which can function as I3, cgw_MiddleName, cgw_LastName, which can function as I1, cgw_Email, which can function as I2, cgw_Suffix, cgw_Address, cgw_Address2, cgw_City, cgw_State, cgw_Zip, cgw_Telephone, cgw_Extension, cgw_County, cgw_Country, cgw_Gender, cgw_Secret, cgw_SecretQuestion, cgw_EmailOptOutDate, cgw_RentOptOutDate, cgw_PreferredMethodofContact, cgw_CompanyContactName, is TestUser, ParentSubscriberProfileID, StagingDataID, which can function as I13, TimeReserved, Prefix and cgw_RoutingNumber fields.SubscriberProfile550 can be functionally connected to one or more ofSDBNotificationCampaigns530 andContract580.
• SDBPricing560 can comprise one or more of PartnerServiceID, which can function as PK and/or FK1, ContractStatus, which can function as PK, ContractTerm, RetailPrice, WholesalePrice, BillingFrequency and ContractId, which can function as FK2, fields.SDBPricing560 can be functionally connected to one or more ofContract580 andSDBPartnerService570.
• SDB Service565 can comprise one or more of PartnerServiceID, which can function as PK and/or FK1, ServiceID, which can function as PK, ServiceName, ServiceDescription, ServiceDisplayName, WebServiceID, Description, ShortName, ServiceCode, Status and FutureStatus fields.SDB Service565 can be functionally connected toSDBPartnerService570.
• SDBPartnerService570 can comprise one or more of PartnerServiceID, which can function as PK, PackageID, which can function as FK1 and/or I1, StartDate, EndDate, CreatedOn, CreatedBy, UpdateOn, UpdatedBy and ContractTerm fields.SDBPartnerService570 can be functionally connected to one or more ofContract580,SDBPartner590,SDB Service565 andSDB Package575.
• SDB Package575 can comprise one or more of PackageID, which can function as PK, PackageCode, Name, Description, CreatedOn, CreatedBy, UpdateOn and UpdatedBy fields.SDB Package575 can be functionally connected toSDBPartnerService570.
• Contract580 can comprise one or more of ContractId, which can function as PK, ContractDetailID, which can function as I4, SubcriberProfileId, which can function as FK1 and/or I21, PartnerServiceID, which can function as FK2 and/or I11, PartnerId, which can function as I9, ServiceId, which can function as I17, ParentContractID, SubscriberID, BC, which can function as I2, [company name]ProductCode, such as EZShieldProductCode, which can function as I7, DateOfPurchase, which can function as I5, PartnerOrderID, which can function as I10, ImportDate, which can function as I8, PaymentMethod, OrderChannel, NumUnits, StartNum, UnitQuantity, AccountNumber, which can function as I1, Reissue, RoutingNumber, which can function as I16, Personal1, which can function as I13, Personal2, which can function as I14, Personal3, which can function as I15, Personal4, Personal5, EffectiveStartDate, EffectiveEndDate, CancellationDate, which can function as I3, CreatedOn, CreatedBy, UpdatedOn, which can function as I22, UpdatedBy, is TestData, Status, which can function as I20, Source, Parts, EnrollmentRefId, which can function as I6, SoftExpirationDate, which can function as I18, HardExpirationDate, StagingDataID, which can function as I19, ContractActivationDate, Personal6, PSID2 and PSIDOLD, which can function as I12.Contract580 can be functionally connected to one or more ofSubscriberProfile550,SDBPricing560 andSDBPartnerService570.
• SDBPartner590 can comprise one or more of PartnerID, which can function as PK, PartnerName, PartnerType, LegacyPartnerCode, which can function as I1 and/or U1, ParentPartnerId, ChannelPartnerId, which can function as I2 and/or U1, DisplayName, CGW_PartnerID, CGW_PartnerName, CGW_DisplayName, Address, BusinessContactEmail, TechnicalContactEmail, Status, RangeValid, CreatedOn, CreatedBy, UpdatedOn, UpdatedBy, BankCode, ReportingDisplayName, PrimaryContact, Address2, City, State, Zip, Telephone, EmailOptOut and PartnerServiceID, which can function as FK1, fields.SDBPartner590 can be functionally connected toSDBPartnerService570.
VI. SECURE PROFILE
• Secure Profile (SP) is a Web service or application that hosts web services that can utilize industry standard cryptographic technologies; provide means to create secure hashes; encrypt data; store encrypted data; retrieve the same; and log all access to the data. The data can be a structured record of information, or a binary (or basic) large object (a.k.a., “blob”) of information. SP can be provided as a standalone application so that it can be hardened, so that access controls can be tightened, so that access controls can be more granular than the applications that use it, such as CGW and DPE, described in detail herein. SP is not necessarily specific to identity management. SP can be used to store any type of information. SP solves a business need in the identity management space in that the security of the data is a core business principle. It is advantageous that a system utilizing SP can store and/or retrieve information at the subscriber layer, and SP can extend across different platforms and uses.
• SP facilitates core functions of an identity management system, namely, secure storage of information including audit and/or logging of all access to the stored information. SP can be useful, for example, when migrating existing users and/or accounts from an older system to a new standalone system. More specifically, for example, some known payment providers associated with the identity management system of the present invention could not properly manage data migration when moving existing users to a separate account. SP can, in an automated fashion, pull out records from a first system, store the records securely and deposit the records to a second system. For example, the first system can be part of an identity management provider, and the second system can be a payment provider.
• SP can be a callable service. SP is streamlined as compared to known systems for data migration. Examples of known, yet inferior systems include, for example, (1) reuse of an existing database system, i.e., SQL server; (2) couch-base (CB); or (3) Infinispan. For example, CGW can use a secure storage system for Personally Identifiable Information, such as SP. SP can be a standalone service oriented component providing encrypted audited storage of structured and unstructured information. SP can include a shared secret access feature.
• An example of Secure Profile within the context of an identity management system is provided, for example, inFIG. 1, which shows aSecureProfile Service6bwithin the integration/application services tier120.
• SP can include create read update delete (CRUD) functionality. SP can include an ETL (extract transform load) process. SP can be used independent of the data source. Because SP is so narrowly focused, it offers simplicity. In the field of security, simplicity wins out, as simpler systems are easier to examine data, confirm data, validate data and the like. SP does not require administrative and/or management tools or interfaces. SP is integration focused. SP can be employed using APIs. SP can support key rotation for Payment Card Industry (PCI) compliance. SP can be isolated and secure. The application and database can be detached from other systems of the identity management system. SP can be hosted elsewhere or in a different environment. SP can serve as a single interface to obtain desired information. SP can utilize four layers of control and access on top of the database itself.
• As a core function of the identity management system line of business, a need was identified to securely capture and store sensitive user information, ranging from SSNs to elements of Credit Card and financial accounts, to Passport details. This need presents an enormous risk to customers as well as in the event of a breach, both external and internal. While the identity management system ensures the safety and security of systems, the potential and threat for a compromise can still exist. To that end, a system was developed with the aim of reducing the risk of exposure of sensitive data, both through technology and process. This document describes the SecureProfile system, which is designed to address the need described thus far.
• Specifically, SecureProfile (SP) is a system that is designed as a repository of data with features and characteristics whose primary purpose is to ensure security and safety of the data which is stores. It offers the following features:
• • A mechanism to define arbitrary data artifacts or Structures which SP treats uniformly and transparently for the purposes of securing them.
  • Multiple containers of data that can be associated with individual Subjects known as Profiles.
  • A Profile in turn contains Records which have an associated Structure.
  • Ability to securely grant access to Profiles to other Subjects.
  • An audit log providing a detailed account of accesses (reading and writing) to any of the data housed within its Profiles.
  • Security-related algorithms and protocols (encryption, hashing, signing, and the like) that are configuration driven so as not to be locked-in to any fixed set.
  • Ability to securely and reliably exchange data between Subjects.
  • Support for shared-secret access to data. (A shared-secret is one where the secret is divided into multiple parts, m, and any subset, n, of those parts can be used to recover the original whole secret.)
  • Support for secured, externalized content.
• SecureProfile can be implemented as a standalone system with well-defined and constrained access mechanisms. As a stand-alone system, it allows reuse of functionality across multiple other systems (Web sites, integrations, tools, etc.) without hard-coding it or tying it any one system. It also facilitates a generic design to service multiple client systems and purposes.
Single Interface
• Many systems provide support for multiple methods of access and interaction, such as via a Web-based or Client-based UI, an API interface, and even direct access to the underlying data store (DB). This often makes it necessary to facilitate flexibility and convenience for working with a system. However, SP is designed to only support a single, well-defined access mechanism which helps limit the attack surface for compromising the system, and it also helps to ensure a focus on securing that mechanism. The access mechanism is an API interface that allows external client systems to interact with SP.
• However, the necessary flexibility and convenience to integrate with SP can still be achieved by building other specialized access points and integrations atop the API interface. This layering approach ensures that a single choke-point applies security protocols defined within SP.
Secure Context
• The API layer is the exposed shell that provides access into SP, and it in turn interfaces into a Secure Context, an environment session attributed to a single, known entity known as a Subject. A Subject (also known as a Principal) is an entity that represents a known individual user or system within SP that can access the SP system and can interact with other elements exposed by SP, such as Profiles and Records.
• As a first step to interacting with SP, a client first establishes a Secure Context by identifying itself and authorizing itself by presenting an authentication credential. This credential is used to directly unlock the Subject's identity and associate it with the Security Context. Further interaction with SP is implemented through the Security Context, which allows to always attribute any action (creating, reading, writing, and the like) against any entity (Subjects, Profiles, Records, and the like) to a known Subject. Security protocols and processes are also implemented within the Secure Context, again to create a single known choke-point against access to the SP system and the data it contains.
Encrypted Persistent Storage
• The Secure Context persists its durable entities to a back-end data storage which can be implemented as a relational database (i.e., SQL Server in the current implementation) or some other facility such as a collection of files or an alternative database technology (for example, BDB, BigTable, Hadoop, or any other suitable database technology). The common factor being that data written to and read from the persistent storage is controlled by a Secure Context and the persistent representation always guarantees encryption of the sensitive data (i.e., any user supplied data, potentially excluding meta-data added by SP).
• In this way the persistent storage is itself a black-box of information, which if isolated and stolen, would expose very little sensitive information without brute-force processing and attacking of the content.
Cryptographic Technology
• SecureProfile makes use of various cryptographic techniques, including symmetric encryption (secret key), asymmetric encryption (public/private key), secure hashing and shared secret to implement its supported features. As a general rule, SecureProfile does not employ any newly invented or crafted algorithms or protocols to support these techniques. Instead, it supports the application of any implementation that fits into a general framework for these techniques.
• Any data that is secured and persisted under the transformation of these techniques is tagged with metadata that will identify the correct reverse transformation to recover the original, insecure form of the data. The metadata is used to resolve a concrete implementation and any instance-specific parameters necessary to perform both the encoding, and if applicable, the decoding of such data. SecureProfile maintains a dynamic, configuration driven library of implementations that are known as transformers. These transformers generalize the majority of the various cryptographic techniques identified above, and allow SP to decouple it security mechanisms from specific algorithms and protocols.
• As an example, the following lists some specific transformer implementations that are supported by this framework:

• 	Secure Hashing
  		MD5
  		SHA
  	Symmetric Encryption
  		Triple DES
  		AES-256
  	Asymmetric Encryption
  		RSA
  		DSS
  		ElGamal

• FIG. 6.A illustrates one example of the Overall System Design of the Secure Profile system of the identity management system. The Secure Profile system can be adapted to provide secure storage of key-value attributes and structured records. The system can include the following features: any access can be tied to a known Principal, and operations can be logged and fully auditable.
• TheSecure Profile system600 can comprise adatabase system610, adata access system620, acontroller system630, acontext system640 and aservice system650, which can, in one example, include the Simple Object Access Protocol (SOAP)protocol652 and the Windows Communication Foundation (WCF)framework654. (SOAP is an XML based communication standard for structured remote procedure calls. WCF is a Microsoft .NET technology for building service-oriented applications.)
• Thedatabase system610 can be adapted to be isolated from other systems with more restricted access and Profile data can be “layer encrypted.”
• Thedata access system620 can be adapted to have atomic primitives providing fundamental data operations for system entities.
• Thecontroller system630 can be adapted to assemble and orchestrate data access primitives into higher level system functions.
• Thecontext system640 can be adapted to provide a stateful security context with a known acting Principal for requested operations.
• Theservice system650 can be adapted to expose client-accessible functionality over a supported remote-access technology.
• FIG. 6.B provides Primary Entity Definitions for one example of the Secure Profile system of the identity management system and illustrates the relationships betweenSubject660,Grant662,Profile664,Record666 andStructure668. For example, Subject660 can have a one-to-many relationship withGrant662,Profile664 can have a one-to-many relationship withGrant662,Profile664 can have a one-to-many relationship withRecord666 and Structure668 can have a one-to-many relationship withRecord666.
• ASecurity Subject660 represents a known Principal within the Secure Profile system. A Subject can be a person or another external system such as CGW or DPE. External interaction with the Secure Profile system (i.e., the Client) is performed as an authenticated Subject. Every Subject has a unique Subject-specific encryption key which is itself stored in an encrypted state and must be decrypted by the Client providing the correct decryption data.Security Subject660 can comprise one or more of a Globally Unique Identifier (GUID), Label and Encoded Subject Key.
• AGrant662 is an award to a Subject for access to a Profile. A Grant stores the Profile-specific encryption key which is itself encrypted using the Subject's own encryption key. Every Subject can have at most one Grant to any Profile, but can be awarded multiple Grants to multiple Profiles. Likewise, a single Profile can be accessible by multiple Subjects via multiple Grants.Grant662 can comprise an Encoded Profile Key.
• AProfile664 is an arbitrary collection of encrypted key-value pairs known as Properties. Regarding the term “encrypted,” please note that the values are encrypted; however, in one embodiment the keys and auxillary information about each key-value entry are not. Every Profile has a unique Profile-specific encryption key. In one embodiment, the unique Profile-specific encryption key is itself never stored directly (see Grant). Profile664 can comprise one or more of a GUID, Label and Key-Value Properties.
• AStructure668 defines an ordered arrangement of named elements. ARecord666 is an entry whose encrypted content is a structured collection of elements. A Record has an associated Structure which acts as a template allowing access to the individual elements encoded within. Please note that a Structure's definition is represented in a well-defined XML format; a Record's content is represented in a well-defined XML format that correlates with the Structure's XML format. Record66 can comprise one or more of a GUID, Label and Content.Structure668 can comprise one or more of Name and Definition.
• FIG. 6.C illustrates one example of Applied Encryption for the Secure Profile system of the identity management system. The legend in the bottom-left-hand corner ofFIG. 6.C discloses that the first symbol corresponds with a Secret Key named KeyName of a shared-key (symmetric) encryption algorithm, that the second symbol corresponds with a Public Key named KeyName of a public-key (asymmetric) encryption algorithm, that the third symbol corresponds with a Public Key named KeyName of a public-key (asymmetric) encryption algorithm, that the fourth symbol corresponds with Content encrypted using encryption algorithm with key named “KeyName” and that the fifth symbol corresponds with Content signed/hashed using algorithm named “SIG.”
• AClient670 authenticates itself to the Secure Profile System as atarget Subject660 by presenting a Subject Globally Unique Identifier (GUID) and the Authentication encryption key (AUTH)672. When successfully authenticated, the Client unlocks the Subject-specific encryption key. (GUID is a 128-bit number used in computer software to assign unique identifiers across multiple systems.)
• A Subject660 stores its Subject-specific encryption key (SUBJ), encrypted with the Authentication encryption key. Additionally, the hashed signature of the SUBJ key is stored to support validation of the AUTH key.
• AGrant662 is an intersection of aSubject660 and aProfile664. It stores the Profile-specific encryption key, encrypted with the Subject-specific key.
• The hash signature of the Profile-specific encryption key (PROF) is stored with theProfile664 for verification. ThePROF665ais used to encrypt theProfile Properties665bas well as child Records666 of theProfile664.
• SecureProfile (SP) can be adapted to support the addition of features to the CGW and/or the identity management system of the present invention. For example, to support addition of features of a system, such as the Vault 2.0 (formerly Wallet 2.0), to the core gateway (CGW), SP includes the ability to securely store arbitrary file content. As any sensitive content associated with a Subscriber is stored in the SP, it is also necessary to extend SP with facilities to efficiently transmit and store file content.
• Overview
• SecureProfile adds the concept of an Object as a new entity type which represents a securely stored blob of arbitrary data. The API to work with Objects is based loosely on the existing API of Records, except that instead of focusing on storing structured or semi-structured data as Records do, Objects are completely unstructured and able to store any stream of binary data. Because of this difference, the Object-related API and related elements can account for the special needs of potentially large streams of data.
• The primary difference that distinguishes Objects is that there can be a set of method calls to deal with creating, updating, deleting and retrieving Object details, and a second set of methods dealing with the reading and writing of the Object content.
• Client Enhancements
• As before, to facilitate the interface to the SecureProfile Web Services, a client-distributable library can contain helper classes and entity classes that support the new Object additions and simplify the interaction with the SP Web Service for any any SP client. As before, the primary entry-point to the client library is the Client class, and it is extended to support the new Object features.
• Client Helper Class
• The Client helper class can be extended with the following methods to help manage and retrieve Object details. This new API mimics the same interface that exists for working with Records. An example of code associated with this functionality is provided as follows:

• 	ObjectInfo[ ] ListAllObjects(Guid profileExtId)
  	ObjectInfo[ ] FindObjects(FindObjectsInfo findInfo)
  	ObjectInfo GetObject(Guid objExtId)
  	ObjectInfo SaveObject(ObjectInfo obj)
  	bool[ ] DeleteObjects(Guid[ ] objExtIds, bool faultOnError)

• It is noted that there is a single SaveObject method that is used for both creating new, and updating existing Objects, the same as with Records.
• In addition, the Client helper class can be extended with the following methods to help manage Object content.

• 	/** Preferred **/
  	void WriteObject(ObjectInfo obj, Stream inputStream)
  	void WriteObject(ObjectInfo obj, FileInfo file)
  	/** Preferred **/
  	void ReadObject(ObjectInfo obj, Stream outputStream)
  	void ReadObject(ObjectInfo obj, FileInfo file)

• The WriteObject methods are used to populate the content of an Object, and the ReadObject methods are used to retrieve the content of an Object. For both groups of methods, the form of the methods that take a Stream instance is highly preferable to a form that works with a FileInfo object. The latter form reads from, and writes to, a file on disk which must be accessible from where the client is calling. This implies that the client must take precautions to ensure the files on disk are secure, even if they are stored intermediately.
• However the Read/Write methods that work with a Stream usually do not have this stipulation as long as the backing store for the Stream is in-memory. For example, if the client is a Web site that supports users uploading and downloading files that in turn are stored in SP, then when a user uploads a file, the HTTP request input stream can feed directly to the WriteObject method that takes and inputs the Stream. Conversely, when a user downloads a file, the HTTP response output stream can be fed directly from the ReadObject method that takes an output Stream.
• Service Enhancements
• New Entities and Service Methods
• The SP API can be extended with the following method signatures to support the exchange of file content. (Concepts and details of usage follow.)

• 	ObjectInfo CreateObject(Guid profileExtId, string Label);
  	ObjectWriteInfo WriteObjectStart(Guid objExtId);
  	ObjectWriteInfo WriteObject(Guid streamExtId, byte[ ] data);
  	ObjectWriteInfo WriteObjectFinal(Guid streamExtId);
  	ObjectReadInfo ReadObjectStart(Guid objExtId);
  	ObjectReadInfo ReadObject(Guid streamExtId, long? count);
  	ObjectReadInfo ReadObjectAbort(Guid streamExtId);
  	bool[ ] DeleteObjects(Guid[ ] objExtIds, bool faultOnError);
  	ObjectInfo GetObject(Guid objExtId);
  	ObjectInfo[ ] GetAllObjects(Guid profileExtId);
  	ObjectInfo[ ] FindObjects(FindObjectsInfo findInfo);

• The following response and detail types can be added to support these methods.

• 	/// <summary>
  	/// Represents the details of a stored Object.
  	/// </summary>
  	public class ObjectInfo
  	{
  	public virtual Guid ExtId
  	{ get; set; }
  	public virtual Guid ProfileExtId
  	{ get; set; }
  	public virtual Guid CreatedBy
  	{ get; set; }
  	public virtual DateTime CreatedDate
  	{ get; set; }
  	public virtual Guid UpdatedBy
  	{ get; set; }
  	public virtual DateTime UpdatedDate
  	{ get; set; }
  	public virtual DateTime? DeletedDate
  	{ get; set; }
  	public virtual string Label
  	{ get; set; }
  	public virtual long? TotalSize
  	{ get; set; }
  	}
  	/// <summary>
  	/// A response message from the <i>WriteObject</i> family
  	of functions.
  	/// </summary>
  	/// <remarks>
  	/// This message acknowledges the start of a read sequence,
  	/// the reading of a segment of a complete object within
  	/// a read sequence or the completion/abortion of a read
  	sequence.
  	/// </remarks>
  	public class ObjectWriteInfo
  	{
  	public const long MAX_SEGMENT_LENGTH = 1024 * 1024;
  	public Guid StreamExtId
  	{ get; set; }
  	public Guid ObjectExtId
  	{ get; set; }
  	public long WriteOffset
  	{ get; set; }
  	public long WriteCount
  	{ get; set; }
  	public long WriteTotal
  	{ get; set; }
  	}
  	/// <summary>
  	/// A response message from the <i>ReadObject</i> family of
  	functions.
  	/// </summary>
  	/// <remarks>
  	/// This message acknowledges the start of a write
  	sequence,
  	/// the writing of a segment of a complete object within
  	/// a write sequence or the completion of a write sequence.
  	/// </remarks>
  	public class ObjectReadInfo
  	{
  	public const long MAX_SEGMENT_LENGTH = 1024 * 1024;
  	public const long MIN_SEGMENT_LENGTH = 1024;
  	public Guid StreamExtId
  	{ get; set; }
  	public Guid ObjectExtId
  	{ get; set; }
  	public long ReadOffset
  	{ get; set; }
  	public long ReadCount
  	{ get; set; }
  	public long ReadTotal
  	{ get; set; }
  	public long TotalSize
  	{ get; set; }
  	public byte[ ] Data
  	{ get; set; }
  	}

• To start with, in SP, the concept of files is more generalized to Objects such that any stream of bytes, regardless of how they are represented or manifested by the SP client can be stored and retrieved. In SP, Objects are analogous to Records which is the existing construct that lets you store a semi-structured fragment of content. While Records impose a requirement that the content be associated with and, conform to an associated, pre-defined Structure, Objects have no such requirement.
• Furthermore, Objects are more suited for, and provide for special provisions to support large content. Theoretically, SP Objects can be of any size, but in practice SP can impose some upper bound limitations to restrict abuse of the system and to provide for practical sanity checks. The client system to SP can further restrict these limitations of size, quantity and even the nature of the content itself (e.g., the client can restrict to image files, or files of known and expected MIME types, or of files that are under a predefined size limit, etc.).
• Aside from an optional Label, SP does not provide for storing any additional meta or reference data with an Object's content.
• The SP client system can develop its own system to store any such content as appropriate for its application and purposes, or it can couple a Record entry of one or more predefined Structure with an Object to encapsulate such information wholly within the SP system. The client can encode such data within the actual Object content stream provided the client does not need easy or ready access to such content prior to the decoding and retrieval of the object. Note, these are but a few examples of how to deal with such a requirement, and there are other approaches as well.
• Service Operation
• An Object within SecureProfile has two parts to its existence. The first part is an entry in the SP system that contains the unique identifier (ExtId or External Identifier as with all other entities in SP), the optional Label attribute, several audit-related attributes (time and user which created or last updated the Object), and the total size of the Object's content. The second part is the actual data or Object content.
• When working with Objects, the entry must first be created using the CreateObject method. This will assign a unique ExtId for the Object and associate the Object with a specific Profile. The Profile association determines the ownership and permissions transferred to the Object. Internally, the Profile also drives the encryption and security characteristics of the Object.
• Once an Object entry is created, the Object content can be uploaded or written using the WriteObject family of methods. These methods can, preferably, be used in a coordinated sequence to successfully and efficiently transmit an Object's content to SP. The write sequence can be as follows:
• 1. First, a WriteObjectStart call is made to initiate the write sequence for an existing Object ExtId. This creates a new and transient Write Stream with its own unique ExtId which will be used for the rest of the write sequence.
• 2. Next, one or more WriteObject calls are made for an open Write Stream ExtId to send subsequent segments of the Object content. The segments should be sequential and each segment must not exceed MAX_SEGMENT_LENGTH bytes of data.
• 3. Finally, after all Object content is transmitted, the WriteObjectFinal call is made to close an open Write Stream ExtId. This finalizes the write sequence and destroys the Write Stream ExtId.
• SP can be adapted such that SP does not provide any locking mechanism for Object writing or reading. Any such facility can be implemented at the client-side. Attempts to open two or more simultaneous Write Streams to the same Object can produce undefined results and can corrupt the Object content.
• The size limit imposed on a single Write Stream segment is to ensure fairness and availability for high volume network activity. The client can typically support this easily by implementing a sliding buffer window of a fixed size not to exceed MAX_SEGMENT_LENGTH. The client iterates through the content to be transmitted in increments of the buffer window, until the content is fully transmitted with the last transmission being of equal or smaller size than the buffer window.
• The Write Sequence should, preferably, be completed from start to finish in a timely manner. A Write Sequence can be tied explicitly to the active session that the client maintains with SecureProfile. If the session expires before the WriteSequence is properly completed, an implicit WriteObjectFinal can be performed to finalize and terminate the Write Stream. While it is theoretically possible to extend the Write Sequence indefinitely as long as a SP Session is maintained, in practice SP can impose further limits to time and size of a Write Sequence to ensure fairness and inhibit poor client implementations.
• The complimentary set of operations that allow an Object's content to be downloaded or read are the ReadObject family of methods and they are similar in structure and behavior to the corresponding WriteObject routine. The read sequence can be as follows:
• 1. First, a ReadObjectStart call is made to initiate the read sequence for an existing Object ExtId. This creates a new and transient Read Stream with its own unique ExtId which will be used for the rest of the read sequence. This initializes the read sequence at the start of the Object's content.
• 2. Next, one or more ReadObject calls are made for an open Read Stream Extid to request subsequent segments of the Object content. The call specifies the maximum segment size to retrieve and SP guarantees to send the next segment of requested maximum or less if the end of the Object's content is reached. The maximum segment size requested can, preferably, be at least MIN_SEGMENT_LENGTH but no more than MAX_SEGMENT_LENGTH.
• 3. After the last available segment of Object content is read, the next call to ReadObject will indicate no more content segments are available. Additionally, this last call will trigger SP to finalize the and destroy the Read Stream ExtId.
• 4. If the Read Stream should be finalized and destroyed prematurely before the whole of the content is to be transmitted, the client can use the ReadObjectAbort call to gracefully terminate the Read Stream.
• SP can be adapted such that SP does not provide any locking mechanism for Object writing or reading. While multiple simultaneous Read Streams can be opened and active for the same Object, any concurrent Write Stream activity on the same Object can produce undefined results and can corrupt the Object content and content returned from the Read Streams. Any locking facility should, preferably, be implemented at the client-side.
• Size limits imposed on a single Read Stream maximum segment length is to ensure fairness and availability for high volume network activity.
• The Read Sequence should, preferably, be completed from start to finish in a timely manner. A Read Sequence can be tied explicitly to the active session that the client maintains with SecureProfile. If the session expires before the WriteSequence is properly completed, an implicit ReadObjectAbort can be performed to finalize and terminate the Read Stream. While it is theoretically possible to extend the Read Sequence indefinitely as long as a SP Session is maintained, in practice SP can impose further limits to time and size of a Read Sequence to ensure fairness and inhibit poor client implementations.
• According to an embodiment of the present invention, a computer implemented method for a secure profile system for an identity management system can comprise: on a computer device having one or more processors and a memory storing one or more programs for execution by the one or more processors, the one or more programs can include instructions for: defining a structure; storing data associated with a profile, wherein the profile contains an object; securely granting access to the profile and a subject; configuring an audit log to provide an account of an access to data housed within the profile; implementing a security-related algorithm and protocol; exchanging data between two or more subjects; and providing secured, externalized content.
• The object can be a stream of binary data.
• The object can be a securely stored blob of arbitrary data.
• The object can be a record, wherein the record has an associated structure.
• The one or more programs can further include instructions for providing shared-secret access to data.
• The one or more programs can further include instructions for storing the data in a database system.
• The one or more programs can further include instructions for accessing the database system with a data access system.
• The data access system can comprise atomic primitives providing fundamental data operations for system entities.
• The one or more programs can further include instructions for: configuring a controller system to access the data access system; configuring a context system to access the controller system; and configuring a service system to access the context system.
• The database system can be isolated from the data access system, the controller system, the context system and the service system. The database system can have a level of access that is more restricted than a level of access for the data access system, the controller system, the context system and the service system. The data associated with the profile can be layer encrypted.
• The controller system can assemble and orchestrate data access primitives into higher level system functions.
• The context system can provide a stateful security context with a known acting principal for all requested operations.
• The service system can expose all client-accessible functionality over a supported remote-access technology.
• The service system can be adapted for use with an XML based communication standard for structured remote procedure calls.
• The XML based communication standard for structured remote procedure calls can be a Simple Object Access Protocol (SOAP) protocol.
• The service system can e adapted for use with Microsoft .NET technology for building service-oriented applications.
• The Microsoft .NET technology for building service-oriented applications can be a Windows Communication Foundation (WCF) framework.
• The one or more programs can further include instructions for rotating a key for Payment Card Industry compliance.
• The one or more programs can consist of instructions for operating the secure profile system with an application programming interface.
• According to an embodiment of the present invention, a computer system for a core gateway for an identity management system can comprise: one or more processors; and memory to store: one or more programs, the one or more programs can comprise instructions for: defining a structure; storing data associated with a profile, wherein the profile contains an object; securely granting access to the profile and a subject; configuring an audit log to provide an account of an access to data housed within the profile; implementing a security-related algorithm and protocol; exchanging data between two or more subjects; and providing secured, externalized content.
• According to an embodiment of the present invention, a non-transitory computer-readable storage medium storing one or more programs configured to be executed by one or more processing units at a computer for a secure profile system for an identity management system can comprise instructions for: defining a structure; storing data associated with a profile, wherein the profile contains an object; securely granting access to the profile and a subject; configuring an audit log to provide an account of an access to data housed within the profile; implementing a security-related algorithm and protocol; exchanging data between two or more subjects; and providing secured, externalized content.
VII. SECURE PORT SECURE SOCKETS LAYER (SSL)Overview
• The main public-facing Web site for the identity management system hosts multiple, Partner-branded sites served up from a single application (identity management system CGW). Due to a limitation of an internet information service, in this case, Microsoft'sIIS6, and the need to require multiple SSL certificates bound to a single IIS Site, a solution is implemented that integrates an SSL accelerator for hosting the SSL certs, and a custom ASP.NET HTTP Module that intercepts incoming requests relayed from the SSL accelerator to CGW. This solution is not limited to ASP.NET and can be adapted for use with any language or runtime environment.
Multiple SSL Certificates and Multiple IP Addresses
• Because one of the primary features of the identity management system CGW application is to support custom Partner-branding, it is necessary for each Partner site to appear as a stand-alone independent site, complete with a custom domain name and associated SSL certificate (EV). Microsoft'sIIS 6, the Web server that CGW currently is deployed upon, has a limitation where it can only support a single SSL certificate bound across HTTPS endpoints associated with a single IIS site.
• To overcome this limitation, the tier above the Web tier is utilized, at the load balancer (LB) appliance. The load balancer supporting the production environment also features SSL accelerator functionality, which includes the ability to host multiple SSL certificates, and direct traffic associated with each SSL cert to a target Web server (or servers). In the present case, SSL certificates associated with the CGW Partner sites are installed into the load balancer, and traffic associated with each of these certs is directed to the same CGW Web server end-point.
• Because an HTTPS request is completely encapsulated in an SSL connection, the typical HTTP protocol negotiation and exchange does not take place until after the SSL connection is fully established. This means that the normal HTTP protocol exchange of target hostname information, which is normally used to support virtual hosting, or the ability to serve up multiple distinct domain-named sites from a singly HTTP endpoint, is not possible when served over SSL. So a unique combination of IP address+listening port number is required to distinguish each target Partner site. To that end, a dedicated VIP (unique IP address listening endpoint) is provided on the load balancer for each Partner site. The dedicated SSL certificate is associated with that VIP on the load balancer, and then these VIPs are directed from the LB to the CGW application on the IIS servers.
SecurePort ASP.NET HTTP Module
• Because the load balancer hosts the SSL certificates, that also means that the LB terminates the secure SSL connections for each incoming client request. Relayed connections are therefore transmitted in the clear to the target IIS Web servers. This presents a problem to the CGW application because it detects whether incoming requests are secure or not, and if not forces a redirect to the corresponding secure connection. Because the client is directly interacting with the LB, and even when the client's connection is secured over SSL, the connection that CGW sees (coming from the LB) will be insecure, and thus CGW will always see an insecure connection and continuously redirect, causing an infinite redirection loop.
• To address this problem, a custom ASP.NET HTTP Module is developed known as the SecurePort Module. This module is installed early on in the CGW request processing pipeline and it is configured to detect certain characteristics of an incoming request connection, for example a special port or local interface IP address. When the incoming request connection matches on these parameters, it alters the current state of the request context to indicate that the connection is secure.
• In the production environment, the CGW application listens onports80 and81 on the local interface, which services the public-facing Partner sites (only reachable by the LB due to networking topology). The SecurePort Module is configured to flag incoming requests on port81 as secure.
DNS Issue for the Core Gateway (CGW)
• The Core Gateway can be used as the primary website for the identity management system and can have a URL with a format of {[identity management system trademark or name].[top level domain (TLD)]}, for example, EZShield.org, but one of its major features is partner-specific skinning and branding. The identity management system dynamically brands and styles the site and its identity for many different partners including, for example, banks and institutions.
• A part of that custom branding is the URL that takes a consumer to a particular partner-branded version of the site. The URL has to be unique to distinguish the target partner site. This both for technical reasons (the incoming URL requested directly determines what skin the CGW renders to the consumer), as well as to complete the custom-branded experience for the user.
• For example, the default site can be EZShield.org, that is a brand specific to the identity management system, which can include a self-standing, distribution channel for the identity management system suite of products. The identity management system can also have branded versions of the site that are skinned to match the look of several other properties or partners. The partner-branded version of CGW for such sites can have a URL in the format of [partner].[identity management system trademark or name].[TLD], for example, [partner].ershield.org, or [identity management system trademark or name].[partner].[TLD], for example, ershield.[partner].org. In this case the partner sites are just sub-domains of the default site.
• Some larger partners, such as, for example, banks, often desire an even more specialized URL to create an even more completely branded impression of the site. One example might have a URL in the format of [partner's security site].[TLD]. As can be readily appreciated, this at the other end of the spectrum from sub-domains and such URLs can have different TLDs. The CGW site has to support any variation of DNS names distinguished from the primary website (for example, EZShield.org).
• Now, CGW in and of itself has no problems supporting multiple distinct DNS aliases, but the problem comes in with SSL. Since CGW is a commerce site, sensitive user purchasing information is captured and in a secure manner, i.e., using an HTTPS session over SSL.
• The first problem is that CGW is an ASP.NET application and is hosted on Microsoft's IIS Web server and IIS has a strict limitation that each unique incoming end-point (that is, a combination of IP Address and Port Number where the IIS server is listening for incoming requests) can only support at most one SSL certificate.
• The second problem is that a channel partner can move over most or all of the Web properties that require secure connections to use Extended Validation (EV) SSL Certificates. These provide an extra level of assurance to consumers, and are so indicated by special decorations in today's most popular Web browsers (e.g., special coloring in the address bar). This very common practice today, especially for any site that is affiliated with the financial or security industries. They also cost quite a bit more because of the extra level of validation that the Certificate Authorities (CA) have to process and the extra level of assurance that they claim the guarantee.
• So, the first problem can actually be partially solved by something called a wild-card SSL certificate. This a cert that identifies a unique primary domain name such as ershield.org but also applies to any and all sub-domains *.ershield.org. This was the original and first solution. The problem is that it does not help with the banks that want a completely distinguished domain name.
• Instead still another type of SSL certificate called a Unified Communications Certificate (UCC) is utilized. This certificate makes use of an SSL extension known as the Subject Alternative Name (SAN) which can list one or more completely unique domain names in addition to the primary name identified by the certificate. So this certificate specifically addresses the issue.
• However, today, neither wild-card certificates, nor UCC certificates are supported by any issuing Certificate Authority with Extended Validation. So to use either one, the EV moniker would otherwise need to be abandoned for the CGW sites.
• So the next thing to consider is how can the CGW support multiple certificates, not just multiple names? Since IIS does not support more than a single cert, one alternative is to push the certificates one level up onto something that sits in front of IIS. A dedicated appliance known as an SSL Accelerator does just that.
• An SSL Accelerator is typically an appliance with specialized hardware for doing the SSL “stuff” very fast (channel negotiation, encryption, decryption, key exchange, and the like), so it's primarily used by sites with very heavy SSL traffic. But it can also solve the problem because most (perhaps all) accelerators can support the installation of multiple SSL certificates.
• It is found that it is quite possible existing load balancer(s) at the Savvis hosting provider can already in fact support the SSL Accelerator functionality. While not strictly concerned with the SSL acceleration features (a concern as traffic grows), it is determined that there is a need to know the following:
• • 1. What SSL Accelerator features the load balancer does support, specifically what limitations if any, on the SSL certificate types and number that can be installed?
  • 2. Are any limitations or concerns as far as load balancing and integrating with the Web server?
  • 3. Is there a need for additional supporting devices, software or configuration and are there any additional costs?
  • 4. If the existing load balancer does not meet the needs of the identity management system, what other options are available, what other devices can be integrated or upgraded, and how doitems #1, 2 and 3 above apply to them?
• Some things to keep in mind:
• • The idea is that potentially hundreds to thousands of partner-branded sites would be required, and each one will need at a minimum, a unique sub-domain, if not a primary domain. If the system continues to require EV certificates, then that means there will be a need to support hundreds to thousands of SSL certificates.
  • For these large numbers, appliances that support multiple certs at once are not necessarily needed. Realistically from a performance and an operations/systems management perspective, there can be a need to create clusters of the CGW environment that could each support say 100 to 200 partner brands (just speculating here, the number could be as low as 50 or as high as 500 depending on the number of customers each brand represents). So an appliance would only need to be capable of supporting this number of SSL certificates.
  • Alternatively there could be multiple end-points that service each cluster. For example, if a load balancer has a limit of 50 certs, but the system is cluster servicing 100 different partner brands requiring 100 diff certs, two IP addresses could be assigned to the cluster and two different load balancers (or sets of load balancers for redundancy) could be placed in front of that cluster, each with half the certificates.
• An example ofBasic Web Interaction1000 is shown inFIG. 10 (please note,FIG. 13 is a symbol key or legend forFIGS. 10-12). In one example of a Web site, two hosts representing theclient1010 andserver1020 communicate directly. On theClient Host1010, some process such as aWeb Browser1012 initiates connections to theServer Host1020. On theServer Host1020, a process such as aWeb Application Server1022 will receive these connections and establish a two-way dialog with the client.
• The client and server processes bind to networkEnd Points1024,1026 on their respective hosts, which are defined by an address and a port. The address uniquely identifies the host, and the port is tied to a specific process on that host.
• The client and server processes communicate using theHTTP protocol1030 which is normally an unsecure protocol (i.e., content and data are transmitted in the clear over the network). However a secure variation that is used over an encrypted connection is implemented with the SSL/TLS protocols to encapsulate and secure HTTP communication (known as HTTP Secure or HTTPS)1040.Ports80 and443 represent the standardlistening End Points1024 and1026 on aServer Host1020 that acceptHTTP communications1030 andHTTPS communications1040, respectively.
• The SSL/TLS protocols represent a mechanism to secure any communication over an insecure channel such as the public Internet. They are implemented using public key encryption, which includes a digital certificate—a document that represents the trusted identity of the party that possesses the certificate. This certificate is signed by a trusted third-party, and includes the symbolic name of the party being identified.
• In a standard HTTP over SSL/TLS, the Web Server will possess an SSL Certificate that will identify the server host using its symbolic DNS name. A Web client will typically initiate contact using the symbolic DNS name—a user-friendly, alpha-numeric name such as www.ershield.com. When the client interacts with the Web server over the clear HTTP protocol, the DNS name is simply a convenient naming convention, but when it interacts with the server over the secure HTTPS protocol, then the DNS name is integrally tied to the overall identity verification process associated with SSL/TLS communication.
• The Web Application Server process is typically a container that hosts different Web Applications. This container manages various infrastructure services such as network connectivity, request decoding and negotiation, resource utilization and delegation of specific Web requests to individual Web Applications. The Web Application Server exposes an environment and execution context to its hosted applications that reflects the attributes of the request, such as the target URL, the request origin, referral information and various runtime characteristics.
• The Web Application Server's responsibilities also typically include the low-level implementation of the HTTP protocol as well as the secure HTTPS variation. This implies the Web Application Server software in turn translates low-level protocol operations and data exchanges into higher-level constructs and concepts upon which Web Applications are built.
• Virtual Hosting and HTTPS Complications are demonstrated inFIG. 11. While a DNS name can be used as a friendly alias for a Web Host address, a DNS name does not have to represent a unique Web server host and indeed typically several related or distinct DNS names will map to a single server host.
• The HTTP protocol includes a provision for the target DNS name to be specified by the client when initiating a connection for an HTTP request. This name can then be used by the Web Application Server to dynamically resolve how to handle the request and to which Web Application the request should be delegated. This technique is known as “Virtual Hosting” and it allows a single physical Server Host, and more specifically a single Web Application Server process on that host, to service multiple requests that span different logical hosts. This technique is often used to adjust the branding or styles that are delivered as part of an HTTP response, or to execute an entirely different set of application logic (i.e., different hostnames resolve to different applications).
• However there is a limitation to this technique, in that it can only be used effectively with the unsecured variation of HTTP. This is due to the fact that with the secure form of HTTP, the SSL/TLS protocols are used to secure the HTTP communication by first establishing an SSL session and then encapsulating the HTTP protocol communication within that session. Because the Virtual Hosting mechanism is an HTTP-specific feature, it is not applicable or accessible by the SSL/TLS protocols when the SSL session is established. (NOTE: Server Name Indication (SNI) is an extension to the SSL/TLS protocols that allows a client to indicate the target hostname being contacted at the start of the SSL/TLS session negotiation. Unfortunately, it is not widely adopted or supported by client or server implementations of HTTP over SSL/TLS, and as such, its usefulness on the public Internet is very limited.)
• When an HTTP SSL session is first established, the server is required to send the SSL digital certificate to the client. Because it has no indication via which DNS name it was contacted (as with the Virtual Hosting technique), it must send the same single SSL certificate to the client for every request. This is why a single SSL certificate is effectively tied exclusively to a single End Point on a server host.
• A variation of Virtual Hosting that also works well with SSL/TLS involves assigning multiple addresses to a single Server Host and having the Web Application Server process bind to all of them. The Web Application Server process then manages all incoming requests across all the different End Points, across all the different addresses, and uses the End Point as a request attribute to distinguish the Virtual Host being targeted akin to the DNS name in the Virtual Hosting technique above. However, some Web Application Servers (e.g., IIS up to version 6.0) suffer from a limitation that allows only a single SSL certificate to be associated with any one Web Application. So regardless of via which End Point a request comes in, only a single SSL identity can be presented to the client.
• In such situations, thetypical approach1100 is to inject anintermediate network node1150 between anHTTP client host1110 and anHTTP server host1120, which is shown, for example, inFIG. 11, such as another Host or a network relay device that can support SSL termination on behalf of the real Server Host (e.g., a network load balancer or SSL accelerator). In this scenario, theintermediate node1150 hosts one ormore SSL Certificates1152 and is assigned one or more End Point addresses1156. TheSSL Certificates1152 are assigned to the different End Points1156. Asunsecure HTTP communication1130 andsecure HTTPS communication1140 are received by theintermediate node1150,secure HTTPS communication1140 is decrypted and then both the decrypted HTTPS traffic and anyclear HTTP traffic1130 is relayed to thereal Server Host1120 via itsown End Point1124, using theclear HTTP protocol1160. TheHTTP client host1110 can comprise aweb browser1112, and theHTTP server host1120 can comprise aweb application server1122.
• Request Filtering and theSecurePort Module1200 are shown, for example, inFIG. 12. The final technique described inFIG. 11 is adequate in many situations; however, there are still scenarios that will ultimately fail with this configuration. Specifically, a Web Application that hosts and collects sensitive data will often require a user to connect to it via a secure connection. A Web Application will detect the method used for incoming connections by inspecting various attributes of the context and environment that the Web Application Server process exposes to it.
• For most Web Application Server platforms (e.g., Java Web Servlets, .NET Framework ASP.NET, the CGI interface) a simple Boolean attribute is made available to indicate if the connection is secure and an encrypted communication channel is established with the client. If the channel is not secure, any interaction that exchanges sensitive data will usually force the Web Application to first send a redirect directive back to the client, specifying that the same request should be repeated over a secure channel.
• For example, let's assume a client requests a simple URL that wants to display a user's bank account summary which would include sensitive information such as account numbers and current balances. They can initiate such a request with this sample URL:
• http://www.samplebank.com/BankAccounts/AccountsSummary
• As you can see this URL indicates a clear HTTP request as indicated by its leading scheme value of “http:”. When the target Web Application that this URL request is relayed to receives this request, it will detect from the hosting container that the request is insecure and send a directive back to the client to retrieve the same request over a secure channel. The Web Application will send back this URL:
• https://www.samplebank.com/BankAccounts/AccountsSummary
• This is the same URL except that the leading scheme value of “https:” now indicates a secure channel. However, in the configuration outlined inFIG. 12, when the client repeats the request using this new URL, it will go through the same chain of events, from client, to intermediate network node, to the server, and ultimately resolve to the same insecure request at the server end as before. Once again the Web Application will detect the insecure request and send the client a redirect to the secure variation. At this point an endless loop has been configured which will prevent the server from ever completing the request.
• In this case, the solution is to alter the context information that is exposed to the Web Application by the Web Application Server process. As an example, one specific technique involves injecting afilter component1290 into the request processing pipeline of theWeb Application Server1222, a mechanism supported by many platforms (e.g., Java Web Servlets, .NET Framework ASP.NET). Thisfilter1290 can be configured such that it can detect some characteristic of the incoming connection being relayed by theintermediate node1250 as an indicator of a connection that originated as secure.
• For example, as is typical of such devices, theintermediate node1250 can be configured to relay connections that were originally secure on an alternate port to the server (for example port81). Another approach simply involves tagging the HTTP request itself with additional information to indicate the security aspect of the connection. For example, the leading portion of an HTTP request allows for the inclusion of various name-value pairs, known as headers. In most cases, the client and server restrict themselves to the set of standard, well-known headers specified in the HTTP protocol specifications, but a properly configured relay device could add a custom header, for example, with the name X-IsSecure: that supports a simple set of values true and false. The relay device would inject this header and an appropriate value into the relayed communication stream back to the server. (The relay device would also need to filter out any such headers that can be transmitted from the client that can be an attempt to spoof the server into misinterpreting connections that were originally insecure.)
• To go along with this configuration on the relay device, a filter, let's call it the “SecurePort Module”1290 would need to be installed and configured on theserver host1220. It would need to be configured in a complementary fashion to the relay device to pick up on the characteristics that indicate an original secure connection, and upon detection of such characteristics alter the context that is exposed to the Web Application. TheHTTP client host1210 can communicate with the HTTPintermediate node1250 via HTTP (clear)1230 and/or HTTPS (SSL/TLS)1240 communications protocols. The HTTPintermediate node1250 can communicate with theHTTP server host1220 via HTTP (clear)1260 and/or alt HTTP (clear)1270 communications protocols, which are connected to theHTTP server host1220 viaend points1224. Theend points1224 can be located onports80 and81,ports80 and81 can bound to theSecurePort Module1290, and theSecurePort Module1290 can be functionally connected with or integrated into theWeb Application Server1222 of theHTTP server host1220.
• In accordance with one embodiment of the present invention, a computer implemented method for managing communications for a web site, can comprise: on a device having one or more processors and a memory storing one or more programs for execution by the one or more processors, the one or more programs including instructions for: processing information from multiple web sites served up from a web application, binding multiple secure socket layer (SSL) certificates to a single site supported by the web application, hosting the SSL certificates using an SSL accelerator, and intercepting incoming requests relayed from the SSL accelerator to the web application with an HTTP module.
• The one or more programs can further include instructions for: hosting client information using an HTTP client host, relaying connections using an HTTP intermediate, hosting server information using an HTTP server host, communicating between the HTTP client host and the HTTP intermediate via an unsecure protocol and via a secure protocol, and communicating between the HTTP intermediate and the HTTP server host via an unsecure protocol and via an alternate unsecure protocol.
• The HTTP client host can comprise a web browser.
• The HTTP intermediate can comprise an HTTP relay process and an SSL certificate bound to a port adapted for communication via the secure protocol.
• The HTTP server host can comprise the HTTP module.
• The HTTP server host can comprise a web application server.
• The web application server can comprise the web application.
• The HTTP module can be adapted to communicate with the unsecure protocol through a first port, and the HTTP module can be adapted to communicate with the secure protocol through a second port.
• Information from the HTTP intermediate can be transmitted to the web application server via the HTTP module.
• Information from the web application server can be transmitted to the HTTP intermediate via the HTTP module.
• The HTTP module can be configured to function as a filter.
• The HTTP module can be configured to function as a filter and detect a characteristic of an incoming connection being relayed by the HTTP intermediate as an indicator of a connection that originated as secure.
• The web application can be an internet information service.
• The internet information service can be Microsoft'sInternet Information Service6.
• In accordance with one embodiment of the present invention, a computer system for managing communications for a web site can comprise: one or more processors; and memory to store: one or more programs, the one or more programs can comprise instructions for: processing information from multiple web sites served up from a web application, binding multiple secure socket layer (SSL) certificates to a single site supported by the web application, hosting the SSL certificates using an SSL accelerator, and intercepting incoming requests relayed from the SSL accelerator to the web application with an HTTP module.
• In accordance with one embodiment of the present invention, a nontransitory computer readable storage medium storing one or more programs configured to be executed by one or more processing units at a computer can comprise instructions for: processing information from multiple web sites served up from a web application, binding multiple secure socket layer (SSL) certificates to a single site supported by the web application, hosting the SSL certificates using an SSL accelerator, and intercepting incoming requests relayed from the SSL accelerator to the web application with an HTTP module.
VIII. URL MATCHEROverview
• UrlMatcher is a component that can be added to an ASP.NET site to allow an operator of the identity management system to more easily define and manage URL matching and manipulation rules.
Vanity URLs
• The initial justification for developing this component came out of a need to better support vanity URLs on the CGW platform. Because CGW is built atop DotNetNuke and because DotNetNuke has some limitations with the way URLs can be defined and the way it manages them, an independent approach is developed to support vanity URLs.
• Initially vanity URLs were supported through IIS's own Virtual Directory feature, where one would define a VDir and map it to a URL redirect (instead of a file path) to the target page within the CGW site. While this approach mostly works, the proliferation of VDirs in the IIS manager is cumbersome and hard to maintain, and it pollutes the administration window when managing the IIS site.
• Also, it means that each vanity URL defined is global across all Partner sites, and you cannot remap a particular vanity URL to mean different things for different Partners. For example, a common vanity URL defined /starthere can be provided that maps to the PSS (see Section XI below) landing page of the identity management system. It currently always maps to the original PSS landing page, but it might be useful for newer partners to always default to the alternate PSS landing page (which does user lookup by Personally Identifiable Information (“PII”) instead of Activation Code). With VDir, this is not an option.
• The need to support vanity URLs more easily was compounded with release 2.2.0 when the alternate PSS activation was first introduced. With this new enrollment method, it is important to be able to quickly support Retailer-specific vanity URLs and there can be quite a number of Retailers per Partner site.
Partner Site Aliases/Redirects
• A second use for the UrlMatcher is supporting redirects for alternative domains (host aliases) for the identity management system's Partner sites. For example, it can be the case that the Partners have a primary host alias, which is used to determine the skinning and branding that the CGW platform delivers, where the URL is in the format of [partner].[identity management system trademark or name].[TLD]. Examples are:
• • [partner].ershield.com
  • www.ershield.com (the default site).
• But in addition to these primary host aliases, alternate host aliases can be defined that redirect back to the primary. For example, “www” can be added in the format of www.[partner].[identity management system trademark or name].[TLD], for example, www.[partner].ershield.com. Other possibilities include a simplified URL in the format of [identity management system trademark or name].[TLD] such as, for example, ershield.com, or alternate TLDs such as, for example, ershield.org or www.ershield.org.
• Using the identity management system, these maps are managed and redirected through a combination of DNS entries (which cannot be avoided) and unique IIS sites are set up on each PROD server for each primary host alias (which can and should be avoided). The use of IIS features is cumbersome, and a pain to manage. Additionally, there are some patterns of aliases that exist for every Partner site (and often are the only alternate aliases), and it would be advantageous to avoid the need to define them for each one, but simply support a single pattern definition to cover them all.
• In order to solve the problems noted above, UrlMatcher was developed, which the identity management system to support vanity URLs more easily and readily and with better specificity and flexibility.
• The UrlMatcher is implemented as an ASP.NET HttpModule/HttpHandler, and it is initially targeted for the CGW app site, but can be reused as needed elsewhere. The component adds support for inspecting incoming requests, matching different elements of the request (usually the URL, but also cookies, params, client IP, and the like) against pre-defined patterns (static values or regex patterns), and then taking some action, such as executing a URL rewrite, a client redirect or transfer to another page within the current site. The patterns or “rules” can be defined in a file on disk, but can also be moved to the database so they are centrally managed and can benefit from an appropriate admin tool.
• A further problem with this approach was encountered. The whole point of vanity URLs is to define a short, user-friendly symbolic name that can be appended to one of the domains owned by the operator of the identity management system, for example, www.ershield.com/starthere or deluxe.ershield.com/[partner], that will take the user to some predefined location or landing page that is normally more cryptic to address directly or that can change over time. One of the problems with using the UrlMatcher is getting IIS to send these URLs to the UrlMatcher in the first place. UrlMatcher is an ASP.NET component, and in order for IIS to send an incoming request to the ASP.NET subsystem, one has to define a rule in IIS6 which tells it which ISAPI Plugin (more accurately, which ISAPI Extension) should handle the request.
• IIS6 supports only two different kinds of such rules—file-extension matching rules or send everything rules. (II7 changes this model completely—it has a much tighter and more native integration with ASP.NET to begin with and these rules are actually defined in the ASP.NET configuration for a given site.) So ASP.NET integration under IIS6 is normally implemented with the file-extension matching rule, and when ASP.NET is installed it adds many of these rules (.aspx, ashx, .asmx, .svc, and the like) to IIS6 for a given site. The problem here is that the vanity URLs do not work with these rules because there is no file extension. The other rule type “send everything” can be used instead—it means that IIS6 will send every request it gets for the target site to ASP.NET, then the UrlMatcher will get a chance to inspect every request. However, this has a negative impact on performance since it means that requests for assets (such as images, Flash files, videos, static on-disk files, and the like) will also have to go through ASP.NET instead of being served directly by IIS.
• So, the only other option that IIS6 provides is ISAPI Filters. Filters are another IIS-native component (written in C or C++)—they also inspect every incoming request, but are much more lightweight (i.e., do not invoke the whole ASP.NET processing pipeline). A Filter can be written to match some pattern (such as 1-segment paths with no extension like the vanity URL format described above) and given that pattern, do something that will make IIS pass that request to ASP.NET and thus the UrlMatcher system.
• Ionic's Isapi Rewrite Filter (IIRF) is an ISAPI filter. The primary purpose of IIRF is to do request URL matching and then redirect or rewrite the request. So with IIRF, vanity requests are matched, and rewritten with some extension. Then, that extension can be mapped and handled by ASP.NET, and UrlMatcher can process them.
• For example, the extension “.vanity” is to be processed by ASP.NET:
• • User sends a request for http://www.ezshield.com/starthere
  • IIRF matches the path part /starthere against regex ̂/[̂Λ·?]$ which describes a single-segment path with no extension (the UrlMatcher also tests for ̂/[̂Λ·]?·$* which is an extensionless, single-segment request with query-string parameters)
  • IIRF rewrites the request as /starthere.vanity
  • IIS6 matches the request and hands it off to ASP.NET
  • ASP.NET sends the request through to UrlMatcher
  • UrlMatcher matches the request to one of its rules and takes action, redirecting to some other URL such as /Default.aspx?tabname=ProvisionalLandingPage
  • If UrlMatcher does not match the request to a rule, then it proceeds through to the normal ASP.NET request processing pipeline
One Example of Implementation Details
• The code and redistributable binaries for UrlMatcher can be provided in a common repository as a part of a core library.
• The UrlMatcher module is preferably integrated into CGW as part of the library dependencies and configuration for the site.
• IIRF needs to be installed and configured with IIS. According to the identity management system, a site-specific configuration file for CGW can be defined and included in the CGW codebase. It references an external config file that is found in the target deployment environment (e.g., DEV, QA, STAGE, PROD, and the like) that defines the environment-specific configuration.
• UrlMatcher is implemented as a collection of components, that include an ASP.NET HTTP Module and HTTP Handler. The Module is a required element that must be included and configured in any site that will use UrlMatcher. The Handler is an optional component that allows usage of UrlMatcher in an alternate mode of operation, which can improve its performance and reduce its intrusion into an ASP.NET application under certain circumstances.
• UrlMatcher can be made available as a set of redistributable binaries (and/or source code) as part of a core library, which can be provided in a common repository. UrlMatcher has some dependencies on other core libraries and components for basic services like logging and templating support. A redistribution folder for UrlMatcher can be adapted to contain the necessary components including its own dependencies.
Configuring an ASP.NET Web Site/Web App
• Note, in this example, UrlMatcher has already been integrated into the identity management system CGW application.
• After obtaining the necessary components described above, the components can be added to a site's/bin folder. The web.config file needs to be configured, for example, as follows:
Define Config Section Handlers
• Add customer handlers for the UrlMatcher configuration sections. Add the necessary lines to the <configSections> element, for example, as follows:

• 	<configSections>
  	<!-- Add this section: -->
  	<sectionGroup name=“EZShield.Web”>
  	<section name=“UrlMatcher” type=
  	“EZShield.Web.Config.UrlMatcherConfiguration,
  	EZShield.Web.UrlMatcher” />
  	</sectionGroup>
  	</configSections>

Enable the HTTP Module and Optional HTTP Handler
• Next, add the UrlMatcher HTTP Module into the <httpModules> section, for example, as follows:

• 	<httpModules>
  	<!-- Add this line: -->
  	<add name=“UrlMatcherModule” type=
  	“EZShield.Web.Modules.UrlMatcherModule,
  	EZShield.Web.UrlMatcher” />*
  	</httpModules>

• UrlMatcher supports two different mechanisms of servicing incoming requests. The first uses the ASP.NET request events and intercepting them from the HTTP module (configured above). The second approach is an alternative that uses HTTP Handlers. (The differences between these two approaches are detailed further below.) If one is using the second approach, then one will need to add the following line to the <httpHandlers> section, for example, as follows:

• 	<httpHandlers>
  	<!-- Add this line: -->
  	<add verb=“*” path=“*.vanity” validate=“true”
  	type=“EZShield.Web.Modules.UrlMatcherModule,
  	EZShield.Web.UrlMatcher” />
  	</httpHandlers>

Configuring UrlMatcher
• Finally, add a new section in the web.config file that specifically configures UrlMatcher operation. Provided below is a sample entry. More details follow concerning the various options:

• <EZShield.Web>
  <!--
  - To enable UrlMatcher you MUST also register an HttpModule and
  optionally an HttpHandler.
  - If registered as a Handler, you must disable Module processing by
  adding the following
  - attribute to this configuration:
  -  evaluateOn=“NONE”
  -
  - To test against Session-related details, evaluate at a later
  - phase of the HttpApplication life-cycle by adding following attribute:
  -  evaluateOn=“PostAcquireRequestState”
  -  forceSession=“True”
  -->
  <UrlMatcher rulesSrc=“~/../../IIRF/EZShieldCGW-UrlMatcher.xml”
  onRuleSrcFail=“FAIL_ONCE”
  allowReloadConfig=“True”
  allowShowConfig=“True”
  allowShowDebug=“True”
  allowShowHelp=“True”
  />
  </EZShield.Web>

• UrlMatcher Configuration Options

  	Name	Details
  	rulesSrc	Required. Specifies an absolute or site-relative
  		path to a “Match Rules” definition file.
  		If prefixed with a leading ~/, the path is
  		resolved relative to the site root (i.e., the
  		folder containing the web.config file).

• The UrlMatcher matching rules can be defined in a centrally-located .xml file.
• UrlMatcher is a matching engine and goes through each rule defined for each eligible request (eligible requests are defined outside of UrlMatcher, see discussion above).
• Basically, every <Match> entry in this file is a rule to test against. If the rule test evaluation is true, then the associated “action” is applied, and it can be any number of things like a redirect or rewrite, or an instruction to continue evaluating the next rule, or to evaluate a sub-group of child rules.
• For this particular request, there is a section of rules for PSS2- and SSS-specific vanity URLs.
• After the rule file is updated, if the CGW site is already running, one needs to add an instruction to the UrlMatcher to reload the rule file. The rule file will always be reloaded from disk when the site is first started up or restarted, but if the site is already up and it is not desirable to restart it, one or more special URLs can be used to access administrative functions of the UrlMatcher, for example, as follows:
• • http://<hostname>/showconfig.umx
    • Displays the current rules that are loaded in UrlMatcher.
  • http://<hostname>/showhelp.umx
    • Displays helpful info about what values can be specified for different elements of rule definitions as well as runtime context information that can be tested against.
  • http://<hostname>/reload.umx
    • Reloads the rules from the rules definitions file.
• The <hostname> can be any host that resolves to that target CGW IIS instance, so, for example, www.qa.dev.ershield.local is a URL that resolves to the QA server instance—the function of UrlMatcher is not affected by the choice of hostname being used as long as it resolves to the desired site.
• The last URL is used to reload the matching rules if they are changed on disk, and the first URL can be used to verify that it is loaded. The second URL is helpful when authoring rules.
• In one embodiment, the URL Matcher defines a rule-based mechanism to evaluate actions based on incoming Web requests and Web application context attributes.
• URLMatcher Request Processing1400 is shown, for example, inFIG. 14. The URL Matcher can be implemented in any Web application platform that supports an extension mechanism to intercept or delegate Web requests. The key component of the URL Matcher is the request processor which is the integration point of the URL Matcher to its hosting Runtime (such as a Java Servlet container or the .NET Framework's ASP.NET Runtime).
• The URL Matcher will accept each Web request that the hosting Runtime will resolve as destined for the Matcher component. For each request, the Matcher will resolve a Match Context (MCTX) which captures all the attributes and elements of the request and application that can be accessed by the URL Matcher.
• The Matcher will iterate through its set of preconfigured Rules, testing the request against each rule in turn. Every Rule is defined by two features:
• • Match Test—a description of something about the Match Context that should be tested against
  • Match Action—some operation that should be invoked upon a successful
Match Test
• Match Tests can be defined by any of the following elements:
• • An evaluation kind that determines how the test should be evaluated, such as an equality test
  • An attribute of the Match Context to test against, such as a URL path
  • An argument value to resolve the test against, such as a comparison value
• Match Action can be defined by any of the following elements:
• • An action kind that determines what action to perform, such as a client redirect
  • An attribute of the Match Context to resolve the action against, such as the original hostname
  • An argument value to resolve the action against, such as a fixed path
• The URL Matcher is configured with a collection of one or more Rule Sets, which is an ordered sequence of Rules. An initial, Top-level Rule Set represents the starting collection of Rules that all evaluations will begin with. Every Rule in a Set can optionally define its own nested Rule Set, known as a Child Rule Set. Depending on the kind of Action configured on a Rule, a successful test can invoke further evaluation of Child Rules.
• When a Rule Match Test evaluates successfully (i.e., a Match is found), the Matcher will evaluate the Rule's Match Action. Depending on the action kind, the Action can allow for altering one or more attributes of the Match Context. The Match Context represents state of the request being processed and so any alterations to the Match Context by any one Rule will persist for subsequent Rule evaluations. In this way Rules can build upon Rules to produce a cumulative effect of a final transformed Match Context.
• A Match Action can also support the notion of Child Rules (see Step1445), which allow grouping of Rules for further, conditional evaluation. In this way, Rules and Rule Sets can define a complex hierarchy of Rules.
• Lastly, a Match Action's specific operation will be invoked (see Step1455). It can take an attribute of the Match Context as an argument, such as a path segment or request scheme. Additionally it can take a static or computed value as an additional argument to resolve the final operation. Finally, if the Match Action kind supports the notion of Continuation (see Step1460), then after the Action is invoked, the Matcher will advance to the next Rule (see Step1465) following the successfully matched Rule and continue to process the request as before. If the matched Rule is the final Rule in a Child Rule Set, then a Continuation will advance the Matcher to the parent Rule Set at the next Rule that follows the parent Rule that defined the current Child Rule Set.
• However, if the matched Rule specifies an Action that does not support Continuation (see1468), or the Matcher has reached the end of Rule Set, then the Matcher's processing of the current request is complete, and it will return control to the hosting Runtime from which it was invoked (see Step1470).
• The URLMatcher Request Processing1400 can comprise a series of steps as follows:Begin Request Processing1410; Capture Request and Application Context; Resolve the Match Context (MCTX)1415; Resolve Set of all Top-Level Rules1420; Evaluate MCTX against a First Rule; Evaluate current Rule's Test againstMCTX1425; If the Rule Does Not Match, then Advance to thenext Rule1430 and evaluate MCTX against the next Rule; If the Rule Does Match, then evaluate whether Action supportsContext Updates1435; If Action supports Context Updates, then Update MCTX against Action Attribute andValue1440 and go toStep1445; If Action does not support Context Updates, then evaluate whether Action supportsChild Rules1445; If Action supports Child Rules, then Advance to first Rule inChild Set Rule1450, evaluate MCTX against the next Rule and go toStep1425; If Action does not support Child Rules, then InvokeAction1445; If Action supportsContinuation1460, then Advance to next Rule in current Set or next Rule inparent Set1465, evaluate MCTX against the next Rule and go toStep1425; and If Action does not supportContinuation1468, then End Request Processing; return control to hostingRuntime1470.
• Sample Implementation in ASP.NET and Modes of Operation is shown, for example, inFIG. 15. While the concept and design of theURL Matcher1500 is truly platform agnostic, one embodiment targets the ASP.NET Runtime of the .NET Framework.
• The .NET Framework is itself hosted in a containingWeb Server1510, such as IIS. IIS receives an incoming request from a Web client, such as a Web browser, and appropriately handed off to theASP.NET Runtime1520, when the request is detected as targeting an ASP.NET resource.
• Within the ASP.NET Runtime, the URL Matcher would be registered as anHTTP Module1530 or anHTTP Handler1540. In the former case, everyrequest1525 will be passed to the URL Matcher to be inspected. In the latter case, only certain requests that match some pre-configured set offile extensions1535 will be passed to the URL Matcher. These are two modes of operation for URL Matcher on the ASP.NET Runtime:
• • As anHTTP Module1530—a component that can be registered to intercept every request to the ASP.NET Runtime for different events in the request processing pipeline. The ASP.NET Runtime defines numerous events during the course of a request, such as the start of the request, the authentication phase, or the session resolution phase. The URL Matcher can be configured to process the request at any one of these events, and the ASP.NET Runtime will pass every request through the URL Matcher during that event phase.
  • As anHTTP Request Handler1540—a component that can be registered to intercept only specific requests that include a path that matches a specific file extension. This mode of operation is much more efficient because it only passes a subset of requests through the URL Matcher, however it is also much more restrictive since it limits the requests that can be processed by matching complete files or file extensions.
Implementation Samples
• The following table lists a set of attributes of a Match Context that are accessible when evaluating a Match Test and/or evaluating a Match Action.

• TABLE 1
  Match Context Attributes accessible for testing a Match
  or invoking an Action

  		Ac-
  URL/Request Attribute	Match	tion	Description
  IsDebug	√		Whether the current rule
  			(or all rules) are enabled
  			for debugging.
  Url	√	√	The complete request URL.
  HttpMethod	√		The client's HTTP transfer
  			method, such as GET,
  			POST or HEAD.
  IsAuthenticated	√		Whether the current
  			request is authenticated.
  IsLocal	√		Whether the current request
  			is from the local computer.
  IsSecure	√		Whether the current request
  			uses secure sockets (HTTPS).
  AuthenticationType	√		The type of authentication
  			used to identify the current
  			user, or empty string.
  UserIdentity	√		The Windows logon name for
  			the current user, or empty string.
  RequestPath	√		The virtual path of the current
  			request, including the PathInfo.
  RequestFilePath	√		The virtual path of the current
  			request, excluding the Pathlnfo.
  RequestPathlnfo	√		Additional path information for
  			a resource with a URL extension.
  RequestPhysicalPath	√		The physical file system path
  			corresponding to the requested
  			URL.
  RequestReferrerUrl	√		The URL of the client's previous
  			request that linked to the current
  			URL.
  RequestUserAgent	√		The raw user agent string of
  			the client browser.
  RequestUserHostAddress	√		The IP host address of the remote
  			client.
  RequestUserHostName	√		The DNS name of the remote
  			client.
  Path	√	√	The full, absolute path of the
  			request URL.
  Authority	√	√	The DNS host name or IP address
  			and the port number.
  DnsSafeHost	√		The unescaped host name that is
  			safe to use for DNS resolution.
  Fragment	√	√	The escaped URI fragment of
  			the request URL.
  Host	√	√	The host component of the
  			request URL.
  HostNameType	√		The type of the host component
  			of the request URL (Unknown,
  			Basic, Dns, IPv4, IPv6).
  IsDefaultPort	√		Whether the port value of the URL
  			is the default for this scheme.
  PathAndQuery	√	√	The combined Path and Query
  			separated by a question mark (?).
  Port	√	√	The port number of the URL.
  Query	√	√	The query information of the URL.
  Scheme	√	√	The scheme name of the URL,
  			converted to lowercase.
  UserInfo	√	√	The combined username and/or
  			password associated with the URL.
  UserName	√	√	The username associated
  			with the URL.
  Password	√	√	The password associated
  			with the URL.
  Headers: UrlPartArg	√		The name/value collection
  			of Headers.
  Cookies: UrlPartArg	√		The name/value collection of
  			Cookies (names and values only).
  QueryParams:	√		The name/value collection of
  UrlPartArg			Query Parameters (GET).
  FormParams:	√		The name/value collection of
  UrlPartArg			Form Parameters (POST).
  ServerVariables:	√		The name/value collection
  UrlPartArg			of IIS server variables.

• The following table lists the kinds of Actions that can be specified by a Rule.

• TABLE 2
  Supported Actions

  	Action Kind	Description
  	ReloadConfig	This action indicates to the UrlMatcher
  		module to reload the configuration that
  		it uses to define its matching rules and actions.
  	ShowConfig	Renders the current Match Rules configuration
  		being evaluated by the UrlMatcher.
  	ShowHelp	Renders a response that provides a references
  		to aid in configuring the match rules.
  	Continue	This action indicates to continue the matching
  		process with the next rule in the current rule group.
  	Exit	This action indicates to stop the matching process
  		and allow the request to continue past the
  		UrlMatcher module.
  	Terminate	This action indicates that the request should be
  		terminated immediately but all buffered
  		output should be flushed.
  	Disconnect	This action indicates that the request should
  		be terminated immediately and abruptly
  		by disconnecting from the client.
  	Redirect	This action indicates that the request should
  		respond back with a client redirect to the
  		path indicated in the associated Action Path.
  	Rewrite	This action indicates that the request URL
  		should be rewritten to the path and query of
  		the current MatchContext.PathAndQuery property.
  	Transfer	This action indicates that the request should be
  		server-transferred to the handler resolved by
  		the associated Action Path.
  	Execute	This action indicates that the request should
  		be server-executed by the handler resolved
  		by the associated Action Path.
  	MatchRules	This action indicates to the UrlMatcher to
  		process the request against the nested
  		children Match Rules configurations.

• Two example kinds of Match Tests are a Value Comparison and a Regular Expression (Regex) Evaluation. For each of these Match kinds, the following table lists the test-specific options that can be specified to control how the Match Test is evaluated.

• TABLE 3
  String Compare Options

  	Option	Is Default
  	CurrentCulture
  	CurrentCultureIgnoreCase
  	InvariantCulture
  	InvariantCultureIgnoreCase
  	Ordinal
  	OrdinalIgnoreCase	√

• TABLE 4
  Regex Compare Options

  	Option	Is Default
  	None
  	IgnoreCase	√
  	Multiline
  	ExplicitCapture
  	Compiled
  	Singleline
  	IgnorePatternWhitespace
  	RightToLeft
  	ECMAScript
  	CultureInvariant

• FIG. 16 represents a sample configuration ofRules1600 showing a Top-level Rule Set1610, which contains aChild Rule Set1620, which itself contains anotherChild Rule Set1630. That is, the present system can utilize nested loops to increase the complexity and functionality of the URL matcher request processing system and method.
• In accordance with one embodiment of the present invention, a computer implemented method for matching a URL with one of a plurality of web sites, the computer implemented method can comprise: on a device having one or more processors and a memory storing one or more programs for execution by the one or more processors, the one or more programs including instructions for: capturing an HTTP request and a Web application context, resolving a match context for the HTTP request and the Web application context, resolving a set of top-level rules for evaluating the HTTP request and the Web application context, evaluating the match context against a first rule among the top-level rules, and invoking an action for modifying one or more of the HTTP request, the Web application context, and the match context.
• The one or more programs can further include instructions for: evaluating the first rule against the match context, and advancing to a next rule if the first rule does not match, determining whether an action supports context updates and updating the match context against an action attribute and value if the action supports context updates, and determining whether the action supports child rules and advancing to a first rule in the child rule set if the action supports child rules.
• The one or more programs can further include instructions for: determining whether the action supports continuation, advancing to a next rule in a current set of rules or a next rule in a parent set of rules if the action supports continuation, and ending HTTP request processing and returning control to a hosting runtime when the action does not support continuation.
• The computer implemented method can support vanity URLs.
• A core gateway of an identity management system can comprise the one or more programs.
• The one or more programs can further include instructions for: iterating through a set of preconfigured rules and testing the HTTP request against each rule in turn, wherein each rule is defined by a match test and a match action.
• The match test can be a description of an attribute of the match context that should be tested against.
• The match action can be an operation to be invoked upon a successful match test.
• The match test can be defined by one of an evaluation kind that determines how the test should be evaluated, an attribute of the match context to test against, and an argument value to resolve the test against.
• The evaluation kind can be an equality test, wherein the attribute is a URL path and wherein the argument value is a comparison value.
• In accordance with one embodiment of the present invention, a computer system for matching a URL with one of a plurality of web sites, the computer system can comprise: one or more processors; and memory to store: one or more programs, the one or more programs can comprise instructions for: capturing an HTTP request and a Web application context, resolving a match context for the HTTP request and the Web application context, resolving a set of top-level rules for evaluating the HTTP request and the Web application context, evaluating the match context against a first rule among the top-level rules, and invoking an action for modifying one or more of the HTTP request, the Web application context, and the match context.
• In accordance with one embodiment of the present invention, a nontransitory computer readable storage medium storing one or more programs configured to be executed by one or more processing units at a computer can comprise instructions for: capturing an HTTP request and a Web application context, resolving a match context for the HTTP request and the Web application context, resolving a set of top-level rules for evaluating the HTTP request and the Web application context, evaluating the match context against a first rule among the top-level rules, and invoking an action for modifying one or more of the HTTP request, the Web application context, and the match context.
IX. BREACH SOLUTIONS
• In some embodiments, the identity management system and method further comprises breach solutions methods, as described in detail below:
• IX.1 Abstract
• IX.2 Example 1: Assist Module
• IX.3 Example 2: Prepare Module
• IX.4 Example 3: Combined Assist and Prepare Modules
• IX.5 Detailed Descriptions
IX.1 Abstract
• Small businesses suffer proportionately more than their larger counterparts due to their inexperience in preparing for and responding to these threats. For example, nearly three quarters of U.S. small businesses experienced a breach attack in 2010 (source: Symantec 2010 SMB Information Protection Survey—Global: June 2010). Small businesses tend to be under-resourced and overwhelmed by countless regulations. Most solution providers are focused on consultative enterprise breach solutions that are much too expensive for smaller businesses to consider. This leaves a large underserved market increasingly vulnerable and progressively more targeted by security threats.
• The identity management system is adapted to include a suite of tailored, customizable security and breach solutions designed to meet a small business's evolving security requirements both before and after a breach incident. One example of such suite is EZSHIELD's SYCURITYMAX Solution, which can include one or more elements of SYCURITY Assist and/or SYCURITY Prepare. The identity management system's breach preparation service offers assistance in creating catered breach response plans that addresses both regulation compliance and security best practices relative to an individual business's profile, enabling a business to act quickly and completely when confronted with a breach threat. With Safe Harbor, PCI, Red Flag, and HIPAA compliance in mind, the identity management system offering produces value and keeps ahead of the most critical regulatory requirements across individual small business industries.
IX.2 Example 1Assist ModuleDescription of ServiceAccess to Assist Portal
• The Assist Module can be provided as part of a customer's annual subscription. The customer's registered representative can access a secure web-based Assist Portal (“Portal”) 24/7 to self-assess Customer's potential risk of exposure, create a security and privacy protection plan, and access employee training materials.
Security Score Self-Assessment
• This assessment will serve as a best practice evaluation in the area of Personally Identifiable Information (“PII”). The assessment will walk Customer through a series of questions pertaining to the policies and procedures it has in place based on Customer's industry and the PII it collects. The results of the assessment will provide Customer with a guideline to determine areas of improvement in its PII protection practices. This assessment will touch on Red Flag, Health Insurance Portability and Accountability Act (HIPAA), Payment Card Industry Security Standards (PCI) and EU-US Safe Harbor compliance (allowing data transfer between the United States and the European Union) needs in addition to general best practices in information security.
Security and Privacy Planning
• Customer will receive access to a portfolio of various policy, procedure and process templates. These templates help the Customer ensure that appropriate levels of security are in place. Together, these various documents then serve as the Customer's working security and privacy plan.
• • Security and Privacy Policy
  • Back-up and Recovery Process
  • Vendor Due Diligence Process
  • Red Flags Compliance Process
  • Employee Screening and training policy
Employee Security and Privacy Training Materials
• The Security and Privacy Training portion of the Assist Module allows the Customer to educate its employees on the importance of protecting their customers and their fellow employees' personal information. “Small Business Employee Privacy Training” can be provided to the Customer, for example, in the form of a PowerPoint presentation focused on Privacy and Security imperatives that employees need to know and do. Also included are a post-training quiz, employee sign-off form, and quarterly newsletters to keep Customer's employees' security and privacy knowledge up to date.
IX.3 Example 2Prepare ModuleDescription of Service
• The Security Prepare service (“Service”) can include the following:
Prepare Materials
• Prepare services help Customer to prepare for how it can handle a breach incident should one occur. There are three sub-areas to this service that can be leveraged to help guide the business through identifying a process flow it can execute in the event of a breach incident. The following materials can be made available:
• • Incident Response Plan
  • Victim List Template
  • Incident Response Sheet
Incident Response Plan
• In order to meet tight timelines for notification of victims once a PII Breach is recognized, certain materials and processes need to be pre-positioned for action, including:
• • incident response process;
  • incident response team roles and contact information;
  • specified data breach “assessment and escalation policy”; and
  • prepared notification messages.
Victim List Template
• Customer is given access to a victim list template form allowing Customer to assess pre-breach incident, how it will execute delivery of this information for a faster turnaround time should an incident occur, mitigating potential legislative risks.
Incident Response Sheet
• The Customer is provided with an incident response sheet to use as a guide in outlining the various information points that will be required to determine an effective and compliant notification plan should a breach occur.
Supplemental Services
• Customer can purchase consulting services (to identify issues or concerns with Customer's proposed data breach response policies and procedures) and/or training services (to implement Customer's data breach response policies and procedures).
Notification Plan Recommendation
• Upon Customer's report of a Breach Incident and completion of a Breach Incident Response Report, Customer can be provided with a Breach Assessment Report which will provide a recommendation as to the course(s) of action Customer should take based on the facts provided and available at the time of the Breach Incident Response Report is submitted. The recommendation can include a notification requirement of Customer's breach victims.
Locked Pricing of Identity Theft Protection Services for Customer's Victims
• Customer can have locked-in, preferred pricing for restoration, monitoring and other identity theft protection services for its breach victims. Preferably, these costs shall not be increased even if the cost of such services should increase over time.
Notification Plan Development Implementation
• Should Customer decide to order notification services and notification plan implementation, the company implementing the identity management system and Customer can negotiate and enter into a services agreement identifying how the company will notify Customer's data breach victims and others of a data breach declared by Customer and how Customer will be charged for such services (“Service Agreement”).
• The Prepare services preferably include, without limitation:
• • a dedicated breach specialist to assist Customer in response process;
  • identifying data breach victim's contact information and a data transfer protocol;
  • notifying breach victims or others of the subject data breach by phone, e-mail and/or letter (per applicable laws);
  • recommendations of notification based on current state and federal incident response regulations;
  • assistance with notification messaging and customer call center scripting;
  • managing the breach response web-site and toll-free call-in number;
  • providing breach victims Customer-sponsored access to Consumer Services; and
  • defined Notification costs and Consumer Services package/pricing.
• Except as otherwise stated in the Service Agreement, preferably, Customer is billed for each breach response provided by the identity management system on a per-victim basis (for both victim contact and the Consumer Services package given).
• Notification to Adhere with Applicable Laws
• The identity management system will implement Prepare per applicable breach notification laws (“Laws”) and maintain prepared Breach Response materials so that they are compatible with current Laws. The Prepare system is adapted to incorporate future changes in applicable Laws.
Victim Notification
• As directed and purchased by Customer, the Prepare system is adapted to notify breach victims of the breach by at least one or more of the following methods (per applicable laws):
• Electronic Mail Service: The Prepare system can e-mail affected persons with Customer's written notification.
• Paper Mail Service: The Prepare system can provide black and white mailers posted using standard rates for notification letters (including printing, addressing, assembly, postage and mailing).
• Phone Service: The Prepare system can notify affected persons, provide information and offer a live call center representative. Automated telephone services are available, but such communication does not constitute effective data breach notification in all states. A toll-free number for breach victims will be provided to serve as a primary contact. Customer service representatives work with victims to guide them through the enrollment process and help with any questions.
• Breach Website and Call Center: A web page and a toll free phone number are preferably provided in order to provide instructions for online enrollment in victims' identity theft protection program, if applicable.
• Location Services: The Prepare system can be adapted to help find the most current addresses of Customer's breach victims as directed by Customer for an additional charge.
IX.4 Example 3Combined Assist and Prepare Modules
• The Assist and Prepare Modules can be provided in a combined package including one or more of the features described in detail in Examples 1 and 2 above.
IX.5 Detailed Descriptions
• Security Assist—Self Assessment and Score
• • The subscriber has created an on-line account and enrolled in the Assist service
  • The subscriber sees a series of questions that are weighted with a scoring value and has an opportunity to answer “yes” or “no” to each question as it is presented.
  • The subscriber reviews each question and completes the entire set of questions presented during the assessment.
  • When the assessment is complete the subscriber sees a calculated score for the assessment
  • The subscriber also sees a customized action plan based on the values entered during assessment
• The Score/Assist solution is anchored by the first step in the process which is the self-assessment questionnaire.
• FIG.7.A—Screenshot—Security Assist Assessment—Get Started
• The assessment is divided into 18 subject matter areas. The subscriber is presented each of the these subject areas in sequence in the form of a question such as: “Does this subject area apply to your business operation?”
• • (I) A subscriber can determine that the presented subject area does not apply to their business operation, in which case;
    • 1) the subscriber would acknowledge with “no skip this area”.
    • 2) the application would note the exclusion of this subject matter area from the business profile
    • 3) the application would present the subscriber with the next subject matter area, again in the form of a question as to its application to the business operation.
• FIG. 7.A shows an example of a computer display screen according to one embodiment of the identity management system and method of the present invention. The display screen can comprise two tabs, one for “My Identity” and another for “My Business,” which is selected in the present example. The horizontal bar at the top of the screen including the two tabs can include links to “CONTACT,” “MY ACCOUNT” and “LOG OUT.”
• Within the “My Business” tab, a navigation bar can be provided on the left side of the screen, which can include branding for the Security Assist Assessment tool, for example, “DELUXE PROVENT^SM Identity Theft Protection” and “4Biz.” The navigation bar can include a statement concerning the start date for the customer's service, for example, “Protected since December 2011.” The navigation bar can have a “REPORT A BREACH” button, a “MY RESTORATION” box with an option for expansion of the field and an option to access a help screen designated with a question mark, (“?”) logo, a “MY BUSINESS WALLET” box with an option for expansion of the field and an option to access a help screen designated with a question mark, (“?”) logo. The navigation bar can include Sycurity Assist navigation bar including “Step 1: Self-Assessment,” “Step 2: Privacy & Security Planning” and “Step3: Employee Security Training”
• The top of the “My Business” tab can contain a second horizontal navigation bar including “My Dashboard,” “My Business Wallet,” “Sycurity Assist,” “Sycurity Prepare” and “Report A Breach” tabs, of which, in the present example, “Sycurity Assist” is selected. The “Sycurity Assist” sub-screen can include a banner (“Sycurity Assist” and “Protect Your Business Identity” in this example), an identification noting the user's progress through the system (“Step 1: Self Assessment Plan” in this example), a prompt to the next step (“Step2” in this example), and an introductory message with a button prompting the user to “Get Started With My Self Assessment Plan.” The bottom of the “Sycurity Assist” sub-screen can include further navigation links and branding associated with the company and/or third party evaluations of the present website (corporate service mark, corporate logo, TRUSTe logo and the Better Business Bureau (BBB) logo, in this example).
• FIG.7.B—Screenshot—Security Assist Assessment—Subject Area “Your Business Office”
• • (II) A subscriber can confirm that a subject area applies to the business operation being assessed.
    • 1) by annotating the subject matter area with “yes (does apply)”
    • 2) the application will deliver a series of subject matter area detail questions
    • 3) the subscriber will acknowledge each detail question with a “yes” or “no/unsure” answer
    • 4) the application captures the response state of “yes” or “no” for each question
• FIG. 7.B includes the features ofFIG. 7.A described above except the identification noting the user's progress through the system (“Step 1: Self Assessment Plan” in this example) no longer includes the prompt to the next step (“Step 2” in this example), and the content below this point now includes the first of several questions from the system, in this example, “QUESTION 1 of 18.” The screen can include two clickable buttons including the text “YES” and “NO—Go to next question,” which trigger the next logical step in the process as appropriate for each answer.
• FIG.7.C—Screenshot—Security Assist Assessment—“Your Business Office” Assessment Area
• • 5) after the completion of detail questions in subject matter area, the application presents the subscriber with the next subject matter area.
• FIG. 7.C follows when “YES” is selected in the screen corresponding withFIG. 7.B and the content of the screen is the same as that set forth inFIG. 7.B except that sub-questions relating to the first question are displayed and a “Next” button is provided at the bottom of the list of sub-questions.
• The application saves the state of the question subject matter area when the subscriber proceeds to the next question subject matter area.
• The subscriber can stop progress through the assessment and return again to the point last saved in the process.
• The subscriber will proceed through the subject matter areas, identifying those that apply and confirming or denying the detail questions as in process (I) or (II) above.
• Upon completion of the assessment the application calculates an assessment score and presents this to the subscriber. (See technical description)
Security Assist—Self Assessment Action Plan
• Upon completion of the assessment the application generates a customized security action plan for the subscriber.
• The action plan is customized based on the responses provided by the subscriber during the self assessment. For each of the subject matter area detail questions that are identified as unresolved by the subscriber, a corresponding recommended action is included in the action plan. (See technical description).
Score Building Technical Description
• Scoring is based on tiers. Each tier represents a percentage of total possible weight. Tiers are currently evenly designated in 20% ranges (e.g., 0-20, 20-40, 40-60, 60-80 and 80-100). The term weight is used because certain assessment areas are deemed to have more or less impact than other areas. A higher weight indicates more impact and a lower weight indicates less impact. Using a tiered score based on a percentage allows for the number of questions and their weights to vary as necessary.
• Each possible answer to a question in the assessment is given a weight. The sum of all weights is the total possible weight. The sum of weights for each answer given in the affirmative is divided by the total possible weight. The resulting percentage then is evaluated to determine into which tier the assessment results belong.
• The diagram below shows how a score is calculated. This assessment has two questions.Question 1 has 4 sub questions.Question 2 has 6 sub questions. The weights for each question are shown in parenthesis. An x indicates the user responded affirmatively for that question. The Score system uses weights for sub-questions when the parent question is answered affirmatively. The weight of the parent should equal the sum of the weights of its children. The Score system uses the weight for the parent question when it is answered negatively. This latter indicates a section does not apply; therefore, it should not impact the score.
• • The total possible weight is the sum of all parent weights.Question 1 has total 9 possible weight.
  • Question 2 has total 6 possible weight. A complete total weight of 15.
  • The user responded affirmatively for question 1-3(weight=4) and question 1-3(weight=4). Total=5.
  • The user responded affirmatively for question 2-1, 2-2, and 2-5 (weight=1 for each). Total=3.
  • Combining these (5+3=8) and dividing by complete total weight (15) results in 0.53 or 53%.
  • This percentage falls intoTier 3.
• FIG.7.D—Data Diagram—Score Calculation
Security Assist—Action Plan Technical Description
• An action plan is based on any assessment parent questions responded to affirmatively, and that its sub-questions responded to in the negative. For each question, a corresponding action text is prescribed. The action plan is built dynamically based on the current collection of user responses.
• Each question has action text associated. For any question which the user responded to negatively for any sub-question, the action text of the question appears as a section header. This usually more generalized in nature. The action text related to the particular sub-question which was responded to negatively is then added for more specific directions.
• Using the previous diagram as a basis for an action plan, the Assist system displays a document containing the following:
FIG.7.E—Data Diagram—Action Plan AssociationsMore Robust and Customized Assessment and Action Plan Development
• The subscriber's “My Account” page collects a deeper profile of the subscriber's business, i.e.,
• • Size of business
  • # of employees
  • Industry
  • Retail or wholesale
  • Locations (storefronts, websites)
  • The scope and nature of customer/client Personally Identifiable Information (PII) Data collected as part of the business processes
  • Payment handling processes/credit line
• If the user has not completed this profiling segment, they are directed to a list of profiling questions via the “Custom Action Plan Management” utility.
• When user enters the assessment, the application determines which sections of self-assessment are relevant based on the profile data provided and tailors the presentation accordingly.
• • Over time, as changes are made to the business profile, the assessment logic provides recommendations for further self-assessment or re-evaluation of past self-assessment subject areas.
• A subscriber provides the following key pieces of information in the business profile.
• • No of employees: between 2 and 5
  • Business Type: Retail
  • Industry: Consumer Merchandise
  • Storefronts: Brick/Mortar (1), Self-hosted website(s)
  • Payment Methods Supported: Credit Card (on-line), Credit Card (point of sale (POS)), Line of Credit, Account Debit Transaction
Customized Assessment System Description
• Identification of discrete values and related business logic are determined. Implementation of UI, storage mechanism, and rules engine are dependent upon this information.
Custom Action Plan Management
• The business has the ability to manage/organize what can has been completed and what still needs to be completed from the action list.
• • User completes assessment and is taken to the customized action plan
  • The action plan provides
    • an area for commenting for each task
    • A complete/uncompleted button
    • The ability to delete certain actions
    • Date and time log of when the task was completed
    • Ability to set a ‘due date’ for individual tasks
    • The ability to set reminder alerts for specific tasks for individual tasks to variable email address (Send reminder on X date); reminder includes ‘due date’ where applicable
      Dynamic Location based Vendor recommendation for individual Action Plan tasks
• When the user completes the assessment and receives the customized action plan, for every task listed, the identity management system provides a recommended vendor to contact for assistance in completing the action. This recommendation would be determined by the business location(s) (as determined by the ‘My Account’ page profiling) and a cross referenced table of vendors
• Example:

• TASK: Install Firewall
  Location: New York, NY
  Vendor X: (Based on vendor location and task asked)
  [recommended vendor's name]
  [recommended vendor's address]
  [recommended vendor's phone number]
  info@blahblah.com
  [recommended vendor's URL]
  Use Promo Code: [code such as a corporate branded code] for 10% off
  [recommended vendor's name]

Dynamic Vendor Recommendation Technical Description
• Alternate/additional vendors can be available for display or search. If multiple vendors exist for a given area, an order of precedence can be established based on factors such as rank, physical distance, company size (revenue or # employees), or other factors.
Custom Tailored Employee Education Video
• On the portal the subscriber is taken through an exercise where they can edit an educational security video for employees. The video is constructed of various “segments” which can be slightly altered (Images and selected copy content that appear thought out) Examples: Video title, Title date, Contact information “who to go to internally with any questions”, Select images (i.e., Employee desk).
Custom Video System Description
• Live action segments, text-to-voice for the configurable meta information, dynamic diagramming or animation can be utilized.
• Streaming or downloading can be utilized while considering factors such as storage space requirements, authoring and delivery technology, and other details.
• Employee Security Self-Education Module (with Quiz)
• Biz uploads an employee list into the identity management system Portal.
• • List stores employee first name and last name
  • Subscriber generates a link that can be distributed to the employees where:
  • Employee is validated via login (leveraging the uploaded employee list)
  • Employee sees an educational video about security
  • Following the video, the employee is given a quiz testing him/her on the video just viewed
  • System dynamically generates an Employee Quiz score upon completion:
    • If the user passes, they are messaged that they passed (w/ score) and they are done
    • If the user fails, they are messaged as such and told to re-view the video and loop back though the test
• System stores the date and time that the user had completed the test and the corresponding score.
• Business can set email alerts to notify them when (a) user(s) have completed the test.
• Business can expire/delete the link/page or delete/turn off an employee's access by editing the employee list.
Employee Training System Description
• Existing platform security can be configured to allow automatic creation of “limited” accounts. The quiz engine can either be integrated or custom-built. Additional logic can be introduced as needed.
Security Prepare—Automated Breach Simulation Generator
• As part of breach preparation, the platform generates example breach scenarios that could affect the small business leveraging a combination of the information from the business “my account” profile page, and answers to a couple of questions:
• • Where the business's customers are located
  • What type of information the business collects
  • The contact information the business has for its customers
  • Where the information is collected (i.e., Online, store, restaurant, office)
  • Where it is stored
• The business uses the output of the generator to pose a sample scenario to the breach incident response team, who then gets together to determine how they should respond to the breach. The simulator gives a high level description of a breach incident:
• • How the breach occurred (i.e., Hacking, stolen computer, lost jumpkey, and the like)
  • What information was taken
  • Where the victims reside
  • How many victims were affected (by state)
• Once the team has communed and decided what they would do in the scenario, they are quizzed by the platform on a series of multiple choice questions:
• • Does this incident require notifications be sent to the victims?
  • Does the incident require victim ITP services?
  • Are there any other groups that need to be notified? (i.e., state attorney general)
  • What are the requirements of the notification by state?
  • How many types of notifications need to be created?
  • What is the method of notification?
  • What are the notification timeline requirements?
• The business breach incident response team submits the quiz answers and receives a score. The business is shown a list of the incorrectly answered questions along with the correct answer highlighted. For every incorrect answer, there is a brief description of the reasoning behind the correct answer, i.e., MA state law requires that notifications go out within 48 hours after the incident was discovered.
Simulation Generator System Description
• Security Prepare—Breach Response Action Plan Generator
• As part of breach response, the platform generates a high level roadmap of what is required in the handling of a particular breach incident.
• The subscriber begins with a list of multiple choice and free form questions, providing information about the incident:
• • When did it happen?
  • How did it occur?
  • Was it malicious intent?
  • What information was compromised?
  • How many victims by state?
  • What contact information does the company have for the victims? (USPS, email, or phone number)
  • How did the business acquire this victim information? (through a vendor, online, in store, etc?)
• The user submits the answers and is provided an outline suggestion of what to do:
• • Is notification required? (by state—breach compliance requirement)
  • What is the timeline requirement for notification (by state—breach compliance requirement)
  • What are the notification guidelines (by state)
  • Are victim protection services (ITP) required (by state)
  • If victim ITP is not required, was the breach still bad enough that the business should still seriously consider offering Victim ITP?
    • What type of ITP is recommended?
  • How should the business notify the customer?
  • Sample notification letter(s) which incorporate the information provided by the business from the breach questionnaire and business my account profile page
  • A list of the relevant parties that need to be notified (State attorney general office, 3rd party vendors) and associated contact information and any other standard requirement (i.e., A copy of the notification(s) must be sent to the State attorney general of Vermont)
• A checklist accompanies the recommendation to assist the business in ensuring it does not miss anything. The checklist should date and time stamp the items as they are checked off.
• • Conduct forensics to identify what has happened
  • Triage to ensure the breach has stopped and will not happen again
  • Communicate the breach details to internal parties (customer service, legal, it, Officers, PR, and the like)
  • Commune breach incident response team
  • Draft notifications
  • Produce notifications
  • Distribute notifications
  • Store a copy of notifications
  • Manage returned mails
  • Set up a call number for when victims have questions
• An automated estimate of what it will cost to produce, manage and send the notifications (based off the generated suggestion) should be shown to the business. If they want to proceed with the identity management system performing this service, there should be a submit button, and TandC checkbox that the business can click. Upon submitting this, an automated alert should hit the identity management system internal breach service team with the details of the incident and the business contact information to contact the small business and begin working the incident
• A copy of the breach incident details (from the questionnaire, recommendation, and time stamped checklist) can be stored in the business's identity management system account for the business to access at any time in the future as needed.
X. IDENTITY ALERT MANAGEMENT (INTERACTION WITH CLIENT ALERT TO RESOLUTION SPECIALIST)
• Problem this Solves
• When personal information is discovered and linked to a customer's identity, the Identity Alert Management system allows the end user to control and flag that information as “approved records” or “threats”. If the data is approved, it is marked as a verified record, if it's not approved and causes concern to the customer, a case is created until that data is clarified or resolved to the end consumer's satisfaction. Once a case is resolved it's added, with full comments and documentation to the updated Secure Profile.
• In short, the Identity Alert Management system solves the issue that everyone has an “identity profile” but not everyone's profile is accurate and verified by the end consumer. This helps to assure that PII that is found and monitored is as accurate as possible and confirmed by the end customer.
Short Description of Solution
• All of the competition in the identity theft space scans for new information and presents it to the user. The Identity Alert Management system allows the end user to interact with the discovered personal information and allows them to approve the records or flag the record as wrong. If a record is flagged as wrong or is not understood by the user, then a case is immediately created and followed up on through a Restoration Process.
• FIG. 8 illustrates an example of User Flow of Fraud Solution Process according to the Identity Alert Management.FIG. 8 is an overview. FIGS.8.A-8.E are expanded views as noted inFIG. 8.FIG. 8.A is the legend for the Figure,FIG. 8.B is the upper portion of the Figure,FIG. 8.C is the center-left portion of the Figure,FIG. 8.D is the center-right portion of the Figure, andFIG. 8.E is the bottom portion of the Figure.
• As illustrated, for example, inFIG. 8.A, the user interface utilizes a color code, where yellow represents a medium-level or potential-threat condition, e.g., “Potential Threat: New Identity Related Information found, must be reviewed,” where red represents a high-level or reported threat condition, e.g., “Case Created, Reported Threat” and where green represents a low-level or reviewed and approved threat condition, e.g., “Reviewed and Approved Record by Account Owner.” Although, yellow, red and green are used in this example, any suitable color or visual queue can be used.
• InFIG. 8.B, the step associated with the text “PII is found against elements of your identity” and Steps A, B and C (see alsoFIGS. 9.A,9.B and9.C, respectively) are yellow conditions. Step D (see alsoFIG. 9.D) is a green condition. Step E (see alsoFIG. 9.E) is a red condition.
• InFIG. 8.C, Step F (see alsoFIG. 9.F), the step associated with the text “Case Managed by EZS with signed Power Attorney” and the step associated with the text “Case is rejected or incomplete—case is reactivated” are red conditions. Step G (see alsoFIG. 9.G) and the step associated with the text “Case Resolved by Specialist, pending approval and final sign off from Customer” are yellow conditions. The step associated with the text “Case is approved by Customer, the records are moved into ‘Approved Records:” is a green condition.
• InFIG. 8.D, Step F (see alsoFIG. 9.F), the step associated with the text “Case Managed by EZS without signed Power Attorney,” the step associated with the text “Case is rejected or incomplete—case is reactivated” and Step K are red conditions. Step H (see alsoFIG. 9.H) and the step associated with the text “Case is resolved by Customer, pending approval and final sign off from Resolution Specialist” are yellow conditions. Step I (see alsoFIG. 9.I) is a green condition.
• InFIG. 8.E, Step J (see alsoFIG. 9.J) is a green condition.
• It is noted that Steps A-K, illustrated, for example, inFIG. 8, correspond with FIGS.9.A-9.K, respectively.
Step A: Email Alert Email is Sent to Customer
• FIG. 9.A (see also Step A) illustrates an example of a potential threat email notification according to the Identity Alert Management. Although presented as an email notification, any other suitable format via any suitable communication method can be used including, for example, a web page, a plain text or SMS notification, a physical letter delivered through a mail system or a private party service and the like. Regardless of the format and mode of communication, the notification can comprise one or more of a corporate logo, a telephone number, a warning banner, the name of the user, a list of suggested actions, a button linking the user to a log in screen, the name and identification information of the company offering the service, and a website URL.
• Step B: Customer Logs into Dashboard and Sees Alert
• FIG. 9.B (see also Step B) illustrates an example of a dashboard including an alert according to the Identity Alert Management. The dashboard can include one or more of a horizontal status bar displaying a current identity protection level with a percentage associated with the level of the current identity protection level for the user, which can include a scale from 0 to 100 percent graded along 25 percent intervals. The color of the bar associated with the current identity protection level can transition through different colors associated with certain levels of the current identity protection level. For example, red can be used at a lower end of the scale, yellow can be used in the middle of the scale and green can be used at the higher end of the scale. Other color combinations can be employed. Also, the right side of the current identity protection level status bar can include an icon showing an unlocked lock and a warning message such as “Potential Threat Detected,” which can be provided with a red background. The dashboard can also comprise three primary fields, “My Wallet,” “My Monitoring” and “My Restoration” in this example. The “My Wallet” field can display an icon (a stylized wallet containing stylized credit cards and bearing a corporate logo, in this example), a number of items that are secured and protected (in this example, “28”), and a button allowing the user to access the Wallet function of the website. The button can include a drop down menu with additional options associated with the Wallet function. The “My Monitoring” field can display a date corresponding with the last scan, and three sub-sections corresponding with Internet monitoring, Credit monitoring and Public Records monitoring functions. The sub-sections can display a number of active threats. A warning icon can be used to flag a new identity alert, in this example, a logo having a triangle with an exclamation point inside the triangle is used. A confirmation icon can be used when no thread exists, in this example, a check mark logo is used. The “My Restoration” field can display a phone number associated with a customer service department, and a button allowing the user to access threat reporting functionality, in this case, a “REPORT A THREAT” button is provided.
Step C: Customer Opens Alert to Review
• Here is what is presented to the customer:
• • the alert details
  • what PII was used to find the alert
  • Alert content
  • Chance to approve the record “I agree with this information” or “YES THIS IS MINE” in this example
  • Chance to disapprove the record “I don't understand or know this information” or “NO THIS IS NOT MINE” in this example
• FIG. 9.C (see also Step C) illustrates an example of a screenshot including a review of a new potential threat according to the Identity Alert Management. The screen can include the horizontal status bar described above. Once a selection is made as to whether to approve or disapprove the record, the user can advance the matter by clicking on a box, such as a box labeled “SUBMIT MY SELECTION(S)” as shown in the present example.
Step D: Approval Popup
• If they click “Approve Record”, they are triggered with a popup to confirm the validity of the record.
• FIG. 9.D (see also Step D) illustrates an example of a popup window where a potential threat is marked as approved and where the system is prompting the user for validation, which can include a confirmation button, which is labeled “APPROVE RECORDS” in this example. The window can also include a link to cancel the process, which is labeled “Cancel” in this example.
Step E: Disapproval Popup
• If they click “Report as an Identity Threat” they are triggered with a popup that makes them aware a case will be immediately created and a Resolution Specialist will be contacting them right away. As above, in this example, buttons and links are used to perform the desired functions.
• FIG. 9.E (see also Step E) illustrates an example of a popup window where a potential threat is marked as an actual threat.
Step F: Case is Created
• FIG. 9.F (see also Step F) illustrates an example of a screenshot indicating that a case has been created in the Identity Alert Management system. The screen can include the horizontal status bar described above. The screen can display a serial number associated with a particular restoration case, the date the case was opened, a tab associated with current status (selected in this example), a tab associated with original scan details and information associated with a customer support or resolution specialist. The information can include a name of the specialist, a photo of the specialist, a status bar indicating whether the specialist is online or not, an email address of the specialist, a direct line for the specialist and an option to click on an icon (a stylized telephone handset in this example) to initiate a call from the service provider to the user, labeled “Click here and we'll call you” in this example.
Step G: If User Signs a Power of Attorney
• With a signed Power of Attorney, the Resolution Specialist can perform the majority of the Restoration tasks on your behalfFIG. 9.G (see also Step G) illustrates an example of a screenshot that can appear when the customer has signed a power of attorney. The information highlighted inFIG. 9.G can be provided on the same screen as the information described above with respect toFIG. 9.F. The screen can display next steps for the user to take (“No actions . . . ” in this example), next steps for the specialist to perform (“Call TransUnion . . . ” in this example) and a list of completed steps, which can further display the name of the specialist, the time of completion and the date of completion.
• Step H: If User does not Sign a Power of Attorney
• Without a signed Power of Attorney form, the Specialist can do less on your behalf, but can follow and assist anywhere you need help in the restoration process.
• FIG. 9.H (see also Step H) illustrates an example of a screenshot that can appear when the customer has not signed a power of attorney. The information displayed here is similar to that described with respect toFIG. 9.G above, except that the display of next steps for the user to take includes a suggested action and a button to be selected upon completion of the step (labeled “DONE” in this case). Also, the screen can include a link to a help screen, which is labeled “I NEED HELP” in this example.
Step I: Final Approval of Closed Case
• Once a case is completed from the Specialist's point of view, it's up to the customer to give the final say. If they are not comfortable with the outcome, the case can be reactivated, and if they are happy with the resolution, the case can be closed.
• FIG. 9.I (see also Step I) illustrates an example of a screenshot that can appear prompting the user to close a case or keep the case active. The screen can include a standard message associated with the completed status of the case, a button prompting the user to close the case if the user is satisfied with the resolution of the case (labeled “CLOSE THIS CASE” and “I'M SATISFIED WITH THIS RESOLUTION” in this example), and a link allowing a user to keep the case active (labeled “If this case has not been resolved to your full satisfaction click here to keep case active >>” in this example). The screen can also notify the user of policies or default actions that can be associated with the service, for example, “We will close this case after 30 days if we don't hear from you.”
Step J: Verified Records
• All records here have gone through the above approval process, each record stored in active services have been reviewed and confirmed as valid Identity elements by the consumer.
• FIG. 9.J (see also Step J) illustrates an example of a screenshot that can appear showing verified records. In this example, relating to “Credit Monitoring,” the screen can include a “Monitoring Snapshot” tab (selected in this example) and a “What Is Being Reported?” tab. The “Monitoring Snapshot” tab can include a number of reported threat(s), a number of potential threat(s) found, a number of record(s) verified by the user, a color-code legend, and a date associated with the completion of a scan. The numbers or text displayed here can be displayed in a color according to the color-code legend. The color-code can, for example, be green for “NOT A THREAT,” yellow for “POTENTIAL THREAT” and red for “REPORTED THREAT.” The screen can further present the user with information associated with a verified record, an option to add personal notes, a date of approval and a link that allows the user to reopen the case as a threat.
Step K: Cases can Always be Reopened
• A case can be reopened for any reason by the consumer or by a Resolution Specialist.
• FIG. 9.K (see also Step K) illustrates an example of a popup window that can appear prompting a user to confirm reopening of a threat. The screen can include a link or button that allows the user to reopen and report the case as an identity threat.
• According to one embodiment of the present invention, a computer implemented method for an identity alert management system for interaction between a customer and a resolution specialist for an identity management system, can comprise: on a computer device having one or more processors and a memory storing one or more programs for execution by the one or more processors, the one or more programs can include instructions for: identifying personally identifiable information against elements of a customer's identity; automatically sending a communication to the customer within a specified time period; authenticating the customer through a secure identity management dashboard; permitting the customer to review a source of an identity alert and details associated with the alert; prompting the customer to mark the alert as a threat or not a threat; sending a record of the threat to an approved records system if the customer marks the alert as not a threat; and creating a case if the customer marks the alert as a threat.
• The specified time period can be less than 24 hours.
• The one or more programs can further include instructions for permitting the user to execute a power of attorney prior to, during or after the threat has been detected.
• The one or more programs can further include instructions for ascertaining whether the customer has executed the power of attorney.
• The one or more programs can further include instructions for providing a first response system for customers that have executed the power of attorney.
• The one or more programs can further include instructions for providing a second response system for customers that have not executed the power of attorney
• The one or more programs can further include instructions for permitting the customer or the resolution specialist to reopen a previously approved record.
• The one or more programs can further include instructions for: performing a customized restoration plan on behalf of the customer, who takes on a support role, by a resolution specialist, who takes on the role of a case owner; resolution of the threat by the resolution specialist; after resolution of the threat by the resolution specialist, permitting the customer to approve the response to the threat and perform a final sign off; if the customer approves of the response, moving the record to the approved records system; and if the customer does not approve of the response, repeating the step of ascertaining whether the customer has executed the power of attorney.
• The one or more programs can further include instructions for: providing preplanned restoration plans to the customer with support from a resolution specialist; resolution of the threat by the customer; after resolution of the threat by the customer, permitting the resolution specialist to approve the response to the threat and perform a final sign off; if the resolution specialist approves of the response, moving the record to the approved records system; and if the resolution specialist does not approve of the response, repeating the step of ascertaining whether the customer has executed the power of attorney.
• According to one embodiment of the present invention, a computer system for a core gateway for an identity management system, can comprise: one or more processors; and memory to store: one or more programs, the one or more programs can comprise instructions for: identifying personally identifiable information against elements of a customer's identity; automatically sending a communication to the customer within a specified time period; authenticating the customer through a secure identity management dashboard; permitting the customer to review a source of an identity alert and details associated with the alert; prompting the customer to mark the alert as a threat or not a threat; sending a record of the threat to an approved records system if the customer marks the alert as not a threat; and creating a case if the customer marks the alert as a threat.
• According to one embodiment of the present invention, a non-transitory computer-readable storage medium storing one or more programs configured to be executed by one or more processing units at a computer for a secure profile system for an identity management system can comprise instructions for: identifying personally identifiable information against elements of a customer's identity; automatically sending a communication to the customer within a specified time period; authenticating the customer through a secure identity management dashboard; permitting the customer to review a source of an identity alert and details associated with the alert; prompting the customer to mark the alert as a threat or not a threat; sending a record of the threat to an approved records system if the customer marks the alert as not a threat; and creating a case if the customer marks the alert as a threat.
XI. PROVISIONAL SUBSCRIBER SYSTEM (PSS)Provisional Subscriber System Description
• The Provisional Subscriber System (PSS) is an integration mechanism to allow partners to provision customer contracts in a platform used to support an identity management system.
Business Need
• The purpose of the Provisional Subscriber System (PSS) is to provide a platform where subscriptions are:
• • a. prepaid or preregistered in advance by a partner
  • b. leveraged to validate responding subscribers' right to access the pre-registered services
  • c. leveraged to determine subscribers' activation status for partner billing and reporting systems
  • d. leveraged to provide subscriber notifications for, activation of, and status changes to, subscriptions that are provided by partners
• The Provisional Subscriber System (PSS) addresses a set of business needs or problems brought forth due to a go-to-market strategy that can be employed by an identity management service provider. This strategy calls for there to be a loosely coupled integration (or, in some cases, no data integration) between the identity management service provider and its marketing or retailing partners. The flexibility of the system to handle various enrollment strategies and activation communication paths for partners is the key driver for the development of the system.
Contract System Variables
• The primary mission of the system is to provide a platform where reservations for contracts (collection of services) between a partner or retailer of identity management subscription services and the end consumer can be activated by the end consumer without requiring a dependency on the part of the partner to convey a specific reservation or contract number to the end consumer.
• This need is brought on by the desire to require little set up and the need for the partner to create a point of sale (POS) system to support enrollments. Partners can enroll end consumers in identity management subscription services within existing programs or new loyalty programs or in a variety of other enrollment strategies. By reducing the dependency on the partner to create a method of conveyance to deliver the activation code or reservation number from the identity management platform to the end consumer at the point of enrollment, the identity management service provider can considerably shorten the go-to-market time for the partner.
• Contracts for identity management services could be in the form of a fixed subscription term (i.e., the partner has sold a fixed term contract to the end consumer) or could be an open ended term. In the event that a fixed term contract was sold the contract system must be able to present the contract to the end consumer as a reservation with an expressed term limit that is set to expire some time in the future. In the event that an open ended subscription term is specified, the partner will want to retain some control over the end term of the subscription (i.e., by notifying the identity management service provider that the end consumer no longer has a subscription for the contract).
• In addition the Contract System will function as the transaction data store that will drive the identity management partner billing process, for contracts purchased on behalf of the end consumer through the partner's own point of sale systems.
Provisioning Methods
• Partners have a variety of ways in which they can integrate with the identity management service provider to provision end consumers with service contracts. For the purpose of understanding the overall design pattern for the PSS, five broad categories are discussed:
• • a. No data integration
  • b. A single direction file submission from the partner to the identity management service provider
  • c. A multi-direction file integration between the partner and the identity management service provider
  • d. A subscription administration portal provided by the identity management service provider
  • e. A real-time integration between the partner POS system and the identity management PSS system
• The provisional subscriber system must provide flexibility to support enrollments across all of the above.
• Partners enroll consumers into subscriptions of identity theft protection services. The partner conveys contact and contract information to the identity management service provider:
• • f. Maintain control over recurring subscription contract (add/cancel/change)
  • g. Prepaid service enrollments
  • h. Billing system solution
  • i. Breach Services
Activation Strategies
• In addition to the multiple methods for partners to provision the identity management contract system with subscription contracts, there are multiple approaches that partners will use to refer end consumers to the identity management platform to activate the contract and gain access to the services provided by the identity management service provider.
PSS1 (Activate Using the Provisional ID)
• In this method the partner provides the identity management service provider with a unique customer id, transaction id, customer names, addresses, and email addresses. The identity management service provider sends an email invitation to each customer's email address. The email contains a link to a partner-branded landing page for the customer to create an account and activate their services. In this mechanism there is an implicit assumption that the person getting the email is the same as the person enrolling and activating. The partner can retain control of the subscription term by later sending updates to; upgrade, extend the term, or cancel services, associated with the unique customer id.
• In the PSS1 method the partner has submitted a prepaid or partially paid subscription to the identity management service provider by submission of a data feed.
• The date feed identifies the type of contract to be associated with the subscriber.
• The data feed also identifies the subscriber with a unique account ID or transaction ID from the partner's system of record for subscription management.
• By providing the unique subscriber ID from the partner system of record two objectives for subscription management are achieved.
• • j. The partner has a direct method by which, through successive updates to the PSS system, they can manage the state of the contract or subscription, enabling the partner to upgrade/downgrade/cancel or extend the term of a contract by referencing the unique subscriber ID. Because they are “provisioned”, the ongoing Partner feed can adjust the Subscriber's free services as necessary (supports upgrades and cancellations by the Partner/Retailer through a data integration).
  • k. The partner can direct a consumer to the retrieve/activate a subscription in the identity management system by referring the subscriber to the identity management service provider along with the unique subscriber ID from the partner system.
• The identity management service provider generates a unique ID for each subscriber enrolled in the PSS system. We'll refer to this unique ID as the “Provisional ID”.
• The “Provisional ID” can be provided to the subscriber in the form of a reservation number that can be used to refer to the subscribers' contract in the PSS system.
• Activation campaign emails generated by the identity management service provider, direct subscribers to an PSS1 landing page along with the specific “Provisional ID”. This “Provisional ID” is embedded in the email call to action referral link.
• A subscriber reaching the PSS1 landing page (on the CGW platform), either enters the “Provisional ID” or has the “Provisional ID” entered via the call to action referral link. The landing page performs a look-up of the “Provisional ID” in the PSS system. The status of the contract is confirmed and CGW retrieves the associated contract data for the subscriber.
Screenshot
• FIG. 17 shows an example of a generic screenshot for the provisional subscriber system (PSS1) according to some embodiments of the present invention. In this screenshot, for example, a viewer or user is presented with Partner-branded graphics in the upper-left-hand corner of the screen, a phone number for the Partner in the upper-right-hand corner of the screen, a customizable graphic on the left side of the screen and a login screen on the right side of the screen. In this example, the login screen includes a message including partner-customizable field (“EZShield” in this example), a Receipt Number field adapted to receive the “Provisional ID,” a Verification Code field and a “Get Started” button. All fields displayed in the screenshot can display content according to a default mode or a customizable (Partner) mode.
• PSS2 (Activate using Personally Identifiable Information (“PII”) lookup)
• In this method the partner provides the identity management service provider with unique customer id, transaction id, names and a minimum few PII elements such as last 4 SSN, Zip code etc. The identity management service provider creates a partner-branded landing page. The partner drives the customer to create an account and activate their services via this landing page. The customer only has to enter 4 pieces of information on the landing page in order to create an account and activate.
• The CGW platform will perform a look up to confirm that the four pieces of information entered by the subscriber are confirmed in the PSS system.
• The partner has access to the identity management services. The partner can retain control of the subscription term by later sending updates to; upgrade, extend the term, or cancel services, associated with the unique customer id.
Example
• FIG. 18 shows an example of a Partner-specific screenshot for the provisional subscriber system (PSS2) according to some embodiments of the present invention. In this screenshot, for example, a viewer or user is presented with Partner-branded graphics in the upper-left-hand corner of the screen, a phone number for the Partner in the upper-right-hand corner of the screen, a customizable graphic on the left side of the screen and a login screen on the right side of the screen. In this example, the login screen includes a First Name field, a Last Name field, a Zip Code field, a Last 4 digits of SSN field, a “Get Started” button, a link with the text “Already have a receipt code?” and a link with the text “Click here if you have already activated.” The bottom portion of screen includes additional graphics and information, which can be associated with the Partner. All fields displayed in the screenshot can display content according to a default mode or a customizable (Partner) mode.
• What Cases is this Used for?
• Customers who are receiving “paid for” services through a Partner or Retailer
• The partner/retailer either cannot or does not desire to provide EZS with the full contact information for activation notification
• The landing page can be designed with a look and feel for many retailers to within a Partner configuration (ex: a Partner site can stand up an individual financial institution landing page with each FI's branding/messaging that introduces (smooths) the subscriber to the Partner brand in the CGW platform.)
• What is Unique about this Method?
• The “Provisional ID” is not needed by the subscriber to proceed with activation process.
• Supports both Partner and Retailer Branding
• The provisional contract is verified against data supplied by partner (full name, Zip, last 4 of SNN, etc. . . . )
• Enrollments can be driven by either Print or Email messaging to the consumer
• Because they are “provisioned”, the ongoing Partner feed can adjust the Subscriber's free services as necessary
• The subscriber has personal knowledge of PII data that is used to locate the provisional contract in the PSS system. The minimum (additional fields can be used to “strengthen” the matching process) required fields of data are: First Name, Last Name, Zip Code and Verification Code. The Zip Code can be “adjusted” to any address that is associated with Partner's customer record, i.e., such as delivery address, billing address, order address, etc. The Verification Code can be customized to any piece of data that is shared between the Partner and Consumer, for example, it's typically the last 4 of the SSN.
• Unlike PSS1, the elements being matched on (customer PII) are not necessarily unique and there is much more dependence on the quality of the Partner's data, so it's possible that more or less than 1 exact match could be found in the PSS system. In either case an error message with a phone number is displayed for the user to call the issue can be resolved through the Response Center.
Screenshot
• FIG. 19 shows an example of a generic screenshot for the provisional subscriber system (PSS2) according to some embodiments of the present invention. In this screenshot, for example, a viewer or user is presented with Partner-branded graphics in the upper-left-hand corner of the screen, a phone number for the Partner in the upper-right-hand corner of the screen, a customizable graphic on the left side of the screen and a login screen on the right side of the screen. In this example, the login screen includes a First Name field, a Last Name field, a Zip Code field, a Last 4 digits of SSN field, a “Get Started” button and a link with the text “Click here if you have already activated.” All fields displayed in the screenshot can display content according to a default mode or a customizable (Partner) mode.
• PSS3 (Activate using Offer Code)
• In this method the partner does not provide any customer information upfront.
• The partner requests a number of reservations (offer codes) be provisioned in the PSS system, typically based on the number of subscribers they would like to make identity management services available to.
• The identity management service provider associates these reservations with a multiple user “Provisional ID”. The “Provisional ID” is typically associated with, and referred to as a “offer code” for the purposes of ease of use.
• The identity management service provider creates a partner-branded landing page. The partner shares the “Provisional ID” with the set of target subscribers.
• The partner refers subscribers to use the “Provisional ID” to enroll and activate their services from this landing page.
• As subscribers complete an activation of the contract type associated with this multiple reservation “Provisional ID”, the PSS system counts down the number of reservations available.
• Once the number of reservations associated with this “Provisional ID” are depleted, no other subscribers are allowed to proceed with an activation using this “Provisional ID”.
• What Cases is this Used for?
• Customers who are receiving “paid for” services because of a Data Breach
• What is Unique about this Method?
• An offer code is generated on our end, this is the code that is entered in “Activation Code”
• It's up to the Partner or Retailer to pass out the code to the victims of breach, or in the case of a Breach Response—within notifications provided by the small business, the identity management service provider, or the designated supplier for notification services.
• Branded for the partner, not retailers (or specific the breach agent, i.e., small business)
• Image and Text is not Customizable Per Event
• A set number (maximum) of victims is set up in the PSS system for the specified event “Activation Code” (Cap can be set by the Partner or defined by the agent of the breach)
• Billing of the “prepaid” services is accomplished via the “set number of victims” defined for the “Activation Code”
• Because they are “provisioned”, the ongoing Partner feed can adjust the Subscriber's free services as necessary (by changing the definition of the “Activation Code”)
Known Limitations
• Because this is an “offer code” being handed out, anyone who uses this offer code can pass it out to others. Our only verification is that a valid code is entered.
• Each valid entry followed up by a completion of the activation (account setup) consumes one for the reservations for the “Activation Code”.
• When all reservations for the “Activation Code” are consumed—further use of the “Activation Code” results in an error message to the user upon entry of that activation code.
Screenshot
• FIG. 20 shows an example of a generic screenshot for the provisional subscriber system (PSS3) according to some embodiments of the present invention. In this screenshot, for example, a viewer or user is presented with Partner-branded graphics in the upper-left-hand corner of the screen, a phone number for the Partner in the upper-right-hand corner of the screen, a customizable graphic on the left side of the screen and a login screen on the right side of the screen. In this example, the login screen includes an Activation Code field. All fields displayed in the screenshot can display content according to a default mode or a customizable (Partner) mode.
• The following primary use cases identify the primary handling of changes to the subscribers' service enrollments as a result of updates provided by the partner to the provisional subscriber system via data feeds from the partner's system of record. The use cases are stated in terms of the Deluxe Partner-Paid membership file submissions.
System DescriptionSystem Overview
• The Provisional Subscriber System is comprised of a collection of work-flows that are distributed logically across the various components of the system that are responsible for the delivery of information regarding the state or notification of the service contract associated with a subscriber.
• PSS is not a separate application. PSS is a collection of operations written within the logic of SDB, DPE, Responsys, and CGW. Actual communications between the four systems are also part of the PSS system. Operations between DPE and SDB, between SDB and CGW, between SDB and ResponSys, between SDB and the billing system all account for the PSS System behavior. The PSS describes the handling of records that must go back and forth between those systems in order to solve the needs of the Provisional Contract.
• FIG. 21 shows an example of a component diagram for the Provisional Subscriber System, whereFIG. 21.A is the left side of the figure andFIG. 21.B is the right side of the figure. PSS is a set of business rules, workflows and interactions between a group of subsystems such as CGW, SDB, DPE, the Responsys engine (email system) and the like. Through a series of workflows and coordinations the PSS provides a network of coordinations between the different subsystems. Data moves between the subsystems in different ways.
• For example, aprovisional subscriber2101 can subscribe to the identity management system through aretail partner2104, which can be a financial institution (FI). Theretail partner2104 can prepare afile2106 to send to achannel partner2108. Thechannel partner2108 can, optionally, send thefile2106 to the provisional subscriber system for file formatting and receive the formatted file from the provisional subscriber system. The channel partner2018 can send formattedfiles2112 to an identity management service provider using a secure file transfer protocol (SFTP)system2114 and specifically to a data processing engine (DPE) andintegration processing system2116, which can be adapted to exchange information with a subscriber database (SDB)system2118. Examples of the DPE and SDB systems are described in detail in separate sections of the present specification. In this example, the formattedfiles2112 are sent on a daily basis; however, any desired regular or irregular frequency can be selected. After processingfiles2112 through DPE and SDB, the processedfiles2120 from DPE and SDB can be send to anemail management system2122 such as Responsys. Thefiles2120 can be sent to customers, partners, an inclusion list or an activity report file as required. Theemail management system2122 can be configured to send email out depending on specifications requested or required by a particular campaign, subscriber or partner. Once an email has been triggered by thesystem2124, an attempt is made to send theemail2126. At this point, if the email is not opened by the recipient then theemail management system2122 sends a reminder again. If the email is opened2128 and a link within the email is clicked2130, then information is sent to the core gateway (CGW)system2132. Specifically, theCGW system2132 performs a lookup of theprovisional subscriber2101 using one or more of the three provisional subscriber methods PSS1, PSS2 and/or PSS3 using theSDB system2118. Once the lookup process is complete, the system generates an unique ID, shown here as “EZshieldID.” Using the results of the lookup process, theCGW system2132 make adecision2134 whether to activate theprovisional subscriber2101. After theprovisional subscriber2101 is activated2136, the profile of theprovisional subscriber2101 in theSDB system2118 is updated, a sync file (shown here as “CGWsync” file with fields such as “Contractsync” and “SubscriberprofileSync”) is generated2148, thesync file2148 is sent to theDPE system2116, and the email program ends2138. If a bad email address is detected2140, then the email program ends2142. If a soft bounce is encountered2144, then theemail management system2122 repeats the process. If a hard bounce is encountered2144, then the email program ends2146. Alternately, a walk-upuser2102 can access the system directly through the identity management system provider's portal. This direct access can be without any input from the provider or using an offer code provided by the provider. Here, the walk-upuser2102 interacts directly with theCGW system2132; all other processes are the same. The PSS system can be considered as a set of processes identified herein as2110,2116,2118,2120,2122,2124,2126,2128,2130 and2132, which are enclosed in the rounded rectangle set forth inFIG. 21.
Use Case Descriptions and Work Flows
• The logical system can be described best by describing the collection of primary use cases or work flows that are managed by the system.
Use Case #1: Add Provisional Subscriber
• A new provisional subscriber record is detected by the provisional subscriber system.
• No previous record for the subscriber has been detected in the provisional subscriber system.FIG. 22 is a flow chart forUse Case #1 including the following steps:
• 1) DPE processes the record (describe DPE system logic as it pertains to PSS record handling)
• 2) SDB recognizes PSS record creates contract record, assigns prov ID
• 3) SDB coordinates contract reporting/billing system
• 4) SDB causes data to be sent to RSys
• 5) RSys triggers activation campaign sequence
• 6) Subscriber responds to the activation request
• 7) Subscriber enters Prov ID provided by SDB PSS
• 8) CGW performs look up of Prov ID/contract in SDB
• 9) SDB confirms state of contract/services
• 10) Subscriber completes the activation of the services associated with the contract in CGW-CGW updates status of the contract in SDB
• 11) Responsys campaign set to continue to notify subscriber until
• 12) Checks with SDB and determines contract is now active (or)
• 13) Billing/reporting system checks with SDB to determine if contract should be billed
• As shown, for example, inFIG. 22, a process for adding a provisional subscriber can begin when a new package or contract is submitted by a partner to thePSS system2205. The PSS system, utilizing the SDB system, can detect thenew contract2210. Information pertaining to the new subscriber contract can be sent to a partner billing/reporting system and can be stored in a database for the billing/reporting system2240. A notification component of the PSS system can send an enrollment or activatenotification2215. In response, a consumer can respond to the notice in anacceptable manner2220. In response, the CGW system can confirm the subscription via aPSS lookup process2225. A confirmation can be exchanged with theSDB system2210/2225. After confirmation, the consumer or subscriber can complete activation using theCGW system2230. Activation information can be exchanged with theSDB system2210/2230. After completing activation, the consumer or subscriber can be given access to partner pre-paid services2235. If activation is not completed within a set period of time (shown here as “n” days)2245, then the notification component of the PSS system can send enrollment or activation reminders to the consumer/subscriber2250 and the subscriber can respond to thenotice2255 and then theconfirmation step2225 follows as per usual. If activation is completed within a set period of time, then the process ends2260.
Use Case #2: Change in Partner-Paid Package/Activated Subscription
• The partner has changed the package to which a subscriber is enrolled.
• PSS has detected that a change to the prepaid package for the subscriber is indicated.
• Further, PSS has detected that the subscriber has previously activated the subscription (via the CGW system) and has obtained access to the services provided.
• PSS will send a Change Notice to the consumer (either via email service provider, or via postal mail).
• FIG. 23 is a flow chart forUse Case #2.
• As shown, for example, inFIG. 23, a process for updating a contract partner can begin when an updated package or contract is submitted by a partner to thePSS system2305. The PSS system, utilizing the SDB system, can detect the updatedcontract2310. Information pertaining to the updated contract partner can be sent to a billing/reporting system and can be stored in a database for the billing/reporting system2340. A notification component of the PSS system can send an updatednotification2315. In response, a consumer can respond to the updated notice in anacceptable manner2320. In response, the CGW system can confirm the subscription via aPSS lookup process2325. After confirmation, the consumer or subscriber can complete the update using theCGW system2330. Activation confirmation and update information can be exchanged with theSDB system2310/2330. After completing activation, the consumer or subscriber can be given access to updated partner pre-paid services2335. If activation is not completed within a set period of time (shown here as “n” days)2345, then the notification component of the PSS system can send update notification reminders to the consumer/subscriber2350 and the subscriber can respond to the updatednotice2355, the CGW system can perform an update via thePSS lookup2357 and then thecompletion step2330 follows as per usual. If activation is completed within a set period of time, then the process ends2360. Additional iterations of thesteps2345 through2360, inclusive, can be repeated insteps2365 through2390, inclusive.
Use Case #3: Change in Partner-Paid Package/Subscription Not Activated
• A change to the package which a previously entitled provisional subscriber is entitled to as part of their prepaid enrollment has been detected by the provisional subscriber system.
• The subscriber has not previously activated their subscription (via the CGW system) and does not have access to services associated with their current prepaid enrollment.
• FIG. 24 is a flow chart forUse Case #3.
• As shown, for example, inFIG. 24, a process for updating a subscriber contract can begin when an inactive or updated package or contract is submitted by a partner to thePSS system2405. The PSS system, utilizing the SDB system, can detect theinactive contract2410 or the updatedcontract2412. Information pertaining to the updated subscriber contract can be sent to a billing/reporting system and can be stored in a database for the billing/reporting system2440. A notification component of the PSS system can send anotification2415. In response, a consumer can respond to the notice in anacceptable manner2420. In response, the CGW system can confirm the subscription via aPSS lookup process2425. After confirmation, the consumer or subscriber can complete the update using theCGW system2430. Activation confirmation and update information can be exchanged with theSDB system2410/2412/2430. After completing activation, the consumer or subscriber can be given access to partner pre-paid services2435. If activation is not completed within a set period of time (shown here as “n” days)2445, then the notification component of the PSS system can send enrollment or activation reminders to the consumer/subscriber2450, the subscriber can respond to thenotice2455, the CGW system can confirm the update via thePSS lookup2457 and then thecompletion step2430 follows as per usual. If activation is completed within a set period of time, then the process ends2460. Additional iterations of thesteps2445 through2460, inclusive, can be repeated insteps2465 through2490, inclusive.
Use Case #4: Cancelled Partner-Paid Enrollment/Subscriber has Activated the Subscription
• A cancellation of enrollment in a package is received by the provisional subscriber system via the DPE integration with the partner.
• The system has detected that the subscriber has activated the subscription for which they had previously been entitled.
• The subscriber currently has access to the services provided by the prepaid enrollment via an on-line account at the identity management service provider's website.
• The PSS system updates the billing system, the cost for the contract will no longer appear on the recurring billing statements for the partner.
• The PSS system will initiate notifications to the subscriber and continue to notify the subscriber until: (1) the subscriber responds to the notification and confirms that services are deactivated; or (2) the length of time allowed for the subscriber to respond (referred to as “grace period”) is exceeded.
• The subscriber responds by updating the state of the contract via the CGW application. The subscriber can either confirm that the contract is cancelled and allow the services to be deactivated, or can elect to convert to a paid subscription and retain the services in an active state. CGW updates the status of the contract in the PSS system.
• In the event that the subscriber fails to respond with the allowed “grace period”, a process to deactivate the subscribers' services is triggered.
• FIG. 25 is a flow chart forUse Case #4.
• As shown, for example, inFIG. 25, a process for canceling a subscriber contract can begin when a canceled contract is submitted by a partner to thePSS system2505. The PSS system, utilizing the SDB system, can detect anactive contract2510 or the canceledcontract2512. Information pertaining to the canceled subscriber contract can be sent to a billing/reporting system and can be stored in a database for the billing/reporting system2540. A notification component of the PSS system can send acancellation notification2515. In response, a consumer can respond to the notice in anacceptable manner2520. In response, the CGW system can confirm the subscription via aPSS lookup process2525. After confirmation, the consumer or subscriber can complete the cancellation using theCGW system2530. Confirmation and cancellation information can be exchanged with theSDB system2510/2512/2530. After completing cancellation, the consumer or subscriber can be given access to a system for purchasing services2535. If cancellation is not confirmed within a set period of time (shown here as “n” days)2545, then the notification component of the PSS system can send cancellation reminders to the consumer/subscriber2550, the subscriber can respond to thenotice2555, the CGW system can confirm the update via thePSS lookup2557 and then thecompletion step2530 follows as per usual. If activation is completed within a set period of time, then the process ends2560. Additional iterations of thesteps2545 through2560, inclusive, can be repeated insteps2565 through2590, inclusive. If the consumer or subscriber never responds to any of the notifications, then the system deactivates the service program for the nonresponsive consumer orsubscriber2595, and the nonresponsive consumer or subscriber can be given access to the system for purchasing services2535.
Use Case #5: Cancelled Partner-Paid Paid Enrollment/Subscriber has not Activated the Subscription
• A cancellation of enrollment in a package is received by the provisional subscriber system via the DPE integration with the partner.
• The system detects that the subscriber has not yet activated the subscription for which they had previously been entitled. The subscriber currently does not have access to the services provided by the prepaid enrollment via an on-line account at the identity management service provider's website.
• The system flags the Provisional Subscriber account as deactivated (canceled)
• The PSS generates a Service Deactivation notification to be sent to the consumer.
• No other action is required.
PSS System Data Model Description
• The PSS System leverages4 component subsystems:
• • a. Data Processing Engine (DPE)—Handles all aspects of the Extract Transform Load (ETL) between that various subsystems
  • b. Subscriber Database (SDB)—Data warehouse of all Subscribers
  • c. Core Gateway (CGW)—Website
  • d. Notification System—Engine that sends subscriber notifications
• Each aspect has been documented in detail in other descriptions. The interaction between the systems can be described in a simple flow diagram.FIG. 26 is a flow chart for an example of a Provisional Subscriber Login process, which can start when a subscriber enters data into alanding page2605. The CGW system can call a stored procedure that looks up the subscriber's data in theSDB system2610. The CGW system can create asubscriber profile2615. TheCGW system2620 can call a stored procedure, update activation status and set an unique ID (shown here as “EZShieldID”). The CGW system can enroll the user or subscriber in one ormore products2625. The CGW system can post data to populate a sync table withfull subscriber records2630. The DPE system can populate a StagingData table2635. The DPE system can import data into the SDB system via a stored procedure that validates and transforms thestaging data2640. The DPE system can export the subscriber and contract data from theSDB system2645. The DPE system can upload the subscriber and contract data to anemail management system2650. A notification system can merge the subscriber and contract information into thenotification database2655. The notification system can halt further activation emails from being sent to thesubscriber2660, and the process can end2665.
• According to an embodiment of the present invention, a computer implemented method for a provisional subscriber system for an identity management system, can comprise: on a computer device having one or more processors and a memory storing one or more programs for execution by the one or more processors, the one or more programs can include instructions for: receiving information about a provisional subscriber from a partner; receiving information about the provisional subscriber from a customer; and authenticating the provisional subscriber as a valid customer based on a comparison of the information from the partner and the customer utilizing a core gateway system and a data processing engine system.
• The receiving information about the provisional subscriber from the partner can comprise an integration of partner information using the data processing engine system.
• The receiving information about the provisional subscriber from the customer can comprise receiving information directly from the customer via the core gateway system.
• The receiving information about the provisional subscriber from the customer can comprise receiving information about the customer from the customer via an email management system.
• A provisional identification can be used as the basis for the comparison.
• Personally identifiable information can be used as the basis for the comparison.
• An offer code can be used as the basis for the comparison.
• The core gateway system can comprise: utilizing a content management system comprising a Framework and a Module; adding a Dimension at the Framework level of the content management system, wherein the Dimension is pervasive across all Modules of the content management system; and displaying content based on the Dimension of each Module.
• The data processing engine system can comprise configuring an inbound or outbound feed; executing the inbound feed; and executing the outbound feed.
• The computer implemented method can further comprise: receiving a new contract from the partner; detecting the new contract with a subscriber database system; notifying the provisional subscriber with a notification system; receiving a response from the provisional subscriber; confirming a subscription with the core gateway system thus validating the provisional subscriber as the valid customer; and providing the valid customer with access to a service.
• The computer implemented method can further comprise: receiving an updated contract from the partner; detecting the updated contract with a subscriber database system; notifying the provisional subscriber with a notification system; receiving a response from the provisional subscriber; confirming an updated subscription with the core gateway system thus validating the provisional subscriber as the valid customer; and providing the valid customer with access to an updated service.
• The computer implemented method can further comprise: receiving a canceled contract from the partner; detecting the canceled contract with a subscriber database system; notifying the provisional subscriber with a notification system; receiving a response from the provisional subscriber; confirming a canceled subscription with the core gateway system; and providing the canceled customer with access to a system for purchasing services.
• The computer implemented method can further comprise: prompting the provisional subscriber to enter data into a landing page; looking up the entered data in a subscriber database system using the core gateway system; creating a subscriber profile using the core gateway system; updating an activation status of the provisional subscriber and establishing an unique identifier for the provisional subscriber using the core gateway system; enrolling the provisional subscriber in a product or service using the core gateway system; populating a sync table with full subscriber records using the core gateway system; populating a table with staging data using the data processing engine system; validating and transforming the staging data using the subscriber database system and the data processing engine system; exporting subscriber and contract data from the subscriber database system using the data processing engine system; uploading the subscriber and contract data to an email system using the data processing engine system; and merging the subscriber and contract data into a notification database using a notification system.
• According to an embodiment of the present invention, a computer system for a provisional subscriber system for an identity management system, can comprise: one or more processors; and memory to store: one or more programs, the one or more programs can comprise instructions for: receiving information about a provisional subscriber from a partner; receiving information about the provisional subscriber from a customer; and authenticating the provisional subscriber as a valid customer based on a comparison of the information from the partner and the customer utilizing a core gateway system and a data processing engine system.
• According to an embodiment of the present invention, a non-transitory computer-readable storage medium storing one or more programs configured to be executed by one or more processing units at a computer for a provisional subscriber system for an identity management system can comprise instructions for: receiving information about a provisional subscriber from a partner; receiving information about the provisional subscriber from a customer; and authenticating the provisional subscriber as a valid customer based on a comparison of the information from the partner and the customer utilizing a core gateway system and a data processing engine system.
• Although some of various drawings illustrate a number of logical stages in a particular order, stages which are not order dependent can be reordered and other stages can be combined or broken out. Alternative orderings and groupings, whether described above or not, can be appropriate or obvious to those of ordinary skill in the art of computer science. Moreover, it should be recognized that the stages could be implemented in hardware, firmware, software or any combination thereof.
• The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to be limiting to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain the principles of the aspects and its practical applications, to thereby enable others skilled in the art to best utilize the aspects and various embodiments with various modifications as are suited to the particular use contemplated.

Claims (21)

We claim:

1. A computer implemented method for a secure profile system for an identity management system, comprising:

on a computer device having one or more processors and a memory storing one or more programs for execution by the one or more processors, the one or more programs including instructions for:

defining a structure;

storing data associated with a profile, wherein the profile contains an object;

securely granting access to the profile and a subject;

configuring an audit log to provide an account of an access to data housed within the profile;

implementing a security-related algorithm and protocol;

exchanging data between two or more subjects; and

providing secured, externalized content.

2. The computer implemented method ofclaim 1, wherein the object is a stream of binary data.

3. The computer implemented method ofclaim 1, wherein the object is a securely stored blob of arbitrary data.

4. The computer implemented method ofclaim 1, wherein the object is a record, wherein the record has an associated structure.

5. The computer implemented method ofclaim 1, the one or more programs further including instructions for providing shared-secret access to data.

6. The computer implemented method ofclaim 1, the one or more programs further including instructions for storing the data in a database system.

7. The computer implemented method ofclaim 6, the one or more programs further including instructions for accessing the database system with a data access system.

8. The computer implemented method ofclaim 7, wherein the data access system comprises atomic primitives providing fundamental data operations for system entities.

9. The computer implemented method ofclaim 7, the one or more programs further including instructions for:

configuring a controller system to access the data access system;

configuring a context system to access the controller system; and

configuring a service system to access the context system.

10. The computer implemented method ofclaim 9, wherein the database system is isolated from the data access system, the controller system, the context system and the service system; wherein the database system has a level of access that is more restricted than a level of access for the data access system, the controller system, the context system and the service system; and wherein the data associated with the profile is layer encrypted.

11. The computer implemented method ofclaim 9, wherein the controller system assembles and orchestrates data access primitives into higher level system functions.

12. The computer implemented method ofclaim 9, wherein the context system provides a stateful security context with a known acting principal for all requested operations.

13. The computer implemented method ofclaim 9, wherein the service system exposes all client-accessible functionality over a supported remote-access technology.

14. The computer implemented method ofclaim 9, wherein the service system is adapted for use with an XML based communication standard for structured remote procedure calls.

15. The computer implemented method ofclaim 14, wherein the XML based communication standard for structured remote procedure calls is a Simple Object Access Protocol (SOAP) protocol.

16. The computer implemented method ofclaim 9, wherein the service system is adapted for use with Microsoft .NET technology for building service-oriented applications.

17. The computer implemented method ofclaim 16, wherein the Microsoft .NET technology for building service-oriented applications is a Windows Communication Foundation (WCF) framework.

18. The computer implemented method ofclaim 1, the one or more programs further including instructions for rotating a key for Payment Card Industry compliance.

19. The computer implemented method ofclaim 1, the one or more programs consisting of instructions for operating the secure profile system with an application programming interface.

20. A computer system for a core gateway for an identity management system, comprising:

one or more processors; and

memory to store:

one or more programs, the one or more programs comprising instructions for:

defining a structure;

storing data associated with a profile, wherein the profile contains an object;

securely granting access to the profile and a subject;

configuring an audit log to provide an account of an access to data housed within the profile;

implementing a security-related algorithm and protocol;

exchanging data between two or more subjects; and

providing secured, externalized content.

21. A non-transitory computer-readable storage medium storing one or more programs configured to be executed by one or more processing units at a computer for a secure profile system for an identity management system comprising instructions for:

defining a structure;

storing data associated with a profile, wherein the profile contains an object;

securely granting access to the profile and a subject;

configuring an audit log to provide an account of an access to data housed within the profile;

implementing a security-related algorithm and protocol;

exchanging data between two or more subjects; and

providing secured, externalized content.

Images