INDIVIDUAL AND INSTITUTION VIRTUALIZATION MECHANISMS

Abstract

A virtualization capability is adapted support virtualization for an individual or an institution. The virtualization for an individual or an institution may be provided using mappings of real information to virtual information. The virtualization for an individual or an institution may be used to support secure communications by the individual or an institution (e.g., electronic communications, non-electronic communications, or the like). The virtualization for an individual or an institution may include various types of E.164 Number Mapping (ENUM) virtualization, such as user ENUM virtualization, infrastructure ENUM virtualization, private ENUM virtualization, enterprise ENUM virtualization, and the like. The virtualization for an individual or an institution may include virtualization for online transactions in a manner that hides real information associated with the individual or an institution (e.g., name, mailing address, or the like) from the online vendor. The virtualization for an individual or an institution may include other types of virtualization.

Description

CROSS REFERENCE TO RELATED APPLICATION

This application claims the benefit of U.S. Provisional Patent Application Ser. No. 61/614,345, entitled “NEW SECURE COMMUNICATION MECHANISMS AND CAPABILITIES,” filed Mar. 22, 2012, which is hereby incorporated herein by reference in its entirety.

TECHNICAL FIELD

This disclosure relates generally to communications and, more specifically but not exclusively, to security of communications.

BACKGROUND

In many cases, the line between corporate communications and personal communications is becoming blurred. The introduction of certain practices, such as bring your own device (BYOD) or bring your own PC (BYOPC), is putting corporate information at risk. Similarly, technologies such as “big data mining” are putting corporate information at risk. Additionally, there also are instances of corporate information or intentions being shared by corporate users, knowingly or unknowingly, in a manner that enables such information or intentions to be passed on to or obtained by competitors or malicious entities (e.g., via social media websites, public forums, cloud platforms, and the like). While most corporations employ security mechanisms within their corporate networks, such mechanisms do not always adequately secure communications of the corporate users of the corporate networks, which may include both corporate communications and personal communications by the corporate users. Furthermore, many such security issues also exist for communications by users of non-corporate entities, personal communications by individuals, and so forth.

SUMMARY OF EMBODIMENTS

Various deficiencies in the prior art are addressed by embodiments for providing virtualization.

In one embodiment, an apparatus includes a processor and a memory communicatively connected to the processor. The memory is configured to store a mapping of a real identity of an entity to a virtual identity of the entity, where the real identity includes real information associated with the entity, the virtual identity includes virtual information associated with the entity, and the entity includes a user or an institution. The processor is configured to receive a communication for the entity where the communication for the entity includes at least a portion of the real information associated with the entity, and process the communication for the entity using at least a portion of the virtual information from the virtual identity of the entity.

In one embodiment, a computer-readable storage medium stores instructions which, when executed by a computer, cause the computer to perform a method. The method includes maintaining a mapping of a real identity of an entity to a virtual identity of the entity, where the real identity includes real information associated with the entity, the virtual identity includes virtual information associated with the entity, and the entity includes a user or an institution. The method includes receiving a communication for the entity where the communication for the entity includes at least a portion of the real information associated with the entity. The method includes and processing the communication for the entity using at least a portion of the virtual information from the virtual identity of the entity.

In one embodiment, a method includes using a processor and a memory for performing steps. The steps include maintaining a mapping of a real identity of an entity to a virtual identity of the entity, where the real identity includes real information associated with the entity, the virtual identity includes virtual information associated with the entity, and the entity includes a user or an institution. The steps include receiving a communication for the entity where the communication for the entity includes at least a portion of the real information associated with the entity. The steps include processing the communication for the entity using at least a portion of the virtual information from the virtual identity of the entity.

BRIEF DESCRIPTION OF THE DRAWINGS

The teachings herein can be readily understood by considering the following detailed description in conjunction with the accompanying drawings, in which:

FIG. 1 depicts an exemplary environment configured to support individual virtualization or institution virtualization;

FIG. 2 depicts exemplary mappings of real information and virtual information for use in entity virtualization;

FIG. 3 depicts an exemplary system illustrating use of virtualization mapping information to provide secure communications;

FIG. 4 depicts an exemplary embodiment of ENUM virtualization in which user ENUM virtualization is supported;

FIG. 5 depicts an exemplary embodiment of ENUM virtualization in which user ENUM virtualization is supported;

FIG. 6 depicts an exemplary embodiment of ENUM virtualization in which infrastructure ENUM virtualization is supported;

FIG. 7 depicts an exemplary embodiment of ENUM virtualization in which private ENUM virtualization is supported;

FIG. 8 depicts an exemplary embodiment of ENUM virtualization in which enterprise ENUM virtualization is supported;

FIG. 9 depicts an exemplary embodiment of ENUM virtualization in which vCard ENUM virtualization is supported;

FIG. 10 depicts an exemplary embodiment of ENUM virtualization in which Calling Name (CNAM) ENUM virtualization is supported;

FIG. 11 depicts an exemplary embodiment of user virtualization for an online transaction; and

FIG. 12 depicts a high-level block diagram of a computer suitable for use in performing functions described herein.

To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures.

DETAILED DESCRIPTION OF EMBODIMENTS

In general, virtualization capabilities are depicted and described herein, although various other capabilities also may be presented herein. The virtualization capabilities may include one or more an individual virtualization capability for virtualizing one or more aspects of an individual, an institution virtualization capability for virtualizing one or more aspects of an institution, or the like. The virtualization for an individual or an institution may be provided using mappings of real information to virtual information. The virtualization for an individual or an institution may be used to support secure communications by the individual or an institution (e.g., electronic communications, non-electronic communications, or the like). The virtualization for an individual or an institution may include various types of E.164 Number Mapping (ENUM) virtualization, such as user ENUM virtualization, infrastructure ENUM virtualization, private ENUM virtualization, enterprise ENUM virtualization, vCard ENUM virtualization, Calling Name (CNAM) ENUM virtualization, and the like. The virtualization for an individual or an institution may include virtualization for online transactions in a manner that hides real information associated with the individual or an institution (e.g., name, mailing address, or the like) from the online vendor. The virtualization for an individual or an institution may include other types of virtualization. Various embodiments of virtualization capabilities for individuals and institutions may be better understood by way of reference to the description which follows.

FIG. 1 depicts an exemplary environment configured to support individual virtualization or institution virtualization.

As depicted in FIG. 1, environment 100 includes a virtualization entity 110 configured to provide virtualization functions for individuals (represented by an individual 120) or one or more institutions (represented by an institution 130).

The virtualization entity 110 provides virtualization functions, which may be performed for individuals (illustratively, individual 120) or institutions (illustratively, institutions 130). The virtualization entity 110 may be any type of entity which may provide virtualization functions for an individual or an institution. In the case of an individual such as individual 120, for example, virtualization entity 110 may be a federated entity, a virtualization service provider, or the like. In the case of an institution such as institution 130, for example, virtualization entity 110 may be a federated entity, a virtualization service provider, a group within or otherwise affiliated with the institution, or the like. In the case of a combination of individuals and institutions, for example, virtualization entity 110 may be a federated entity, a virtualization service provider, or the like.

