Method and system for associating internet protocol (ip) address, media access control (mac) address and location for a user device

DESCRIPTION OF THE RELATED ART

Location-based services are becoming more and more prevalent. An example of a location-based service is the delivery of location-based context-aware content to a user of a mobile computing device, such as a smartphone, or other device, that is capable of accessing a website without using a third-party application. For example, a user of a mobile device enters a geographic area that is monitored by a network of wireless access points. Typically, the mobile device will connect to one of the wireless access points and gain access to the network. Such a network of wireless access points typically uses wireless fidelity (WiFi) as the underlying technology to allow the user to wirelessly connect to the network. An example of a WiFi network is one that is implemented according to one or more of IEEE 802.11b/g/n, or similar wireless access standards. The user of the mobile device uses a web browser on the mobile device to request a website associated with the entity that provides the network and the monitored area. The user then receives context-aware content based on, for example, the location of the user.

Generally, WiFi uses a Media Access Control (MAC) address that is assigned to each mobile device for identifying users and providing location-based services. However, an application layer entity will typically employ an Internet Protocol (IP) address as a way of identifying a mobile device. Unfortunately, a MAC address does not translate or correspond to an IP address at the application layer thus making it difficult to provide location-based services to the WiFi-connected mobile device at the application level. Therefore, to provide location-based services to a mobile device at the application layer, applications and services require a method of mapping an IP address to a MAC address.

SUMMARY

Various embodiments of methods and systems for associating an Internet Protocol (IP) address, a media access control (MAC) address and a location for a user device are disclosed. An exemplary embodiment of a method for associating an Internet Protocol (IP) address, a media access control (MAC) address and a location for a user device, comprises receiving IP to DHCP (dynamic host configuration protocol) bindings related to a user device from a domain name server (DNS), receiving a MAC address related to the user device from the DNS, associating the IP address and the MAC address for the user device, using the MAC address to obtain a geographic location of the user device, building a table having the IP:MAC address association, the location of the user device and a timestamp corresponding to the IP:MAC address association and the location of the user device, and using the IP:MAC address association and the location of the user device to deliver contextual content to the user device.

BRIEF DESCRIPTION OF THE DRAWINGS

In the figures, like reference numerals refer to like parts throughout the various views unless otherwise indicated. For reference numerals with letter character designations such as “<b>102</b><i>a</i>” or “<b>102</b><i>b</i>”, the letter character designations may differentiate two like parts or elements present in the same figure. Letter character designations for reference numerals may be omitted when it is intended that a reference numeral encompass all parts having the same reference numeral in all figures.

<figref idrefs="DRAWINGS">FIG. 1</figref> is a functional block diagram of an embodiment of a system and method for associating IP address, MAC address and location for a user device.

<figref idrefs="DRAWINGS">FIG. 2</figref> is a functional block diagram of the position mapper of <figref idrefs="DRAWINGS">FIG. 1</figref>.

<figref idrefs="DRAWINGS">FIG. 3</figref> is a call flow diagram illustrating an embodiment of a method for associating IP address, MAC address and location.

<figref idrefs="DRAWINGS">FIG. 4</figref> is a block diagram of the domain name server of <figref idrefs="DRAWINGS">FIG. 1</figref> and an example of an IP:DHCP binding table.

<figref idrefs="DRAWINGS">FIGS. 5A and 5B</figref> are a flow chart collectively illustrating an embodiment of a method for associating IP address, MAC address and location for a user device.

DETAILED DESCRIPTION

The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any aspect described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects.

In this description, the term “application” may also include files having executable content, such as: object code, scripts, byte code, markup language files, and patches. In addition, an “application” referred to herein, may also include files that are not executable in nature, such as documents that may need to be opened or other data files that need to be accessed.

As used in this description, the terms “component,” “database,” “module,” “system,” and the like are intended to refer to a computer-related entity, either hardware, firmware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a computing device and the computing device may be a component. One or more components may reside within a process and/or thread of execution, and a component may be localized on one computer and/or distributed between two or more computers. In addition, these components may execute from various computer readable media having various data structures stored thereon. The components may communicate by way of local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and/or across a network such as the Internet with other systems by way of the signal).

As used herein, the terms “user device” and “client device” include a device capable of receiving content from a web site and transmitting information to a website. A user device or client device can be a stationary device or a mobile device. The terms “user device” and “client device” can be used interchangeably.

As used herein, the term “user” refers to an individual receiving content on a user device or on a client device and transmitting information to a website.

