SYSTEMS AND METHODS FOR USE IN ESTABLISHING REUSABLE DATA FILES ASSOCIATED WITH USERS

Systems and methods are provided for extending data files beyond sources of the data files. One example computer-implemented method includes receiving, from a mobile device of a user, selection of an option to extend a data file compiled at a source party, where the option includes a unique identifier for the user and a source identifier, and soliciting, from the mobile device, an image of the user. The method also includes receiving a captured image of the user from the mobile device and retrieving, based on the unique identifier and the source identifier, the data file from the source party. The method then includes, when the captured image matches the data file, storing the data file as a reusable data file, whereby the data file is available to be provided to one or more relying parties, different than the source party, upon consent from the user.

FIELD

The present disclosure is generally directed to systems and methods for use in establishing reusable data files associated with specific users, and in particular, to repurposing a single-use data file for a first party for use with multiple other parties.

BACKGROUND

Users may be associated with data files, which reflect identities of the users. The data files may be specific to particular parties (e.g., particular merchants, etc.), whereby the users establish the data files with the particular parties. In connection therewith, the users are known to provide specified attributes of their identities to the parties, such as, for example, names, addresses, government identifiers, dates of birth, etc., and the parties include the attributes in the data files for the users. As such, the data files are representative of, and include, identities of the users, which are stored with the parties for later use, as needed. For example, a data file at a party, for a user, may include a payment credential specific to the user, whereby a product may be purchased from the party by the user and delivered to the user, without the user having to re-enter data included in the data file (e.g., a shipping address, the payment credential, etc.).

DETAILED DESCRIPTION

When a user applies for an account with a party, or interacts to purchase a product from the party, or otherwise interacts with the party, etc., based on an identity of the user, the party inputs certain identity data related to the user. For example, when a purchase is initiated, the party may require a payment credential and a shipping address. In connection therewith, the party may invite the user to enroll in a data file or profile with the party, whereby the identity data for the user may be re-used in later interactions, etc. The data file, however, is limited to the specific party, whereby the user is required to similarly enroll with each different party with which that the user needs, or desires, to interact. The re-entry of identifying information is inefficient, and may further provide a security danger of exposing the user's identifying information across multiple different parties, etc.

Uniquely, the systems and methods herein provide for establishing reusable data files for users, by leveraging original data files for the users established with first parties (or source parties or sources) for use with one or more other parties. In particular, an identity provider (IDP) may offer a user an option to extend an enrollment of a data file, as generated at a source party (or source) to other parties as a reusable data file. In connection therewith, upon compilation of the data file, through the source party, an option is presented to the user (e.g., via a source application associated with the source party, etc.), to extend the data file to other parties. Then, upon selection of the option, the IDP requests certain information from the source party, and confirms the identity of the user attempting to extend the data file. Once confirmed or verified, the IDP retrieves additional portions of the data file from the source party, as needed, and stores the data file (or portions thereof), whereby the data file is available to be provided to one or more relying parties, different than the source party, upon consent from the user. In this manner, the data file compiled by the source party is usable with various other parties, to reduce, if not eliminate, the repeated manual disclosure, by the user, of the same identifying information to individual ones of the subsequent relying parties. As such, by extending the data file, the user is permitted to seamlessly link the one data file to other relying parties, as desired.

FIG.1illustrates an example system100in which one or more aspects of the present disclosure may be implemented. Although the system100is presented in one arrangement, other embodiments may include the parts of the system100(or other parts) arranged otherwise depending on, for example, relationships between users and identification providers and/or third parties, particular types of users and/or data associated with the users, particular mobile applications implemented, privacy requirements, etc.

The system100generally includes an identification provider (IDP)102, a mobile device104associated with a user106, a source party108(broadly, a source), and a verification provider110, each of which is coupled to one or more networks to provide communication therebetween. The network(s) is/are indicated generally by arrowed lines inFIG.1, and each may include one or more of, without limitation, a local area network (LAN), a wide area network (WAN) (e.g., the Internet, etc.), a mobile network, a virtual network, and/or another suitable public and/or private network capable of supporting communication among two or more of the parts illustrated inFIG.1, or any combination thereof.

The IDP102of the system100generally is associated with forming and/or managing digital identities associated with users (e.g., for user106, etc.), and in this example embodiment, for also managing reusable digital identities for the users in the form of data files, based on digital identities generated for the users (and/or existing for the users, etc.) at one or more sources, such as the source party108.