The individual 120 represents any individual for which virtualization functions may be provided. Various types of information may be virtualized for the individual 120, including one or more of an identity of the individual (e.g., the name of the individual, the gender of the individual, the age of the individual, or the like), one or more physical addresses of the individual (e.g., home address, mailing address, or the like), device information (e.g., device identifier, device type, device manufacturer, device version number, or the like) for one or more user devices of the individual (e.g., a computer, a smart phone, a modem, a set top box, a television, a gaming console, or the like), one or more network addresses of the individual (e.g., one or more e-mail addresses, one or more domain addresses, one or more Internet Protocol (IP) addresses, E.164 Number Mapping (ENUM) information, or the like), or the like, as well as various combinations thereof. It will be appreciated that although primarily depicted and described with respect to virtualization at the individual level, virtualizations may be maintained for groups of people (e.g., members of a family or the like). It will be appreciated that, although omitted for purposes of clarity, the individual 120 may use one or more user devices to communicate with virtualization entity 110 (e.g., to provide real information to virtualization entity 110 and receive virtual information generated by virtualization entity 110 based on the real information). The propagation of real information from individual 120 to virtualization entity 110 (e.g., from a user device of the individual 120) and propagation of associated virtual information from virtualization entity 110 to individual 120 (e.g., to a user device of the individual 120) is depicted in FIG. 1. An individual also may be referred to herein as a user.

The institution 130 represents any type of institution for which virtualization functions may be provided. For example, institution 130 may be a corporation, an educational institution, an organization, or the like. Various types of information may be virtualized for the institution 130, including one or more of the identity of the institution (e.g., the name of the institution, an institution type of the institution, or the like) one or more physical addresses of the institution (e.g., one or more office address locations, one or more mailing addresses, or the like), information about the organizational structure of the institution (e.g., names of groups within the institution, information associated with matrices of relationships between individuals of the institution, or the like), information associated with physical resources/assets of the institution, information associated with virtual resources/assets of the institution, proprietary information of the institution (e.g., technology areas, product areas, product names, or the like) or the like, as well as various combinations thereof. Additionally, information that may be virtualized for institution 130 may include, for each of one or more individuals associated with institution 130, any of the information described as capable of being virtualized for an individual (or any other type(s) of information which may be associated with an individual in conjunction with his or her role in the institution (e.g., an employee identifier of an employee at a corporation, information associated with a virtual space provided for use by the individual in performing functions on behalf of the institution, or the like)). It will be appreciated that, although omitted for purposes of clarity, the institution 130 may use one or more devices to communicate with virtualization entity 110 (e.g., to provide real information to virtualization entity 110 and receive virtual information generated by virtualization entity 110 based on the real information). The propagation of real information from institution 130 (e.g., from one or more devices of or associated with institution 130) to virtualization entity 110 and propagation of associated virtual information from virtualization entity 110 to institution 130 (e.g., to one or more devices of or associated with institution 130) is depicted in FIG. 1. An institution may be considered to include one or more users which may perform functions on behalf of the institution.

In at least some embodiment, virtual information for a user or institution may be referred to as a virtual profile of the user or the institution, a virtual definition for the user or the institution, or the like.

In at least some embodiments, virtual information for a user or an institution may be static in that the virtual information may be defined and used multiple times.

In at least some embodiments, the virtual information may be renewed periodically (e.g., by the associated user or institution). In at least some embodiments, the virtualization entity 110 may monitor a timer associated with the virtual information of a user or an entity and either renew the virtual information based on a determination that an indication of renewal of the virtual information is received before expiration of the timer or invalidate the virtual information based on a determination that an indication of a renewal of the virtual information is not received before expiration of the timer. The timer may be set by the user or institution. The renewal may be initiated by the user or institution.

In at least some embodiments, the virtual information for a user or an institution may be updated. The virtual information may be updated by a user or institution or automatically (e.g., based on detection of needs of the user or institution, based on detection of one or more trigger conditions, or the like).

In at least some embodiments, virtual information for a user or an institution may be dynamic in that the virtual information may be defined (e.g., generated, modified, or the like) each time that the virtual information is used by the user or entity. For example, each time a sender has something to send to a receiver, a new virtual name may be generated for the sender. For example, each time a user places an order, a new virtual address may be generated for the user.

In at least some embodiments, a virtual definition may have one or more triggers associated therewith. The virtual triggers may trigger expiration of an existing virtual definition, generation of a new virtual definition, or the like, as well as various combinations thereof. The triggers may include one or more of a temporal trigger, an event-based trigger, a context-based trigger, a location-based trigger, or the like, as well as various combinations thereof. The user or institution associated with the virtual definition may be provided with a capability to modify such triggers on demand. For example, a virtual name may expire when a particular time is reached. For example, a new virtual address may be generated when a particular location is reached. The triggers may be maintained and monitored by virtualization entity 110.

In at least some embodiments, the real information associated with virtual information for a user or institution may be modified. This enables the user or institution to update real information (e.g., real name after marriage or divorce, real address after moving, temporary change of home address to vacation address, addition of a new address for a new office location of an institution, or the like) without requiring generation of new virtual information or even modification of existing virtual information (although it will be appreciated that, alternatively or additionally, some or all of the existing virtual information also may be updated or new virtual information may be generated). The updating of real information may be initiated by the associated user or institution, initiated automatically based on detection of one or more conditions (e.g., based on an event, a context, a location, or the like), or the like.

In at least some embodiments, in which a sender and receiver communicate or otherwise interact in some manner, the virtual information associated with the receiver may be obtained by the sender from virtualization entity 110 and only that receiver will be able to translate the virtual information of the receiver back to the real information for the receiver at the virtualization entity 110 via presentation of its credentials.

In at least some embodiments, a user or an institution may apply virtualization multiple times to an entity or its virtual entity. This process may be generated automatically based on one or more profiles initiated or created by a user on demand.

It will be appreciated that, although primarily depicted and described herein with respect to providing virtualization functions for individuals and/or institutions, virtualization functions may be provided for any suitable type of entity or group of entities having associated therewith real information for which associated virtual information may be assigned and used in order to provide security for the entity or group of entities. Accordingly, the various references herein to individual virtualization (or user virtualization) or institution virtualization may be read more generally as references to entity virtualization.

