RU2763000C2 - Tag delay monitoring and controlling system for increasing web page performance - Google Patents

Abstract

FIELD: data transmission.

SUBSTANCE: blocking the loading of slow-running third-party code included in the requested web page is performed, a set of tag states is used to control the suspension of tags based on an asynchronous process that actively monitors tag performance, response time and delay.

EFFECT: increase in web page performance.

30 cl, 12 dwg

Description

Links to related claims

This application claims priority under Provisional US Patent Application Serial No. 13/554500 5, filed July 20, 2012, entitled "Tag Latency Monitoring and Management System for Improving Web Page Performance," the entire contents of which are incorporated to this document by reference.

The technical field to which the invention relates

The present invention relates generally to tag control, and in particular, but not exclusively, to the use of multiple tag states to control tag suspension using an asynchronous process for actively monitoring tag latency.

State of the art

Many websites today include third party services that are separate from the site itself. For example, a website may contain from a third party vendor: advertisements, chat support, monitoring services, or the like. Typically, a third party vendor can sell its services on a website in such a way that when a user visits a particular web page, the web page is loaded with the services of the third party. Occasionally, downloading a third-party service may involve executing code for a third-party service from a remote location. However, if a third-party service is slow or unresponsive, then the loading of the web page may be slowed down or the loading of the web page may stop altogether. Thus, in consideration of these and other considerations, the present invention has been accomplished.

Brief Description of Drawings

Non-limiting and non-exhaustive embodiments of the present invention are described with reference to the following diagrams. In the diagrams, like reference numbers refer to like portions in different figures, unless otherwise indicated.

For a better understanding of the present invention, reference will be made to the following detailed description, which should be read in conjunction with the accompanying diagrams, wherein:

FIG. 1 is a system diagram of an environment in which embodiments of the present invention may be implemented;

FIG. 2 shows an embodiment of a client device that may be included in a system such as that shown in FIG. one;

FIG. 3 shows an embodiment of a network device that may be included in a system such as that shown in FIG. one;

FIG. 4 is a logic flow diagram mainly showing one embodiment of an overview of a process for changing a tag state based on asynchronous monitoring of tag latency and enabling tag deployment based on a tag state;

FIG. 5 is a logic flow diagram mainly showing one embodiment of a process for changing a tag state based on a tag delay event and a current tag state;

FIG. 6 is a flowchart mainly showing one embodiment of a method for changing the state of a tag based on a no tag delay event and the current state of the tag;

FIG. 7 is a flowchart mainly showing one embodiment of a method for using a tag in one of a plurality of states and changing the state of the tag based on a delayed or non-delayed event;

FIG. 8 illustrates one embodiment of a use case illustrating a graphical representation of a plurality of tag states and events that can cause a state change;

FIG. 9A-9B are a flow diagram mainly showing an alternate process for using a tag in one of a plurality of states and changing the state of the tag based on the tag delay;

FIG. 10 is an alternate embodiment of a use case illustrating a graphical representation of a plurality of tag states and events that can cause a state change; and

FIG. 11 shows one embodiment of a use case illustrating a diagram of a system that can be used to control tag latency and control tag change and deployment.

Implementation of the invention

Throughout the specification and claims, the following terms assume their explicitly associated meanings herein, unless the context clearly indicates otherwise. As used herein, the phrase “according to one embodiment” does not necessarily refer to the same embodiment, although it may. In addition, as used herein, the phrase “in another embodiment” does not necessarily refer to another embodiment, although it may. Thus, as described below, various embodiments of the present invention can be easily combined without departing from the scope or spirit of the present invention.

In addition, as used herein, the term “or” includes the operator “or” and is equivalent to the term “and / or” unless the context clearly indicates otherwise. The term "based on" is not intended to be exclusive and is intended to be based on additional factors not described unless the context clearly indicates otherwise. In addition, throughout the description, the meanings of the indefinite articles and the definite article include plural references. The meaning "in" includes "in" and "on".

As used in this document, the term "tag" generally refers to code that can be entered into a web page, using third-party solutions, at any point during the display of the web page. In some embodiments, the third-party solution may reference vendor code that is separate from the host of the web page. In at least one embodiment, loading a tag onto a web page may also be referred to as deploying a tag. In some embodiments, web page displays may be provided when a guest visits a website or takes action on a page.

As used herein, the term "tag delay" generally refers to the period of time between when a tag is requested and when a response based on the tag request is received from the server. In at least one embodiment, the tag delay may be based on the time period between when the tag is requested and when the complete tag is deployed. In some embodiments, the tag delay may be based on the cumulative response time of each tag component, including any additional code or resources needed for the tag component. In other embodiments, the tag delay may be based on long component response times from among the plurality of tag components. In another embodiment, the tag delay may be based on an error message received in response to a tag request, such as, for example, a response from a server with error codes 400-500. In some embodiments, the tag delay may be the period of time between when the tag is requested and when an error message is received in response from the server.

As used herein, the term "latency event" refers to the result of monitoring tag latency where the tag latency is greater than the maximum delay time threshold. In contrast, as used herein, the term “no latency event” refers to the result of monitoring tag latency, where the tag latency is less than the maximum delay time threshold. In at least one embodiment, the maximum threshold delay time may be determined and / or changed by a user (eg, a website host for deploying a tag). In some embodiments, the maximum latency threshold may be based on a target web page load time, average tag load time, or the like.

Embodiments of the present invention are briefly described below to provide a basic understanding of some aspects of the invention. This summary is not intended to be an extensive overview. It is not intended to identify key or critical elements, or to define or otherwise narrow the scope. Its purpose is only to present some concepts in a simplified form as a prelude to the more detailed description that follows.

In short, various embodiments are directed to using multiple tag states to monitor tag suspension based on an asynchronous process to actively monitor tag performance and measure response times. In some embodiments, tag latency can be monitored and / or measured to determine the performance and / or response time of the tag. In at least one embodiment, a user can register with a service to select tags to deploy to a web page. In some embodiments, a user may refer to a website, website host, website administrator, website consultant, or the like, or an agent thereof. Tags can be in one of a variety of states, such as, for example, the NORMAL state, the MARKED state, the SUSPEND_A state, or the SUSPEND_B state. In at least one embodiment, tags in the NORMAL or TAGGED state may be enabled for deployment (i.e., they are available for deployment), and tags in the SUSPEND_A or SUSPEND_B state may be blocked from deployment (i.e., suspended from deployment).

Tag latency can be asynchronously controlled depending on web page requests. In some embodiments, the frequency of tag monitoring may be based on the status of the tag. The state of the tag can change based on the asynchronous monitoring of the tag delay.

Briefly, according to some embodiments, if a delay event occurs (i.e., the tag delay exceeds the maximum delay time threshold), then the state of the tag may change from NORMAL to LABELED, from MARKED to SUSPEND_A, or from SUSPEND_B to SUSPEND_A. In other embodiments, if a no-delay event occurs (i.e., the tag delay does not exceed the maximum delay time threshold), then the state of the tag may change from SUSPEND_W to MARKED or from MARKED to NORMAL. In at least one embodiment, sequential delay events or sequential non-latency events may be used to change the state of a tag. With many different states and tag state changes based on a delay / no-delay event (and / or sequential delay / no-delay events), the tag cannot be early blocked from deployment due to a sharp increase in tag delay, or prematurely enabled for deployment after blocking due to a sharp drop in tag latency.

Demonstration operating environment

FIG. 1 shows the components of one embodiment of an environment in which the present invention may be applied. Not all components may be required to practice the invention, and variations in arrangement and type of components may be made without departing from the spirit or scope of the invention. As shown, the system in FIG. 1 includes local area networks (LAN) / wide area computer networks (WAN) - (network) 110, wireless network 108, client devices 102-105, tag monitoring server device (TMSD) 112, tag management server device (TCSD) 114 and a tag deployment server device (TDSD) 116.

At least one embodiment of client devices 102-105 is described in more detail below with reference to FIG. 2. In one embodiment, at least some of the client devices 102-105 may operate over a wired and / or wireless network, such as network 110 and / or 108. Typically, client devices 102-105 may include virtually any computing a device capable of communicating over a network to transmit and receive information, perform various online actions, offline actions, or the like. In one embodiment, one or more client devices 102-105 can be configured to operate in a business or other organization to provide various services to a business or other organization. For example, client devices 102-105 can be configured to act as a web server, accounting server, production server, inventory server, or the like. However, client devices 102-105 are not limited to these services, and can also be used, for example, as an end-user computing node according to other embodiments. It should be recognized that more or less all client devices can be included in such a system as described herein, and the embodiments are therefore not limited to the number or type of client devices used.

Devices that can operate as client device 102 may include devices typically using wired or wireless communications for communication, such as personal computers, multiprocessor systems, microprocessor or programmable electronic devices, networked PCs, or the like. According to some In embodiments, client devices 102-105 may include virtually any portable computing device that is compatible in connection with and receiving information with another computing device, such as laptop 103, mobile smartphone 104, tablet computers 105, and the like. However, portable computing devices are not so limited and may also include other portable devices such as cell phones, display pagers, radio frequency (RF) devices, infrared (IR) devices, personal digital assistants (PDAs), handheld computers, laptop computers. , integrated devices combined from one or more prior devices, and the like. Thus, client devices 102-105 typically fluctuate widely in terms of capabilities and functionality. In addition, client devices 102-105 can access various computer applications, including a browser or other web application.

The web-based client device may include a browser application configured to receive and send web pages, web messages, and the like. The browser application can be configured to receive and display graphics, text, multimedia, and the like, using virtually any web programming language, including Wireless Data Protocol (WAP) messages, and the like. In one embodiment, the browser application enables the use of Handheld Markup Language (HDML), Wireless Markup Language (WML), WMLScript, JavaScript, Generalized Markup Language (SGML), Hypertext Markup Language (HTML), Extensible Markup Language (XML) etc. to display and send a message. In one embodiment, a user of a client device can use a browser application to perform various actions on a network (online). However, another application can also be used to perform various online activities.

Client devices 102-105 may also include at least one client application that is configured to receive and / or transmit content to another computing device. The client application may include the ability to send and / or receive content or the like.

The client application can also provide information that identifies itself, including type, capability, name, and the like. In one embodiment, client devices 102-105 can uniquely identify themselves through any of a variety of mechanisms, including Internet Protocol (IP), address, telephone number, mobile identification number (MIN), electronic serial number (ESN), or other device identifier. ... Such information may be provided in a network packet or the like, transferred between different client devices TMSD 112, TCSD 114, TDSD 116, or other computing devices.

Client devices 102-105 can further be configured to contain client applications that allow an end user to log into an end user account that can be controlled by another computing device such as TMSD 112, TCSD 114, TDSD 116, or the like. Such an end-user account, in one non-limiting example, may be configured to allow the end-user to control one or more online activities, including one non-limiting example, searching for activity, social media activity, browsing various sites, communicating with others. users or the like. However, engaging in such online activity can also be performed without logging into the end user account.