As used herein, the term “MAC address” and the term “MAC ID” refer to the media access control (MAC) identifier assigned to a device and can be used interchangeably.

<figref idrefs="DRAWINGS">FIG. 1</figref> is a functional block diagram of an embodiment of a system for associating IP address, MAC address and location for a user device. The system <b>100</b> comprises a user device <b>102</b>, a network <b>106</b>, a router/switch <b>107</b>, a proxy server <b>108</b>, a web server <b>110</b> and a domain name server <b>115</b>. The user device <b>102</b> can be a stationary device or a mobile device, and is typically a mobile computing device including a browser <b>104</b>, such as a hypertext transfer protocol (HTTP) web browser <b>104</b> for accessing and viewing web content. In an embodiment, the user device <b>102</b> is a mobile device, such as a smart phone that can connect to the Internet. The web server <b>110</b> can be an HTTP server.

In an embodiment, the network <b>106</b> comprises a network of access points <b>105</b> (each labeled “AP”). In an example, the mobile device <b>102</b> is wirelessly connected to the access point <b>105</b><i>a </i>using a connection in accordance with IEEE 802.11b/g/n, or another wireless access standard. The location of the user device <b>102</b> can be determined in a number of ways including, but not limited to, knowing the location of the access point to which the user device <b>102</b> is connected, algorithms that use radio parameters such as receive signal strength indication (RSSI), round trip time (RTT), to determine the location, GPS mapping, a combination of these, or another location determination technology.

The router/switch <b>107</b> comprises various functionality including, but not limited to, a router, a switch, and other functionality. The router/switch <b>107</b> is connected to the domain name server <b>115</b> over connection <b>117</b>. The network <b>117</b> can be a LAN, a WAN, or another network. Moreover, although shown as separate elements, the router/switch <b>107</b> and the DNS <b>115</b> may reside inside of the network <b>106</b>. The network <b>106</b> also comprises a software module <b>122</b>. The software module <b>122</b> has logic for routing based on contextual parameters, and manages the flow of context aware metadata, in that it applies, appends, attaches, or otherwise associates metadata to an HTTP or HTTPS request received from the user device <b>102</b>. In an implementation example, the software module <b>122</b> can comprise and manage the functionality provided by a proxy server <b>108</b>, an Internet content adaptation protocol (ICAP) element <b>112</b>, a position mapper <b>114</b> and a location engine <b>116</b>, these elements being referred to as a “context server” <b>130</b>. In an example, the metadata appended by the software module <b>122</b> identifies the context of the user device <b>102</b> and provides context aware metadata to the proxy server <b>108</b>. The context aware metadata is appended to an HTTP or HTTPS request sent by the user device <b>102</b>, the metadata defining, corresponding to, or otherwise identifying the context of the user device <b>102</b>. The context of the user device <b>102</b> may be, for example, whether the user device is moving or stationary, the specific location of the user device, whether the user of the device is walking, shopping, driving, indoors, out of doors, etc. An example of providing location-based context aware content is a website tailoring content provided to a user based on whether, for example, the user is at one or another location determined by the location engine using the access points <b>105</b> or other IP based system in conjunction with the system and method for associating an IP address with a MAC address.

Depending on the implementation, the software module <b>122</b> manages one or more of the proxy server <b>108</b>, ICAP element <b>112</b>, position mapper <b>114</b>, and the location engine <b>116</b> to identify the context of the user device <b>102</b> and provide, append, or otherwise associate context aware metadata as part of an HTTP or HTTPS request. The communication between the ICAP element <b>112</b> and the proxy server <b>108</b> provides a standard way for implementing HTTP header modification functionality.

The location engine <b>116</b> provides the current location of the user device <b>102</b>. The location engine <b>116</b> can use one or more of triangulation, latency data, access point connection data, or other ways to detect the current location of the user device <b>102</b>. Typically, a mobile device <b>102</b> is identified to the network <b>106</b> by a MAC address and is assigned an IP address. The IP address can be a dynamically assigned IP address.