In connection therewith, the IDP102may participate in providing the digital identity for the user106to one or more relying parties, as required or requested (e.g., by the user106, by the relying party, etc.). InFIG.1, the IDP102is illustrated as a standalone service and/or device of the system100, and is also standalone relative to the source party108. However, the IDP102may additionally, or alternatively, be incorporated in whole or in part with another party in the system100, such as, for example, a payment network, a business entity, or a banking institution, etc., generally separate from the other entities, as described herein. Specifically, for example, the IDP102may be incorporated, in whole or in part, into the Mastercard® payment network and configured to operate as described herein to provide one or more identity-based services to users via and/or in association with the Mastercard® payment network.

In addition, it should be appreciated that while the IDP102is illustrated as a single entity and/or computing device inFIG.1, the IDP102may be segregated into multiple different entities and/or computing devices in other embodiments, with data being distributed and/or exchanged therebetween, so that the IDP102, overall, is still configured to operate as described herein (but includes a distributed configuration, etc.).

The mobile device104of the system100includes a smartphone, tablet, PDA, smartwatch, laptop, etc., or other computing device that is generally considered portable with the user106, when the user106moves from location to location. In addition, the mobile device104may include software, one or more application, one or more browser extension or similar executable instructions, which configure the mobile device104as described herein. In at least one embodiment, though, the mobile device104may be replaced by an immobile computing device associated with the user106, whereby the mobile device104may be more generally referenced to herein as a computing device or communication device.

The source party108, in this example embodiment, includes a first party, with which the user106may interact, whereby the user106communicates identifying information to the source party108for one or more reasons, for example, relating to an interaction between the user106and the source party108, etc. In connection therewith, the source party108may include, for example, a financial provider (e.g., a banking institution, an investment house, etc.), a medical provider, a merchant, a social network host, a service provider (e.g., related to ridesharing, delivery, telecommunications, utilities, plumbing, etc.), etc. In general, then, the user106may enroll with the source party108, for one or more reasons (e.g., as part of the desired interaction, etc.), and in doing so, provide identifying information, such as, for example, a name, address, contact information, biometric(s), government ID, other identifiers (e.g., insurance numbers, employee ID numbers, etc.), etc., as part of the enrollment, as described in more detail below.

The verification provider110includes an entity, or service, associated with verification of information related to users, including the user106, for example, in connection with the provisioning or extending of a digital identity, or data file representative thereof, to or for the user106. In the illustrated embodiment, in connection with the provisioning of a digital identity to (or for) the user106(or extending such digital identity), the verification provider110is configured to perform a biometric verification of the user106, for example, between an image of a document (e.g., provided by the user106as a basis for identifying the user106, etc.) and a biometric (e.g., a facial image or selfie, etc.) for the user106, etc. Additionally, or alternatively, the verification provider110may be configured to verify the user106based on other information about the user106, as provided from or retrieved from, a party seeking the verification (e.g., the source party108, the IDP102, etc.) (e.g., based on a biometric provided by the IDP102, etc.) or other party (e.g., based on information from an agency issuing a document received by the verification provider110, etc.). In other embodiments, the verification provider110may be configured to authenticate the user106in other manners. For example, the verification provider110may be configured to authenticate the user106based on a trusted source of their identity, for example, through a customer authentication (or login) setup at a financial institution for an account of the user106(whereby the financial institution may be the source party108, etc.) (e.g., under an open banking type service that verifies a name and date of birth of the user106, etc.), or through cryptographic verification of a token (e.g., via Chip & PIN of a payment card, NFC read of a passport/identity card, verification of a Mobile Station International Subscriber Directory Number (MSISDN) using a device SIM to obtain identity information of the user, etc.).

In this example embodiment, the verification provider110is illustrated as separate from the IDP102, yet should be understood to be included in part or in whole with the IDP102, or potentially, separate therefrom.

FIG.2illustrates an example computing device200that can be used in the system100ofFIG.1. The computing device200may include, for example, one or more servers, workstations, personal computers, laptops, tablets, smartphones, etc. In addition, the computing device200may include a single computing device, or it may include multiple computing devices located in close proximity or distributed over a geographic region, so long as the computing devices are specifically configured to function as described herein. In the example embodiment ofFIG.1, each of the IDP102, the mobile device104, the source party108, the verification provider110should be understood to include, or as being implemented or embodied in, a computing device at least partially consistent with the computing device200, coupled to (and in communication with) one or more of the networks. However, the system100should not be considered to be limited to the computing device200, as described below, as different computing devices and/or arrangements of computing devices may be used in other embodiments. In addition, different components and/or arrangements of components may be used in other computing devices.