Wireless network 108 is configured for a pair of client devices 103-105 and their components with network 110. Wireless network 108 may comprise any of a variety of wireless subnets, which may additionally overlap autonomous ad hoc networks and the like to provide an infrastructure focused on connecting client devices. 103-105. Such subnets can include mesh networks, wireless local area networks (WLAN), cellular networks, and the like. In one embodiment, a system can comprise more than one wireless network.

Wireless network 108 may further include a stand-alone system of terminals, gateways, routers, and wireless radio related networks, and the like. These connectors can be configured to roam freely and randomly and organize themselves arbitrarily so that the topology of the wireless network 108 can change rapidly.

Wireless network 108 can further utilize a variety of access technologies, including second (2G), third (3G), fourth (4G), fifth (5G) generation cellular radio access, WLAN, wireless mesh router (WR), and the like. Access technologies such as 2G, 3G, 4G, 5G and future access networks may enable global coverage for mobile devices such as 103-105 client devices with varying degrees of mobility. In one non-limiting example, wireless network 108 may enable radio communications over a radio access network such as Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Enhanced Media for GSM (EDGE), Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Wideband Code Division Multiple Access (WCDMA), High Speed Channel Packet Access (HSDPA), Long Term Evolution (LTE) and the like. As such, wireless network 108 can include virtually any wireless communication mechanism by which information can move between client devices 103-105 and another computing device, network, or the like.

Network 110 is configured for a pair of network devices with other computing devices including TMSD 112, TCSD 114, TDSD 116, client device 102, and client devices 103-105 via wireless network 108. Network 110 allows any form of digital machine media to communicate from one electronic device to another. Also, network 110 may include the Internet in addition to local area networks (LANs), wide area computer networks (WANs), direct connections such as a universal serial bus (USB port), other forms of digital computing media, or any combination thereof. ... In an interconnected group of LANs, including those based on different architectures and protocols, the router acts as a link between LANs, allowing messages to be sent from one to the other. In addition, communication channels within a LAN typically include twisted pair or coaxial cable, while the communication line between networks can use analog telephone lines, fully or partially leased digital lines, including T1, T2, T3 and T4 and / or other communication service mechanisms, including, for example, a class E channel, an integrated digital network service (ISDN), digital subscriber line (DSL), wireless connections including satellite links or other communication links known to those of skill in the art ... In addition, the communications links may additionally use any of a variety of signaling technologies, including but not limited to, for example, DS-0, DS-1, DS-2, DS-3, DS-4, OC-3, OC-12, OC-48 or the like In addition, remote computers and other associated electronic devices can be remotely connected to either a LAN or WAN via a modem and a temporary telephone line. In one embodiment, network 110 can be configured to communicate using Internet Protocol (IP). As such, network 110 includes any communication method by which information can move between computing devices.

In addition, communications media typically contain computer readable instructions, data structures, program modules, or other transmission mechanisms, and include any information delivery vehicle. By way of example, communication media includes wired communications such as twisted pair, coaxial cable, fiber optics, waveguides, and other wired communications and wireless communications such as acoustic, RF, infrared, and other wireless communications.

One embodiment of the TMSD 112 is described in more detail below with reference to FIG. 3. In short, however, the TMSD 112 includes virtually any network device capable of monitoring tag latency. In at least one embodiment, the TMSD 112 can monitor tag latency asynchronously. Asynchronous monitoring can be performed independently of a request to load a web page (for example, from a website visitor). The TMSD 112 can emulate a browser, request a tag, and detect a tag delay. In at least one embodiment, the TMSD 112 can determine the tag latency by calculating the time it takes for the requested tag to load into an emulated browser. In some embodiments, the TMSD 112 can communicate with the TCSD 114 to determine which tags to monitor and / or provide a specific tag delay. Devices that can be configured to operate as a TMSD 112 include various network devices including, but not limited to, personal computers, desktop computers, multiprocessor systems, microprocessor or programmable consumer electronics, networked PCs, server devices, networked devices, and etc.

While FIG. 1 shows the TMSD 112 as a single computing device, the present invention is not so limited. For example, one or more of the functions of the TMSD 112 may be distributed over one or more different network devices. In addition, the TMSD 112 is not limited to a specific configuration. Thus, in one embodiment, the TMSD 112 may comprise a plurality of network devices for monitoring tag latency. In another embodiment, the TMSD 112 may comprise a plurality of network devices that operate in a master / slave approach in which one of the plurality of TMSD 112 network devices operates to control and / or otherwise coordinate operations with other network devices. In other embodiments, the TMSD 112 can operate as multiple network devices in a clustered, peer-to-peer, and / or even cloud architecture. Thus, the present invention should not be construed as being limited to a single environment, and other configurations and architectures are contemplated. In at least one embodiment, each of the plurality of TMSD 112 may be geographically dispersed. In another embodiment, the TMSD 112 may include various computing devices for monitoring tags in each of a variety of different tag states.

In at least one embodiment, the system can be expanded or narrowed by adding or removing network devices from the system, such as the TMSD 112. In some embodiments, adding additional TMSDs to the system can increase the bandwidth for tag monitoring. In at least one embodiment, each TMSD may be designed to allow the system to scale such that scaling can be implemented without adding additional scaling functions to each TMSD during scaling.

At least one embodiment of TCSD 114 is described in more detail below in conjunction with FIG. 3. Briefly, however, TCSD 114 can include virtually any network device capable of managing the state of each of a plurality of tags and allowing available tags to be expanded based on the state of the tag. In some embodiments, TCSD 114 can communicate with TMSD 112 to determine which tags to monitor and / or can receive tag delay information. In some embodiments, TCSD 114 may provide TDSD 116 with a list of tags available for deployment. In at least one embodiment, TCSD 114 may communicate with a database (not shown) that may contain tables for each state of a tag, which may include a list of each tag in each state. Devices that can operate as TCSD 114 include various network devices including, but not limited to, personal computers, desktop computers, multiprocessor systems or programmable consumer electronics, networked PCs, server devices, network devices, and the like.

While FIG. 1 shows the TCSD 114 as a single computing device, the present invention is not so limited. For example, one or more TCSD 114 functions can be distributed over one or more different network devices. In addition, TCSD 114 is not limited to a specific configuration. Thus, in one embodiment, the TCSD 114 may comprise a plurality of network devices to control tag monitoring and / or tag deployment. Likewise, in another embodiment, TCSD 114 may comprise a plurality of network devices that operate in a master / slave approach in which one of the plurality of TCSD network devices 114 operates to control and / or otherwise coordinate the operations of other network devices. In other embodiments, TCSD 114 can operate as a plurality of network devices in a cluster of architecture, peer-to-peer architecture, and / or even in a cloud architecture. Thus, the invention should not be construed as being limited to a single environment, and other configurations and architectures are contemplated.

At least one embodiment of the TDSD 116 is described in more detail below in conjunction with FIG. 3. Briefly, however, the TDSD 116 can include virtually any network device capable of deploying a tag. In some embodiments, the TDSD 116 can be optimized to provide tags for websites in response to a web request (eg, a request from a visitor to a website to view a web page). In at least one embodiment, the TDSD 116 can communicate with the TCSD 114 to obtain a list of tags available for deployment. In some embodiments, the TDSD 116 can collect web page data and can record expanded tag information. Devices that can operate as a TDSD 116 include various network devices including, but not limited to, personal computers, desktop computers, multiprocessor systems, or programmable consumer electronics, networked PCs, server devices, network devices, and the like.

While FIG. 1 shows the TDSD 116 as a single computing device, the invention is not so limited. For example, one or more TDSD 116 functions may be distributed across one or more different network devices. In addition, the TDSD 116 is not limited to a specific configuration. Thus, in one embodiment, the TDSD 116 may include multiple network devices for deploying tags to web pages. Similarly, in another embodiment, the TDSD 116 may comprise a plurality of network devices that operate in a master / slave approach in which one of the plurality of TDSD network devices 116 operates to control and / or otherwise coordinate operations with other network devices.

In other embodiments, TCSD 116 can operate as a plurality of network devices in a cluster of architecture, peer to peer architecture, and / or even in a cloud architecture. Thus, the invention should not be construed as being limited to a single environment and other configurations and architectures are also contemplated.

Illustrative client device

FIG. 2 illustrates one embodiment of a client device 200 that may be included in a system implementing embodiments of the present invention. Client device 200 may contain many more or fewer components than shown in FIG. 2. However, the components shown are sufficient to illustrate the practical implementation of an embodiment of the present invention. Client device 200 may be, for example, one of the embodiments of at least one of client devices 102-105 in FIG. one.

As shown in the diagram, client device 200 includes a processor 202 coupled to mass memory 226 via bus 234. In some embodiments, processor 202 may include one or more central processing units (CPUs). The client device 200 also includes a power supply 228, one or more network interfaces 236, an audio interface 238, a display 240, a keyboard 242, a backlight 244, a video interface 246, an I / O interface 248, a tactile interface 250, and a GPS receiver 232. (GPS).

Power supply 228 provides power to client device 200. A rechargeable or non-rechargeable battery may be used to provide power. Power can also be obtained from an external power source such as an AC adapter or a docking station that adds and / or charges the battery.

Client device 200 can additionally communicate with a base station (not shown) or directly with another computing device. Network interface 236 includes circuitry for connecting client device 200 to one or more networks and is configured for use with one or more communication protocols and technologies, including but not limited to GSM, CDMA, TDMA, GPRS, EDGE, WCDMA, HSDPA, LTE, protocol User Datagrams (UDP), Transmission Control Protocol / Internet Protocol (TSNPR), Short Message Service (SMS), WAP, Ultra Wideband (UWB), IEEE 802.16 Worldwide Wireless Broadband Access (WiMAX), Session Protocol / Transport Protocol mode real-time (SIP / RTP) or any of a variety of other wireless protocols. Network interface 236 is sometimes referred to as a transceiver, transceiver device, or network interface card (NIC).

Audio interface 238 is configured to produce and receive audio signals such as the sound of a human voice. For example, audio interface 238 may be coupled to a speaker and microphone (not shown) to allow telephone communication with another device and / or generate audio confirmation for an action.

Display 240 may be a liquid crystal display (LCD), plasma, light-emitting diode (LED), organic LED display, or any other type of display used with a computing device. Display 240 may also include a responsive touch screen capable of being input by an object such as a stylus or human finger.

Keypad 242 may encompass any input device configured to receive input from a user. For example, keypad 242 may include a keypad or numeric keypad.

Keypad 242 may also include command buttons that are associated with selecting and submitting images.

Backlight 244 can provide status indication and / or provide backlighting. Backlight 244 may remain active for certain periods of time or in response to events. For example, when backlight 244 is active, it can illuminate buttons on keyboard 242 and remain on while the client device is operating. In addition, backlight 244 can illuminate these buttons in a specific manner when specific actions are performed, such as dialing another client device. Backlight 244 can also cause light sources located within a transparent or semi-transparent body of the client device to backlight in response to actions.

Video interface 246 is configured to capture video images such as a photo, video segment, infrared video, or the like. For example, video interface 246 may be coupled to a digital video camera, webcam, or the like. Video interface 246 may include lenses, an image sensor, and other electronics. The image sensors can include a complementary metal oxide semiconductor (CMOS) integrated circuit, a charge-coupled device (CCD), or any other integrated circuit for sensing light.