In an embodiment, the position mapper <b>114</b> receives IP to DHCP bindings and MAC addresses related to the user device <b>102</b> from the DNS <b>115</b> via the router/switch <b>107</b> and network <b>106</b> over logical connection <b>160</b>. Alternatively, the DNS <b>115</b> may be directly connected to the network <b>106</b>, or the functionality of the router/switch <b>107</b> can be part of the network <b>106</b>. The position mapper <b>114</b> receives location information related to the user device <b>102</b> from the location engine <b>116</b>. The position mapper <b>114</b> uses the IP and MAC address association corresponding to the user device <b>102</b> to build a table <b>120</b>, which includes IP to MAC address mapping (IP:MAC), a location fix for the user device <b>102</b>, and a timestamp identifying the time corresponding to the location fix. In this manner, the position mapper <b>114</b>, by using the DNS <b>115</b> to provide the IP:MAC address mapping in real-time, and the location engine <b>116</b> to provide device location based on MAC address, does not rely on any particular IP:MAC address mapping because it decouples the IP address of the user device <b>102</b> from the location determination technology. In an embodiment, the location of the user device <b>102</b> is determined using the MAC address of the user device <b>102</b>. The IP to MAC address association is created from the IP to DHCP bindings and MAC addresses received from the DNS <b>115</b> and is maintained by the position mapper <b>114</b> so that requests from various application layers can include location information in a response. In an embodiment where the system is centralized and each AP has its own DHCP table, the mapping will also include AP information as well as MAC address and IP information to identify a user device <b>102</b> and its location.

In particular, the position mapper <b>114</b> takes the IP address of the user device <b>102</b>, determines a MAC address for the user device <b>102</b> based on the IP address and the IP:MAC address mapping, and requests location information from the location engine <b>116</b> based on the MAC address of the user device <b>102</b>. The position mapper <b>114</b> then returns the location information to the ICAP element <b>112</b>, which requested contextual information for the user device <b>102</b> as part of the operation of the context awareness metadata software <b>122</b>. In this manner, location information related to the user device <b>102</b> is sent to the ICAP element <b>112</b> from the position mapper <b>114</b>, and the ICAP element <b>112</b> provides a modified HTTP header to the proxy server <b>108</b> with the location information of the user device <b>102</b>. The proxy server <b>108</b> receives the modified header and provides a modified HTTP request to the web server <b>110</b>, the modified request having the current location of the user device <b>102</b>, thus allowing the web server <b>110</b> to provide contextual content to the user device <b>102</b> based on the location of the user device <b>102</b>.

<figref idrefs="DRAWINGS">FIG. 2</figref> is a functional block diagram of a computing device <b>200</b> that can be used to implement the position mapper <b>114</b> of <figref idrefs="DRAWINGS">FIG. 1</figref>. In an embodiment, the computing device <b>200</b> can be implemented as a stand-alone computing device, such as a server device. In an embodiment, the computing device <b>200</b> can be part or all of the context server <b>130</b> (<figref idrefs="DRAWINGS">FIG. 1</figref>).

In an embodiment, the computing device <b>200</b> comprises a memory <b>202</b>, a processor <b>204</b>, a database <b>206</b> and an input/output (I/O) element <b>208</b>, operatively connected over a system bus <b>212</b>. The memory <b>202</b> can comprise any type of volatile or non-volatile memory, shared memory, distributed memory, and in an embodiment, can be non-volatile memory that stores a position mapper software module <b>114</b> and an application software module <b>210</b>.

The processor <b>204</b> can be a general purpose or special purpose microprocessor that executes the position mapper software module <b>114</b> and the application software module <b>210</b>. The system bus <b>212</b> can comprise the physical and logical connections to couple the above-described elements together and enable their interoperability.

In an embodiment, the position mapper software module <b>114</b> executes a number of functions, illustrated as processes or execution threads within the position mapper software module <b>114</b>.

The IP to MAC to Location thread <b>222</b> is the thread process that correlates the IP address, MAC address and location to develop the binding table <b>410</b> (<figref idrefs="DRAWINGS">FIG. 4</figref>) and the position mapper sample table <b>120</b> (<figref idrefs="DRAWINGS">FIG. 1</figref>), an instance of each of which is illustrated as being located in the database <b>206</b>.

The mobile view cache thread <b>224</b> is the thread process that stores location information with associated IP addresses and MAC addresses. Storing the location information with associated IP addresses and MAC addresses enables quicker look up of information without having to make a synchronous call to the location engine <b>116</b> to get the location information for each query. Multiple instances of the mobile view cache thread <b>224</b> may execute simultaneously.

The REST server thread <b>226</b> is a process thread that exposes a JavaScript Object Notation (JSON) interface for other third party applications, which allows those third party applications to request location information from the computing device <b>200</b> based on an IP address or other information in the mobile view cache thread <b>224</b>. The term “REST” denotes a “Representational State Transfer” software architecture used for distributed systems, such as the World Wide Web. In an embodiment, the REST server thread <b>226</b> can be implemented by a JSON server. Multiple instances of the REST server thread <b>226</b> may execute simultaneously.

