US20130179988A1 - Secure Profile System And Method - Google Patents

Secure Profile System And Method Download PDF

Info

Publication number
US20130179988A1
US20130179988A1 US13/730,717 US201213730717A US2013179988A1 US 20130179988 A1 US20130179988 A1 US 20130179988A1 US 201213730717 A US201213730717 A US 201213730717A US 2013179988 A1 US2013179988 A1 US 2013179988A1
Authority
US
United States
Prior art keywords
system
data
partner
customer
access
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US13/730,717
Inventor
Eugene Bekker
Darrell Lee Laffoon
Jonathan Marc Huet Bridges
Joseph P. Baker
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
EZShield Inc
Original Assignee
EZShield Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to US201261584745P priority Critical
Priority to US13/730,717 priority patent/US20130179988A1/en
Application filed by EZShield Inc filed Critical EZShield Inc
Priority claimed from CA 2801659 external-priority patent/CA2801659A1/en
Publication of US20130179988A1 publication Critical patent/US20130179988A1/en
Assigned to NATIONAL BANK OF CANADA reassignment NATIONAL BANK OF CANADA SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: EZSHIELD, INC.
Assigned to EZSHIELD, INC. reassignment EZSHIELD, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BAKER, JOSEPH P., BEKKER, EUGENE, LAFFOON, DARRELL LEE
Assigned to PROSPECT CAPITAL CORPORATION, AS COLLATERAL AGENT reassignment PROSPECT CAPITAL CORPORATION, AS COLLATERAL AGENT SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: EZSHIELD, INC.
Assigned to EZSHIELD, INC. reassignment EZSHIELD, INC. RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS). Assignors: NATIONAL BANK OF CANADA
Assigned to EZSHIELD, INC. reassignment EZSHIELD, INC. RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS). Assignors: PROSPECT CAPITAL CORPORATION
Assigned to NATIONAL BANK OF CANADA reassignment NATIONAL BANK OF CANADA SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: EZSHIELD, INC.
Assigned to BRIGHTWOOD LOAN SERVICES, LLC reassignment BRIGHTWOOD LOAN SERVICES, LLC SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: EZSHIELD, INC., IDENTITYFORCE, INC.
Assigned to EZSHIELD, INC. reassignment EZSHIELD, INC. RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS). Assignors: NATIONAL BANK OF CANADA
Application status is Abandoned legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network
    • H04L63/0823Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network using certificates
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/62Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce, e.g. shopping or e-commerce
    • G06Q30/01Customer relationship, e.g. warranty
    • G06Q30/018Business or product certification or verification
    • G06Q30/0185Product, service or business identity fraud
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
    • G06Q50/10Services
    • G06Q50/26Government or public services
    • G06Q50/265Personal security, identity or safety
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/02Network-specific arrangements or communication protocols supporting networked applications involving the use of web-based technology, e.g. hyper text transfer protocol [HTTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/16Implementing security features at a particular protocol layer
    • H04L63/168Implementing security features at a particular protocol layer above the transport layer

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, where FIG. 1.A is the left side of the figure and where FIG. 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, where FIG. 2.A is the left side of the figure and where FIG. 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, where FIG. 4A is the top portion of the figure, and where FIG. 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, where FIG. 5.A is the top portion of the figure, and where FIG. 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 and 7.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, where FIGS. 8.A, 8.B, 8.C, 8.D and 8.E are various expanded views of FIG. 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 for FIGS. 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, where FIG. 21.A is the left side of the figure and FIG. 21.B is the right side of the figure;
  • FIG. 22 is a flow chart for Use Case #1;
  • FIG. 23 is a flow chart for Use Case #2;
  • FIG. 24 is a flow chart for Use Case #3;
  • FIG. 25 is a flow chart for Use 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 a system 100 in accordance with some embodiments of the present disclosure. The identity management system 100 interacts with one or more external service providers 160, subscribers 170 and partners 180. Subscribers 170 can include platforms suitable for individual users 172, mobile users 174 and partner portals 176. The system 100 is adapted to accommodate future systems. For each partner 180, there can be provided one or more partner integration systems 180-1 . . . 180-n. The identity management system 100 can comprise a three-tier system, which can include a data tier 110, an integration/application services tier 120 and a public/web tier 130, such as that shown in FIG. 1, which illustrates one example of the architecture of the identity management system 100. The data tier 110 can comprise one or more of a response center 112, a content management system (CMS) database 10, an online transaction processing (OLTP) database 11 and an online analytics processing (OLAP) database 12. The integration/application services tier 120 can comprise one or more of internal tools and sites 5 a, a Maestro tool 5 b, internal web services and application programming interfaces (APIs) 6 a, a SecureProfile Service 6 b (see Section VI below), partner integration services 7, business intelligence 8, customer relationship management (CRM) and/or case management (CM) systems 122, and provider integration services 9. The public/web tier 130 can comprise one or more of SecurePort SSL 1 (see Section VII below), URL Matcher 2 (see Section VIII below), Dynamic Branded Sites 3, Public API (Web Services) 4 and public transfer (XFER) 13. The public API 4 can be representational state transfer (REST)-based API, user-oriented or partner-oriented.
  • As seen best in FIG. 1A, two major systems 140, 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 the data tier 110, integration/application services tier 120 and the public/web tier 130. For example, in one embodiment, CGW 142 can be configured to operate with SecurePort SSL 1, URL Matcher 2, Dynamic Branded Sites 3, Public API (Web Services) 4 and Public XFER 13, and DPE 144 can be configured to operate with Public XFER 13, Partner Integration Services 7, Business Intelligence 8, Partner Integration Services 9, OLTP 11 and OLAP 12.
  • As seen best in FIG. 1A, the identity management system 100 can comprise one or more product modules 150 including check fraud protection (CFP) 151, identity restoration (IDR) 152, Public Records 153, Credit Data 154, Internet Monitoring 155 and SYCURITY Score 156.
  • It is noted that the like numbers in FIG. 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 in FIG. 1B, the service providers 160 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 providers 160 can include one or more of campaign management 161, payment processing 162, credit bureau data feed 163, independent security scanning and testing 164, and web trends and analytics 165.
  • 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 a system 200 in accordance with some embodiments of the present disclosure, in which the DPE processes a feed by executing fundamental tasks shown.
  • File Retrieval
  • The DPE 200 has been designed to support flexible transmission settings that are defined in the meta data associated with a feed. An FTP Server Remote or internal Server 205 can be functionally connected to a File Retrieval system 210. The File Retrieval system 210 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 a local server 215 where files can be “dropped off” or the system can poll a remote 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
  • A Local File Server 215 can be provided between the File Retrieval system 210 and a File Parsing/File ETL system 220. The File Parsing/File ETL system 220 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. A StagingData system 225 can be provided between the File Parsing/File ETL system 220 and a Business Rule Processing system 230. 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 Business Rule Processing system 230 can be provided between the StagingData system 225 and an ETL into SDB system 240. The Business Rule Processing system 230 can validate records in the StagingData system 225 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 into Destination system 240 can be provided between the Business Rule Processing system 230 and a Destination system 250 such as SDB. The ETL into Destination system 240 can send records that pass all business rules into the Destination system 250. 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 Model 300 can be provided for the Data Processing Engine (DPE). FIG. 3 illustrates an exemplary table 300 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.
  • TransmissionDetail 310—Server and transmission settings, which can include one or more of TransmissionID, ServerName, Username, Password, Port, DirectoryLocation, TransferProtocol, CreatedOn, CreatedBy, UpdatedOn and UpdatedBy fields. TransmissionDetail 310 can be functionally connected to DataFeed 320. For example, TransmissionDetail 310 can have a one-to-many relationship with DataFeed 320.
  • DataFeed 320—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. DataFeed 320 can be functionally connected to one or more of TransmissionDetail 310, FeedDetail 330, Notification 350 and Schedule 360. For example, TransmissionDetail 310, Notification 350 and Schedule 360 each can have a one-to-many relationship with DataFeed 320, and DataFeed 320 can have a one-to-many relationship with FeedDetail 330.
  • FeedDetail 330—Specific file(s) associated with DataFeed 320; Multiple files can be associated with one DataFeed. FeedDetail 330 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. FeedDetail 330 can be functionally connected to one or more of DataFeed 320 and FieldMapping 340. For example, DataFeed 320 can have a one-to-many relationship with FeedDetail 330 and FeedDetail 330 can have a one-to-many relationship with FieldMapping 340.
  • FieldMapping 340—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. FieldMapping 340 can be functionally connected to FeedDetail 330. For example, FeedDetail 330 can have a one-to-many relationship with FieldMapping 340.
  • Notification 350—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. Notification 350 can be functionally connected to DataFeed 320. For example, Notification 350 can have a one-to-many relationship with DataFeed 320.
  • Schedule 360—Scheduling information associated with a specific DataFeed 320, which can include one or more of ScheduleID, ScheduleDetails, CreatedOn, CreatedBy, UpdatedOn and UpdatedBy fields. Schedule 360 can be functionally connected to DataFeed 320. For example, Schedule 360 can have a one-to-many relationship with DataFeed 320.
  • FIG. 4 illustrates an exemplary table 400 in a database, which is used in some embodiments to store information about entities used for file processing. DataFeedJob 410—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. DataFeedJob 410 can be functionally connected to FeedDetailLog 420. For example, DataFeedJob 410 can have a one-to-many relationship with FeedDetailLog 420.
  • FeedDetailLog 420—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. FeedDetailLog 420 can be functionally connected to one or more of DataFeedJob 410 and StagingData 430. For example, DataFeedJob 410 can have a one-to-many relationship with FeedDetailLog 420, and FeedDetailLog 420 can have a one-to-many relationship with StagingData 430.
  • StagingData 430—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. StagingData 430 can be functionally connected to FeedDetailLog420. For example, FeedDetailLog 420 can have a one-to-many relationship with StagingData 430.
  • ErrorLog 440—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 the TransmissionDetail 310
        • i. Define TransferProtocol
          • 1. e.g., FTP
        • ii. Define ServerName
        • iii. Define Port
        • iv. Define Credentialing
          • 1. e.g., Username/Password
      • b. Define DataFeed 320
        • 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. Define FeedDetail 330
        • 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 FieldMapping 340 (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 each DataFeed 320 . . .
        • i. Connect to TransmissionDetail 310
        • ii. Retrieve all associated FeedDetail 330
          • 1. Execute process for each FeedDetail 330 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 to FieldMapping 340 with a destination of StagingData 430
            •  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 into FeedDetailLog 420
        • iii. Iterate back to ii (Retrieve all associated FeedDetail 330)
        • iv. Insert DataFeed 320 execution results into DataFeedJob 410
      • c. Iterate back to b (For each DataFeed 320 . . . )
      • d. For each DataFeed 320, all records in a staging area (for example, stored in StagingData 430 (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., from DataFeed 320, FeedDetail 330
        • 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., FieldMapping 340, and store in temporary local location
      • g. Log FieldMapping 340 construct results to DataFeedJob 410, FeedDetailLog 420
      • h. Based on details in TransmissionDetail 310, transmit the file from local source to destination
      • i. Log transmission results to DataFeedJob 410
  • 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 of SDB Schema 500 of the identity management system, which can be a table in a database. The SDB Shema 500 can include one or more of the following systems: SDBNotificationEvents 510, SDBEvents 520, SDBNotificationCampaigns 530, SDB Campaigns 540, SubscriberProfile 550, SDBPricing 560, SDB Service 565, SDBPartnerService 570, SDB Package 575, Contract 580 and SDBPartner 590.
  • In FIG. 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.
  • SDBNotificationEvents 510 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. SDBNotificationEvents 510 can be functionally connected to one or more of SDBEvents 520 and SDBNotificationCampaigns 530.
  • SDBEvents 520 can comprise one or more of EventID, which can function as PK, EventName, PartnerEventID, CreatedOn, CreatedBy, UpdatedOn and UpdatedBy fields. SDBNotificationEvents 510 can be functionally connected to SDBEvents 520.
  • SDBNotificationCampaigns 530 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. SDBNotificationCampaigns 530 can be functionally connected to one or more of SDBNotificationEvents 510, SDB Campaigns 540 and SubscriberProfile 550.
  • SDB Campaigns 540 can comprise one or more of SDBCampaignID, which can function as PK, CampaignName, SourceSystem, SourceCampaignID, CreatedOn, CreatedBy, UpdatedOn, UpdatedBy fields. SDB Campaigns 540 can be functionally connected to SDBNotificationCampaigns 530.
  • SubscriberProfile 550 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. SubscriberProfile 550 can be functionally connected to one or more of SDBNotificationCampaigns 530 and Contract 580.
  • SDBPricing 560 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. SDBPricing 560 can be functionally connected to one or more of Contract 580 and SDBPartnerService 570.
  • SDB Service 565 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 Service 565 can be functionally connected to SDBPartnerService 570.
  • SDBPartnerService 570 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. SDBPartnerService 570 can be functionally connected to one or more of Contract 580, SDBPartner 590, SDB Service 565 and SDB Package 575.
  • SDB Package 575 can comprise one or more of PackageID, which can function as PK, PackageCode, Name, Description, CreatedOn, CreatedBy, UpdateOn and UpdatedBy fields. SDB Package 575 can be functionally connected to SDBPartnerService 570.
  • Contract 580 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