Client device 200 also includes an I / O interface 248 for communicating with external devices such as a headset or other input or output devices not shown in FIG. 2. The I / O interface 248 may utilize one or more communication technologies such as USB, infrared, Bluetooth ™, or the like.

Tactile interface 250 is configured to provide tactile feedback to a user by a client device. For example, the haptic interface 250 can be used to vibrate the client device 200 in a specific manner when another user of the computing device calls. In some embodiments, the tactile interface 250 may be optional.

The client device 200 may also include a GPS transceiver 232 for determining the physical coordinates of the client device 200 on the surface of the earth. The GPS transceiver 232, according to some embodiments, may be optional. The GPS transceiver 232 typically provides a location in the form of latitude and longitude values. However, the GPS transceiver 232 may also use other geolocation mechanisms, including but not limited to triangulation, Assisted GPS (AGPS), Enhanced Time Differential Observation (E-OTD), Cellular Identifier (O), Service Area Identifier (SAI), Enhanced Synchronization signal path (ETA), base station system (BSS) or the like to further determine the physical location of the client device 200 on the surface of the Earth. It will be understood that under various conditions the GPS transceiver 232 can determine the physical location in millimeters from the client device 200; and in other cases, the determined physical location may be less accurate, such as within a meter or much greater distances. However, in one embodiment, the mobile device 200 can provide other information through other components that can be used to determine the physical location of the device, including, for example, media access control (MAC address), IP address, or the like.

Mass storage device 226 includes random access memory (RAM) 204, read-only memory (ROM) device 222, and other storage media. Mass storage device 226 illustrates an example of a computer-readable medium (device) for storing information such as computer-readable instructions, data structures, program modules, or other data. The mass storage device 226 stores a basic input / output system (BIOS) 224 for controlling low-level operations of the client device 200. The mass storage device also stores an operating system 206 for controlling the operation of the client device 200. It should be appreciated that this component may include an operating system. a general purpose system such as a UNIX or Linux ™ version or specialized communication client operating systems such as Microsoft Corporation's Windows Mobile ™, Apple Corporation's iOS ™, Google Corporation's Android ™, or the Symbian® operating system. The operating system may include an interface to a Java virtual machine module that allows hardware components and / or operating system actions to be controlled through Java applications.

The mass storage device 226 further includes one or more data stores 208 that can be used by the client device 200 to store applications 214 and / or other data in particular. For example, data store 208 can also be used to store information that describes the various capabilities of client device 200. This information can then be provided to other devices based on any of a variety of events, including may be sent as part of a header during communication. , sent on request, or the like. Data store 208 can also be used to store social networking information, including address books, buddy lists, pseudonyms, user profile information, or the like. In addition, the data store 208 may also store a message, web page content, or any of a variety of user-generated content. At least some of the information may also be stored on another component of the network device 200, including, but not limited to, processor-readable storage medium 230, disk, or other computer-readable storage devices (not shown) in the client device 200.

Processor-readable media 230 may include volatile, nonvolatile, removable, and non-removable media implemented in any method or technology for storing information such as machine or processor readable instructions, data structures, program modules, or other data. Examples of computer-readable storage media include RAM, ROM, electronic programmable memory (EEPROM), flash memory or other technology memory, readable compact disc (CD-ROM), digital versatile discs (DVD), or other optical storage. magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage, or any other physical medium that can be used to store desired information and which can be accessed by a computing device. Processor-readable medium 230 may also be referred to herein as computer-readable media and / or computer-readable memory.

Applications 214 may include computer executable instructions that client device 200 transmits, receives, and / or otherwise processes network data. The network data may include, but is not limited to, messages (eg, SMS, Multimedia Messaging Service (MMS), Instant Message (IM), Email, and / or other messages), audio, video, and the ability to telephonize with another user on another client device.

Applications 214 may include, for example, browser 218 and other applications 220. Other applications 220 may include but are not limited to calendars, search programs, email clients, IM applications, SMS applications, Voice over Internet Protocol (VoIP) applications, contact managers, task managers, transcoders, database programs, word processing programs, security applications, spreadsheets, games, search programs, etc.

Browser 218 can include virtually any application for receiving and displaying graphics, text, multimedia, messages, and the like, using virtually any web language. In one embodiment, the browser application is allowed to use HDML, WML, WMLScript, JavaScript, SGML, HTML, XML, and the like. to display and send a message. However, any of a variety of web programming languages can be used. In one embodiment, browser 218 may allow a user of client device 200 to communicate with another network device, such as TMSD 112, TCSD 114, and / or TDSD 116 shown in FIG. one.

An exemplary network device

FIG. 3 shows one embodiment of a network device 300 in accordance with one embodiment of the present invention. Network device 300 may include many more or fewer components than shown. The components shown, however, illustrate quite accurately an embodiment of the invention. Network device 300 can be configured to act as a server, client, node, host, or any other device.

Network device 300 may be, for example, TMSD 112, TCSD 114, TDSD 116 shown in FIG. 1, and / or other network devices.

Network device 300 includes a processor 302, a processor-readable medium 328, a network interface unit 330, an I / O interface 332, a hard disk 334, a video adapter 336, and memory 326, all connected to each other via a bus 338. In some embodiments, the processor 302 may include one or more central processing units.

As shown in FIG. 3, the network device 300 can also communicate over the Internet or some other communication network using a network interface unit 330 that is configured to work with various communication protocols, including the TCP / IP protocol. The network interface unit 330 is sometimes known as a transceiver, transceiver device, or network interface card (NIC).

Network device 300 also includes an I / O interface 332 for communicating with external devices such as a keyboard or other input or output devices not shown in FIG. 3. The I / O interface 332 may utilize one or more communication technologies such as USB, infrared, Bluetooth ™, or the like.

Memory 326 typically includes RAM 304, ROM 322, and one or more read-only storage devices such as hard disk 334, tape drive, optical drive, and / or floppy disk. Memory 326 stores an operating system 306 for controlling the operation of the network device 300. Any general-purpose operating system may be enabled. A basic input / output system (BIOS) 324 is provided to control low-level operations of the network device 300.

Although shown separately, memory 326 may include processor-readable media 328. Processor-readable medium 328 may be referred to as and / or include computer-readable media, computer-readable storage media, and / or processor-readable memories. Processor-readable media 328 may include volatile, nonvolatile, removable, and non-removable media implemented in any method or technology for storing information such as computer readable instructions, data structures, program modules, or other data. Examples of processor-readable media include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROMs, digital versatile disks (DVDs) or other optical storage media, magnetic cassettes, magnetic tapes, magnetic disk drives, or others. magnetic storage devices, or any other medium that can be used to store necessary information, and which can be accessed by a computing device.

Memory 326 further includes one or more data stores 308 that can be used by the network device 300 to store, in particular, application 314 and / or other data. For example, data store 308 can also be used to store information that describes the various capabilities of the network device 300. This information can then be provided to other devices based on any of a variety of events, including being sent as part of a header during communication. upon request or the like. Data store 308 can also be used to store messages, web page content, or the like. At least some of the information may also be stored on another component of the network device 300, including, but not limited to, processor-readable medium 328, hard disk 334, or other machine-readable storage (not shown) in client device 300.

The data store 308 may include a database, text, tables, folder, file, or the like, which can be configured to maintain and store user account IDs, user profiles, email addresses, IM addresses, and / or other network addresses or the like Data store 308 may further include program code, data, algorithms, and the like for use by a processor, such as processor 302, to execute and present actions. In at least one embodiment, data store 308 may include at least one state table to indicate which tags are in a particular state. In one embodiment, at least some of the data stores 308 may also be stored on another component of the network device 300 including, but not limited to, processor-readable storage medium 328, hard disk 334, or the like.

Applications 314 can include computer execution instructions that can be loaded into mass memory and run an operating system 306. Examples of application programs can include transcoders, schedulers, calendars, database programs, word processing programs, Hypertext Transfer Protocol (HTTP ), custom user interface programs, IPS applications, encryption programs, security programs, SMS message servers, IM message servers, mail servers, personal managers, etc. Applications 314 may also include a web server 318, a tag monitoring (TMA) application 319, a tag deployment (TDA) application 320, and a tag management (TCA) application 321.

Web server 318 may represent any of a variety of information and services that are configured to transmit content, including messages, over a network to another computing device. Thus, the web server 318 may include, for example, a web server, a file transfer protocol (FTP) server, a database server, a content server, or the like. The web server 318 can transmit content including messages over the network using any of a variety of formats including but not limited to WAP, WML HDML, SGML, HTML, XML, Compact HTML (cHTML), Extended HTML (xHTML), or etc.

The TMA 319 can be configured to asynchronously monitor the tag delay. In at least one embodiment, the TMA 319 can asynchronously monitor tag latency independently of a request to load a web page (eg, from a site visitor). The TMA 319 can emulate the browser to request a tag and determine the tag delay. In at least one embodiment, the TMA 319 can determine the tag latency by calculating the time it takes for the requested tag to load in an emulated browser. In some embodiments of the TMA 319, the TMSD 112 of FIG. 1. In any event, the TMA 319 may use processes or portions of processes similar to those described with reference to FIG. 4-7 and 9A-9B to perform at least some of its actions.

TDA 320 can be configured for tag deployment. In some embodiments, the TDA 320 can provide tags to a website upon request (eg, a request from a visitor to a website to view a web page). In at least one embodiment, the TDA 320 can collect web page data and can record expanded tag information. According to some embodiments of the TDA 320, the TDSD 116 of FIG. 1. In any event, the TDA 319 may use processes or portions of processes similar to those described with reference to FIG. 4-7 and 9A-9B to perform at least some of its actions.

TCA 321 can be configured to control the status of each of the multiple tags. In some embodiments, the TCA 321 can be configured to notify and / or provide the TCA 319 with every tag that may be ready to be monitored. In some embodiments, TCA 321 can record the last time the tag was checked (ie, when the tag delay was determined for the tag), which can be used to determine the next time the tag was checked. In at least one embodiment, the TCA 321 can record tag measurements (eg, tag latency) that are returned from the TMA 319. These measurements can be used by the TCA 321 to determine if a tag state needs to be changed, or can be used to generate reports.

In at least one embodiment, TCA 321 may change the state of a tag. In some embodiments, TCA 321 can modify the state table by adding or removing a tag from a given state. In some embodiments, TCA 321 may be configured to allow existing tags to be deployed, or to block tags from being deployed (eg, disable tags) based on the tagged state. In at least one embodiment, the TCA 321 can be configured to provide and / or notify the TCA 320 with tags available for deployment. According to some TCA 321 embodiments, TCSD 114 of FIG. 1. In any event, TCA 321 may employ processes or sub-processes similar to those described with reference to FIG. 4-7 and 9A-9B to perform at least some of its actions.

General operating instructions

The operation of some aspects of the present invention will now be described in conjunction with FIG. 4-7. FIG. 4 is a logical flow diagram typically showing one embodiment of an overview of a tag state change process based on asynchronous monitoring of tag latency and allowing tag deployment based on tag state. In some embodiments, the method 400 of FIG. 4 may be implemented and / or executed on a single network device, such as the network device 300 of FIG. 3. In other embodiments, the method 400, or portions of the method 400 of FIG. 4 may be implemented and / or executed on a variety of network devices, such as the network device 300 of FIG. 3. In at least one of various embodiments, method 400 may be performed on each of a plurality of tags.

