U.S. patent application number 13/731645 was filed with the patent office on 2013-09-26 for individual and institution virtualization mechanisms.
The applicant listed for this patent is Madhav Moganti, Mayuresh Pandit, Anish Sankalia. Invention is credited to Madhav Moganti, Mayuresh Pandit, Anish Sankalia.
Application Number | 20130254854 13/731645 |
Document ID | / |
Family ID | 49213398 |
Filed Date | 2013-09-26 |
United States Patent
Application |
20130254854 |
Kind Code |
A1 |
Moganti; Madhav ; et
al. |
September 26, 2013 |
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.
Inventors: |
Moganti; Madhav; (Edison,
NJ) ; Pandit; Mayuresh; (Chatham, NJ) ;
Sankalia; Anish; (Lawrenceville, GA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Moganti; Madhav
Pandit; Mayuresh
Sankalia; Anish |
Edison
Chatham
Lawrenceville |
NJ
NJ
GA |
US
US
US |
|
|
Family ID: |
49213398 |
Appl. No.: |
13/731645 |
Filed: |
December 31, 2012 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61614345 |
Mar 22, 2012 |
|
|
|
Current U.S.
Class: |
726/5 |
Current CPC
Class: |
H04L 63/20 20130101;
H04L 41/00 20130101; H04L 63/08 20130101 |
Class at
Publication: |
726/5 |
International
Class: |
H04L 29/06 20060101
H04L029/06 |
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.
Description
CROSS REFERENCE TO RELATED APPLICATION
[0001] 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
[0002] This disclosure relates generally to communications and,
more specifically but not exclusively, to security of
communications.
BACKGROUND
[0003] 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
[0004] Various deficiencies in the prior art are addressed by
embodiments for providing virtualization.
[0005] 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.
[0006] 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.
[0007] 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
[0008] The teachings herein can be readily understood by
considering the following detailed description in conjunction with
the accompanying drawings, in which:
[0009] FIG. 1 depicts an exemplary environment configured to
support individual virtualization or institution
virtualization;
[0010] FIG. 2 depicts exemplary mappings of real information and
virtual information for use in entity virtualization;
[0011] FIG. 3 depicts an exemplary system illustrating use of
virtualization mapping information to provide secure
communications;
[0012] FIG. 4 depicts an exemplary embodiment of ENUM
virtualization in which user ENUM virtualization is supported;
[0013] FIG. 5 depicts an exemplary embodiment of ENUM
virtualization in which user ENUM virtualization is supported;
[0014] FIG. 6 depicts an exemplary embodiment of ENUM
virtualization in which infrastructure ENUM virtualization is
supported;
[0015] FIG. 7 depicts an exemplary embodiment of ENUM
virtualization in which private ENUM virtualization is
supported;
[0016] FIG. 8 depicts an exemplary embodiment of ENUM
virtualization in which enterprise ENUM virtualization is
supported;
[0017] FIG. 9 depicts an exemplary embodiment of ENUM
virtualization in which vCard ENUM virtualization is supported;
[0018] FIG. 10 depicts an exemplary embodiment of ENUM
virtualization in which Calling Name (CNAM) ENUM virtualization is
supported;
[0019] FIG. 11 depicts an exemplary embodiment of user
virtualization for an online transaction; and
[0020] FIG. 12 depicts a high-level block diagram of a computer
suitable for use in performing functions described herein.
[0021] 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
[0022] 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.
[0023] FIG. 1 depicts an exemplary environment configured to
support individual virtualization or institution
virtualization.
[0024] 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).
[0025] 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.
[0026] 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.
[0027] 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.
[0028] 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.
[0029] 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.
[0030] 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.
[0031] 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).
[0032] 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.
[0033] 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.
[0034] 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.
[0035] 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.
[0036] 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.
[0037] 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.
[0038] 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.
[0039] 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.sub.1-210.sub.3 (collectively, sets of
virtualization mapping information 210 associated therewith. The
first set of virtualization mapping information 210.sub.1 includes
a mapping of a set of real information 211.sub.1 to a set of
virtual information 212.sub.1 for use in public communications by
the entity 201. The second set of virtualization mapping
information 210.sub.2 includes a mapping of a set of real
information 211.sub.2 to three sets of virtual information
212.sub.2A-212.sub.2C over time for use in private communications
by the entity 201. The third set of virtualization mapping
information 210.sub.3 includes a mapping of a set of real
information 211.sub.3 to three sets of virtual information
212.sub.3A-212.sub.3C over time for use in third-party
communications by the entity 201. The sets of real information
211.sub.1, 211.sub.2, and 211.sub.3 may be referred to collectively
herein as sets of real information 211 and, similarly, the sets of
virtual information 212.sub.1, 212.sub.2A-212.sub.2C, and
212.sub.3A-212.sub.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>.
[0040] 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.
[0041] 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.
[0042] 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.
[0043] 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.
[0044] The virtualization management system 112 may be configured
to provide various other virtualization functions as depicted and
described herein.
[0045] FIG. 3 depicts an exemplary system illustrating use of
virtualization mapping information to provide secure
communications.
[0046] As depicted in FIG. 3, system 300 includes virtualization
entity 110, a pair of communication endpoints 310 (including a
communication source 310.sub.A and a communication destination
310.sub.Z), and a pair of virtualization endpoints 320 (including a
virtualization source 320.sub.A and a virtualization destination
320.sub.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.
[0047] The communication endpoints 310 are endpoints of a
communication transaction to be secured using virtual information
of an entity. The communication source 310.sub.A may be a user
device or a network device and, similarly, the communication
destination 310.sub.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.sub.A may be a
user device and the communication destination 310.sub.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.sub.A may be a network device and the communication destination
310.sub.Z may be a user device.
[0048] The virtualization endpoints 320 are configured to secure a
communication transaction between communication source 310.sub.A
and communication destination 310.sub.Z (or at least a portion of
the path between communication source 310.sub.A and communication
destination 310.sub.Z, depending on deployment of the
virtualization endpoints 320). The virtualization endpoints 320
secure the communication transaction between communication source
310.sub.A and communication destination 310.sub.Z by using virtual
information in place of real information for the communication
transaction between the virtualization endpoints 320.
[0049] The virtualization source 320.sub.A is configured to receive
an original (unsecured) communication transaction from
communication source 310.sub.A. The virtualization source 320.sub.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.sub.A
receives the virtual information from virtualization entity 110.
The virtualization source 320.sub.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.sub.A) such that the virtualization source 320.sub.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.sub.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.
[0050] The virtualization source 320.sub.A is configured to
propagate the communication transaction toward the virtualization
destination 320.sub.Z.
[0051] The virtualization destination 320.sub.Z is configured to
receive a secured communication transaction from virtualization
source 320.sub.A. The virtualization destination 320.sub.Z is
configured to modify the secured communication transaction by
remove the virtual information added to the unsecured communication
transaction by virtualization source 320.sub.A and adding the real
information removed from the unsecured communication transaction by
virtualization source 320.sub.A, thereby recovering the original
(unsecured) communication transaction. The virtualization
destination 320.sub.Z, like the virtualization source 320.sub.A,
receives the virtual information from virtualization entity 110.
The virtualization destination 320.sub.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.sub.Z) such that the virtualization
destination 320.sub.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.sub.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.sub.A is configured to propagate the
communication transaction toward the communication destination
310.sub.Z.
[0052] 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.sub.A and virtual
information associated with an entity that is using communication
destination 320.sub.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.sub.A when the communication transaction is being
provided in a direction from the communication source 310.sub.A
toward the communication destination 310.sub.Z.
[0053] The virtualization endpoints 320 each may be deployed at any
suitable location between communication source 310.sub.A and
communication destination 310.sub.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).
[0054] 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.
[0055] FIG. 4 depicts an exemplary embodiment of ENUM
virtualization in which user ENUM virtualization is supported.
[0056] As depicted in FIG. 4, communication system 400 includes a
first SIP client 410.sub.A associated with a first SIP Proxy
420.sub.A and a second SIP client 410.sub.B associated with a
second SIP Proxy 420.sub.B. The communication system 400 also
includes: (1) an ENUM/DNS server 430 associated with first SIP
Proxy 420.sub.A, and a first Virtualization Server 450.sub.A
associated with ENUM/DNS server 430 and (2) a second Virtualization
Server 450.sub.B associated with second SIP Proxy 420.sub.B. The
first SIP Proxy 420.sub.A and second SIP Proxy 420.sub.B are
configured to communicate via a communication network (e.g., the
Internet).
[0057] As further depicted in FIG. 4, communication system 400
includes various types of real and virtual information. The second
SIP client 410.sub.B has a telephone number (e.g., x-xxx-xxx-xxxx)
associated therewith. The second SIP client 410.sub.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.sub.B to the real SIP
name and real SIP domain of second SIP client 410.sub.B. The first
Virtualization Server 450.sub.A and second Virtualization Server
450.sub.B each have access to virtualization mapping information
for second SIP client 410.sub.B that includes a mapping of the real
SIP name and real SIP domain of second SIP client 410.sub.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.sub.B.
[0058] 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.sub.A) adapted to provide user
ENUM virtualization. At step 461, a caller associated with first
SIP client 410.sub.A dials the telephone number associated with the
second SIP client 410.sub.B, and a message is routed from first SIP
client 410.sub.A to first SIP Proxy 420.sub.A. At step 462, first
SIP Proxy 420.sub.A (e.g., operating as a proxy UAC for the first
SIP client 510.sub.A) queries the ENUM/DNS server 430 for the
location of the second SIP client 410.sub.B based on the telephone
number associated with the second SIP client 410.sub.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.sub.A, where the ENUM/DNS server 430 generates the NAPTR
record by using the telephone number associated with the second SIP
client 410.sub.B to retrieve the real SIP URL associated with the
second SIP client 410.sub.B via an ENUM/DNS lookup at ENUM/DNS
server 430, querying the first Virtualization Server 450.sub.A
using the real SIP URL associated with the second SIP client
410.sub.B to obtain the virtual SIP URL that is mapped to the real
SIP URL for the second SIP client 410.sub.B, and including the
virtual SIP URL associated with the second SIP client 410.sub.B
(rather than the real SIP URL associated with the second SIP client
410.sub.B) in the NAPTR record. At step 464, first SIP Proxy
420.sub.A (e.g., operating as a proxy UAC for the first SIP client
510.sub.A) initiates connection of the call to second client device
410.sub.B using the virtual SIP URL by propagating a SIP call
request message (which includes the virtual SIP URL) from first SIP
Proxy 420.sub.A to second SIP Proxy 420.sub.B. At step 465, the
second SIP Proxy 520.sub.B queries the second Virtualization Server
450.sub.B associated with second SIP Proxy 420.sub.B using the
virtual SIP URL associated with second client device 510.sub.B to
obtain the real SIP URL associated with the second client device
410.sub.B. At step 466, the second Virtualization Server 450.sub.B
associated with the second SIP Proxy 420.sub.B returns a NAPTR
record (including the real SIP URL, e.g., sip:name@domain.com) to
second SIP Proxy 420.sub.B, where the second Virtualization Server
450.sub.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.sub.B in order to obtain the real SIP URL
associated with the second SIP client 410.sub.B. At step 467, the
second SIP Proxy 420.sub.B sends a call setup message to second SIP
client 410.sub.B using the real SIP URL. In this manner, the real
SIP URL of second SIP client 410.sub.B is hidden for the length of
the communication path between first SIP proxy 420.sub.A and second
SIP Proxy 420.sub.B.
[0059] FIG. 5 depicts an exemplary embodiment of ENUM
virtualization in which user ENUM virtualization is supported.
[0060] As depicted in FIG. 5, communication system 500 includes a
first SIP client 510.sub.A associated with a first SIP Proxy
520.sub.A and a second SIP client 510.sub.B associated with a
second SIP Proxy 520.sub.B. The communication system 500 also
includes: (1) an ENUM/DNS server 530 associated with first SIP
Proxy 520.sub.A, an ENUM database 540 associated with ENUM/DNS
server 530, and a first Virtualization Server 550.sub.A associated
with ENUM/DNS server 530 and (2) a second Virtualization Server
550.sub.B associated with second SIP Proxy 520.sub.B. The first SIP
Proxy 520.sub.A and second SIP Proxy 520.sub.B are configured to
communicate via a communication network (e.g., the Internet).
[0061] As further depicted in FIG. 5, communication system 500
includes various types of real and virtual information. The second
SIP client 510.sub.B has a telephone number (e.g., x-xxx-xxx-xxxx)
associated therewith. The second SIP client 510.sub.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.sub.B to the real SIP
name and real SIP domain of second SIP client 510.sub.B. The first
Virtualization Server 550.sub.A and second Virtualization Server
550.sub.B each have access to virtualization mapping information
for second SIP client 510.sub.B that includes a mapping of the real
SIP name and real SIP domain of second SIP client 510.sub.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.sub.B.
[0062] 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.sub.A) adapted to provide user
ENUM virtualization. At step 561, a caller associated with first
SIP client 510.sub.A dials the telephone number associated with the
second SIP client 510.sub.B. At step 562, first SIP client
510.sub.A (e.g., a UAC of first SIP client 510.sub.A) queries the
ENUM/DNS server 530 for the location of the second SIP client
510.sub.B based on the telephone number associated with the second
SIP client 510.sub.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.sub.A, where
the ENUM/DNS server 530 generates the NAPTR record by using the
telephone number associated with the second SIP client 510.sub.B to
retrieve the real SIP URL associated with the second SIP client
510.sub.B via an ENUM/DNS lookup at ENUM/DNS server 530, querying
the first Virtualization Server 550.sub.A using the real SIP URL
associated with the second SIP client 510.sub.B to obtain the
virtual SIP URL that is mapped to the real SIP URL for the second
SIP client 510.sub.B, and including the virtual SIP URL associated
with the second SIP client 510.sub.B (rather than the real SIP URL
associated with the second SIP client 510.sub.B) in the NAPTR
record. At step 564, the first SIP client 510.sub.A (e.g., a UAC of
the first SIP client 510.sub.A) initiates a call to second client
device 510.sub.B using the virtual SIP URL. The SIP call request
message is propagated from first SIP client 510.sub.A to first SIP
Proxy 520.sub.A and from SIP Proxy 520.sub.A to second SIP Proxy
520.sub.B. At step 565, the second SIP Proxy 520.sub.B queries the
second Virtualization Server 550.sub.B associated with second SIP
Proxy 520.sub.B using the virtual SIP URL associated with second
client device 510.sub.B to obtain the real SIP URL associated with
second client device 510.sub.B. At step 566, the second
Virtualization Server 550.sub.B associated with second SIP Proxy
520.sub.B returns a NAPTR record (including the real SIP URL, e.g.,
sip:name@domain.com) to second SIP Proxy 520.sub.B, where the
second Virtualization Server 550.sub.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.sub.B in
order to obtain the real SIP URL associated with the second SIP
client 510.sub.B. At step 567, the second SIP Proxy 520.sub.B sends
a call setup message to second SIP client 510.sub.B using the real
SIP URL. In this manner, the real SIP URL of second SIP client
510.sub.B is hidden for the length of the communication path
between first SIP client 510.sub.A and second SIP Proxy
520.sub.B.
[0063] FIG. 6 depicts an exemplary embodiment of ENUM
virtualization in which infrastructure ENUM virtualization is
supported.
[0064] As depicted in FIG. 6, communication system 600 includes a
first SIP client 610.sub.A (denoted as SIP client A) associated
with a first carrier network 620.sub.A (denoted as carrier A) and a
second SIP client 610.sub.B (denoted as SIP client B) associated
with a second carrier network 620.sub.B (denoted as Carrier B). The
communication system 600 also includes: (1) a first Virtualization
Server 650.sub.A associated with first carrier network 620.sub.A;
(2) a second Virtualization Server 650.sub.B associated with second
carrier network 620.sub.B, and (3) an ENUM/DNS server 630,
associated with first carrier network 620.sub.A and second carrier
network 620.sub.B, an Infrastructure ENUM (I-ENUM) database 640
associated with ENUM/DNS server 630.sub.I, and a third
Virtualization Server 650.sub.I associated with ENUM/DNS server
630.sub.I.
[0065] The first carrier network 620.sub.A includes a SIP PBX 621
(to which the first SIP client 610.sub.A is connected) configured
to communicate at least with ENUM/DNS server 630.sub.I. The second
carrier network 720.sub.B includes a SIP Proxy 622. The first
carrier network 620.sub.A and second carrier network 620.sub.B
include pluralities of interconnected communication elements 623
supporting communication between first SIP client 610.sub.A and
second SIP client 610.sub.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.sub.A and second SIP client 610.sub.B includes SIP PBX
621 and SIP Proxy 622.
[0066] The communication system 600 is configured to support I-ENUM
virtualization.
[0067] 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.
[0068] 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.
[0069] 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.
[0070] FIG. 7 depicts an exemplary embodiment of ENUM
virtualization in which private ENUM virtualization is
supported.
[0071] As depicted in FIG. 7, communication system 700 includes a
first SIP client 710.sub.A (denoted as SIP client A) associated
with a first carrier network 720.sub.A (denoted as carrier A) and a
second SIP client 710.sub.B (denoted as SIP client B) associated
with a second carrier network 720.sub.B (denoted as Carrier B). The
communication system 700 also includes: (1) a first ENUM/DNS server
730.sub.A associated with first carrier network 720.sub.A, a first
Private ENUM (P-ENUM) database 740.sub.A associated with first
ENUM/DNS server 730.sub.A, and a first Virtualization Server
750.sub.A associated with first ENUM/DNS server 730.sub.A; (2) a
second ENUM/DNS server 730.sub.B associated with second carrier
network 720.sub.B, a second Private ENUM (P-ENUM) database
740.sub.B associated with second ENUM/DNS server 730.sub.B, and a
second Virtualization Server 750.sub.B associated with second
ENUM/DNS server 730.sub.B; and (3) a third ENUM/DNS server 730,
associated with first carrier network 720.sub.A and second carrier
network 720.sub.B, an Infrastructure ENUM (I-ENUM) database 740,
associated with third ENUM/DNS server 730.sub.I, and a third
Virtualization Server 750.sub.I associated with third ENUM/DNS
server 730.sub.I.
[0072] The first carrier network 720.sub.A includes a SIP PBX 721
(to which the first SIP client 710.sub.A is connected) configured
to communicate at least with first ENUM/DNS server 730.sub.A and
third ENUM/DNS server 730.sub.I. The second carrier network
720.sub.B includes a SIP Proxy 722 configured to communicate at
least with second ENUM/DNS server 730.sub.B. The first carrier
network 720.sub.A and second carrier network 720.sub.B include
pluralities of interconnected communication elements 723 supporting
communication between first SIP client 710.sub.A and second SIP
client 710.sub.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.sub.A and
second SIP client 710.sub.B includes SIP PBX 721 and SIP Proxy
722.
[0073] 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.
[0074] FIG. 8 depicts an exemplary embodiment of ENUM
virtualization in which enterprise ENUM virtualization is
supported.
[0075] As depicted in FIG. 8, communication system 800 includes
three SIP clients 810 as follows: (1) a first SIP client 810.sub.A1
(denoted as SIP client A1) and a second SIP client 810.sub.A2
(denoted as SIP client A2) associated with a first carrier network
820.sub.A (denoted as carrier A) and (2) a third SIP client
810.sub.B (denoted as SIP client B) associated with a second
carrier network 820.sub.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.
[0076] The first carrier network 820.sub.A includes a SIP PBX 821
(to which the first SIP client 810.sub.A1 is connected) configured
to communicate at least with the ENUM/DNS server 830. The second
carrier network 820.sub.B includes a SIP Proxy 822 configured to
communicate at least with third SIP client 810.sub.B and ENUM/DNS
server 830. The first carrier network 820.sub.A and second carrier
network 820.sub.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).
[0077] The communication system 800 is configured to support
various forms of enterprise ENUM virtualization.
[0078] 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.
[0079] 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.
[0080] 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.
[0081] The communication system 800 may be configured to support
various other forms of enterprise ENUM virtualization.
[0082] FIG. 9 depicts an exemplary embodiment of ENUM
virtualization in which vCard ENUM virtualization is supported.
[0083] As depicted in FIG. 9, communication system 900 includes a
first SIP client 910.sub.A (denoted as SIP client A) associated
with a first carrier network 920.sub.A (denoted as carrier A) and a
second SIP client 910.sub.B (denoted as SIP client B) associated
with a second carrier network 920.sub.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.
[0084] The first carrier network 920.sub.A includes a SIP PBX 921
(to which the first SIP client 910.sub.A is connected). The second
carrier network 920.sub.B includes a SIP Proxy 922 configured to
communicate at least with second SIP client 910.sub.B, ENUM/DNS
server 930, and vCard server 960. The first carrier network
920.sub.A and second carrier network 920.sub.B include pluralities
of interconnected communication elements 923 supporting
communication between first SIP client 910.sub.A and second SIP
client 910.sub.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.sub.A and
second SIP client 910.sub.B includes SIP PBX 921 and SIP Proxy
922.
[0085] 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.
[0086] FIG. 10 depicts an exemplary embodiment of ENUM
virtualization in which Calling Name (CNAM) ENUM virtualization is
supported.
[0087] As depicted in FIG. 10, a communication system 1000 includes
a first SIP client 1010.sub.A (denoted as SIP client A) associated
with a first carrier network 1020.sub.A (denoted as carrier A) and
a second SIP client 1010.sub.B (denoted as SIP client B) associated
with a second carrier network 1020.sub.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.
[0088] The first carrier network 1020.sub.A includes a SIP PBX 1021
(to which the first SIP client 1010.sub.A is connected). The second
carrier network 1020.sub.B includes a SIP Proxy 1022 configured to
communicate at least with second SIP client 1010.sub.B and ENUM/DNS
server 1030. The first carrier network 1020.sub.A and second
carrier network 1020.sub.B include pluralities of interconnected
communication elements 1023 supporting communication between first
SIP client 1010.sub.A and second SIP client 1010.sub.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.sub.A and second SIP client
1010.sub.B includes SIP PBX 1021 and SIP Proxy 1022.
[0089] 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.sub.A in order to determine the Calling Name (CNAM) of
the user associated with first SIP client 1010.sub.A. The second
SIP client 1010.sub.B generates a query request. The second SIP
client 1010.sub.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.sub.A. The
Virtualization Server 1050 generates a query response including the
CNAM of the user associated with first SIP client 1010.sub.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.sub.B.
[0090] 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.
[0091] 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.
[0092] FIG. 11 depicts an exemplary embodiment of user
virtualization for an online transaction.
[0093] 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.
[0094] 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.
[0095] 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.
[0096] 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.
[0097] 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.
[0098] 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.
[0099] 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.
[0100] 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).
[0101] FIG. 12 depicts a high-level block diagram of a computer
suitable for use in performing functions described herein.
[0102] 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).
[0103] 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.
[0104] 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)).
[0105] 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.
[0106] 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.
[0107] 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.
[0108] 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").
[0109] 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.
* * * * *