The mobile view real time tracking “RTT” thread <b>228</b> is a process thread that manages the tracking sessions of each user device. Tracking sessions can be maintained for a defined period of time and for a particular MAC address. The two input parameters to the mobile view RTT thread <b>228</b> are how often to report the location requests and how long to track a user device. Multiple instances of the mobile view real time tracking “RTT” thread <b>228</b> may execute simultaneously.

The location engine interface <b>232</b> is a library interface to the location engine <b>116</b>.

The router <b>234</b> can be any router that provides access to the network <b>106</b> (<figref idrefs="DRAWINGS">FIG. 1</figref>) and in general, can be any router that provides Internet access.

The reference time thread <b>236</b> provides a timestamp corresponding to the time that a location fix is provided for a particular user device.

<figref idrefs="DRAWINGS">FIG. 3</figref> is a call flow diagram illustrating an embodiment of a method for associating IP address, MAC address and location. The diagram <b>300</b> illustrates the operation of various elements in <figref idrefs="DRAWINGS">FIG. 1</figref> for reference. As an example, call <b>302</b> represents a dynamic host configuration protocol (DHCP) request provided from the user device <b>102</b> to the network <b>106</b>. In <figref idrefs="DRAWINGS">FIG. 3</figref>, the functionality of the access points <b>105</b>, the network <b>106</b>, the router/switch <b>107</b> and the DNS <b>115</b> are combined for ease of explanation. In response to the call <b>302</b>, the access point <b>105</b><i>a, </i>the router/switch <b>107</b> and the network <b>106</b> provides a call <b>304</b>, assigning an Internet Protocol (IP) address to the user device <b>102</b>, thus allowing the user device <b>102</b> to access and communicate over the network <b>106</b>. The IP address is assigned by the APs <b>105</b> and/or the DNS <b>115</b> and/or the router/switch <b>107</b>. The DNS <b>115</b> builds an IP:DHCP binding table that associates the IP address assigned to the user device <b>102</b> with the MAC address of the user device <b>102</b>. An example of an IP:DHCP binding table is shown in <figref idrefs="DRAWINGS">FIG. 4</figref>. The IP:DHCP binding table <b>410</b> illustrates the association of an IP address with a MAC address for a particular user device.

The call <b>306</b> illustrates an HTTP request for a website (e.g., www.domain.com) made by the user device <b>102</b> and forwarded through the network <b>106</b> to the proxy server <b>108</b>. The call <b>320</b> represents IP and media access control (MAC) address mapping between the network <b>106</b> and the position mapper <b>114</b>, as described herein.

The call <b>308</b> represents the transfer of a request for a modified HTTP header sent from the proxy server <b>108</b> to the ICAP element <b>112</b>. The request for a modified HTTP header is sent from the proxy server <b>108</b> over connection <b>142</b>, and includes context aware metadata pertaining to the context of the user device <b>102</b>. In an embodiment, the context of the user device can be determined in a number of different ways. In the example shown in <figref idrefs="DRAWINGS">FIG. 1</figref>, the context of the user device <b>102</b> is determined by one or more of the network <b>106</b>, the proxy server <b>108</b>, and the web server <b>110</b>, without any contribution or interaction from the user device <b>102</b>. In other words, the user device <b>102</b> is a standard, unmodified device and any context awareness is determined by elements other than the user device <b>102</b>. In an embodiment, one or more of the network <b>106</b>, the proxy server <b>108</b>, and the server <b>110</b> determines the context of the user device <b>102</b> based on network parameters.

The call <b>312</b> issued between the ICAP element <b>112</b> and the position mapper <b>114</b> is made over connection <b>144</b> to determine the position of the user device <b>102</b> and to obtain modified header information.