Method 400 begins after a start block at block 402, where a tag may be determined to be monitored. In some embodiments, each of the plurality of tags can be monitored, each tag being associated with at least one web page. In other embodiments, a portion of the plurality of tags can be monitored and another portion of the plurality of tags cannot be monitored. In at least one embodiment, the monitored tags must be predefined, defined, changed by the user, or the like.

In some embodiments, a tag can be in one of a variety of different states. Each state can allow the tag to be expanded, or it can block the tag from being expanded. The state of a tag can change from one state to another based on monitoring, the time the tag has been in the state, and the like. or combinations thereof. In some embodiments, various triggers (i.e., the number of consecutive delay events) can be used to move the tag from one state to another state. Embodiments of processes for changing a tagged state are described in more detail below with reference to FIG. 7 and 9A-9B. In at least one embodiment, the tag may be in one of the following states: NORMAL, MARKED, SUSPEND_A, or SUSPEND_B. One form of graphical illustration of the various state data is described in more detail below with reference to FIG. eight.

However, the embodiments are not so limited and a different number of states, types of states, algorithms / metrics may be used to change the state. For example, in at least one embodiment, a tag may be in one of the following states: NORMAL, MARKED, PUSHED, PUSHED, and POST-PUSHED. One embodiment of a graphical representation of the present various states is described in more detail below with reference to FIG. 10. In another embodiment, historical measurement records (eg, tag delay) can be used to change the number of states and / or types of states used to change the state of a tag, parameters or the like. For example, historical records can indicate that tags may be stuck in a particular state for an extended period of time. According to one such example, an additional state can be added that can be used to monitor the tag more frequently. As another example, if historical records can indicate that a tag is currently producing planned results in a delayed state (eg, due to scheduled server maintenance), then the tag can be proactively moved to a different state for that period of time.

In any event, method 400 continues at block 404, where the delay tag may be monitored asynchronously. In some embodiments, monitoring may be asynchronous as long as it is independent of a request for a web page from a visitor to the web page. In at least one embodiment, monitoring can be based on at least the state of the tag to be monitored. In some embodiments, the tag state may determine the rate and / or frequency at which the tag is monitored. In some embodiments, the rate at which the tag is monitored may be configurable and / or variable for each state. In one embodiment, each state can correspond to a different frequency of asynchronous tag monitoring. For example, a tag in the NORMAL state can be monitored every 15 minutes, a tag in the MARK state can be monitored every five minutes, a tag in the SUSPEND_B state can be monitored every minute, while a tag in the SUSPEND_A state can be inactive and not monitored for for a given period of time. However, the embodiments are not so limited and other frequencies can be used to periodically monitor the tag delay.

In some other embodiments, a tag monitoring delay may be determined. In at least one embodiment, the delay may be determined by measuring the period of time from the request for the tag to the receipt of the server response. However, the embodiment described in more detail above is not so limited, and other methods for determining the tag delay can be used.

Method 400 proceeds to logic block 406 where it may be determined that the tag delay has resulted in a delay event. In at least one embodiment, the tag delay may be compared to a maximum delay time threshold. If the tag lag is greater than the maximum lag time threshold, then the tag monitoring result may indicate that a lag event has occurred. In at least one embodiment, the maximum threshold delay time may be tuned and / or changed for each user and / or each state. Accordingly, the maximum lag time threshold may be the same and / or different for each user and / or state. If the tag latency is less than the maximum latency threshold, then the tag monitoring result may indicate that a no latency event has occurred. If a delay event has occurred, then processing may flow to block 408; otherwise, a no-delay event may occur and processing may flow to block 410.

At block 408, the state of the tag may be changed based on the delay event, which will be described in more detail below with reference to FIG. 5. However, in a nutshell, if the definition of delay (eg, sequential delay events) and tag state indicate a state modification, then the tag state may be changed to a different state. In some embodiments, if the number of delay events exceeds a delay event threshold, the tag may change state based on the current state of the tag. For example, in some embodiments, a tag may change from a NORMAL state to a MARKED state if a threshold value for the number of delay events is exceeded. In other embodiments, a tag may change from a MARKED state to a SUSPEND_A state if a threshold for the number of delay events is exceeded. In still other embodiments, the tag may change from a SUSPEND_B state to a SUSPEND_A state if a threshold value for the number of delay events is exceeded. In some embodiments, the delay event threshold may be any suitable number of consecutive delay events, such as, for example, 1-3 consecutive delay events. In other embodiments, the delay event threshold may be any suitable number of delay events that occur within a predetermined time period (eg, 3 delay events in five minutes). However, the embodiments are not so limited, and the delay event threshold may be based on other metrics / algorithms to determine if the tag is moving out of a given state and into which state the tag has transitioned.

For example, a tag can change from one state to another based on: the severity of the delay condition (for example, the tag delay value is above a severity threshold), the number of consecutive delay events above the severity threshold, the number of delay events above the severity threshold for a given period of time , the duration of the tag's presence in this state, etc. or any combination of them. In some embodiments, the delay event threshold used for each state may be tuned and / or changed individually. In at least one embodiment, each of these delay event thresholds may be individually configured for each user. Processing then flows to logic block 412.

If, according to logic block 406, it is determined that a no delay event has occurred, then processing may flow from logic block 406 to block 410. According to block 410, the state of the tag may be changed based on the absence of a delay event, which is described in more detail below with reference to FIG. 6. However, in a nutshell, if the definition of the delay time (eg, consecutive no delay events) and the state of the tag indicates a modification in the state, then the state of the tag may be changed to a different state. In some embodiments, the tag may change state based on the current state of the tag and if the number of delay events exceeds a threshold of no delay events.

In some embodiments, a tag may change from a TAGGED state to a NORMAL state if a threshold for the number of no-delay events is exceeded. In other embodiments, the tag may change from a SUSPENDED state to a MARKED state if a threshold value for the number of no-delay events is exceeded. In some embodiments, the no-lag threshold may be any suitable number of consecutive non-lag events, such as, for example, 1-3 consecutive non-lag events. In other embodiments, the no-lag event threshold may be any suitable number of no-lag events that occur within a predetermined time period (eg, 3 no-lag events per minute). However, the present options are not so limited and the no-lag event threshold can be based on other metrics / algorithms to determine if the tag is moving out of the given state and into which state the tag has entered.