It will be appreciated that, although primarily depicted and described with respect to embodiments in which virtualization mapping information for an entity includes a single set of virtualization mapping information including a mapping of one set of real information to one set of virtual information, virtualization mapping information for an entity include any suitable number of sets of virtualization mapping information where each set of virtualization mapping information may include one or more mappings of one or more sets of real information to one or more sets of virtual information. The different sets of virtualization mapping information or the different mappings between real information and virtual information may be based on one or more factors. For example, the different factors may include different types of information associated with the entity, use under different conditions (e.g., for different devices used by a user, for different types of communication by a user, for different times at which a user communicates, or the like), or the like, as well as various combinations thereof). For example, a given entity may have two sets of virtualization mapping information assigned thereto, including: (1) a first set of virtualization mapping information including a single mapping of real information to virtual information may be used for private communications by the entity and (2) a second set of virtualization mapping information including two mappings of real information of the entity to two different sets of virtual information for the entity may be used for public communications by the entity where the first mapping of real information to a first set of virtual information may be used for communications by the entity via a computer and the second mapping of real information to a second set of virtual information may be used for communications by the entity via a smart phone. For example, a given entity may have three sets of virtualization mapping information assigned thereto, including: (1) a first set of virtualization mapping information including three mappings of real information of the entity to three different sets of virtual information for the entity may be used for data-based communications by the entity where the first mapping of real information to a first set of virtual information may be used for e-mail communications by the entity, the second mapping of real information to a second set of virtual information may be used for instant messaging by the entity, and the third mapping of real information to a third set of virtual information may be used for online purchased made by the entity, (2) a second set of virtualization mapping information including a single mapping of real information to virtual information may be used for voice-based communications by the entity, and (3) a third set of virtualization mapping information including a single mapping of real information to virtual information may be used for other types of communications which may be performed by the entity. It will be appreciated that the multiple sets of virtualization mapping information for an entity may have various temporal associations (e.g., co-existing, existing at different times where the entity modifies the virtualization mapping information over time for enhanced security, or the like, as well as various combinations thereof). It will be appreciated that the foregoing examples are merely a few of the various ways in which virtual information may be mapped to real information of an entity for use in securing communications by the entity. An exemplary embodiment depicting mappings of real information and virtual information for an entity is depicted and described with respect to FIG. 2.