The call <b>314</b> made between the position mapper <b>114</b> and location engine <b>116</b> over connection <b>146</b> refers to a first detection of the location of the user device <b>102</b>. The immediate polling requests improve the user experience by shortening the perceived time to first fix (TTFF). The calls <b>316</b> refer to a series of polling intervals and position location fixes that occur in real-time between the position mapper <b>114</b> and the DNS <b>115</b>, and between the position mapper <b>114</b> and the location engine <b>116</b> to determine the location of the user device <b>102</b> after the initial request by the call <b>314</b>. The polling intervals can be any duration and, in an example, can be one (1) second. As an example, the position mapper <b>114</b> polls the DNS <b>115</b> every one (1) second to determine IP:MAC address associations. The position mapper <b>114</b> polls the location engine <b>116</b> every five (5) seconds for all MAC IDs, location fixes, and timestamps for each location fix. The location engine <b>116</b> may have MAC ID, location fix and timestamp information from a previous tracking request. The position mapper <b>114</b> may obtain this information from the location engine <b>116</b> and map it to the recent IP:MAC address associations received from the DNS <b>115</b>. The position mapper <b>114</b> may obtain a single fix query for a particular MAC ID as well for a device that does not have a current location fix.

The call <b>318</b> from the position mapper <b>114</b> to the ICAP element <b>112</b> includes the location of the user device <b>102</b> as determined by the location engine <b>116</b>. In an embodiment, the call <b>318</b> can be a JavaScript object notation (JSON) response and is provided from the position mapper <b>114</b> to the ICAP element <b>112</b> and refers to the location and related context information of the user device <b>102</b>. In an embodiment, the location can be referred to as a “geofenced zone” location, which refers to a geographic area that is monitored for the presence of a user device <b>102</b> and a user. In an embodiment, such a geofenced zone can comprise an attraction at an amusement facility, a performance venue, or any other area that can be monitored using one or more technologies, such as GPS, radio frequency identification (RFID), video surveillance, etc. The position mapper <b>114</b> uses the IP:MAC address association, the location information, and timestamp information to build the table <b>120</b>.

The call <b>322</b> issued from the ICAP element <b>112</b> to the web server <b>110</b> attempts to determine whether the user is logged in, for example to further retrieve context information from the web server <b>110</b>.

The call <b>324</b> from the web server <b>110</b> to the ICAP element <b>112</b> contains information on whether the user device <b>102</b> is logged in to the web server <b>110</b>.

The call <b>326</b> issued from the ICAP element <b>112</b> to the proxy server <b>108</b> over connection <b>142</b> provides a modified HTTP header to the proxy server <b>108</b>. The modified HTTP header includes the context aware metadata and also includes the location of the user device <b>102</b>.

The call <b>320</b> represents IP and media access control (MAC) address mapping between the network <b>106</b> and the position mapper <b>114</b>. The position mapper <b>114</b> takes the IP address and the MAC address of the user device <b>102</b> from the binding table <b>410</b> (<figref idrefs="DRAWINGS">FIG. 4</figref>), and requests location information from the location engine <b>116</b> based on the MAC address of the user device <b>102</b>. The position mapper <b>114</b> then associates the location of the user device <b>102</b> to the IP address and the MAC address and builds the table <b>120</b> (<figref idrefs="DRAWINGS">FIG. 1</figref>). A timestamp is generated by the reference time thread <b>236</b> in the position mapper <b>114</b> and is associated with the IP:MAC address association and the location information. The timestamp provides the age of the location fix and is based on a configurable threshold to determine whether a new location fix should be requested. The timestamp can be provided by the local time kept by the computing device <b>200</b> in which the position mapper software <b>114</b> executes.

All devices in the system <b>100</b> need not to be synchronized to the same time source because the position mapper <b>114</b> maintains its own timestamp for a position fix regardless of the location engine <b>116</b>. The timestamp threshold is configurable, where if it determined that the location fix is older than a threshold amount (more than, for example, 1 minute old), a new timestamp is generated. The threshold is based on the intended application and to balance and control the number and frequency of requests to the location engine <b>116</b> (<figref idrefs="DRAWINGS">FIG. 1</figref>). For example, if a position location fix is older than 1 minute in the mobile view cache <b>224</b>, a new tracking request is initiated to the mobile view RTT thread <b>228</b> to obtain updated position information.

The position mapper <b>114</b> then returns location information to the ICAP element <b>112</b> in call <b>318</b>, which requested contextual information for the user device <b>102</b>. In this manner, location information related to the user device <b>102</b> is sent back to the ICAP element <b>112</b>, and the ICAP element <b>112</b> provides a modified HTTP header to the proxy server <b>108</b> (in call <b>326</b>) with the location information of the user device <b>102</b>. In this manner, location information and, to a broader extent, context information related to the user device <b>102</b> is added to the HTTP request either explicitly or implicitly.

The call <b>328</b> provided from the proxy server <b>108</b> to the web server <b>110</b> over connection <b>136</b> includes a modified HTTP request (e.g., using url modification as shown or using x tag insertion as examples) having context aware metadata and includes the location of the user device <b>102</b>.