For example, a tag may change from one state to another based on: the moderation of one or more no-lag events (for example, a tag's latency value is below the temperance threshold), the number of consecutive no-lag events below the temperance threshold, the number of no-lag events below the temperance threshold moderation for a given period of time, the length of time the tag has been in this state, and so on. or any combination of them. In some embodiments, the no-lag event threshold used for each state may be individually tuned and / or changed. In at least one embodiment, each of these no-latency event thresholds may be individually configured for each user.

Method 400 proceeds to logic block 412 where a determination can be made as to whether the tag is blocked from deployment based on the current state of the tag. In some embodiments, a tag in a NORMAL state and / or in a TAGGED state may not be blocked and may be allowed to be deployed. In other embodiments, a tag in the SUSPEND_A state and / or the SUSPEND_B state may be disabled and not allowed to be deployed. If the tag is blocked from being deployed, then processing can loop to block 404 to continue to asynchronously monitor tag latency; otherwise, processing may flow to block 414.

At block 414, the tag may be allowed to be expanded. In some embodiments, allowing the tag to be expanded may include notifying the web page that the tag can be requested and loaded into the web page if a web page request is granted. In other embodiments, allowing a tag to be deployed may include notifying a tag deployer, such as the TDSD 116 shown in Figure 1, that a tag can be requested and loaded into a web page if a request for the web page is provided. In at least one embodiment, deployable tags may be included in tables or lists of deployable tags. According to some embodiments, if the determination of the current state of the tag indicates deployment affirmatively (as determined by block 412) and the web page is requested, the tag may be expanded with the associated web page.

After block 414, method 400 can loop to block 404 to continue to asynchronously monitor tag latency.

FIG. 5 is a flow chart showing generally one embodiment of a process for changing a tag state based on a tag delay event and a current tag state. In some embodiments, the method 500 of FIG. 5 may be implemented and / or executed on a single network device, such as the network device 300 of FIG. 3. In other embodiments, the method 500, or portions of the method 500 of FIG. 5 may be implemented and / or executed by a plurality of network devices, such as the network device 300 of FIG. 3.

Method 500 begins after the start block, according to logic block 502, where it can be determined whether the tag is in a normal state. In at least one embodiment, each state (i.e., NORMAL state, MARKED state, SUSPENDED_A and / or SUSPENDED_B state) may correspond to a table that identifies tags in that particular state. For example, a normal tag table might identify tags in a NORMAL state; the tagged tag table can identify tags in the tagged state; the SUSPEND_A tag table can identify tags in the SUSPEND_A state and the SUSPEND_B tag table can identify the tags in the SUSPEND_B state. In some embodiments, a tag may be determined to be in a NORMAL state if the tag is included in the normal tag table. If the tag is in the NORMAL state, then processing may flow to logic block 504; otherwise, processing may flow to logic block 510.

At block 504, it may be determined if the delay event exceeds a threshold. In some embodiments, the delay event threshold may be the total number of consecutive delay events. In one non-limiting, non-exhaustive example, the delay event threshold for the NORMAL state may be a single delay event. In at least one such embodiment, determining if a delay event threshold has been exceeded may include comparing a number of successive delay events to a delay event threshold. In other embodiments, the delay event threshold may be the total number of delay events that have occurred over a period of time. However, the present embodiments are not so limited and other thresholds for delay events may be used. If the delay event threshold is exceeded, then processing may flow to block 506; otherwise, processing may flow to block 508.

At block 506, the tag may be moved to the MARKED state. In at least one embodiment, moving a tag to the MARKED state may include removing the tag from the NORMAL tag table and adding the tag to the TAGED tag table. However, the present embodiments are not so limited, and other methods for identifying and changing the state of a tag can be used. In some embodiments, a tag in the MARKED state may not be blocked and may be allowed to be deployed. In at least one embodiment, an e-mail, text message, or other notification may be sent to a user to indicate that a tag has been placed in a MARKED state. In some other embodiments, if the tag returns an error (eg, 4xx | 5xx http responses) when the tag delay tag is monitored, then the tag may be placed in the STAGED state. After block 506, method 500 may return to the calling process to perform other actions.

If, according to logic block 504, it is determined that the delay event threshold has not been exceeded, then processing may flow from logic block 504 to block 508. According to block 508, the tag may remain in a NORMAL state. In at least one embodiment, a tag in the NORMAL state may not be locked and may be allowed to be deployed. After block 506, method 500 may return to the calling process to perform other actions.

If, according to logic block 502, it is determined that the tag is not in the NORMAL state, then processing may flow from logic block 502 to block 510. According to logic block 510, a determination can be made whether the tag is in the MARKED state. In some embodiments, a tag may be defined to be in the TAGGED state if the tag is included in the TAGGED tags table. If the tag is in the MARKED state, processing may flow to logic block 512; otherwise, processing may flow to logic block 516.

According to logic block 512, a determination can be made as to whether a threshold value for delay events has been exceeded. In at least one embodiment, logic block 512 may use embodiments of logic block 504 to determine if a delay event threshold is exceeded. In some embodiments, the delay event threshold for the MARKED state may be the same or different from the NORMAL delay event threshold. According to one non-limiting, non-exhaustive example, the threshold number of delay events for a state LABELED may be three consecutive delay events. However, the present embodiments are not so limited and other thresholds for delay events may be used. If the delay event threshold is exceeded, then processing may flow to block 524; otherwise, processing may flow to block 514.

At block 514, the tag may remain in the MARKED state. In at least one embodiment, a tag in the TAGGED state may not be blocked and may be allowed to be deployed. After block 514, method 500 may return to the calling process to perform other actions.

If, according to logic block 510, it is determined that the tag is not in the MARKED state, then processing may flow from logic block 510 to logic block 516. According to logic block 516, a determination can be made whether the tag is in the SUSPEND_W state. In some embodiments, a tag may be determined to be in the SUSPEND_W state if the tag is included in the SUSPEND_W tag table. If the tag is in the SUSPEND_W state, processing may flow to logic block 518; otherwise, the tag may be in a SUSPEND_A state and processing may flow to logic block 520.

At block 520, the tag may remain in the SUSPEND_A state. In at least one embodiment, a tag in the SUSPEND_A state may be disabled and not allowed to be deployed. In some embodiments, the tag may remain in the SUSPEND_A state for a predetermined period of time, regardless of delay and / or no delay events. After block 520, method 500 may return to the calling process to perform other actions.

If logic block 516 determines that the tag is in the SUSPEND_B state, then processing may flow from logic block 516 to logic block 518. Based on logic block 518, a determination can be made as to whether a delay event threshold has been exceeded. In at least one embodiment, logic block 518 may use embodiments of logic block 504 to determine if a delay event threshold has been exceeded. In some embodiments, the delay event threshold for the SUSPEND_B state may be the same or different with the delay event threshold for the NORMAL and / or TAGGED state. In one non-limiting, non-exhaustive example, the threshold number of delay events for the SUSPEND_B state may be three consecutive delay events. However, the present embodiments are not so limited and other thresholds for delay events may be used. If the delay event threshold is exceeded, then processing may flow to block 524; otherwise, processing may flow to block 522.

At block 524, the tag may be moved to a SUSPEND_A state. In at least one embodiment, placing a tag in the SUSPEND_A state may include adding the tag to the SUSPEND_A tag table and removing the tag from the TAGED tag table or the SUSPEND_B tag table. In some embodiments, a tag in the SUSPEND_A state may be disabled and not allowed to be deployed. After block 524, method 500 may return to the calling process to perform other actions.

If, according to logic block 518, it is determined that the delay event threshold is not exceeded, then processing may flow from logic block 518 to block 522. According to block 522, the tag may remain in the SUSPEND_B state. In some embodiments, a tag in the SUSPEND_B state may be blocked and not allowed to be deployed. After block 522, method 500 may return to the calling process to perform other actions.

FIG. 6 is a flow diagram showing generally one embodiment of a process for changing the state of a tag based on a no tag delay event and the current state of the tag. In some embodiments, the method 600 of FIG. 6 may be implemented and / or performed by a single network device, such as the network device 300 of FIG. 3. In other embodiments, the method 600, or portions of the method 600 of FIG. 6 may be implemented and / or performed by a plurality of network devices, such as the network device 300 of FIG. 3.

The method 600 begins after the start block according to logic block 602, where it can be determined if the tag is in a NORMAL state. In at least one embodiment, logic block 602 may use embodiments of logic block 502 in FIG. 5 to determine if the tag is in NORMAL state. If the tag is in the NORMAL state, then processing may flow to block 604; otherwise, processing may flow to logic block 606.

At block 604, the tag can remain in the NORMAL state and the tag is allowed to be deployed. In at least one embodiment, block 604 may use embodiments of block 508 in FIG. 5. After block 604, method 600 may return to the calling process to perform other actions.

If, according to logic block 602, it is determined that the tag is not in the NORMAL state, then processing may flow from logic block 602 to logic block 606. According to logic block 606, a determination can be made whether the tag is in the MARKED state. In at least one embodiment, logic block 606 may use embodiments of logic block 510 in FIG. 5 to determine if the tag is in the MARKED state. If the tag is in the MARKED state, then processing may flow to logic block 608; otherwise, processing may flow to logic 610.

According to logic block 608, a determination may be made as to whether a no-delay event threshold has been exceeded. In some embodiments, the no-lag event threshold may be the total number of consecutive no-lag events. In one non-limiting, non-exhaustive example, the no-delay event threshold for the LABEL state may be three consecutive no-delay events. According to at least one such embodiment, determining that a no-lag event threshold has been exceeded may include comparing a series of consecutive non-lag events with a no-lag event threshold. In other embodiments, the no-lag event threshold may be the total number of no-lag events occurring over a period of time. However, the present embodiments are not so limited and other thresholds for no-delay events may be used. If the no-delay event threshold is exceeded, then processing may flow to block 616; otherwise, processing may flow to block 614.

At block 616, the tag may be set to NORMAL. In at least one embodiment, making a tag NORMAL may include removing the tag from the TAGGED tag table and adding the tag to the NORMAL tag table. However, the options for implementation are not so limited, and can be used in other ways to identify and change the state of the tag. In some embodiments, a tag in the NORMAL state may not be locked and may be allowed to be deployed. In some other embodiments, the tag may return to NORMAL if the user resets the tag state, the HTML field of the tag is edited, tag monitoring is disabled, and / or the geographic scope of tag monitoring has changed (i.e., the user can select the geographic location of the servers to monitor tags). After block 616, method 600 may return to the calling process to perform other actions.

If, according to logic block 608, it is determined that the no-delay event threshold has not been exceeded, then processing may flow from logic block 608 to block 614. According to block 614, the tag may remain in the MARKED state. In at least one embodiment, block 614 may use embodiments of block 514 in FIG. 5. After block 614, method 600 may return to the calling process to perform other actions.

If, according to logic block 606, it is determined that the tag is not in the MARKED state, then processing may flow from logic block 606 to block 610. According to logic block 610, a determination can be made whether the tag is in the SUSPEND_W state. In at least one embodiment, logic block 610 may use embodiments of logic block 516 in FIG. 5 to determine if the tag is in the SUSPEND_W state. If the tag is in the SUSPEND_B state, then processing may flow to logic block 618; otherwise, processing may flow to logic 612.

At block 612, the tag may remain in the SUSPEND_A state. In at least one embodiment, block 612 may use embodiments of block 520 in FIG. 5. After block 612, method 600 may return to the calling process to perform other actions.

If, according to logic block 610, it is determined that the tag is not in the SUSPEND_B state, then processing may flow from logic block 610 to block 618. According to logic block 618, a determination may be made as to whether a no-delay event threshold has been exceeded. In at least one embodiment, logic block 618 may use embodiments of logic block 608 to determine if a no-delay event threshold has been exceeded. In some embodiments, the no-lag event threshold for the SUSPEND_A state may be the same or different from the no-lag event threshold for the MARKED state. In one non-limiting, non-exhaustive example, the threshold number of no-delay events for the SUSPEND_A state may be three consecutive no-delay events. However, the embodiments are not so limited and other thresholds for no-delay events may be used. If the no-delay event threshold is exceeded, then processing may flow to block 622; otherwise, processing may flow to block 620.

At block 622, the tag may be moved to the MARKED state. In at least one embodiment, block 622 may use embodiments of block 506 in FIG. 5. After block 622, method 600 may return to the calling process to perform other actions.

If, according to logic block 618, it is determined that the no-delay event threshold has not been exceeded, then processing may flow from logic block 618 to block 620. According to block 620, the tag may remain in the SUSPEND_B state. In at least one embodiment, block 620 may use embodiments of block 522 in FIG. 5. After block 620, method 600 may return to the calling process to perform other actions.

FIG. 7 is a flow diagram showing generally one embodiment of a process for using a tag in one of a plurality of states and changing the state of a tag based on delayed or non-delayed events. In some embodiments, the method 700 of FIG. 7 may be implemented and / or performed by a single network device, such as the network device 300 of FIG. 3. In other embodiments, the method 700, or a portion of the method 700 of FIG. 7 may be implemented and / or executed on a variety of network devices, such as the network device 300 of FIG. 3.

Method 700 begins after a start block, at block 702, where a tag in a NORMAL state may be used. In at least one embodiment, a tag in the NORMAL state may not be locked and may be allowed to be deployed. As described above (at block 404), tag latency can be asynchronously monitored. In at least one embodiment, the delay of the tag in the normal state can be monitored every 15 minutes. However, other frequencies can be used to monitor a tag in the MARKED state.

Method 700 continues at logic block 704 where it may be determined for a tag if a delay event has occurred. In at least one embodiment, logic block 704 may employ embodiments of logic block 406 in FIG. 4 to determine if a delay event has occurred based on asynchronous monitoring of the tag delay. If a delay event has occurred, then processing may flow to logic block 705; otherwise, processing may loop to block 702 where the tag may remain in its normal state.

According to logic block 705, it may be determined whether the delay event exceeds a threshold. In at least one embodiment, logic block 705 may employ embodiments of logic block 504 in FIG. 5 to determine if a tag delay event threshold is exceeded in the NORMAL state. If the delay event threshold is exceeded, then the tag may be placed in the MARKED state and processing may flow to block 706; otherwise, processing may loop to block 702 where the tag may remain in a NORMAL state. In some embodiments, method 700 may employ embodiments of block 506 in FIG. 5 to put the tag in the MARKED state.

At block 706, the tag may be used in the MARKED state. In at least one embodiment, a tag in the MARKED state may not be blocked and may be allowed to be deployed. In at least one embodiment, the tag delay in the MARKED state may be monitored every five minutes. However, other frequencies can be used to monitor a tag in the MARKED state.

In some embodiments, a user can manually transition a tag from a MARKED to NORMAL state using a "reset" tag. In at least one embodiment, the user can put the tag in the NORMAL state by pressing the "reset" button. However, the embodiments are not so limited and other embodiments can be used to reset the tag and / or manually return the tag to NORMAL. In at least one embodiment, manual tag translation may occur independently of the tag delay monitoring process. If the tag is in the MARKED state by manually “resetting” to NORMAL, then method 700 can loop (not shown) to block 702.

In at least one embodiment, a tag in any state (and / or specified state) may be "reset" to a NORMAL state.

In any event, method 700 continues at logic block 710, where it can be determined if a tag delay event has occurred. In at least one embodiment, logic block 710 may use embodiments of logic block 704 to determine if a delay event has occurred. If a delay event has occurred, then processing may flow to logic block 712; otherwise, processing may flow to logic block 708.

According to logic block 708, a determination may be made as to whether the no-delay event is exceeded by a threshold. In at least one embodiment, logic block 708 may use embodiments of logic block 608 in FIG. 6 to determine that the no-delay event threshold has been exceeded for a tag in the MARKED state. If the no-delay event threshold is exceeded, then the tag may be moved to NORMAL and processing may flow to block 702; otherwise, processing may loop to block 706 where the tag may remain in the MARKED state. In some embodiments, method 700 may use embodiments of block 616 in FIG. 6 to move the tag to NORMAL state.

If, according to logic block 710, a delay event has occurred, then processing may flow from logic block 710 to logic block 712. According to logic block 712, a delay event threshold may be determined. In at least one embodiment, logic block 712 may use embodiments of logic block 512 in FIG. 5 to determine if the tag delay event threshold has been exceeded in the MARKED state. If the threshold value of the delay event is exceeded, then the tag may be placed in the SUSPEND_A state and processing may flow to block 714; otherwise, processing may loop to block 706 where the tag may remain in the MARKED state. In some embodiments, method 700 may employ embodiments of block 524 in FIG. 5 to move the tag to the PAUSE_A state.

At block 714, the tag may be used in the PAUSE_A state. In some embodiments, a tag in the SUSPEND_A state may remain in the SUSPEND_A state for a predetermined period of time. In at least one embodiment, the tag delay cannot be monitored while the tag is in the SUSPEND_A state. In some embodiments, a tag in the SUSPEND_A state may be disabled and not allowed to be deployed.

In some embodiments, the user can manually move the tag from the SUSPEND_A state to NORMAL by "clearing" the tag. In at least one embodiment, block 714 may use embodiments of block 706 to "reset" the tag. If the tag is in the SUSPEND_A state and is manually "reset" to NORMAL, then method 700 may loop (not shown) to block 702.

Method 700 continues at logic block 716, where it may be determined if a period of time has elapsed for the tag to remain in the SUSPEND_A state. In at least one embodiment, the time period can be determined and / or changed by the user. In some embodiments, the time period may be 20 minutes. However, the options for implementation are not so limited, and can be used for other periods of time. If the time period has elapsed, then the tag may be placed in a SUSPENDED_B state and processing may flow to block 718; otherwise, processing may loop to block 714, where the tag may remain in the SUSPEND_A state.

At block 718, the tag may be used in the SUSPEND_W state. In at least one embodiment, a tag in the SUSPEND_B state may be disabled and not allowed to be deployed. In at least one embodiment, the tag delay in the SUSPEND_B state may be monitored every minute. However, other frequencies can be used to monitor the tag in the SUSPEND_W state.

In some embodiments, a user can manually transition a tag from SUSPEND_B to NORMAL by "resetting" the tag. In at least one embodiment, block 718 may use embodiments of block 706 to "clear" a tag. If the tag is in the SUSPEND_B state and is manually "reset" to NORMAL, then method 700 may loop (not shown) to block 702.

Method 700 then proceeds to logic block 720 where it may be determined for a tag whether a delay event has occurred. In at least one embodiment, logic block 720 may use embodiments of logic block 704 to determine if a delay event has occurred. If a delay event has occurred, then processing may flow to logic block 722; otherwise, processing may flow to logic block 724.

According to logic block 722, it may be determined if a delay event threshold is exceeded. In at least one embodiment, logic block 722 may use embodiments of logic block 518 in FIG. 5 to determine if the delay event threshold has been exceeded for a tag in the SUSPEND_W state. If the threshold value of the delay event is exceeded, then the tag may be moved to the SUSPEND_A state and processing may flow to block 714; otherwise, processing may loop to block 718 in which the tag may remain in the SUSPEND_B state. In some embodiments, method 700 may employ embodiments of block 524 in FIG. 5 to move the tag to the PAUSE_A state.

If, according to logic block 720, no delay event has occurred, then processing may flow from logic block 720 to logic block 724. According to logic block 724, it can be determined whether a threshold value for a no delay event has been exceeded. In at least one embodiment, logic block 724 may use embodiments of logic block 618 in FIG. 6 to determine that the no tag delay event has been exceeded in the SUSPEND_B state. If the delay event threshold is exceeded, then the tag may be moved to the MARKED state and processing may loop to block 706; otherwise, processing may loop to block 718 where the tag may remain in the SUSPEND_B state. In some embodiments, method 700 may employ embodiments of block 506 in FIG. 5 to move the tag to the MARKED state.

It should be understood that each block of the block diagram, and combinations of blocks in the block diagram, may be implemented by instructions of a computer program. These program instructions can be provided to the processor for execution by the machine, such that the instructions that execute on the processor provide the means to perform the actions indicated in the flowchart or blocks. Computer program instructions may be executed by the processor to invoke a series of operational steps performed by the processor to produce a computer-assisted process such that instructions that execute on the processor provide steps for performing the specified actions in a flowchart or blocks. Computer program instructions can also call at least some of the operational steps shown in the flowchart blocks to be executed in parallel. In addition, some of the steps may also be performed on more than one processor, such as may occur in a multiprocessor computer system. In addition, one or more blocks or block combinations in the block diagram may also be executed concurrently with other blocks or block combinations, or even in a different sequence than shown, without departing from the scope or spirit of the present invention.

Accordingly, the blocks of the flowchart support combinations of means for performing specified actions, combinations of steps for performing specified actions, and means of program commands for performing specified actions. In addition, it should be understood that each block of the block diagram and combinations of blocks of the block diagram may be implemented with special purpose hardware systems that perform specific actions or steps, or a combination of special purpose hardware and computer instructions. The above example is not to be construed as limiting and / or exhaustive, but rather as an indicative use of at least one of the various embodiments of the invention.

FIG. 8 illustrates one embodiment of a use case graphically illustrating a representation of a plurality of tag states and events that can cause a state change. As shown, tags can be in one of the system 800 states: NORMAL 802 state, STAGED 804 state, SUSPEND_A 806 state, or SUSPEND_B state 808. In some embodiments, a tag is in NORMAL 802 state, STAGED 806 state, STAFF_A 806 state, and / or state SUSPEND 808 may be used similar to block 702, block 706, block 714, and / or block 718 shown in FIG. 7, respectively.

A tag in the NORMAL 802 state may be allowed to run. In at least one embodiment, allowing the tag to fire may include determining whether the tag is available for deployment and allowing the tag to be deployed. In some embodiments, a tag in the NORMAL 802 state may be placed in a MARKED 804 state if one delay event is monitored for the tag. However, the options for implementation are not so limited; rather, metrics can be used to determine the movement of a tag from NORMAL 802, which is described in more detail below.

A tag in the STAGED 804 state may be allowed to run. In some embodiments, a tag in the LABELED state 804 may be moved to the SUSPEND_A 806 state if three consecutive delay events are observed for the tag. In other embodiments, a tag in the STAGED 804 state may be moved to the NORMAL 802 state if three consecutive no-delay events are observed for the tag. However, the options for implementation are not so limited; rather, metrics can be used to determine the transition of a tag from the LABELED 804 state, which are described in more detail below.

A tag in the SUSPEND_A state 806 may be blocked from starting. In at least one embodiment, blocking a tag from firing includes determining that the tag is not available for deployment and prevents the tag from being deployed. In some embodiments, a tag in the SUSPEND_A state 806 may be moved to the SUSPEND_B state after being in the SUSPEND_A state for 20 minutes. However, the options for implementation are not so limited; rather, metrics can be used to determine the movement of a tag out of the STOP_A 806 state, which is described in more detail below.

The status tag SUSPENDED_B 808 may be blocked from starting. In some embodiments, a tag in the SUSPEND_B 808 state may be moved to the SUSPEND_A 806 state if three consecutive delay events are observed for the tag. In other embodiments, a tag in the SUSPEND_B state 808 may be moved to the STAGED 804 state if three consecutive no-delay events are observed for the tag. However, the options for implementation are not so limited; but rather, other metrics can be used to determine the movement of a tag from the SUSPENDED state to 808.

It should be noted that Figure 8 shows one embodiment of a plurality of states and movement of a tag from one state to another. However, the options for implementation are not so limited. For example, in some embodiments, a different number of states may be used. In other embodiments, the tag may move from one state to another state that cannot be shown in FIG. 8, such as, for example, the tag may change from the NORMAL 802 state to the SUSPEND_A 806 state. In yet other embodiments, each state may use different parameters to determine whether the tag moves from a given state and to which state the tag moves. In some embodiments, these metrics can be predefined, customized, and / or modified for each user. Various embodiments of metrics that may be used may include, without limitation, the number of consecutive delay events, the number of delay events within a given time period, the severity of the delay event (e.g., the tag delay value is above a severity threshold), the number of consecutive delay events above severity threshold, the number of delay events above the severity threshold within a given time period, the number of consecutive no-delay events, the number of no-delay events in a given time period, the moderation of one or more delay events (for example, the tag latency value is below the moderation threshold), the number of consecutive no-lag events below the temperance threshold, the number of no-latency events below the temperance threshold for a given period of time, the length of time the tag has been in its present state, or the like ., or any combination of them.

Alternative embodiment of the invention

FIG. 9A-9B are logic flow diagrams generally showing an alternate embodiment of a process for using a tag in one of a plurality of states and changing the state of the tag based on tag delay. In some embodiments, the method 900 of FIG. 9A-9B may be implemented and / or executed on a single network device, such as the network device 300 of FIG. 3. In other embodiments, method 900, or a portion of method 900 shown in FIG. 9A-9B may be implemented and / or executed on a variety of network devices, such as the network device 300 of FIG. 3.

Method 900 begins after the start block at block 902, where the tag may be used in a NORMAL state. In at least one embodiment, block 902 may use embodiments of block 702 shown in FIG. 7 to use the tag in a NORMAL state. In some embodiments, a tag in the NORMAL state may have a monitoring rate of 15 minutes.

Method 900 proceeds to logic block 904 where a determination can be made as to whether a monitored tag delay tag has exceeded a wait threshold. In at least one embodiment, the latency threshold may be a specified delay (i.e., a predetermined amount of time). In at least one embodiment, the sleep threshold may be determined and / or modified by a user. If the tag latency exceeds the wait threshold, then the tag may be moved to a PRE-POSTED state and processing may flow to block 912; otherwise, processing may flow to logic block 906.

According to logic block 906, it may be determined if the tag delay exceeds a warning threshold. In at least one embodiment, the alert threshold may be a predetermined tag delay time. In at least one embodiment, the warning threshold can be determined and / or changed by a user. In some embodiments, the alert threshold may be greater than the user's desired tag delay, but less than the latency threshold. If the tag latency exceeds the warning threshold (but does not exceed the wait threshold), then the tag may be moved in the MARKED state and processing may flow to block 908; otherwise, processing may loop to block 902 where the tag may remain in a NORMAL state.

At block 908, the tag may be used in the MARKED state. In at least one embodiment, block 908 may use embodiments of block 706 shown in FIG. 7 to use the tag in the MARKED state. In some embodiments, a tag in the MARKED state may have a monitoring rate of five minutes. In at least one embodiment, a tag in the TAGGED state may remain in the TAGGED state as long as the tag delay does not exceed the wait threshold (same as logic block 910) or does not exceed the alert threshold (as well as logic block 914) ... In some embodiments, an e-mail, text message, or other notification may be sent to the user indicating that the tag is in the STAGED state.

Method 900 continues at logic 910, where it may be determined if the tag delay is greater than a tag wait threshold. In at least one embodiment, logic block 910 may use embodiments of logic block 904 to determine if a sleep threshold has been exceeded. If the tag latency exceeds the wait threshold, then the tag may be moved to a PRE-POSTED state and processing may flow to block 912; otherwise, processing may flow to logic block 914.

According to logic block 914, it may be determined if the tag delay exceeds a warning threshold. In at least one embodiment, logic block 910 may use embodiments of logic block 904 to determine if a warning threshold has been exceeded. If the tag delay exceeds the warning threshold (but does not exceed the wait threshold), then the tag may remain in the MARKED state and processing may loop to block 908; otherwise, the tag may be moved to NORMAL and processing may loop to block 902.

If, according to logic block 910, the tag latency exceeds the wait threshold, then processing may flow from logic block 910 to block 912. According to block 912, the tag may be used in the PRE-POSTED state. In at least one embodiment, the tag may not be blocked and may be allowed to be deployed. In some embodiments, a tag in the PUSHED state may have a monitoring rate of one minute. In at least one embodiment, tags in the PRE-PUSHED state may remain in the PRE-PUSHED state for five minutes.

Method 900 proceeds to logic block 916 where it may be determined if the tag delay is greater than a wait threshold. In at least one embodiment, logic block 916 may use embodiments of logic block 904 to determine if a sleep threshold has been exceeded. If the tag delay exceeds the wait threshold, then processing may flow to logic block 918; otherwise, the tag may be moved to the MARKED state and processing may loop to block 908.

According to logic block 918, it may be determined if a sequential number of sleep thresholds have been exceeded. In at least one embodiment, the sequential suspend threshold may be two consecutive monitored delay tags that exceed the latency threshold. If the sequential wait threshold is exceeded, then the tag may be moved in a SUSPENDED state and processing may flow to block 920 in FIG. 9B; otherwise, processing may loop to block 912, where the tag may remain in a SUSPENDED state.

Method 900 continues at block 920 of FIG. 9B, where the tag can be used in the SUSPENDED state. In at least one embodiment, the tag may be blocked and not allowed to be deployed. In some embodiments, a tag in a SUSPENDED state cannot be monitored. In at least one embodiment, a tag in the SUSPENDED state may remain in the SUSPENDED state for 30 minutes. In some embodiments, an e-mail, text message, or other notification may be sent to users indicating that the tag is in the STAGED state.

Method 900 proceeds to logic block 922 where a determination may be made as to whether a SUSPENDED state limit has been exceeded. In at least one embodiment, the SUSPENDED state limit may be 30 minutes. If the PUSHED state limit is exceeded, then the tag may be moved to the POST-PUSHED state and processing may flow to block 924; otherwise, processing may loop to block 920, in which the tag may remain in a SUSPENDED state.

At block 924, the tag may be used in the POST-POSTED state. In at least one embodiment, the tag may be blocked and not allowed to be deployed. In some embodiments, a tag in the POST-STOP state may have a monitoring rate of five minutes. In at least one embodiment, tags in the POST-POST state may remain in the POST-POST state for five minutes.

Method 900 continues at logic block 926, where it may be determined if the tag delay exceeds a wait threshold. In at least one embodiment, logic block 926 may use embodiments of logic block 904 to determine if a sleep threshold has been exceeded. If the tag delay threshold is exceeded, then processing may flow to logic block 928; otherwise, processing may flow to logic block 930.

According to logic block 928, it may be determined if a sequential number of sleep thresholds have been exceeded. In at least one embodiment, logic block 928 may use embodiments of logic block 918 in FIG. 9A to determine if the consecutive waits threshold has been exceeded. In at least one embodiment, the sleep threshold may be two consecutive monitored tag delays that exceed the sleep threshold. If the consecutive waits threshold is exceeded, then the tag may be moved to a PUSHED state and processing may loop to block 920; otherwise, processing may loop to block 924 where the tag may remain in the POST-POSTED state.

If, according to logic block 926, the tag delay does not exceed the wait threshold, then processing may flow from logic block 926 to logic block 930. According to logic block 930, it can be determined if the tag delay exceeds the warning threshold. In at least one embodiment, logic block 930 may use embodiments of logic block 904 to determine if a warning threshold has been exceeded. If the tag delay exceeds the warning threshold (but does not exceed the wait threshold), then processing may flow to logic block 932; otherwise, the tag may be moved to a normal state and processing may loop to block 902 in FIG. 9A.

According to logic block 932, it can be determined if the number of consecutive warning thresholds has been exceeded. In at least one embodiment, the sequential alert threshold may be two sequential monitored tag delays that exceed the alert threshold. If the consecutive alert threshold is exceeded, then the tag may be moved to the MARKED state and processing may loop to block 922 in FIG. 9A; otherwise, processing may loop to block 924 in which the tag may remain in the POST-POSTED state.

FIG. 10 shows an alternative graphical representation of the use of a tag in one of a variety of states and events that can trigger a state change. As shown, tags can be in one of five states of system 1000: state NORMAL 1002, state LABELED 1004, state PUSHED 1006, state PUSHED 1008, or POSTPONED state 1010. In some embodiments, the tag is in NORMAL state 1002, DECLARED state 1004, POST-STOPPED state 1006, PUSHED state 1008, and / or POST-PUSHED state 1010 may be used in a similar manner to the embodiment of block 902, block 908, block 912, block 920, and / or block 924 of FIG. 9, respectively.

Phase 1: Tags in state NORMAL 1002 that exceed the specified alert threshold can be moved to state TAGGED 1004. Tags in state MARKED 1004 can return to state NORMAL 1002 if the number of delays decreases (i.e., the monitored tag latency is less than the warning threshold).

Step 2: Tags in the NORMAL state 1002 that exceed the specified threshold may be moved to the PRE-POST 1006 state. In at least one embodiment, the sleep threshold may be greater than the alert threshold. In one non-limiting, non-exhaustive example, the alert threshold may be 500 milliseconds and the latency threshold may be 800 milliseconds.

Phase 3: Tags in STATE 1002 that exceed the specified threshold can be moved to STATE 1006. Tags in STATE 1006 may return to STATE 1004 if the number of delays decreases (i.e., the monitored tag delay is less than the threshold expectations).

Step 4: Tags in the PUSHED state 1006 that exceed the wait threshold for two consecutive approaches can be moved to the PUSHED state 1008.

Step 5: Tags in the PUSHED state 1008 that have reached their suspended state limit (for example, 30 minutes) may be moved to the POST-PUSHED state 1010. Tags in the POST-PUSHED state 1010 may return to the PUSHED state 1008 if they exceed the sleep threshold for two consistent approaches. In some embodiments, the wait threshold used to determine when to move tags from one state to another may be the same or a different threshold.

Step 6: Tags in POST-PUSHED state 1010 can transition to STAGED 1004 state if they exceed the alert threshold for two consecutive hits. Tags in the POST-PUSHED state 1010 can be moved to the NORMAL state 1002 as long as they do not exceed the warning threshold or wait threshold for two consecutive hits.

An example of using the operating environment

FIG. 11 illustrates one embodiment of a use case illustrating a system diagram of a system that can be used to monitor tag latency and manage tag state changes and deployment. As shown, system 1100 can include a plurality of monitoring servers, a management server, a database, and tag servers. In some embodiments, the plurality of monitoring servers may be similar to the TMSD 112 embodiments of FIG. 1. Multiple monitoring servers can include multiple monitoring server groups to monitor tags in various states, including: post-paused tag monitoring servers, paused tag monitoring servers, preemptive tag monitoring servers, tagged tag monitoring servers, normal tag monitoring servers. Each of the monitoring server groups can be physically located in different geographic locations such as North America (NA), Europe (EU), Asia (i.e., Asia and the Pacific (APAC)), and South America (SA). In some embodiments, the user may be allowed to select with which geographic location of the monitoring server the tag will be monitored.

The database can also include a list of all tags (i.e., all tag tables). The database may also include a plurality of tables for each of a variety of states, including a paused tags table, a paused tags table, a post-paused tags table, a normal tag table, and a tagged tag table.

The management server can access the database to determine which tags to monitor and when. In some embodiments, the management server may be similar to the TCSD 114 embodiments of FIG. 1. When a tag is monitoring, the management server can notify (eg, send a tag ID) to the monitoring server at the selected geographic location for the current state of the tag. For example, if a user selects European monitoring servers and is to monitor a tag in the MARKED state, then the management server can notify the tagged tag monitoring servers in Europe. Each of the many monitoring servers can provide monitored tag latency to the management server. Based on the tag latency, the management server can determine whether or not the state of the tag needs to be changed. If a tag has changed state, the management server can update the corresponding tables in the database to reflect the change in state. In some embodiments, the management server may send an e-mail or other notification to the user if a tag changes to a specific state (eg, MARKED, PUSHED, or the like). In addition, the management server can communicate with the push notification service to identify a tag that is available for deployment (i.e., include a tag for deployment).

The push notification service can be configured to provide tags to tag servers. In at least one embodiment, a push notification service can provide tag servers with the most up-to-date information about available tags received from a management server. Based on information provided by the push notification service, tag servers can deploy tags to a client browser web page. In some embodiments, the tag servers may be similar to the TDSD 116 embodiments shown in FIG. 1. In at least one embodiment, the management server and monitoring servers may asynchronously execute requests to a web page (including a push notification service and tag servers).

In some embodiments, if the tag is blocked from deployment (eg, in the SUSPEND_A 806 state and / or the SUSPEND_B state 808 in FIG. 8, or in the SUSPENDED state and / or POST-POST 1010 state in FIG. 10), the management server may allow the deployment of "inactive »Tag instead of a locked tag. In at least one embodiment, an inactive tag may be a non-executable version of a locked tag.

In some embodiments, an inactive tag can be used to determine how many times a blocked tag might have been expanded but not (because it was blocked). In at least one embodiment, the management server can provide the inactive tag to the push notification service and ultimately to the tag servers. In some embodiments, tag servers may refer to inactive tags as real tags to collect statistical information about tags, but cannot expand the inactive tag.

The above description, examples and data provide a complete description of the composition, manufacture and use of the present invention. Since many embodiments of the present invention can be carried out without departing from the spirit and scope of the invention, the present invention is encompassed by the scope of the appended claims.

Claims (142)

1. A method for managing tags for web pages over a network, wherein at least one network device permits actions to be performed to implement a method comprising: defining at least one tag for monitoring, which is associated with at least one web page, and at least one tag is characterized by one of a plurality of states; monitoring at least one tag based on at least one state of at least one tag, the monitoring being asynchronous for each request for at least one web page; determining a delay for monitoring at least one tag; if the determination of the delay and state of at least one tag indicates a state modification, the state change of at least one tag to another state, and, if the determination of the current state of at least one tag affirmatively indicates deployment and at least one web page is requested, deploying the at least one tag with the associated at least one web page. 2. The method of claim 1, wherein the plurality of states include at least a normal state, a flagged state, and at least one suspended state. 3. The method of claim 1, wherein deploying the at least one tag further comprises: allowing the expansion of at least one tag if at least one tag is in a normal state; allowing expansion of at least one tag if at least one tag is in a flagged state; and blocking the deployment of at least one tag if at least one tag is in a suspended state. 4. The method according to claim 1, wherein changing the state of at least one tag further comprises: moving at least one tag in the first state to the second state if the delay results are at least one of the following, including: the delay results exceed the threshold for the number of consecutive delay events; the delay results exceed the threshold for the number of delay events within the specified time period, and latency results exceed the severity threshold. 5. The method according to claim 1, wherein changing the state of at least one tag further comprises: moving at least one tag in the first state to the second state if the delay results are at least one of the following, including: the delay results exceed the threshold for the number of consecutive no-delay events, the delay results exceed the threshold for the number of no-delay events within the specified time period, and the delay results are below the lightness threshold. 6. The method according to claim 1, wherein changing the state of at least one tag further comprises: if the delay results in a delay event for at least one tag, take further actions, including: moving at least one tag in the normal state to the tagged state if the delay results exceed a threshold value for the number of delay events; moving at least one tag in the marked state to the first suspended state if the delay results exceed another threshold value for the number of delay events; moving at least one tag in the first suspended state to the second suspended state after a predetermined period of time, and moving at least one tag in the second suspended state to the first suspended state if the delay results exceed yet another threshold for the number of delay events. 7. The method according to claim 1, wherein changing the state of at least one tag further comprises: if the delay results in a no-delay event for at least one tag, take further actions, including: moving at least one tag in the marked state to the normal state if the no-delay event exceeds a threshold value for the number of no-delay events; and moving at least one tag in the suspended state to the flagged state if the no-delay event exceeds another threshold value of the number of no-delay events. 8. The method according to claim 1, wherein changing the state of at least one tag further comprises: moving at least one tag in a normal state to a flagged state if the delay exceeds a warning threshold; moving at least one tag in a normal state to a pre-terminated state if the delay exceeds the sleep threshold, the sleep threshold exceeding the warning threshold; moving at least one tag in the flagged state to a pre-suspended state if the delay exceeds the wait threshold; moving at least one tag in a pre-suspended state to a suspended state if the delay exceeds a threshold for multiple consecutive monitoring attempts; moving at least one tag in a suspended state to a post-suspended state after a specified period of time, and moving at least one tag in a post-suspended state to a suspended state if the delay exceeds the wait threshold for multiple consecutive monitoring attempts. 9. The method according to claim 1, wherein changing the state of at least one tag further comprises: moving at least one tag in a tagged state to a normal state if the delay is less than a warning threshold; moving at least one tag in a pre-terminated state to a flagged state if the delay is less than the sleep threshold, the sleep threshold being greater than the warning threshold; moving at least one tag in a post-paused state to a flagged state if the latency is greater than the alert threshold and less than the latency threshold for multiple consecutive monitoring attempts, and moving at least one tag in a post-paused state to a normal state if the delay is less than the warning threshold for multiple consecutive monitoring attempts. 10. The method of claim 1, wherein changing the state of at least one tag further comprises: providing a notification to at least one user to indicate that at least one tag has changed state. 11. A system for managing tags for web pages over a network, containing: a client device that is configured to perform actions that include: requesting a web page from a server device; a server control device that is configured to perform actions that include: defining at least one tag for monitoring that is associated with at least one web page, and at least one tag is in one of a plurality of states; defining at least one delay tag for monitoring, and, if the determination of the delay and state of at least one tag indicates a modification to a state, a modification of the state of at least one tag to a different state; at least one server monitoring device that is configured to perform actions including: monitoring at least one tag based on the status of at least one tag, the monitoring being asynchronous for each request for at least one web page, and at least one server deployment device that is configured to perform actions including: if the determination of the current state of at least one tag affirmatively indicates deployment and at least one web page is requested, deploying the at least one tag with an associated at least one web page on the client device. 12. The system of claim 11, wherein the plurality of states include at least a normal state, a flagged state, and at least one suspended state. 13. The system of claim 11, wherein deploying at least one tag further comprises: allowing the expansion of at least one tag if at least one tag is in a normal state; allowing at least one tag to expand if at least one tag is in a checked state, and blocking the deployment of at least one tag if at least one tag is in a suspended state. 14. The system of claim 11, wherein changing the state of at least one tag further provides: moving at least one tag in the first state to the second state if the delay results are at least one of the following, including: the delay results exceed the threshold for the number of consecutive delay events; the delay results exceed the threshold for the number of delay events within the specified time period, and latency results exceed the severity threshold. 15. The system according to claim 11, in which changing the state of at least one tag further provides: moving at least one tag in the first state to the second state if the delay results are at least one of the following, including: the delay results exceed the threshold for the number of consecutive no-delay events, the delay results exceed the threshold for the number of no-delay events within the specified time period, and the delay results are below the threshold value of the magnitude of moderation. 16. The system of claim 11, wherein changing the state of at least one tag further provides: if the delayed event results in a delayed event for at least one tag, take further actions, including: moving at least one tag in the normal state to the tagged state if the delay results exceed a threshold value for the number of delay events; moving at least one tag in the marked state to the first suspended state if the delay results exceed another threshold value for the number of delay events; moving at least one tag in the first suspended state to the second suspended state after a predetermined period of time, and moving at least one tag in the second suspended state to the first suspended state if the delay results exceed another threshold for the number of delay events. 17. The system of claim 11, wherein changing the state of at least one tag further provides: If the delay results from a no delay event for at least one tag, take further actions, including: moving at least one tag in the tagged state to the normal state if the No Delay Event exceeds the No Delay Event Threshold, and moving at least one tag in the suspended state to the flagged state if the no-delay event exceeds another threshold value for the number of no-delay events. 18. The system of claim 11, wherein changing the state of at least one tag further comprises: moving at least one tag in a normal state to a flagged state if the delay exceeds a warning threshold; moving at least one tag in the normal state to a pre-terminated state if the delay exceeds the sleep threshold at which the sleep threshold exceeds the warning threshold; moving at least one tag in the flagged state to a pre-suspended state if the delay exceeds the wait threshold; moving at least one tag in a pre-suspended state to a suspended state if the delay exceeds a threshold for multiple consecutive monitoring attempts; moving at least one tag in a suspended state to a post-suspended state after a specified period of time, and moving at least one tag in a post-suspended state to a suspended state if the delay exceeds the wait threshold for multiple consecutive monitoring attempts. 19. The system of claim 11, wherein changing the state of at least one tag further comprises: moving at least one tag in a tagged state to a normal state if the delay is less than a warning threshold; moving at least one tag in a pre-terminated state to a flagged state if the delay is less than the sleep threshold, wherein the sleep threshold is greater than the alert threshold; moving at least one tag in a post-paused state to a flagged state if the latency is greater than the alert threshold and less than the latency threshold for multiple consecutive monitoring attempts, and moving at least one tag in a post-paused state to a normal state if the delay is less than the warning threshold for multiple consecutive monitoring attempts. 20. The system of claim 11, wherein the server control unit is configured to perform further actions, including: if at least one tag is blocked from being deployed, take further actions, including: generating an inactive tag, which is a non-executable copy of the locked tag, and providing an inactive tag to at least one deployment server to collect statistics about the locked tag. 21. The system of claim 11, wherein changing the state of at least one tag further provides: providing a notification to at least one user to indicate that at least one tag has changed state. 22. A processor-readable storage medium that includes instructions for managing tags for web pages on a network, where the execution of the instructions by the processor permits actions that include: defining at least one tag for monitoring that is associated with at least one web page, with at least one tag in one of a plurality of states; monitoring at least one tag based on at least one state of at least one tag, the monitoring being asynchronous for each request for at least one web page; determining for monitoring the latency of at least one tag; if the determination of the delay and state of at least one tag indicates a modification in a state, a modification of the state of at least one tag to a different state, and, if the determination of the current state of the at least one tag affirmatively indicates deployment and at least one web page is requested, deployment of at least one tag associated with the at least one web page. 23. The medium of claim 22, wherein deploying the at least one tag further comprises: allowing the expansion of at least one tag if at least one tag is in a normal state; allowing at least one tag to expand if at least one tag is in a checked state, and blocking the deployment of at least one tag if at least one tag is in a suspended state. 24. The medium of claim 22, wherein changing the state of at least one tag further comprises: moving at least one tag in the first state to the second state if the delay results are at least one of the following, including: the delay results exceed the threshold for the number of consecutive delay events; the delay results exceed the threshold for the number of delay events within the specified time period, and latency results exceed the severity threshold. 25. The medium of claim 22, wherein changing the state of at least one tag further comprises: moving at least one tag in the first state to the second state if the delay results are at least one of the following, including: the delay results exceed the threshold for the number of consecutive no-delay events, the delay results exceed the threshold for the number of no-delay events within the specified time period, and the delay results are below the threshold value of the magnitude of moderation. 26. The medium of claim 22, wherein changing the state of at least one tag further comprises: If the delay results in a delayed state for at least one tag, take further actions, including: moving at least one tag in the normal state to the tagged state if the delay results exceed a threshold value for the number of delay events; moving at least one tag in the marked state to the first suspended state if the delay results exceed another threshold value for the number of delay events; moving at least one tag in the first suspended state to the second suspended state after a predetermined period of time, and moving at least one tag in the second suspended state to the first suspended state if the delay results exceed yet another threshold for the number of delay events. 27. The medium of claim 22, wherein changing the state of at least one tag further comprises: If the delay results from a no delay event for at least one tag, take further actions, including: moving at least one tag in the tagged state to the normal state if the No Delay Event exceeds the No Delay Event Threshold, and moving at least one tag in the suspended state to the flagged state if the no-delay event exceeds another threshold value for the number of delay events. 28. The medium of claim 22, wherein changing the state of at least one tag further comprises: moving at least one tag in a normal state to a flagged state if the delay exceeds a warning threshold; moving at least one tag in the normal state to a pre-terminated state if the wait threshold is greater than the warning threshold; moving at least one tag in the flagged state to a pre-suspended state if the delay exceeds the wait threshold; moving at least one tag in a pre-suspended state to a suspended state if the delay exceeds a wait threshold for multiple consecutive monitoring attempts; moving at least one tag in a suspended state to a post-suspended state after a specified period of time, and moving at least one tag in a post-suspended state to a suspended state if the delay exceeds the wait threshold for multiple consecutive monitoring attempts. 29. The medium of claim 22, wherein changing the state of at least one tag further comprises: moving at least one tag in a tagged state to a normal state if the delay is less than a warning threshold; moving at least one tag in a pre-terminated state to a flagged state if the delay is less than the sleep threshold, wherein the sleep threshold is greater than the warning threshold; moving at least one tag in a post-paused state to a flagged state if the latency is greater than the alert threshold and less than the latency threshold for multiple consecutive monitoring attempts, and moving at least one tag in a post-paused state to a normal state if the delay is less than the warning threshold for multiple consecutive monitoring attempts. 30. The medium of claim 22, wherein changing the state of at least one tag further comprises: providing a notification to at least one user to indicate that at least one tag has changed state.

Images