FIG. 2 depicts exemplary mappings of real information and virtual information for use in entity virtualization. As depicted in FIG. 2, an entity 201 has three sets of virtualization mapping information 210₁-210₃ (collectively, sets of virtualization mapping information 210 associated therewith. The first set of virtualization mapping information 210₁ includes a mapping of a set of real information 211₁ to a set of virtual information 212₁ for use in public communications by the entity 201. The second set of virtualization mapping information 210₂ includes a mapping of a set of real information 211₂ to three sets of virtual information 212_2A-212_2C over time for use in private communications by the entity 201. The third set of virtualization mapping information 210₃ includes a mapping of a set of real information 211₃ to three sets of virtual information 212_3A-212_3C over time for use in third-party communications by the entity 201. The sets of real information 211₁, 211₂, and 211₃ may be referred to collectively herein as sets of real information 211 and, similarly, the sets of virtual information 212₁, 212_2A-212_2C, and 212_3A-212_3C may be referred to collectively herein as sets of virtual information 212. In each of the sets of virtualization mapping information 210: (1) the set of real information 211 includes the following real information: Name, Address, Domain, ENUM, vCard, and, other types of real information as represented by <Others>, and (2) the set of virtual information 212 includes the following virtual information that is mapped to the real information: vName, vAddress, vDomain, vENUM, vvCard, and other types of virtual information as represented by <Others>.

Returning now to FIG. 1, it will be appreciated that, as described herein, the virtualization entity 110 provides virtualization functions for individuals or institutions, including generation of mappings of real information and virtual information for use in individual virtualization or institution virtualization.

The virtualization entity 110 includes a virtualization management system 112 and a virtualization mappings database 114. The virtualization management system 112 is configured to provide various virtualization functions as depicted and described herein. The virtualization mappings database 114 is configured to maintain virtualization mapping information that is generated by virtualization management system 112.

The virtualization management system 112 may be configured to receive and process requests for assignment of virtual information based on real information. The virtualization management system 112 receives a virtual information assignment request from an entity (e.g., from individual 120 or institution 130). The virtual information assignment request is a request by the entity for the virtualization management system 112 to assign virtual information corresponding to associated real information of the entity. The real information may be provided to the virtualization management system 112 at any suitable time (e.g., prior to sending of the request or as part of the request). The virtualization management system 112 generates virtual information for the real information. The virtualization management system 112 provides virtualization mapping information including a mapping of the virtual information to the real information. The virtualization management system 112 may maintain the virtualization mapping information locally within the virtualization entity 110 (illustratively, using virtual mappings database 114), propagate the virtualization mapping information toward the requesting entity (as depicted in FIG. 1 for both individual 120 and institution 130), or the like, as well as various combinations thereof.

The virtualization management system 112 may be configured to provide virtualization mapping information of an entity to one or more devices adapted to use the virtualization mapping information in order to provide virtualization functions for the entity. For example, virtualization management system 112 may be configured to provide virtualization mapping information of an entity to a device for use by the device in performing virtualization conversions from real information to virtual information or from virtual information to real information (where it will be appreciated that the virtualization mapping information may be provided to the device for storage at the device for later use by the device in performing virtualization conversions or may be provided to the device on demand in response to a request from the device when the device needs to perform a virtualization conversion). An exemplary embodiment is depicted and described with respect to FIG. 3.

The virtualization management system 112 may be configured to provide various other virtualization functions as depicted and described herein.

FIG. 3 depicts an exemplary system illustrating use of virtualization mapping information to provide secure communications.

As depicted in FIG. 3, system 300 includes virtualization entity 110, a pair of communication endpoints 310 (including a communication source 310_A and a communication destination 310_Z), and a pair of virtualization endpoints 320 (including a virtualization source 320_A and a virtualization destination 320_Z), and a communication network 330. The virtualization endpoints 320 are configured to communicate with virtualization entity 110 and with each other via the communication network 330.

The communication endpoints 310 are endpoints of a communication transaction to be secured using virtual information of an entity. The communication source 310_A may be a user device or a network device and, similarly, the communication destination 310_Z may be a user device or a network device. It will be appreciated that user devices may include desktop computers, laptop computers, tablet computers, landline telephones, cellular phones, smart phones, or the like. It will be appreciated that network devices may include servers, databases, virtual machines, or the like. For example, for a case in which the communication transaction is a voice call, the communication endpoints 310 each may be user devices (e.g., a smart phone and a landline phone, a pair of smartphones or the like). For example, for the case in which the communication transaction is an email, the communication endpoints 310 each may be user devices (e.g., a pair of computers, a computer and a smart phone, or the like. For example, for the case in which the communication transaction is a web browsing session, the communication source 310_A may be a user device and the communication destination 310_Z may be a web server. For example, for the case in which the communication transaction is a network data push, the communication source 310_A may be a network device and the communication destination 310_Z may be a user device.

The virtualization endpoints 320 are configured to secure a communication transaction between communication source 310_A and communication destination 310_Z (or at least a portion of the path between communication source 310_A and communication destination 310_Z, depending on deployment of the virtualization endpoints 320). The virtualization endpoints 320 secure the communication transaction between communication source 310_A and communication destination 310_Z by using virtual information in place of real information for the communication transaction between the virtualization endpoints 320.

The virtualization source 320_A is configured to receive an original (unsecured) communication transaction from communication source 310_A. The virtualization source 320_A is configured to modify the unsecured communication transaction by removing real information and including virtual information associated with the real information, thereby providing a secured communication transaction. The virtualization source 320_A receives the virtual information from virtualization entity 110. The virtualization source 320_A may receive the virtual information from the virtualization entity 110 prior to the time at which the communication transaction is executed and store the virtual information locally (e.g., using a virtualization source database 321_A) such that the virtualization source 320_A may retrieve the virtual information locally at the time of the communication transaction and modify the communication transaction to include the virtual information. The virtualization source 320_A may be configured to request and receive the virtual information from virtualization entity 110 based on detection of the communication transaction and then modify the communication transaction to include virtual information.

The virtualization source 320_A is configured to propagate the communication transaction toward the virtualization destination 320_Z.

The virtualization destination 320_Z is configured to receive a secured communication transaction from virtualization source 320_A. The virtualization destination 320_Z is configured to modify the secured communication transaction by remove the virtual information added to the unsecured communication transaction by virtualization source 320_A and adding the real information removed from the unsecured communication transaction by virtualization source 320_A, thereby recovering the original (unsecured) communication transaction. The virtualization destination 320_Z, like the virtualization source 320_A, receives the virtual information from virtualization entity 110. The virtualization destination 320_Z may receive the virtual information from the virtualization entity 110 prior to the time at which the communication transaction is executed and store the virtual information locally (e.g., using a virtualization destination database 321_Z) such that the virtualization destination 320_Z may retrieve the virtual information locally at the time of the communication transaction and modify the communication transaction to remove the virtual information (and, optionally, to include associated real information). The virtualization destination 320_Z may be configured to request and receive the virtual information from virtualization entity 110 based on detection of the communication transaction and then modify the communication transaction to remove the virtual information (and, optionally, to include associated real information). The virtualization source 320_A is configured to propagate the communication transaction toward the communication destination 310_Z.

The virtualization endpoints 320 may use virtual information that includes one or both of virtual information associated with an entity that is using communication source 310_A and virtual information associated with an entity that is using communication destination 320_A (although, in at least some embodiments, it is more likely that virtualization endpoints 320 will use virtual information that is associated with an entity using communication source 310_A when the communication transaction is being provided in a direction from the communication source 310_A toward the communication destination 310_Z.

The virtualization endpoints 320 each may be deployed at any suitable location between communication source 310_A and communication destination 310_Z (e.g., within a local network with which the communication endpoint 310 is associated, within a communication network of a communications service provider, or the like). It will be appreciated that, although not depicted and described with respect to FIG. 3, a virtualization endpoint 320 also may be included within its associated communication endpoint 310 (e.g., as a secure communication agent or module within a user device or network device).

In at least some embodiments, virtualization capabilities may be used to provide ENUM virtualization. Exemplary embodiments of ENUM virtualization are depicted and described with respect to FIGS. 4-11.

FIG. 4 depicts an exemplary embodiment of ENUM virtualization in which user ENUM virtualization is supported.

As depicted in FIG. 4, communication system 400 includes a first SIP client 410_A associated with a first SIP Proxy 420_A and a second SIP client 410_B associated with a second SIP Proxy 420_B. The communication system 400 also includes: (1) an ENUM/DNS server 430 associated with first SIP Proxy 420_A, and a first Virtualization Server 450_A associated with ENUM/DNS server 430 and (2) a second Virtualization Server 450_B associated with second SIP Proxy 420_B. The first SIP Proxy 420_A and second SIP Proxy 420_B are configured to communicate via a communication network (e.g., the Internet).

As further depicted in FIG. 4, communication system 400 includes various types of real and virtual information. The second SIP client 410_B has a telephone number (e.g., x-xxx-xxx-xxxx) associated therewith. The second SIP client 410_B also has a real SIP name and a real SIP domain (e.g., sip:name@domain.com) associated therewith. The ENUM/DNS server 430 stores a mapping of the telephone number of second SIP client 410_B to the real SIP name and real SIP domain of second SIP client 410_B. The first Virtualization Server 450_A and second Virtualization Server 450_B each have access to virtualization mapping information for second SIP client 410_B that includes a mapping of the real SIP name and real SIP domain of second SIP client 410_B to a virtual SIP name and a virtual SIP domain (e.g., sip:v-name@v-domain) assigned for the second SIP client 410_B.

The communication system 400 is configured to support user ENUM virtualization. The communication system 400 is configured to support a user ENUM/SIP call flow (in which the ENUM query is initiated by first SIP client 410_A) adapted to provide user ENUM virtualization. At step 461, a caller associated with first SIP client 410_A dials the telephone number associated with the second SIP client 410_B, and a message is routed from first SIP client 410_A to first SIP Proxy 420_A. At step 462, first SIP Proxy 420_A (e.g., operating as a proxy UAC for the first SIP client 510_A) queries the ENUM/DNS server 430 for the location of the second SIP client 410_B based on the telephone number associated with the second SIP client 410_B. At step 463, the ENUM/DNS server 430 returns a NAPTR record (including a virtual SIP URL, e.g., sip:v-name@v-domain.com) to the first SIP Proxy 420_A, where the ENUM/DNS server 430 generates the NAPTR record by using the telephone number associated with the second SIP client 410_B to retrieve the real SIP URL associated with the second SIP client 410_B via an ENUM/DNS lookup at ENUM/DNS server 430, querying the first Virtualization Server 450_A using the real SIP URL associated with the second SIP client 410_B to obtain the virtual SIP URL that is mapped to the real SIP URL for the second SIP client 410_B, and including the virtual SIP URL associated with the second SIP client 410_B (rather than the real SIP URL associated with the second SIP client 410_B) in the NAPTR record. At step 464, first SIP Proxy 420_A (e.g., operating as a proxy UAC for the first SIP client 510_A) initiates connection of the call to second client device 410_B using the virtual SIP URL by propagating a SIP call request message (which includes the virtual SIP URL) from first SIP Proxy 420_A to second SIP Proxy 420_B. At step 465, the second SIP Proxy 520_B queries the second Virtualization Server 450_B associated with second SIP Proxy 420_B using the virtual SIP URL associated with second client device 510_B to obtain the real SIP URL associated with the second client device 410_B. At step 466, the second Virtualization Server 450_B associated with the second SIP Proxy 420_B returns a NAPTR record (including the real SIP URL, e.g., sip:name@domain.com) to second SIP Proxy 420_B, where the second Virtualization Server 450_B generates the NAPTR record by using the virtual SIP URL as a key into virtualization mapping information associated with the second SIP client 410_B in order to obtain the real SIP URL associated with the second SIP client 410_B. At step 467, the second SIP Proxy 420_B sends a call setup message to second SIP client 410_B using the real SIP URL. In this manner, the real SIP URL of second SIP client 410_B is hidden for the length of the communication path between first SIP proxy 420_A and second SIP Proxy 420_B.

FIG. 5 depicts an exemplary embodiment of ENUM virtualization in which user ENUM virtualization is supported.

As depicted in FIG. 5, communication system 500 includes a first SIP client 510_A associated with a first SIP Proxy 520_A and a second SIP client 510_B associated with a second SIP Proxy 520_B. The communication system 500 also includes: (1) an ENUM/DNS server 530 associated with first SIP Proxy 520_A, an ENUM database 540 associated with ENUM/DNS server 530, and a first Virtualization Server 550_A associated with ENUM/DNS server 530 and (2) a second Virtualization Server 550_B associated with second SIP Proxy 520_B. The first SIP Proxy 520_A and second SIP Proxy 520_B are configured to communicate via a communication network (e.g., the Internet).

As further depicted in FIG. 5, communication system 500 includes various types of real and virtual information. The second SIP client 510_B has a telephone number (e.g., x-xxx-xxx-xxxx) associated therewith. The second SIP client 510_B also has a real SIP name and a real SIP domain (e.g., sip:name@domain.com) associated therewith. The ENUM/DNS server 530 stores a mapping of the telephone number of second SIP client 510_B to the real SIP name and real SIP domain of second SIP client 510_B. The first Virtualization Server 550_A and second Virtualization Server 550_B each have access to virtualization mapping information for second SIP client 510_B that includes a mapping of the real SIP name and real SIP domain of second SIP client 510_B to a virtual SIP name and a virtual SIP domain (e.g., sip:v-name@v-domain) assigned for the second SIP client 510_B.

The communication system 500 is configured to support user ENUM virtualization. The communication system 500 is configured to support a user ENUM/SIP call flow (in which the ENUM query is initiated by first SIP client 510_A) adapted to provide user ENUM virtualization. At step 561, a caller associated with first SIP client 510_A dials the telephone number associated with the second SIP client 510_B. At step 562, first SIP client 510_A (e.g., a UAC of first SIP client 510_A) queries the ENUM/DNS server 530 for the location of the second SIP client 510_B based on the telephone number associated with the second SIP client 510_B. At step 563, the ENUM/DNS server 530 returns a NAPTR record (including a virtual SIP URL, e.g., sip:v-name@v-domain.com) to the first SIP client 510_A, where the ENUM/DNS server 530 generates the NAPTR record by using the telephone number associated with the second SIP client 510_B to retrieve the real SIP URL associated with the second SIP client 510_B via an ENUM/DNS lookup at ENUM/DNS server 530, querying the first Virtualization Server 550_A using the real SIP URL associated with the second SIP client 510_B to obtain the virtual SIP URL that is mapped to the real SIP URL for the second SIP client 510_B, and including the virtual SIP URL associated with the second SIP client 510_B (rather than the real SIP URL associated with the second SIP client 510_B) in the NAPTR record. At step 564, the first SIP client 510_A (e.g., a UAC of the first SIP client 510_A) initiates a call to second client device 510_B using the virtual SIP URL. The SIP call request message is propagated from first SIP client 510_A to first SIP Proxy 520_A and from SIP Proxy 520_A to second SIP Proxy 520_B. At step 565, the second SIP Proxy 520_B queries the second Virtualization Server 550_B associated with second SIP Proxy 520_B using the virtual SIP URL associated with second client device 510_B to obtain the real SIP URL associated with second client device 510_B. At step 566, the second Virtualization Server 550_B associated with second SIP Proxy 520_B returns a NAPTR record (including the real SIP URL, e.g., sip:name@domain.com) to second SIP Proxy 520_B, where the second Virtualization Server 550_B generates the NAPTR record by using the virtual SIP URL as a key into virtualization mapping information associated with the second SIP client 510_B in order to obtain the real SIP URL associated with the second SIP client 510_B. At step 567, the second SIP Proxy 520_B sends a call setup message to second SIP client 510_B using the real SIP URL. In this manner, the real SIP URL of second SIP client 510_B is hidden for the length of the communication path between first SIP client 510_A and second SIP Proxy 520_B.

FIG. 6 depicts an exemplary embodiment of ENUM virtualization in which infrastructure ENUM virtualization is supported.

As depicted in FIG. 6, communication system 600 includes a first SIP client 610_A (denoted as SIP client A) associated with a first carrier network 620_A (denoted as carrier A) and a second SIP client 610_B (denoted as SIP client B) associated with a second carrier network 620_B (denoted as Carrier B). The communication system 600 also includes: (1) a first Virtualization Server 650_A associated with first carrier network 620_A; (2) a second Virtualization Server 650_B associated with second carrier network 620_B, and (3) an ENUM/DNS server 630, associated with first carrier network 620_A and second carrier network 620_B, an Infrastructure ENUM (I-ENUM) database 640 associated with ENUM/DNS server 630_I, and a third Virtualization Server 650_I associated with ENUM/DNS server 630_I.

The first carrier network 620_A includes a SIP PBX 621 (to which the first SIP client 610_A is connected) configured to communicate at least with ENUM/DNS server 630_I. The second carrier network 720_B includes a SIP Proxy 622. The first carrier network 620_A and second carrier network 620_B include pluralities of interconnected communication elements 623 supporting communication between first SIP client 610_A and second SIP client 610_B (as well as between various other elements depicted and described with respect to FIG. 6). As depicted in FIG. 6, a communication path 660 between first SIP client 610_A and second SIP client 610_B includes SIP PBX 621 and SIP Proxy 622.

The communication system 600 is configured to support I-ENUM virtualization.

In at least some embodiments of I-ENUM virtualization, one or more service providers may selectively announce to one or more other service providers a set of interconnection points for service termination. The interconnection points may be virtualized using a federated Virtualization Service at the I-ENUM location. The virtualization of interconnection points in this manner may be used to ensure that only the source carrier and the destination carrier are able to know the origination and destination of the I-ENUM.

In at least some embodiments, I-ENUM virtualization may be provided by (1) having a service provider announce, in some I-ENUM DNS domain, the virtualized E.164 number block for which the service provider is the service provider of record, (2) having the service provider populate its DNS zone with a description(s) of the services that the service provider is willing to terminate, and (3) having the service provider nominate the IP interconnection points (e.g., URIs or the like) that perform service termination in the network of the terminating service provider.

It will be appreciated that I-ENUM virtualization may utilize virtualization technology that is the same as or at least similar to virtualization technology utilized for user ENUM virtualization (e.g., as depicted and described with respect to FIG. 5); however, in I-ENUM virtualization the service providers are attempting to undertake the virtualized discovery and termination operation relative to the terminating service provider (rather than relative to the end user as in user ENUM virtualization). Thus, in at least some embodiments of I-ENUM virtualization, the operations that are performed are similar to operations performed for user ENUM virtualization, but translated into a service provider context. In at least some embodiments, for example, such operations may include identifying the service being requested, (2) performing a lookup for the called virtualized E.164 number in the I-ENUM DNS domain, selecting the virtualized URI of the terminating carrier for a compatible terminating service entry that is published against an enclosing virtualized number block entry, and completing the call request using the virtualized service interconnection point.

FIG. 7 depicts an exemplary embodiment of ENUM virtualization in which private ENUM virtualization is supported.

As depicted in FIG. 7, communication system 700 includes a first SIP client 710_A (denoted as SIP client A) associated with a first carrier network 720_A (denoted as carrier A) and a second SIP client 710_B (denoted as SIP client B) associated with a second carrier network 720_B (denoted as Carrier B). The communication system 700 also includes: (1) a first ENUM/DNS server 730_A associated with first carrier network 720_A, a first Private ENUM (P-ENUM) database 740_A associated with first ENUM/DNS server 730_A, and a first Virtualization Server 750_A associated with first ENUM/DNS server 730_A; (2) a second ENUM/DNS server 730_B associated with second carrier network 720_B, a second Private ENUM (P-ENUM) database 740_B associated with second ENUM/DNS server 730_B, and a second Virtualization Server 750_B associated with second ENUM/DNS server 730_B; and (3) a third ENUM/DNS server 730, associated with first carrier network 720_A and second carrier network 720_B, an Infrastructure ENUM (I-ENUM) database 740, associated with third ENUM/DNS server 730_I, and a third Virtualization Server 750_I associated with third ENUM/DNS server 730_I.

The first carrier network 720_A includes a SIP PBX 721 (to which the first SIP client 710_A is connected) configured to communicate at least with first ENUM/DNS server 730_A and third ENUM/DNS server 730_I. The second carrier network 720_B includes a SIP Proxy 722 configured to communicate at least with second ENUM/DNS server 730_B. The first carrier network 720_A and second carrier network 720_B include pluralities of interconnected communication elements 723 supporting communication between first SIP client 710_A and second SIP client 710_B (as well as between various other elements depicted and described with respect to FIG. 7). As depicted in FIG. 7, a communication path 760 between first SIP client 710_A and second SIP client 710_B includes SIP PBX 721 and SIP Proxy 722.

The communication system 700 is configured to support private ENUM virtualization. As depicted and described with respect to FIG. 6, I-ENUM virtualization identifies the service provider of record where the business relationship between service providers is securely encapsulated via virtualization. However, if there is no business relationship between service providers, then direct interconnection is not possible where the service providers use virtualized private ENUMS. Thus, in at least some embodiments, private ENUM virtualization may be used translate a virtualized E.164 number into a virtualized URI, and I-ENUM virtualization may then be used to interconnect the virtualized private ENUMs.

FIG. 8 depicts an exemplary embodiment of ENUM virtualization in which enterprise ENUM virtualization is supported.

As depicted in FIG. 8, communication system 800 includes three SIP clients 810 as follows: (1) a first SIP client 810_A1 (denoted as SIP client A1) and a second SIP client 810_A2 (denoted as SIP client A2) associated with a first carrier network 820_A (denoted as carrier A) and (2) a third SIP client 810_B (denoted as SIP client B) associated with a second carrier network 820_B (denoted as Carrier B). The communication system 900 also includes an ENUM/DNS server 830, an ENUM database 840 associated with ENUM/DNS server 830, and a Virtualization Server 850 associated with ENUM/DNS server 830.

The first carrier network 820_A includes a SIP PBX 821 (to which the first SIP client 810_A1 is connected) configured to communicate at least with the ENUM/DNS server 830. The second carrier network 820_B includes a SIP Proxy 822 configured to communicate at least with third SIP client 810_B and ENUM/DNS server 830. The first carrier network 820_A and second carrier network 820_B include pluralities of interconnected communication elements 823 supporting communication between the SIP clients 810 (as well as between various other elements depicted and described with respect to FIG. 8).

The communication system 800 is configured to support various forms of enterprise ENUM virtualization.

In at least some embodiments, communication system 800 is configured to support private ENUM virtualization within the enterprise context (e.g., supporting internal translation from E.164 to SIP URI). This is denoted in FIG. 8 by element number 891. The use of private ENUM virtualization may be better understood by way of reference to FIG. 7.

In at least some embodiments, communication system 800 is configured to support I-ENUM virtualization within the enterprise context (e.g., supporting internal translation from E.164 to SIP URI). This is denoted in FIG. 8 by element number 892. The use of I-ENUM virtualization may be better understood by way of reference to FIG. 6.

In at least some embodiments, communication system 1000 is configured to support public ENUM virtualization within the enterprise context (e.g., supporting internal translation from E.164 to SIP URI). This is denoted in FIG. 8 by element number 893.

The communication system 800 may be configured to support various other forms of enterprise ENUM virtualization.

FIG. 9 depicts an exemplary embodiment of ENUM virtualization in which vCard ENUM virtualization is supported.

As depicted in FIG. 9, communication system 900 includes a first SIP client 910_A (denoted as SIP client A) associated with a first carrier network 920_A (denoted as carrier A) and a second SIP client 910_B (denoted as SIP client B) associated with a second carrier network 920_B (denoted as Carrier B). The communication system 900 also includes an ENUM/DNS server 930, a Private ENUM (P-ENUM) database 940 associated with ENUM/DNS server 930, and a Virtualization Server 950 associated with ENUM/DNS server 930. The communication system 900 also includes a vCard server 960, a vCard database 970 associated with vCard server 960, and a Virtualization Server 980 associated with vCard server 960.

The first carrier network 920_A includes a SIP PBX 921 (to which the first SIP client 910_A is connected). The second carrier network 920_B includes a SIP Proxy 922 configured to communicate at least with second SIP client 910_B, ENUM/DNS server 930, and vCard server 960. The first carrier network 920_A and second carrier network 920_B include pluralities of interconnected communication elements 923 supporting communication between first SIP client 910_A and second SIP client 910_B (as well as between various other elements depicted and described with respect to FIG. 9). As depicted in FIG. 10, a communication path 990 between first SIP client 910_A and second SIP client 910_B includes SIP PBX 921 and SIP Proxy 922.

The communication system 900 is configured to support vCard ENUM virtualization. The use of vCard ENUM virtualization may be better understood by way of reference to FIG. 5.

FIG. 10 depicts an exemplary embodiment of ENUM virtualization in which Calling Name (CNAM) ENUM virtualization is supported.

As depicted in FIG. 10, a communication system 1000 includes a first SIP client 1010_A (denoted as SIP client A) associated with a first carrier network 1020_A (denoted as carrier A) and a second SIP client 1010_B (denoted as SIP client B) associated with a second carrier network 1020_B (denoted as Carrier B). The communication system 1000 also includes an ENUM/DNS server 1030, a Private ENUM (P-ENUM) database 1040 associated with ENUM/DNS server 1030, and a Virtualization Server 1050 associated with ENUM/DNS server 1030.

The first carrier network 1020_A includes a SIP PBX 1021 (to which the first SIP client 1010_A is connected). The second carrier network 1020_B includes a SIP Proxy 1022 configured to communicate at least with second SIP client 1010_B and ENUM/DNS server 1030. The first carrier network 1020_A and second carrier network 1020_B include pluralities of interconnected communication elements 1023 supporting communication between first SIP client 1010_A and second SIP client 1010_B (as well as between various other elements depicted and described with respect to FIG. 9). As depicted in FIG. 9, a communication path 1060 between first SIP client 1010_A and second SIP client 1010_B includes SIP PBX 1021 and SIP Proxy 1022.

The communication system 1000 is configured to support CNAM ENUM virtualization. The communication system 1000 is configured to support a query on the originating E.164 number of the first SIP client 1010_A in order to determine the Calling Name (CNAM) of the user associated with first SIP client 1010_A. The second SIP client 1010_B generates a query request. The second SIP client 1010_B sends a query request to SIP Proxy 1022. The SIP Proxy 1022 propagates the query request to ENUM/DNS server 130. The ENUM/DNS server 130 propagates the query request to Virtualization Server 1050. The Virtualization Server 1050 determines the CNAM of the user associated with first SIP client 1010_A. The Virtualization Server 1050 generates a query response including the CNAM of the user associated with first SIP client 1010_A. The Virtualization Server 1050 propagates the query response to the ENUM/DNS server 130. The ENUM/DNS server 1030 propagates the query response to the SIP Proxy 1022. The SIP Proxy 1022 propagates the query response to the second SIP client 1010_B.

As will be appreciated at least from the various ENUM virtualization embodiments depicted and described with respect to FIGS. 4-10, ENUM virtualization may be used to provide security for one or more of access (e.g., secure public DNS, secure private DNS, or the like), content (e.g., user URI, interconnection URI, or the like), control of content (e.g., secure user opt-in and control, secure carrier control, or the like), routing decisions (e.g., secure originating user, terminating user, carrier, or the like), or the like, as well as various combinations thereof.

In at least some embodiments, virtualization capabilities may be used to provide online retail virtualization. Exemplary embodiments of online retail virtualization are depicted and described with respect to FIGS. 11-12.

FIG. 11 depicts an exemplary embodiment of user virtualization for an online transaction.

As depicted in FIG. 11, a communication system 1100 includes a user device 1110, online transaction server 1120, a parcel processing center 1130, a virtualization entity 1140, and a communication network 1150. The user device 1110, the online transaction server 1120, the parcel processing center 1130, and the virtualization entity 1140 each are configured to communicate with the communication network 1150.

The user device 1110 is a communication device of a user 1102, where the user has a real name and a real address (e.g., home address, mailing address, or the like, which, illustratively, is associated with a location 1103) associated therewith. The user device 1110 is configured to enable the user to browse for products and services online and to place orders for products and services online (illustratively, from online transaction server 1120). For example, user device 1110 may be a desktop computer, a laptop computer, a tablet computer, a smartphone, or the like.

The online transaction server 1120 is operated by an entity. The online transaction server 1120 hosts a website via which users may browse products offered by the entity and place orders for products offered by the entity.

The parcel processing center 1130 is operated by a parcel carrier which is capable of delivering parcels. The parcel processing center 1130 may include one or more network-based systems which may be configured to perform functions such as managing parcel deliveries, enabling third parties to track parcel deliveries, obtaining virtualization mapping information from virtual entity 1140, or the like, as well as various combinations thereof.

The virtualization entity 1140 is configured to assign and maintain virtualization mapping information for individuals and institutions. The virtualization mapping information for user 1102 includes: (1) a mapping of a real name of the user 1102 to a virtual name for the user 1102 (e.g., a fake name, a numeric or alphanumeric identifier, or the like) and (2) a mapping of a real address of the user 1102 (associated with location 1103) to a virtual address for the user 1102 (e.g., a fake address, a numeric or alphanumeric identifier, or the like). For example, the virtualization entity 1140 may be implemented as depicted and described with respect to virtualization entity 110 of FIG. 1.

The operation of the system 1100 in providing user virtualization for an online transaction may be better understood by considering an example in which user 1102 of user device 1110 orders a product from the entity that is operating online transaction server 1120 and the product is delivered to the user 1102, at location 1103, by the parcel carrier that is operating parcel processing center 1130. The user 1102 uses the user device 1110 to access a website hosted by online transaction server 1120. The user 1102 browses for various products available via the website. The user 1102 decides to order one of the products listed on the website, and begins a checkout process. During the checkout process, rather than providing the real information for the user 1102 (e.g., the real name and real address of the user 1102), the virtual information for the user 1102 (e.g., the virtual name and virtual address of the user 1102) are provided to online transaction server 1120. The virtual name and virtual address of the user may be entered by the user 1102 during the checkout process, may be automatically entered by user device 1110 during the checkout process, may be added to the order by the user device 1110 after the checkout process is complete but before the order is propagated toward online transaction server 1120 (e.g., where the user 1102 enters the real name and real address of the user 1102 during checkout, and the real information of the user 1102 is replaced by the corresponding virtual information of the user 1102 before the order is propagated toward online transaction server 1120). The entity which is operating the online transaction server 1120 receives and processes the order for the product, packages the product for shipping (including specification of the virtual name and virtual address of the user 1102, as provided in the order received from user device 1110, for use in delivering the product to the user 1102), and provides the product to the parcel processing center 1130. The parcel processing center 1130 uses virtualization mapping information associated with the user 1102 to determine the real name and real address of the user 1102 based on the virtual name and virtual address of the user 1102 that is received from the entity that is operating online transaction server 1120. The parcel processing center 1130 may perform the reverse mapping from the virtual information of the user 1102 to the real information of the user 1102 locally (e.g., where the parcel processing center 1130 previously received virtualization mapping information for the user 1102 from the virtualization entity 1140) or by initiating a request to the virtualization entity 1140 (e.g., a request for the virtualization mapping information for the user 1102 so that the parcel processing center 1130 can determine the real information based on the virtual information, a request for the real information for the user 1102 where the parcel processing center 1130 sends the virtual information for the user 1102 to the virtualization entity 1140 such that virtualization entity 1140 may determine the real information associated with the virtual information and may return the real information to the parcel processing center 1130, or the like). The parcel carrier which is operating parcel processing center 1130 may then deliver the product to the user 1102 at the location 1103 based on the real name and real address of the user 1102 (where, it will be appreciated, the real address of the user 1102 specifies the location 1103). In this manner, use of the virtual information of the user 1102 rather than the real information of the user 1102 prevents the entity which is operating online transaction server 1120, as well as any entity which may have access to communications between user device 1110 and online transaction server 1120, from gaining access to the real information of the user 1102. This provides significant protection for the real information of the user 1102.

It will be appreciated that, although primarily depicted and described individually, the various security mechanisms depicted and described herein also may be used in various combinations.

It will be appreciated that, although primarily depicted and described within the context of providing virtualization for a single individual, virtualization may be provided for a group of individuals (e.g., member of a family, a group of friends, or the like). Similarly, It will be appreciated that, although primarily depicted and described within the context of providing virtualization for a single institution, virtualization may be provided for a group of institutions (e.g., a group of companies, a group of educational institutions, or the like).

FIG. 12 depicts a high-level block diagram of a computer suitable for use in performing functions described herein.

As depicted in FIG. 12, computer 1200 includes a processor element 1202 (e.g., a central processing unit (CPU) and/or other suitable processor(s)) and a memory 1204 (e.g., random access memory (RAM), read only memory (ROM), and the like).

The computer 1200 also may include a cooperating module/process 1205. In one embodiment, the cooperating process 1205 can be loaded into memory 1204 and executed by the processor 1202 to implement functions as discussed herein. Thus, cooperating process 1205 (including associated data structures) can be stored on a computer readable storage medium, e.g., RAM memory, magnetic or optical drive or diskette, and the like.

The computer 1200 also may include one or more input/output devices 1206 (e.g., a user input device (such as a keyboard, a keypad, a mouse, and the like), a user output device (such as a display, a speaker, and the like), an input port, an output port, a receiver, a transmitter, and storage devices (e.g., a tape drive, a floppy drive, a hard disk drive, a compact disk drive, and the like)).

It will be appreciated that computer 1200 depicted in FIG. 12 provides a general architecture and functionality suitable for implementing functional elements described herein and/or portions of functional elements described herein.

It will be appreciated that the functions depicted and described herein may be implemented in hardware or a combination of software and hardware, e.g., using a general purpose computer, via execution of software on a general purpose computer so as to provide a special purpose computer, using one or more application specific integrated circuits (ASICs) or any other hardware equivalents, or the like, as well as various combinations thereof.

It will be appreciated that at least some of the method steps discussed herein may be implemented within hardware, for example, as circuitry that cooperates with the processor to perform various method steps. Portions of the functions/elements described herein may be implemented as a computer program product wherein computer instructions, when processed by a computer, adapt the operation of the computer such that the methods or techniques described herein are invoked or otherwise provided. Instructions for invoking the inventive methods may be stored in fixed or removable media, transmitted via a data stream in a broadcast or other signal bearing medium, or stored within a memory within a computing device operating according to the instructions.

It will be appreciated that the term “or” as used herein refers to a non-exclusive “or,” unless otherwise indicated (e.g., “or else” or “or in the alternative”).

It will be appreciated that, while the foregoing is directed to various embodiments of features present herein, other and further embodiments may be devised without departing from the basic scope thereof.

Claims

1. An apparatus, comprising:

a memory configured to store a mapping of a real identity of an entity to a virtual identity of the entity, wherein the real identity comprises real information associated with the entity and the virtual identity comprises virtual information associated with the entity, wherein the entity comprises an individual or an institution; and

a processor communicatively connected to the memory, the processor configured to: receive a communication for the entity, the communication for the entity comprising at least a portion of the real information associated with the entity; and process the communication for the entity using at least a portion of the virtual information from the virtual identity of the entity.

2. The apparatus of claim 1, wherein the processor is configured to:

receive new real information associated with the entity; and

update at least a portion of the real information based on the new real information.

3. The apparatus of claim 1, wherein the processor is configured to:

receive new virtual information associated with the entity; and

update at least a portion of the virtual information based on the new virtual information.

4. The apparatus of claim 1, wherein the processor is configured to:

receive a request for generation of new virtual information associated with the entity;

generate the new virtual information for the entity; and

update at least a portion of the virtual information based on the new virtual information.

5. The apparatus of claim 1, wherein the processor is configured to:

monitor a timer associated with the virtual information; and

invalidate at least a portion of the virtual information based on a determination that an indication of a renewal of the virtual information is not received before expiration of the timer.

6. The apparatus of claim 1, wherein the processor is configured to:

generate or modify at least a portion of the virtual information dynamically based on receipt of the communication for the entity.

7. The apparatus of claim 1, wherein the processor is configured to:

generate, modify, or invalidate at least a portion of the virtual information based on detection of at least one trigger condition associated with the virtual information.

8. The apparatus of claim 7, wherein the at least one trigger condition comprises at least one of a temporal trigger, an event-based trigger, a context-based trigger, or a location-based trigger.

9. The apparatus of claim 1, wherein the processor is configured to:

propagate at least a portion of the real information or at least a portion of the virtual information toward a device based on validation of credentials received from the device.

10. The apparatus of claim 1, wherein the mapping is a first mapping of a first real identity of the entity to a first virtual identity of the entity, wherein the processor is configured to:

generate a second mapping of the first real identity of the entity or a second real identity of the entity to a second virtual identity of the entity.

11. The apparatus of claim 1, wherein the mapping is a first mapping of the real identity of the entity to a first virtual identity of the entity, wherein the memory is configured to store a second mapping of the real identity of the entity to a second virtual identity of the entity, wherein the processor is configured to:

select the first mapping for use in processing the communication for the entity based on at least a portion of the real information included in the communication for the entity.

12. The apparatus of claim 1, wherein the real information comprises at least one of a real name of the entity, a real address of the entity, a real domain of the entity, a real ENUM identifier associated with the entity, or a real vCard associated with the entity.

13. The apparatus of claim 1, wherein the virtual information comprises at least one of a virtual name of the entity, a virtual address of the entity, a virtual domain of the entity, a virtual ENUM identifier associated with the entity, or a virtual vCard associated with the entity.

14. The apparatus of claim 1, wherein the communication comprises an order, wherein the real information included in the communication comprises a real name and a real mailing address, wherein the virtual information used for processing the communication comprises a virtual name and a virtual mailing address.

15. The apparatus of claim 1, wherein the communication is an ENUM-based communication, wherein the real information included in the communication comprises a real ENUM identifier, wherein the virtual information used for processing the communication comprises a virtual ENUM identifier.

16. The apparatus of claim 15, wherein the ENUM-based communication is associated with at least one of user ENUM virtualization, infrastructure ENUM virtualization, private ENUM virtualization, enterprise ENUM virtualization, vCard ENUM virtualization, or Calling Name (CNAM) ENUM virtualization.

17. The apparatus of claim 15, wherein the processor is configured to:

identify a service associated with the communication of the entity;

perform a lookup for a called virtualized E.164 number in an ENUM Domain Name Server (DNS) domain;

select a virtualized Uniform Resource Identifier (URI) of a terminating carrier for a compatible terminating service entry that is published against an enclosing virtualized number block entry; and

initiate completion of the call request based on a virtualized service interconnection point.

18. The apparatus of claim 1, wherein the communication comprises a vCard-based communication, wherein the real information included in the communication comprises a real vCard of the individual, wherein the virtual information used for processing the communication comprises a virtual vCard of the individual.

19. A computer-readable storage medium storing instructions which, when executed by a computer, cause the computer to perform a method, the method comprising:

maintaining a mapping of a real identity of an entity to a virtual identity of the entity, wherein the real identity comprises real information associated with the entity and the virtual identity comprises virtual information associated with the entity, wherein the entity comprises an individual or an institution;

receiving a communication for the entity, the communication for the entity comprising at least a portion of the real information associated with the entity; and

processing the communication for the entity using at least a portion of the virtual information from the virtual identity of the entity.

20. A method, comprising:

using a processor and a memory for: maintaining a mapping of a real identity of an entity to a virtual identity of the entity, wherein the real identity comprises real information associated with the entity and the virtual identity comprises virtual information associated with the entity, wherein the entity comprises an individual or an institution; receiving a communication for the entity, the communication for the entity comprising at least a portion of the real information associated with the entity; and processing the communication for the entity using at least a portion of the virtual information from the virtual identity of the entity.