Referring toFIG.2, the example computing device200includes a processor202and a memory204coupled to (and in communication with) the processor202. The processor202may include one or more processing units (e.g., in a multi-core configuration, etc.). For example, the processor202may include, without limitation, a central processing unit (CPU), a microcontroller, a reduced instruction set computer (RISC) processor, an application specific integrated circuit (ASIC), a programmable logic device (PLD), a gate array, and/or any other circuit or processor capable of the functions described herein.

The memory204, as described herein, is one or more devices that permit data, instructions, etc., to be stored therein and retrieved therefrom. The memory204may include one or more computer-readable storage media, such as, without limitation, dynamic random access memory (DRAM), static random access memory (SRAM), read only memory (ROM), erasable programmable read only memory (EPROM), solid state devices, flash drives, CD-ROMs, thumb drives, floppy disks, tapes, hard disks, and/or any other type of volatile or nonvolatile physical or tangible computer-readable media. The memory204may be configured to store, without limitation, identity details and data related to identities of users, biometrics, and/or other types of data (and/or data structures) suitable for use as described herein. Furthermore, in various embodiments, computer-executable instructions (e.g., in the form of applications (e.g., application112, application114, etc.), etc.) may be stored in the memory204for execution by the processor202to cause the processor202to perform one or more of the functions described herein, such that the memory204is a physical, tangible, and non-transitory computer readable storage media. Such instructions often improve the efficiencies and/or performance of the processor202and/or other computer system components configured to perform one or more of the various operations herein (e.g., one or more of the operations of method300, etc.), whereby upon (or in connection with) performing such operation(s) the computing device200may be transformed into a special purpose computing device. It should be appreciated that the memory204may include a variety of different memories, each implemented in one or more of the functions or processes described herein.

In the example embodiment, the computing device200also includes a presentation unit206that is coupled to (and is in communication with) the processor202(however, it should be appreciated that the computing device200could include output devices other than the presentation unit206, etc.). The presentation unit206outputs information, visually or audibly, for example, to a user of the computing device200(e.g., prompts to the user106at the mobile device104, etc.), etc. And various interfaces (e.g., as defined by the applications112,114, etc.) (e.g., including instructions to the user106, etc.) may be displayed at computing device200, and in particular at presentation unit206, to display certain information in connection therewith. The presentation unit206may include, without limitation, a liquid crystal display (LCD), a light-emitting diode (LED) display, an organic LED (OLED) display, an “electronic ink” display, speakers, etc. In some embodiments, the presentation unit206may include multiple devices.

In addition, the computing device200includes an input device208that receives inputs from the user (i.e., user inputs) of the computing device200such as, for example, selections of parties, images of documents, biometrics, etc., in response to prompts, as further described below. The input device208may include a single input device or multiple input devices. The input device208is coupled to (and is in communication with) the processor202and may include, for example, one or more of a keyboard, a pointing device, a mouse, a stylus, a camera, a touch sensitive panel (e.g., a touch pad or a touch screen, etc.), another computing device, and/or an audio input device. In various example embodiments, a touch screen, such as that included in a tablet, a smartphone, or similar device, may behave as both the presentation unit206and an input device208.

Further, the illustrated computing device200also includes a network interface210coupled to (and in communication with) the processor202and the memory204. The network interface210may include, without limitation, a wired network adapter, a wireless network adapter (e.g., an NFC adapter, a Bluetooth™ adapter, etc.), a mobile network adapter, or other device capable of communicating to one or more different ones of the networks herein and/or with other devices described herein. In some example embodiments, the computing device200may include the processor202and one or more network interfaces incorporated into or with the processor202.

With reference again toFIG.1, the system100provides for provisioning of a data file, in the form of a digital identity, for the user106, at the source party108, and then extending the data file to the IDP102as a reusable data file.

In particular, the user106interacts with the mobile device104to provision the data file (in the form of the digital identity for the user106), at or to the source party108. In connection therewith, in the embodiment ofFIG.1, the mobile device104includes source application112and digital identity application114. The source application112configures the mobile device104to communicate with the source party108and/or to operate as described herein. In addition, the source application112may include a software development kit (SDK), or other code or part, which is/are specific to the IDP102and/or the digital identity application114, as described below, whereby the source application112may configure the mobile device104to transform from creating/starting/collecting a data file to extending the data file to the IDP102, etc. It should be appreciated that, while the source application112is included in this example embodiment, the mobile device104may instead access a source website associated with the source party108in other embodiments (whereby the source website configures the mobile device104to communicate/operate similar to the source application112). What's more, it should be appreciated that operations described herein with reference to the mobile device104and the source party108may, at least in part, be in either the source application112(to configure the mobile device104to operate accordingly), or in the source party108, or various combinations thereof.

