Network gateway for collecting geographic data information6523064Abstract In accordance with a first aspect of the present invention, a gateway device comprises a central processing unit, an external network interface, an internal network interface, and a positioning unit each coupled to the central processing unit. The gateway device further comprises a persistent memory, also coupled to the central processing unit, wherein the persistent memory is configured to store statistical data pertaining to content received through the external network interface as well as geographic location information. The gateway device is configured to collecting statistical geographic location information. According to an embodiment, a method for collecting the statistical geographic location information comprises: storing geographic location information in a persistent memory dedicated to a positioning unit, sampling incoming data passing between the external network interface and the internal network interface of the gateway device, recording the sampled incoming data in a persistent data table, receiving a request, the request comprising a demand for information contained in the persistent data table, and in response to the request, transmitting information contained in the persistent data table together with geographic location information. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
TABLE 1
CPU NR4650 133 MHz
(NKK Micro Devices)
DRAM 8 MB
ROM 128 kB
FLASH 4 MB
PCI Bridge & Peripheral Controller NR4650-PSC (NKK Micro Devices)
1394 LINK LSI MD8411 (Fuji Film Micro Device)
1394 PHY LSI MD8401 (Fuji Film Micro Device)
ATM LSI LASAR-155 (PMC-Sierra)
Internal Bus PCI
The CPU 704, ROM 712, FLASH 716, RS232 724 and DRAM 720 are communicatively coupled to each other via PCI bridge & peripheral controller 708 and local bus 706. The PCI bridge & peripheral controller 708 is also connected to the PCI bus 724. The PCI bus 724 is, in turn, connected to the ATM LSI 728, the 1394 LINK LSI 736 and register, LED and dip-switch unit 744. FIG. 8 depicts a firmware stack 800, employed by the home gateway 504. An operating system (OS) kernel 804 resides at the core of the firmware stack 800, and communicates with a service controller 808, system management 812, ATM driver 816 and 1394 driver 820. The ATM driver 816 communicates with the service controller 808, the 1394 driver 820 and various hardware components 824 (i.e., physical electronics components in the home entertainment system 500.). Similarly, the 1394 driver 820 communicates with the service controller 808, ATM driver 816 and hardware 824. System management 812 includes functions for initialization, self-diagnostics,.system health checking and debugging. Service controller 808 includes functions for MPEG TS and EPG filtering and multicasting, IP routing and terminal functions, MPEG over the 1394 bus and MPEG over ATM, as well as IP over 1394 bus and IP over ATM, address mapping, home network service command and control (e.g., MPEG service control, TV image control, remote handling, and camera control), and other functions (e.g., gaming, home automation, and directory services) The 1394 driver 820 realizes asynchronous data transmission, isochronous data transmission, physical layer control packet transmission, bus reset and control, root and cycle master processing, configuration status register and configuration ROM handling, bus management and address mapping table updates, whereas the ATM driver 816 realizes ATM pack transmission and ATM permanent virtual connection ("PVC") establishment and release. The OS kernel 804 provides for task switching, message queue and delivery, interrupt handling, timer management and memory management. Also, the OS kernel 804 provides the electronic device interoperability functions which are used to control home gateway 504. The hardware 824 represents the physical layer, or lowest layer, of the firmware stack 800. In a presently preferred embodiment, the home gateway 504 functions as a bridge/router between the external network 904 and the internal network 912 (described in detail with reference to FIGS. 9-12 below). The home gateway 504 therefore provides a middle-layer between the external network 904 and the internal network 912 that is used for protocol and data formatting transformation, as well as address mapping functionality (described below). In particular, the home gateway 504 is a preferred "managing node" for maintaining the address mapping table (described below with reference to FIG. 16), wherein the home gateway 504 stores node address information in a memory, periodically updates the node address information, polls IEEE 1394 nodes (as used herein, "IEEE 1394 nodes" refers to one or more nodes residing on the IEEE 1394 bus 568 and comporting with the node 104 described with reference to FIGS. 1-4 above) on the internal network 912 and gathers node attributes from the polled IEEE 1394 nodes for the address mapping table 1600. Further details of the address mapping 1600 and the address mapping service are described below with reference to FIG. 13. Protocol Stacks FIGS. 9 through 12 depict various aspects of the protocol stacks employed between the respective external networks, the home gateway and the internal network(s), which pertain to the home entertainment system network. FIGS. 9-11 pertain to the home gateway 504. FIG. 12 pertains to the protocol stack between home electronic devices located on the home entertainment system network. Commonly shown in FIGS. 9-12 is an external network 904, a bridge 908, and an internal network (i.e., IEEE 1394 bus) 912. The external network 904 can comprise. an MPEG network 916 (e.g., a digital video service provider), and an IP network 920 (e.g., the "Internet"). An access network 924 connects to both the MPEG network 916 and IP network 920. According to one embodiment, the access network 924 is an internet access provider ("IAP") such as, e.g., America Online or @ Home. The external network 904 is coupled to the internal network 912 through a bridge 908. The bridge 908 is preferably an home gateway 504. The home gateway 504 converts data and signals from the external network 924 from ATM packets to an IEEE 1394 format, which can be forwarded to the internal network 912. The internal network 912 comprises a television adapter 932 and a standard or high definition television 936 (or alternatively a single unit incorporating a 1394 node and a television) and a personal computer 946. The protocol stacks are depicted in FIGS. 9-12 under the portion of the overall system to which they correspond. FIG. 9 depicts the protocol stack 900 according to ATM data transmission from an MPEG network 916 to a TV adapter 932. MPEG data is formatted at the MPEG network 916 from MPEG TS ("transport stream") protocol or control command ("CTRL COM") 956 to ATM adaption layer 5 ("AAL5") 952. From AAL5, the data is converted to ATM data 948, and from ATM 948 it is converted to synchronous optical network "SONET" protocol 944. An ATM network is preferred at the lowest layer, given its high reliability, but in alternative embodiments, a different carrier can be employed (e.g., by replacing the ATM layers). From the access network 924, data is received at the home gateway 504. At the home gateway 504, the communications from the external network are converted (or "bridged") from an ATM protocol to an IEEE 1394 protocol. Additional protocol layer conversions are shown in FIG. 9, including IEC 61883 964, which formats MPEG data for IEEE 1394 communication and is further described in International Electrotechnical Commission Standard 61883 entitled "Digital Interface for Consumer Audio/Visual Equipment" and which is publicly available from the IEC. IEEE 1394 protocol 968, is described in the IEEE 1394-1995 standard. From the gateway 908, data is sent via IEEE 1394 protocol to the internal network 912, where it is subsequently converted back into an MPEG transport stream for presentation/playback on a video display unit. It is further possible with TV adapter 932 to convert the data to an analog signal cable of providing audio/visual data to a standard or high definition television set. Preferably, however, TV 936 is capable of supporting MPEG data. FIG. 10 depicts a protocol stack 1000 according to IP data transmission from IP network 920 to PC 946. The transmission control protocol ("TCP") or user datagram protocol ("UDP") 1008, which are described in publicly available documents Internet RFC 793 and Internet RFC 768 respectively, are layered over internet protocol ("IP") 1004, which is described in Internet RFC 791. This facilitates transmission of packet data from an internet (e.g., the Internet or World-Wide Web). At the home gateway 504 and PC 946, an IP over 1394 protocol 1012, described in Internet Engineering Task Force ("IETF") document "IPv4 over IEEE 1394", by Peter Johansson is employed. The IETF document "Ipv4 over IEEE 1394"is incorporated herein by reference in its entirety. The protocol stack 1000 is especially advantageous for finding or exploring content on the World-Wide Web and Internet. FIG. 11 illustrates a protocol stack 1100 for TCP/IP data transmission from the IP network 920 to the PC 946. In order to facilitate automatic setup and IP address assignments, the protocol stack 1100 supports a domain name system ("DNS"), as described in Internet RFCs 1034 and 1035, and dynamic host configuration protocol ("DHCP"). FIG. 12 illustrates a protocol stack 1200 for bitmap transfer between devices (e.g., from the home gateway 504 or PC 946 to the TV adapter 932) over the internal network 912. The protocol stack 1200 employs additional and previously non-described protocol "DD-Connect AsyBmp" 1204. The "bitmap transfer" protocol is described in further detail below. The "AP" protocol 1208 is simply the particular protocol used at the application layer (e.g., a display protocol or a mouse protocol). Address Mapping FIG. 13 depicts an exemplary address mapping table 1600. The address mapping table 1600 preferably comprises at least four columns and as many rows as there are devices on the home entertainment network 500. The address mapping table 1600 is preferably partitioned into three distinct sections. The first section 1620 comprises IEEE 1394 service data, the second section 1624 comprises MPEG service data, and a third section 1628 comprises IP service data. Each section has its own "mini-table" for information, although the address mapping table 1600 is physically a single table. In the IEEE 1394 section 1620, the first column is the node unique ID column 1604, the node unique ID is permanently encoded into the hardware or ROM of the node 104. The next group of columns are node attribute columns 1602. The node attribute columns include a common name column 1608, which identifies a particular node by a user selected/programmed name that is stored in the node, a node_ID column 1612, which contains a dynamically assigned 16_bit node_ID, a node type column 1616, and an IP address column 1618. In the MPEG service section 1624, the first column is the ATM VPI/VCI column 1632, the next column is the program information column 1636, the third column is the IEEE 1394 isochronous channel column 1640 and the last column is the node unique ID column 1604. In the IP service section 1628, the first column is the ATM VPI/VCI column 1632, the next column is the IP address column 1618, the third column is the node_ID column 1612, and the last column is the node unique ID column 1604. The address mapping table 1600 is created by the IEEE 1394 driver (e.g., IEEE 1394 driver 816 shown in FIG. 8) when a bus reset occurs. The IEEE 1394 driver receives a response from each node in the IEEE 1394 bus (e.g., IEEE 1394 bus 568 shown in FIG. 5) identifying the node's node unique ID and other information. Based on the information received from the node, the IEEE 1394 driver adds the node unique ID to the address mapping table 1600 and then queries the particular node for additional information (e.g., common name, node capabilities and IP address). The IEEE 1394 driver assigns a valve to node_ID column 1612 for the node. Command and Control Transfer FIGS. 14-17, depict aspects of command and control transfer according to a presently preferred embodiment of the present invention. Moreover, FIGS. 14 and 15 are flowcharts illustrating the steps for command and control transfer and packet data handling, respectively, whereas FIGS. 16A-C depict an embodiment of the display information that is created on a video display unit as a result of the steps depicted in FIGS. 14 and 15. FIG. 17 illustrates a node icon table. To begin the command and control transfer process, a trigger is received. For example, a trigger can include a "menu" button on a remote control that initiates the command and control transfer process, or a stored procedure in a device residing in the home entertainment network 500. As shown in FIG. 14, a packet engine output from process 1804 (described below with reference to FIG. 15) can initiate the acts for command and control transfer. Act 1704 includes reading the address mapping table 1600. Once the address mapping table 1600 is read, a node icon table is read in act 1708. The node icon table has no less than two columns and identifies an image for each device on the home entertainment network 500. The first column represents a node (for example, either a node unique ID or a node type), and the second column represents the node's icon. It is, however, possible to have additional columns in the table, such as a node type, and a node unique ID. Accordingly, if a particular node's icon is desired, the first the node icon table is scanned for the node's unique ID, if the node unique ID is not found, then the node icon table is scanned for the desired node type (e.g., the node can be compliant with a particular device standard). When a matching node unique ID or, alternatively, a matching node type is found, then the icon for the desired node is retrieved at act 1716. An embodiment of a node icon table is depicted in FIG. 17. The node icon table 2000 includes node unique ID column 1604, a node type column 1608, and a bitmap data column 2004. The bitmap data column holds approximately 4 kB of data for the node icon. In one embodiment, data for a single icon is contained in the node icon table 2000, however, in an alternative embodiment, data for two icons is contained in the node icon table 2000: one icon is an "inactive" icon, meaning the icon displayed when the node is not selected, and the second is an active node icon, meaning the icon displayed when the node is selected. In act 1720, a complete node navigation tree is generated. The node navigation tree is depicted in FIGS. 16A-B. In FIG. 16A, the node navigation tree 1900 comprises a control node represented by icon 1904. The control node is the node through which a user is communicating. Destination nodes are represented by icons 1908, 1912 and 1916. As depicted in FIG. 16A, control node's icon 1904 is in active mode, whereas the destination nodes' icons 1908, 1912 and 1916 are in inactive mode. When additional nodes are added to the home entertainment system 500, the number of destination node icons will increase. Similarly, when existing nodes are removed from the home entertainment system 500, the number of destination node icons will be reduced accordingly. The node navigation tree 1900 is transmitted to the video display unit at act 1724. According to one embodiment, the node navigation tree 1900 is output to a packet engine 1800, where it is processed as an input to process 1808 (described below with reference to FIG. 15). In act 1728 a navigation input is received. Again, the navigation input can be received from an input device within the internal network 912 (FIG. 9), or it can be received from the external network 904, such as through the packet engine process 1804. Based on the input received in act 1728, a particular destination node will be identified. The control node retrieves the icon information (e.g., the active mode graphic) from the node navigation table 1600, and, in act 1732, modifies a subset of the navigation tree 1900. In an alternative embodiment, standard active mode data, such as a highlighted border or ring, is added to the portion of the navigation tree 1900 representing the selected destination node, thus, retrieval of active mode icon data from the address mapping table 1600 is not required. Based upon the active mode data, a portion, or subset of the node navigation tree 1900 is modified. The portion of the node navigation tree 1900 modified can include modified data corresponding to the "newly" selected active node, or it can additionally include modified data corresponding to the node which has been switched from active mode to inactive mode. According to a presently preferred embodiment, both data concerning the new active node icon and the old active node icon are modified. FIG. 16B depicts the node navigation tree 1900 after the destination node corresponding to icon 1916 has been selected as the active node. The portion of the node navigation tree 1900 that has been modified is the subset of data corresponding to icons 1904 and 1916. In act 1736 the modified subset of the node navigation tree 1900 is transmitted to the video display unit. In an alternative embodiment, the modified subset of the node navigation tree 1900 is passed to the packet engine 1800 and routed to the external network 904 by process 1808. An optional intermediate act can occur between acts 1736 and 1740. The optional step is confirming from the user that the destination node that was navigated to in act 1728 is in fact the desired destination node. This act is simply receiving another input, such as an "ENTER" command after navigation to the desired destination icon. In act 1740 the node function table is read. FIG. 18 depicts a node function table 2100. The node function table 2100 preferably comprises two columns, a node type column 1616 and a function list column 2104. The function list column 2104 comprises a plurality of entries, each entry 2108 comprising a mapping of single character alphanumeric inputs, a corresponding function name and an op code. When the controller reads the node function table 2100, the node function table 2100 is scanned for the particular active destination node type and the corresponding entries 2108 containing the valid commands for the active destination node. The valid commands are retrieved in act 1740. In act 1744 a node function list, based on the data retrieved from act 1740 is generated. The node function list is then transmitted to the video display unit in act 1748. Again, transmission to the video display unit can also include sending the outgoing node function list to the packet engine for processing and routing by process 1808. FIG. 16C depicts a node function list 1928 as presented on the video display unit. The first column of the node function list 1928 represents an input value column 1920. The second column, text column 1924, represents text corresponding the adjacent input value, the text describing the function that will result if the adjacent input value in column 1920 is received by the controller. In act 1752 a node function input is received at the controller. The input can come over the IEEE 1394 bus 568, or it can come from an external network 904, in which case the node function input is directed to the controller by packet engine 1800. The node function input is compared against valid input values 1920 in act 1756, and if the node function input matches a valid input value 1920, then the controller continues to act 1764. If, however, the node function input does not match a valid input value 1920, then the controller continues to act 1760, where an error message (e.g., "invalid command, please re-enter") is transmitted to the video display unit (or packet engine 1800). From act 1760, processing continues to act 1752. Alternatively, processing can continue to step 1748, such that the video display unit can be refreshed. Finally, the input value 1920 received at the controller is mapped to a function in the node function list 1928. A command is formatted with an appropriate op code and is transmitted to the destination node in act 1764. After act 1764, the command and control transfer method is complete. Packet Engine FIG. 15 depicts packet engine 1800. According to one embodiment, packet engine 1800 is a software bridge/router that receives and formats data for and from the internal network 912 and the external network 904. However, packet engine 1800 can also be implemented in hardware alone, or a combination of hardware and software. The steps for passing a data packet from the external network 904 to the internal network 912 are depicted in process 1804, whereas the steps for passing data from the internal network 912 to the external network 904 are depicted in process 1808. In process 1804, a data packet is received from the external network 904 at act 1810. In act 1812 the data packet is parsed into an input request--for example a node function input--and output routing information--for example, information necessary to send a response back the data packet sender. In act 1816 the input request is formatted and sent to the controller. In process 1808 data output (e.g., the node navigation tree 1900) is received at the packet engine 1800 from the internal network 912 at act 1824. In act 1828 data received from the internal network is formatted into acceptable data packet for routing over the external network. The output routing information parsed at step 1812 of process 1804 is used to this end. According to one embodiment an acceptable data packet is an IP packet in another embodiment an ATM packet is acceptable. In the home entertainment system network 500 comprising the home gateway 504, it is possible to monitor and control nodes on the internal network 912 from the external network 904. In such an embodiment, the address mapping table 1600 facilitates communication between a device residing on the external network 904 and the node on the internal network 912. The home gateway 504 (described above) preferably maintains the address mapping table 1600 and acts as a "gatekeeper" for inbound and outbound data from/to the external network 904. Furthermore, the home gateway 504 functions as a repository for information pertaining to the home entertainment system network 500, storing in memory (e.g., flash memory 716 or DRAM memory 720) node attribute information such as node type, compatibility, and additional ATM, MPEG, IEEE 1394 and IP service information. Service controller 808 handles much of the functionality described below. In one embodiment, the home gateway 504 includes in the firmware stack 800 a SNMP (simple network management protocol) manager and agent. The SNMP agent responds to queries concerning the IEEE 1394 nodes in the home entertainment network system 500 and effectively provides the home gateway 504 the ability to respond to queries from other SNMP managers. The information queried by the SNMP managers is contained in a management information base ("MIB"), which is stored in the home gateway 504. One embodiment of a MIB is the address mapping table 1600, together with other tables such as the node functionality table 2100. In an alternative embodiment, another MIB, such as one defined by RFC 1213 is employed. SNMP is further described in Internet Architecture Board document RFC 1157, which are publicly available. Furthermore, the SNMP agent is capable of initiating tasks requested by particular IEEE 1394 nodes in the system 500. For example, the SNMP manager may receive a request for a bus reset. The request for the bus reset is passed to the SNMP agent, and the SNMP agent then causes the 1394 driver 820 to trigger the bus reset. Another example is receiving a command passed through a remote SNMP manager. The command, like the request described above, is passed to the SNMP agent and the SNMP agent processes the command and formats it for transmission to the subsequent layer--e.g., the 1394 driver 820, or the OS kernel 804. In another embodiment, the home gateway 504 incorporates web-server functionality. More specifically, the home gateway 504 serves requests from outside clients, for example a web browser, and returns information about IEEE 1394 nodes in the home entertainment network system 500. For example, in one embodiment requests for the node navigation tree 1900 and responses returning the node navigation tree 1900 are handled by the web-server. Thus, the web-server includes functionality, such as that of the packet engine 1800 described above with reference to FIG. 15. The web-server functionality is substantially similar to the SNMP functionality but with the web-server, the monitoring and control is preferably controlled through a remote client such as a web browser. Commands from the outside client can also include a bus reset, a trigger to cause a VCR to start recording, or a switch to lock a door or turn out a light. In either the web-server or SNMP manager embodiments, a central office or monitoring site, for example the VSP 648 or IAP/ISP 640 (described above with reference to FIG. 6), is capable of monitoring devices within the home entertainment network system 500. The remote monitoring and control acts are depicted in FIG. 19. The acts are performed by the home gateway 504, and can be performed more particularly by the SNMP manager and agent, or the web-server component of the home gateway 504. In act 2604, an output data packet is received at the home gateway 504. In act 2608, the output data packet is parsed. For example, a input data packet is separated from other header or meta data, which describes the remote client and information about the input data packet (e.g., security information, remote IP address, etc.) The input data packet is transmitted from the home gateway 504 to the target node in act 2612. In act 2616, a response to the input data packet transmitted in act 2612 is received at the home gateway 504. An output data packet is generated in act 2620, and in act 2624, the output data packet is returned to the remote client that requested the information. The address mapping table 1600 is highly useful in the remote monitoring and control aspects of the invention. For example, the address mapping table 1600 is used for act 2612 to assist in addressing the target IEEE 1394 node in the home entertainment network system 500 for which the request or command is directed. Similarly, the address mapping table 1600 can also be used to authenticate requests for data or commands from the remote client by including the IP address, or other address information (e.g., node unique ID) to verify authority of the remote client to request such data or commands. Furthermore, the IP service description in U.S. application Ser. No. 09/304,213, and incorporated by reference in its entirety above, is also useful in understanding the more general description of remote monitoring and control set forth above. Geographic Data Collection FIG. 20 depicts a block diagram of a hardware architecture of an IEEE 1394 home gateway node 2700 configured to collect geographic statistical data, together with a central server 2750 (e.g., a central office server or a head-end server). In a preferred embodiment, the home gateway 2700 is similar to home gateway 504, with only selected components of the home gateway 2700 shown for simplicity. The home gateway 2700 comprises a central processing unit 704, a persistent memory, such as non-volatile memory 2712, an external network interface 2704, such as ATM LSI 728 (not shown in FIG. 20--shown in FIG. 7), an internal network interface 2708, such as 1394 LINK LSI 736 (not shown in FIG. 20--shown in FIG. 7), and a positioning unit 2716. The non-volatile memory 2712 is communicatively coupled to the CPU 704 via a local bus 706, whereas the CPU 704, external network interface 2704 the internal network interface 2708 and the positioning unit 2716 are communicatively interconnected via PCI bus 724. Central server 2750 is preferably an enterprise quality server, such as a Sun.TM. Enterprise.TM. 250 system, available from Sun Microsystems in Mountain View, Calif. running a client-server software system, such as an Oracle 8.TM. database, available from Oracle Corporation in Redwood Shores, Calif. Central server 2750 is operated by a service provider, such as a cable or video service provider and is located at a remote location relative to the home gateway 2700. Central server 2750 is depicted in block diagram format as having a CPU 2754, a non-volatile memory 2758 (e.g., a persistent disk), and an external network interface 2762. The CPU 2754, the NV memory 2758 and the external network interface 2762 are communicatively coupled via a local bus 2756. The central server 2750 and the home gateway 2700 are communicatively coupled via a physical medium between the external network interfaces 2704 and 2762, such as fiber optic cable 2702. Other coupling mediums can include copper (twisted pair or coaxial) and wireless interfaces. The positioning unit 2716, shown in home gateway 2700, can have multiple embodiments. For example, in one preferred embodiment, the positioning unit 2716 comprises a global positioning module such as the ACE II GPS.TM. module that is available from Trimble Navigation in Sunnyvale, Calif. However, a particular, or highly accurate global positioning module is not necessarily required, as the geographic resolution of the unit is not critical. By way of further example, geographic location data is to be requested by the central server 2750--e.g., from a cable provider--thereby triggering the global positioning module to update location information for the home gateway 2700. The positioning unit 2716 then provides the updated location information to the central server 2750--for example, directly from the positioning unit 2716 or via the CPU 704. In an alternative, and more cost effective embodiment, a persistent memory, such as a non-volatile RAM, can be employed in the positioning unit 2716, together with a software based user prompt that is initialized during the home gateway 2700 power-up, or at a user's request. The user prompt directs a user to manually enter a geographic location identifier, such as a zip code, and the user response is recorded into the non-volatile RAM. When subsequent request for geographic location information for the home entertainment network system 500 are made, the home gateway 2700 can respond by returning the location identifier stored in the persistent memory. FIG. 21 is a flowchart depicting a method for collecting statistical geographic location information in a network environment, such as the home entertainment network system 500. The method is preferably performed via a sequence of instructions--e.g., a firmware routine--executing in the home gateway 2700. Referring to the first act depicted in FIG. 21, a test is performed by the home gateway 2700 at act 2804 to determine whether the location information stored in the positioning unit 2716 is current. Under normal circumstances, the test is performed on a regular, e.g., biweekly basis, so a counter/timer may be used to determine whether the geographic location information is current. Preferably the counter/timer is set to reflect an invalid time whenever a power off occurs, thereby forcing an update of the geographic location information. If the counter/timer is current, then the process continues to act 2816, otherwise, the process continues to act 2808. In act 2808, the processing unit 2716 retrieves geographic location information either automatically (e.g., through a global positioning module), or manually (e.g., through a user prompt and response). In act 2812, the geographic location information is stored in a persistent memory in the home gateway 2700--e.g., NV memory 2712, or in a dedicated persistent memory (not shown) which is part of the positioning unit 2716. In act 2816, incoming content information from the external network 904, which is passing through the external network interface 2704, is sampled. The sampled incoming data includes a channel identifier and can also include a broadcaster's time and date stamp. In act 2820, the sampled data is recorded in statistical data table 3000 (described in detail with reference to FIG. 23) residing in a persistent memory, e.g., NV memory 2712. In a preferred embodiment, each time a channel is changed on an IEEE 1394 node in the IEEE 1394 bus 568 for a period longer than a predetermined length of time, e.g., five minutes, the home gateway 2700 will create a corresponding record in the statistical data table 3000. In act 2824, a test is performed to determine whether a request has been received for statistical geographic data. Generally, the statistical data request will come from the central server 2750 at a broadcaster's facility over the external network 904. However, the statistical data request can come from within the home entertainment network system 500, such as, for example, by a parent wishing to review a child's viewing habits. If a statistical data request has not been received, then the present iteration of the process ends and the home gateway 2700 cycles back to act 2804. If, however, a statistical data request has been received by the home gateway 2700, then processing continues to act 2828, where the sampled data contained in the statistical data table 3000 is encrypted. According to an embodiment, a public key/private key encryption pair is used for the decryption/encryption mechanism, such as the Message Digest 5 "MD5" algorithm. The MD5 algorithm is described in the publicly available Internet RFC 1321, entitled, "The MD5 Message Digest Algorithm", R. Rivest, 1992, which is incorporated herein by reference in its entirety. After the information from the statistical data table is encrypted, it is transmitted, together with the location identifier (if needed), over the external network interface 2704 to the central server 2750 at act 2832. Notably, if only particular home gateways 2700 having a particular location identifier are polled at any given time, then it may not be necessary to include the location identifier. However, if periodic updates are pushed from the home gateway 2700 to the central server 2750, then the location identifier becomes necessary. Thereafter, the present iteration of the process terminates and a new cycle can begin again at act 2804. FIG. 23 is a flowchart depicting a method for collecting statistical geographic information from a network environment by the central server 2750. The method is preferably performed via sequences of instructions--e.g., an application--running on the central server 2750. Beginning at act 2904, the central server 2750 initializes communication with the home gateway 2700. According to one embodiment, the initialization sequence includes authenticating the identity of both the central server 2750 to the home gateway 2700, as well as the home gateway 2700 to the central server 2750. In another embodiment, the authentication process further includes registering additional IEEE 1394 nodes residing in the home entertainment network system 500. This can be performed by including selected data such as the node unique IDs from the address mapping table 1600 (described in detail with reference to FIGS. 13). In yet another embodiment, when the geographic location information/identifier is recorded in the home gateway 2700 at act 2808 (FIG. 21), the location identifier is stored in both the address mapping table 1600 and within a reserved persistent memory location of each IEEE 1394 node residing on the IEEE 1394 bus 568 (when write access is allowed). When a bus reset occurs, discrepancies between the location identifiers, e.g., between any IEEE 1394 node and the home gateway 2700, detected by the home gateway 2700 or the central server 2750 triggers the authentication/registration process with the central server 2750. Alternatively, the home gateway 2700 can periodically synchronize a portion of its address mapping table 1600 with the central server 2750. The node unique ID of the particular IEEE 1394 node (which has a differing location identifier) and the node unique ID of the home gateway 2700 are then reconciled by the central server 2750. If, for some reason, the discrepancy cannot be reconciled, then appropriate service personal can be notified of either a potential user error or a stolen device. After act 2904, the central server 2750 requests sampled statistical data, e.g., all or only a portion of the statistical data table 3000, from the home gateway 2700 in act 2908. After requesting the sampled statistical data, the central server 2750 will wait for a period of time for the sampled statistical data in act 2912. If no sampled statistical data is received, then processing continues to act 2904. However, if sampled statistical data is received, then processing continues to act 2916. In act 2916, the sampled statistical data received from the home gateway 2700 is decrypted. Again, according to one embodiment, the encryption/decryption algorithm is the MD5 function described herein with reference to Internet RFC 1321. In act 2920, the decrypted sampled statistical data is analyzed for viewing patterns and user preferences. Based upon the sampled statistical data, particular content, such as types of advertising or program listings, can be selectively broadcast to a user viewing content passing through the home gateway 2700. For example, if a user consistently watches a particular program or channel, then that program or channel may be thereafter marked as a "preferred" viewing channel in an electronic program guide. Similarly, demographics, e.g., age, sex or zip code of a particular user, or group of users who view a particular program, can also be recorded. Based upon the demographics of a particular program, advertising geared toward the particular user or group of users can be broadcast with the program, as well as enhanced viewing information, such as uniform resource locators, "URLs", related to the program and user preferences. FIG. 23 is a diagram of an exemplary statistical data table 3000. The statistical data table 3000 has five columns, although it could have more or less columns in alternate embodiments. The node unique ID column 3004 stores a unique identifier for each IEEE 1394 device receiving content through the home gateway 2700 at a given instant. The channel column 3008 stores an identifier for the particular channel that is being piped through the home gateway 2700. A timestamp/counter field 3012, e.g., a 16-bit time and date stamp, for uniquely identifying a particular date and time for each record, stores the time viewing began for a particular user and channel. Similarly, the timestamp/counter field 3016 is used to record the data and time when viewing ended for the particular user and channel. The timestamp/counter data for fields 3008 and 3012 is preferably generated and broadcast by the central server 2750 so as a standard frame of reference is used when analyzing the statistical data. Alternatively, the timestamp/counter can be generated by the home gateway 2700, however it should still be periodically synchronized with the central server 2750. User field 3020 records a user identifier for the particular statistic data record. For example, users knowing a password to disable parental control can be assigned a predetermined user identifier. Three rows 3024, 3028, and 3032 are shown in the statistical data table 3000. For example, when analyzed by the central server 2750, the information stored in rows 3024 and 3028 communicates that User A watched channel "2" on a Mitsubishi TV for six minutes on a particular date and at a particular time. Furthermore, the records indicated that User A thereafter switched to channel "4", wherein they continued to watch for nine additional minutes. Row 3032 indicates to the central server 2750 that while User A was viewing channel "4", User B tuned in channel "2" on a different IEEE 1394 node (here on an ACME PC) for twenty-six minutes. The information in the statistical data table 3000 can be augmented with the address mapping table 1600 (described herein) to add depth to the data samples. The methods and processes described herein are preferably performed by one or more processors executing one or more sequence of instructions stored on a computer-readable medium, such as a persistent disk, a CD-ROM, a floppy disk, a volatile memory (e.g., random access memory "RAM"), or a non-volatile memory (such as a flash memory or read-only memory "ROM"), rather than in a particular hardware arrangement. However, in the broader spirit of the inventions, various aspects of the methods and processes described herein can be implemented via hardware components such as TTL logic, or gate arrays. Furthermore, if a preference for a firmware level, e.g., a lower level programmic implementation of software component that is, generally, stored in ROM, or an application level, e.g., a higher level programmic implementation of a software component that runs over firmware, an operating system kernel, and/or server processes, software component is desired, then that preference is specified. If no preference is specified, then either level of implementation is acceptable. Accordingly, the written description and accompanying figures contained herein are to be regarded in an illustrative, rather than a restrictive sense.
|
Same subclass Same class Consider this |
||||||||||