The call <b>332</b> from the web server <b>110</b> to the proxy server <b>108</b> over connection <b>138</b> includes location-based contextual content that is tailored to the user based on the location and context of the user device <b>102</b>. The call <b>334</b> provided from the proxy server <b>108</b> to the mobile device <b>102</b> over connections <b>134</b> and <b>132</b> includes the context aware content delivered to the user device <b>102</b>. In this manner, the context of the user device <b>102</b> is determined and context specific content is provided from the web server <b>110</b> to the user device <b>102</b>.

<figref idrefs="DRAWINGS">FIGS. 5A and 5B</figref> are a flow chart <b>500</b> collectively illustrating an embodiment of a method for associating IP address, MAC address and location for a user device.

In block <b>502</b>, a user device <b>102</b> initiates a dynamic host configuration protocol (DHCP) request and sends the request to the DNS <b>115</b> either directly or via the router/switch <b>107</b>, and to the network <b>106</b>. The DNS <b>115</b>, router/switch <b>107</b> and the network <b>106</b> respond with an Internet Protocol (IP) address, thus allowing the user device <b>102</b> to access and communicate over the network <b>106</b>.

In block <b>504</b>, the position mapper <b>114</b> polls the DNS <b>115</b> for a DHCP table to obtain the IP to DHCP bindings for the user device <b>102</b>.

In block <b>506</b>, the position mapper <b>114</b> polls the DNS <b>115</b> for the MAC address of the user device <b>102</b>.

In block <b>508</b>, the position mapper <b>114</b> associates the IP address and the MAC addresses and builds the table <b>120</b> (<figref idrefs="DRAWINGS">FIG. 1</figref>).

In block <b>512</b>, the ICAP element <b>112</b> requests a header from the position mapper <b>114</b> for the contextual information of the user device <b>102</b> by IP address and to obtain information to modify the HTTP request.

In block <b>514</b>, the position mapper <b>114</b> sends a request for the location of the user device <b>102</b> to the location engine <b>116</b> using the MAC address of the user device <b>102</b>.

In block <b>516</b>, the location engine <b>116</b> provides the location of the user device <b>102</b>.

In block <b>518</b>, the position mapper <b>114</b> timestamps the location fix received from the location engine <b>116</b> and sends a response in the form of a JSON response to the ICAP element <b>112</b> with the location of the user device <b>102</b>.

In block <b>522</b>, the ICAP element <b>112</b> receives the location of the user device <b>102</b>.

In block <b>524</b>, the ICAP element <b>112</b> determines if the user device <b>102</b> is logged in to the web server <b>110</b>.

In block <b>526</b>, the ICAP element <b>112</b> receives information on whether the user device <b>102</b> is logged in to the web server <b>110</b>.

In block <b>528</b>, the ICAP element <b>112</b> provides a modified HTTP header to the proxy server <b>108</b>. The modified HTTP header includes the context aware metadata and also includes the location of the user device <b>102</b>.

In block <b>532</b>, the proxy server <b>108</b> delivers the modified HTTP request to the web server <b>110</b>. The modified HTTP request includes context aware metadata and the location of the user device <b>102</b>.

In block <b>534</b>, the web server <b>110</b> provides content to the proxy server <b>108</b>, the content including contextual content for the location and context of the user device <b>102</b>.

In block <b>536</b>, the proxy server <b>108</b> provides the context aware content to the user device <b>102</b>.

In view of the disclosure above, one of ordinary skill in programming is able to write computer code or identify appropriate hardware and/or circuits to implement the disclosed invention without difficulty based on the flow charts and associated description in this specification, for example. Therefore, disclosure of a particular set of program code instructions or detailed hardware devices is not considered necessary for an adequate understanding of how to make and use the invention. The inventive functionality of the claimed computer implemented processes is explained in more detail in the above description and in conjunction with the FIGS. which may illustrate various process flows.

In one or more exemplary aspects, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that may be accessed by a computer. By way of example, and not limitation, such computer-readable media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to carry or store desired program code in the form of instructions or data structures and that may be accessed by a computer.

Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (“DSL”), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium.

Disk and disc, as used herein, includes compact disc (“CD”), laser disc, optical disc, digital versatile disc (“DVD”), floppy disk and Blu-Ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

Although selected aspects have been illustrated and described in detail, it will be understood that various substitutions and alterations may be made therein without departing from the spirit and scope of the present invention, as defined by the following claims.