In turn, the mobile device104, as configured by the source application112, solicits an identity from the user106in connection with the user106attempting to access a service associated with the source party108or to otherwise interact with the source party108. In response, the user106provides an image of himself/herself, as a selfie, at the mobile device104. In connection therewith, the mobile device104, as configured by the source application112, captures the image of the user106and also performs, in this example, a liveness verification (e.g., to confirm the image is an image of the user106and not an image of an image of the user106, etc.). The mobile device104, as configured by the source application112, then also captures an image of a physical document of the user106indicative of an identity of the user106(e.g., a passport, a driver's license, or other government issued ID, a social security card, a health insurance card, an employee ID, a utility bill, etc., generally, which includes a biometric, such as a facial image for the user106; etc.).

The mobile device104, as configured by the source application112, transmits the image of the user106and the image of the document to the source party108. The source party108, in turn, is configured to verify the user106, via the images, with the verification provider110. In particular, the verification provider110is configured to receive the images, to compare the facial image of the user106(e.g., selfie, etc.) to a part of the image of the document including the user's facial image, and to verify the user106, and certain information about the user106, when the comparison reveals a match. The verification provider110is configured to not verify the user106, when the comparison reveals no match.

When the user106is not verified by the verification provider110, the source party108is configured to halt interactions with the user106, or otherwise issue a fail notice.

Conversely, when the user106is verified, the source party108is configured to store a data file, including the information about the user106relating to the user's digital identity, in a memory (e.g., the memory204, etc.) and to generate a unique code for the data file and/or the user106, which is also stored in the data file. Next, the source party108is configured to notify the user106of an option to extend the data file, or classify the data file, as a reusable data file, through the IDP102. In connection therewith, the source party108may be configured to notify the user106of the option, via the source application112, whereby the option is displayed to the user106at the mobile device104(and the option is linked to the unique code for the data file as well as a source identifier). Alternatively, the source party108may be configured to notify the user106via an email or SMS message, etc., which again includes the option linked as described above.

When the user106opts to accept the option to extend his/her data file as a reusable data file, the user106selects the option at the mobile device104(e.g., a deferred deep link option, etc.). In response, the mobile device104is configured to determine whether the digital identity application114is installed in the mobile device104, and to launch the digital identity application114at the mobile device104(when installed) to specify enrollment content for the IDP102. In this embodiment, when the digital identity application114is determined not to be installed, the mobile device104is configured to install the application114(e.g., via an application store application, etc.), and then, to open the application114to receive the specific content for enrollment. In either instance, the source identifier and the unique code for the user's data file is passed to the digital identity application114. It should be appreciated that the digital identity application114is associated with the IDP102, and configures the mobile device104to participate in certain operations specific to the digital identity or data file of the user106(e.g., provision a digital identity, manage a digital identity, share a digital identity with a relying party, etc.).

The mobile device104, as configured by the digital identity application114, next captures an image of the user106(e.g., a selfie, etc.) (and performs a liveness verification in connection therewith), and submits the image, along with the source identifier and the unique code, to the IDP102.

In this example embodiment, the IDP102is configured to request a portion of the data file from the source party108, sufficient to verify the image from the mobile device104(e.g., an image of the user106and/or the physical document included in the data file, etc.), whereupon, the source party108is configured to provide the requested portion of the data file. The IDP102is configured to then submit the image and the portion of the data file to the verification provider110. In turn, the verification provider110is configured to verify the user106, again, based on the images, and to verify the user106with the IDP102, when there is a match.

The IDP102is configured to then retrieve the data file, or additional portions, as needed, from the source party108. The IDP102is configured to transmit the data file to the mobile device104. The mobile device104, as configured by the digital identity application114, displays at least a portion of the data file to the user106for confirmation. The mobile device104, as configured by the digital identity application114, receives a confirmation input from the user106, and creates the data file as a reusable data file for the user106, which may be provided to various relying parties (beyond the source party108) as requested by the relying parties and/or the user106.

FIG.3illustrates an example method300for use in extending data files as reusable data files for users. The example method300is described as implemented in the IDP102, the mobile device104, and the source party (or source)108of the system100. Reference is also made to the computing device200. However, the methods herein should not be understood to be limited to the system100or the computing device200, as the methods may be implemented in other systems and/or computing devices. Likewise, the systems and the computing devices herein should not be understood to be limited to the example method300.

At the outset in the method300, the user106decides to interact with the source party108, whereby at least part of the identity of the user106is required for the interaction. In connection therewith, the user106accesses the source application112, at the mobile device104. And, the mobile device104receives, from the user106, at302, a request to access a service, for example, related to the interaction with the source party108, etc. (e.g., a specific service (e.g., a banking, medical, telecommunication, personal, retail, etc. service), an account service, a scheduling service or task, etc.).

In turn, the mobile device104(by the source application112) requests proof of the identity of the user106, at304. The request may provide a specific instruction as to the form of the identity, whether through a physical document, a biometric, etc. In this example embodiment, the mobile device104requests that the user106capture an image of a physical document, such as, for example, a passport, driver's license, etc., and also capture an image (e.g., a selfie image, etc.) of the user106, etc. In response, the user106presents the document, and the mobile device104captures, at306, an image of the document. It should be appreciated that the mobile device104, in connection therewith, may employ one or more verification techniques, to ensure the document presented is a whole, complete document (and not a document with a different user image, or different information placed thereon, etc.). For example, the mobile device104may perform a visual verification of the document by confirming that particular security features, typeface, check digits, expiry dates, etc. are present and/or are located at appropriate locations based on a type of the document. Additionally, or alternatively, the mobile device104may communicate with an issuer of the document (or other authorized party) and request a validity check for the document.

At308, the mobile device104captures an image of the user106, and in this example, an image of the face of the user106(e.g., a selfie, etc.). It should be appreciated that other biometrics may be captured by the mobile device104in other examples. Generally, however, the biometric will be consistent with a biometric available either from the physical document or from, for example, the verification provider110, etc. In connection with the image capture, the mobile device104provides for a liveness verification (e.g., ensuring some movement or image transition in connection with capturing the image of the user106and/or the biometric from the user106, etc.) to ensure the image being captured is of a live person, and not of a picture.

In addition to the images, the user106may provide identifying information, such as, a name, an address, etc., and may also provide consent to verify the information provided, either internally by the source party108or through one or more third parties (e.g., the verification provider110, etc.).

Next in the method300, at310, the mobile device104(by the source application112) submits the images, and other pertinent identifying information, to be verified, to the source party108. In turn, the source party108transmits an ID request to the verification provider110, at312, including, for example, the images received from the mobile device104. The verification provider110then performs, at314, verification of the user106, via the images(s) included in the request. For example, the verification provider110may compare the image of the user106to the image of the physical document, and specifically, to an image of the user106included in the physical document. A match indicates that the user106is verified, while a mismatch indicates the user106is not verified. In addition, the verification provider110may extract text from the physical document image, and also make other suitable comparisons, etc., with an issuing authority of the document, etc., to verify other identifying information included in the ID request, as needed or desired. That said, as described above, the identity of the user106may be verified in other manners within the scope of the present disclosure, for example, via login credentials to an account maintained for the user106at the verification provider110, via cryptographic verification of a token, etc.

Once the user106is verified, or not, the verification provider110transmits, at314, an ID result to the source party108, which indicates a verified or not verified result. When not verified, the method300ends, and the user106is informed that his/her identity was not verified (e.g., by the source party108via the source application112, by the source party108via an SMS message to the mobile device104, etc.). Conversely, when verified, the source party108assigns, at316, an identifier to the user106and stores the identifying information about the user106(i.e., received from the user106via the source application112and/or verified by the verification provider110) as a data file in memory (e.g., memory204, etc.), as a verified digital identity for the user106.FIG.4illustrates an interface402that may be displayed to the user106, by the source application112, at the mobile device104, which confirms the user's identity has been verified and, then, that the identifying information provided by the user106has been also stored as a data file by the source party108.

Uniquely, then, in the method300, the source party108transmits, at318, a notification to the user106at the mobile device104(via the source application112), which includes an invitation to extend the data file just created beyond the source party108for use with other relying parties, through the IDP102. The invitation includes a link, which is associated with the unique identifier for the user106(as assigned in step316) (or with a different identifier unique to the user106) and a source identifier, etc.FIG.4illustrates an example interface404that may be displayed to the user106, by the source application112, at the mobile device104, which includes an invitation or option406to extend the data file for the user106as a digital identity through the IDP102. At320, in the method300, the user106selects the option or invitation and, in response, the mobile device104launches the digital identity application114.

It should be appreciated that the option included in the notification from the source108(at318) may include a deep link, which is linked to the digital identity application114, even if not installed in the mobile device104(as indicated by the dotted border around “App114” inFIG.3). Consequently, when the option (or deep link) is selected, in step320, the mobile device104will launch the digital identity application114when installed or, when not installed, navigate to an interface through which the digital identity application114may be downloaded and installed at the mobile device104. In connection therewith,FIG.4illustrates an example interface408that may be displayed to the user106, by the source application112, at the mobile device104, with an option to download and install the ID application (e.g., the digital identity application114, etc.), for example, from an App Store, etc. (e.g., where the ID application may be provided by Partner Bank, etc.). In response, when the digital application is not installed, the user106selects the digital identity application114and downloads and installs the same, whereby the digital identity application114is launched in the mobile device104.

In either instance, when launched, the mobile device104(by the digital identity application114) provides an interface to the user106to extend the data file (compiled with the source party108) as a reusable data file for use with various relying parties.

As part of a session with the digital identity application114, at322, the mobile device104provides the unique identifier for the user106and the source identifier for the source party108to the IDP102. In response, the IDP102solicits, at324, an image of the user106, via the mobile device104, for use in verifying the user106. In connection therewith, the mobile device104captures, at326, an image of the user106, and in this example, the face of the user106(e.g., a selfie, etc.). As part of the image capture, the mobile device104may again provide for a liveness verification (as described above). The mobile device104then submits, at328, the captured image to the IDP102.

In turn, the IDP102retrieves, at330, the data file, or a portion thereof, from the source party108based on the unique identifier and the source identifier for the source party108. The IDP102then submits, at332, the captured image (from steps326and328), and an image included in the data file, or portion thereof, from the source party108(e.g., an image of a document associated with the user106, etc.) to the verification provider110. At334, the verification provider110performs verification of the images, for example, by comparing the images, and then, at336, transmits a result of the verification to the IDP102, where the result is either a match or verification, or not. Again, as described above, the identity of the user106may be verified in other manners within the scope of the present disclosure (other than comparison of images), for example, via login credentials to an account maintained for the user106, via cryptographic verification of a token, etc. When the user106is not verified, the method300ends, and the IDP102notifies the user106that his/her identity was not verified (e.g., via the digital identity application114, via a SMS message to the mobile device104, etc.). However, when matched/verified, the IDP102retrieves, at338any additional portions of the data file, from the source party108, as needed or desired, and, at340, verifies the information included in the data file with the user106, at the mobile device104. In particular, the IDP102, via the digital identity application114, may display the information to the user106and request a verification input for some or all of the information, collectively, or separately.FIG.4, for example, illustrates an example interface410that may be displayed to the user106, by the source application112, at the mobile device104, which includes identifying information to be confirmed by the user106.

And, when the user106confirms the identifying information for the data file, the IDP102stores, at342, the data file as a reusable data file in memory (e.g., the memory204, etc.), whereby the reusable data file is accessible to the user106, via the digital identity application114or otherwise, or by relying parties with consent from the user106.

In view of the above, the systems and methods herein provides for extending a data file for a user to additional relying parties, beyond the original source of the data file. In this manner, friction associated with provisioning a data file for a user to multiple, different relying parties may be reduced, and network traffic associated with the repeat provisioning of such files (and related identifying data) to different parties may be reduced.

As will be appreciated based on the foregoing specification, the above-described embodiments of the disclosure may be implemented using computer programming or engineering techniques including computer software, firmware, hardware or any combination or subset thereof, wherein the technical effect may be achieved by performing at least one or more of the following operations: (a) receiving, by a computing device, from a mobile device associated with a user, a selection of an option to extend a data file compiled at a source party, the option including a unique identifier for the user and a source identifier; (b) soliciting, by the computing device, from the mobile device, an image of the user; (c) receiving, by the computing device, a captured image of the user from the mobile device; (d) retrieving, by the computing device, based on the unique identifier and the source identifier, at least a portion of the data file from the source party; and (e) when the captured image from the mobile device matches the at least a portion of the data file, storing the data file as a reusable data file, whereby the data file is available to be provided to one or more relying parties, different than the source party, upon consent from the user.