Abstract:
Disclosed are systems and methods of building a default set of parameters into a software application by defining a widget template having associated parameter schema and then instantiating a widget by substituting a new set of application parameters for the built-in defaults such that the new parameters meet the same constraints defined for the default parameters. Aspects of the invention also include testing the original application containing the default parameters, along with the parameter substitution process itself, using a Statistical Software Testing Methodology (SSTM) to ensure the application meets a pre-determined level of quality.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    The present application claims priority to U.S. Provisional Patent Application No. 61/242,136, filed Sep. 14, 2009, which is hereby incorporated by reference in its entirety. The present application is also related to U.S. patent application Ser. No. 11/532,286 entitled “Self-Contained Mini-Applications Systems and Methods for Digital Television” to Slothouber et al., filed on Sep. 15, 2005, the disclosure of which is hereby incorporated by reference in its entirety. 
     
    
     FIELD OF THE INVENTION 
       [0002]    The invention relates generally to the field of interactive computing devices such as set-top boxes, and specifically to the use of computing applications to interact with such devices. 
       BACKGROUND OF THE INVENTION 
       [0003]    In constrained computing environments, such as set-top boxes, self-contained mini-applications provide effective means for supporting user interaction. These self-contained mini-applications are sometimes referred to as “widgets.” Widgets have been implemented in a variety of different ways including as compiled source code targeted to run in particular end-user hardware and software environments. Widgets have also been implemented as source code that is compiled into bytecode and then run on a platform-specific virtual machine which makes appropriate use of the platform&#39;s middleware, operating system, and other resources. Widgets have also been implemented as Enhanced TV Binary Interchange Format 1.0 (EBIF) applications. 
         [0004]    To speed deployment, reduce costs, and improve reliability, application template customization approaches can be used for widget implementation. These approaches are generally oriented toward reducing the need to create and test new code by reusing components and parameterizing common functions. Skinning, which generally refers to the ability to personalize application Graphic User Interfaces (GUIs) by separating presentation details from the underlying data, has deployment, cost, and reliability benefits. Skinning accomplishes this by providing multiple platform-specific GUIs while leveraging some common components. Well known examples of skinning include those implemented in most instant messaging clients, media players, and web browsers like Mozilla and Opera. In the interactive TV (iTV) domain, use of templates and skinning are disclosed in U.S. Pat. Nos. 7,231,630 and 7,430,718. 
         [0005]    Any approach that generates customized source code, even code based on common, reused source modules, can cause problems when not properly created and tested to function with end-user environments. In cable TV systems, for example, a given widget will likely be deployed simultaneously to a large number of heterogeneous digital cable systems across the country. A single misspelling or excessively long text string introduced during template customization can produce serious errors. An extraneous byte in a popular application&#39;s measurement response can cause a system&#39;s return-path network to fail. To provide acceptable reliability, a conventional application template customization approach may require testing for every application variation created from a template. At least one full operator system trial may also be required to uncover any bandwidth or timing induced problems. This approach would be prohibitively expensive and rule out rapid sales-customization-deployment-response cycles. It would therefore be desirable to have a way to reduce defects in customized templates. 
       SUMMARY OF THE INVENTION 
       [0006]    Aspects of some embodiments of the invention may comprise systems and methods of building a default set of parameters into an application and subsequently substituting a new set of application parameters for the built-in defaults such that the new parameters meet the same constraints defined for the original default parameters. Aspects of the invention also include testing the original application containing the default parameters, along with the parameter substitution process itself, using a Statistical Software Testing Methodology (SSTM) to ensure the application meets a pre-determined level of quality. 
         [0007]    It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only, and are not restrictive of the invention as claimed. The accompanying drawings constitute a part of the specification, illustrate certain embodiments of the invention and, together with the detailed description, serve to explain the principles of the invention. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0008]    The invention can be more fully understood by reading the following detailed description together with the accompanying drawings, in which like reference indicators are used to designate like elements. The drawings are exemplary only and should not be construed as limiting the invention. 
           [0009]      FIG. 1  is a schematic diagram depicting the creation of a certified application template containing a default parameter set in conjunction with an associated schema. 
           [0010]      FIG. 2  is a schematic diagram depicting the creation of a widget template and associated schema. 
           [0011]      FIG. 3  is a schematic diagram depicting the widget instantiation process of substituting a default set of parameters with another parameter set. 
           [0012]      FIG. 4  is a schematic diagram depicting the certification of applications containing a customized parameter set and schemas. 
           [0013]      FIG. 5  is a schematic diagram depicting the creation and deployment of applications based on widget templates and associated schema. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0014]    As used herein, the term “widget” may refer to self-contained, mini-applications that support user interaction. The term “widget template” may describe the application containing the default parameter set. The term “widget instantiation” may describe the process of substituting a default set of parameters with another parameter set. A “widget” may be the application that results from the “widget instantiation process.” 
         [0015]    In some embodiments of the present invention, the widgets may be implemented as applications compliant with the EBIF specification running on set-top boxes over a cable TV broadband network. Widget instantiation may also be appropriate for use with other application software standards and practices, Customer Premises Equipment (CPE) devices, and networks. 
         [0016]    In certain preferred embodiments of the invention, widget instantiation may be utilized in processes for the creation of certified widget templates and schemas and the use of these templates and schemas to create and deploy customized widgets. 
         [0017]    The process of creating and certifying widget templates and schemas is typically done by software engineers and/or software quality assurance personnel (a.k.a. “widget template developers”). The second process of using these templates and schemas to create and deploy customized widgets may generally be accomplished by widget application developers (a.k.a. “widget developers”). The goal of these processes is to avoid the time-consuming and costly testing process that is conventionally required for each customized application built from a template. Instead, a statistical testing process may be applied to the process of instantiating widgets from widget templates to certify that the probability of a defect in any widget produced by the system is below a previously determined threshold. In some embodiments, this testing process may be completely automatable. In some embodiments, human quality assurance may be injected into the system to judge defects in aesthetics or to assure widget quality in any other way. 
         [0018]    While it is possible to provide template-based application development with ad-hoc testing of templates and the generated customized applications, this testing typically does not explore the entire template parameter space, nor does it typically provide any formal correlation between the number of testing trials performed and the expected defect rate. In short, ad-hoc testing typically does not know what to test, nor how much testing is sufficient. 
         [0019]    As shown in  FIG. 1 , the creation of a certified widget template and schema may comprise the steps of starting a process in step  105 , creating a widget template and schema in step  110 , certifying the widget template and schema in step  120 , and stopping the process in step  130 . 
         [0020]    As shown in  FIG. 2 , a process for the creation of a widget template and schema may be started in step  205 . In step  210 , a widget template and associated parameter schema are defined. A widget template may be an application containing parameters whose values can be customized to provide a particular set of widget features. In some embodiments of the invention, widget templates embody interactive features. In some embodiments of the invention, widget templates embody non-interactive features. For example, an interactive widget template might enable a TV viewer to request information from an advertiser (an RFI Widget) wherein parameters are provided for indicating the advertiser and product names, relevant images, descriptive text, and a means to enter customer contact information. A non-interactive widget template might, for example, provide captions or advertising messages for presentation over video running on a particular TV channel. Various types of widgets, such as those provided by FourthWall Media Ad Widgets® and TV Widgets®, may be suitable for widget templates. In some embodiments, these widgets may be suitable for widget templates when parameters that enable a given template to be customized for multiple uses are capable of being identified. 
         [0021]    The term “parameter schema” in step  210  may be a data structure or program associated with a widget template. A parameter schema may provide constraints for controlling what values are legal for each customizable parameter in the template. Such constraints may include, but are not limited to: required variable type for each parameter; minimum and maximum lengths of strings; maximum size of images; valid characters for strings; formatting rules/patterns for strings; minimum and maximum values for numeric parameters; identification of illegal values for strings and numeric parameters; rules relating one parameter value to another; restrictions on image data and other blobs checkable by parsing the data against a specification (e.g., assuring valid PNGs of certain types); checking strings against controlled vocabularies/dictionaries; and other similar constraints. 
         [0022]    The parameter schema in step  210  may also be used in verifying legal parameter values during widget instantiation in step  330 , and in automatically generating test cases during the widget template certification process in step  430 . These parameter schema may be implemented as an XML Schema, enhanced XML Schema, a SIAD (“Symbolic Input Attribute Decomposition”) tree, or using other similar approaches. In an embodiment, widget templates may be designed to have parameters that are static literal values with no dependencies on one another, e.g., independent text, images, bloom filters, Boolean values, etc. Thus, in one preferred embodiment, a simple XML Schema suffices to constrain legal values for the processes defined herein. The subject methods are not, however, restricted to having only semantic constraints such as those typically provided by a standard XML Schema. More advanced constraints (e.g., contextual/syntactic) may be supported. In addition, the parameter schema defined in step  210  may, in some embodiments, include information or further constraints about the likelihood of values to be used in practice by widget developers. In some embodiments, this information may be used to provide test cases which may better reflect actual defect rate and mean time between failure (MTBF) estimates during the certification process. 
         [0023]    In some preferred embodiments, widget templates and parameter schemas may be defined in step  210  so that a default parameter (i.e., placeholder) values may be readily replaced during widget instantiation. In some embodiments, such placeholders may be implemented by defining parameter slots sized appropriately for the largest data values allowable for each parameter and/or by employing other knowledge about compilation mechanisms and the layout of applications in memory. In these embodiments, the resulting source code may then be compiled into a binary data structure wherein placeholder values can be quickly and reliably replaced without requiring recompiling the source code during a subsequent widget instantiation step. In these embodiments, it may be important that both the default and substituted parameter values conform to identical constraints specified by the associated schema. 
         [0024]    In a preferred embodiment, widget templates may be developed using the EBIF standard to provide Enhanced TV (ETV) functionality on CPE devices such as set-top boxes connected to a broadband cable TV network. Available EBIF tools, validators, user agents, and other components may be used. Other software development environments, procedures, and tools may also be applicable to widget template and schema definition, which will be apparent to a person of ordinary skill in the art. Any programming language may be used to support widget template development and any widget development suite suitably modified to support widget instantiation. 
         [0025]    Steps  220  through  240  in  FIG. 2  depict testing steps preferably executed during the widget template and schema creation process. In step  220 , test parameter values based on the associated schema may be defined. In some embodiments, such values may be oriented toward typical values, boundary values, and/or degenerative case values. In step  230 , the widget template may be instantiated using the parameter values defined in step  220 . Exemplary details of step  230  are further described in  FIG. 3 . In step  240 , the instantiated widget may be tested with the values inserted in step  230 . If a test fails as indicated in step  250 , then the process may return to step  210  and the widget template and associated schema may be redefined as necessary. If all critical tests pass in step  250 , then the widget template and schema may be considered complete and the process may continue to step  260 . In step  260 , the widget template and schema may be made available for the certification process described in  FIG. 4 . The current process may be stopped in step  270 . 
         [0026]    The widget template and schema creation process of  FIG. 2  corresponds generally to source code development, compilation into binaries, and unit testing by the developer until ready for more rigorous testing by software quality assurance personnel. In some embodiments of the invention, the required application functionalities are balanced with the widget size and expected deployment requirements in step  210 . For example, while it is possible to define a single widget template to encompass all functionality for a class of applications, it may be preferable to develop several distinct templates for a given class, each optimized for specific layout options (e.g., vertical, horizontal, etc.). 
         [0027]    As shown in  FIG. 3 , an exemplary process of instantiating a widget template with parameter values comprises the steps of starting the process in step  305 , inputting a widget template and corresponding widget parameter schema in step  310 , inputting widget parameter values in step  320 , validating the parameter values against the schema in step  330 , replacing placeholder parameter values in the widget template with the specified parameter values in step  340 , making the resulting widget available in step  350 , and stopping the process in step  360 . 
         [0028]    The process depicted in  FIG. 3  may be utilized, for example, in step  230 , step  440 , or step  530 . To initialize the widget instantiation process, two sets of inputs are provided in  FIG. 3 : the widget template to be instantiated and its associated schema in step  310 , and parameter values to be used to customize the template in step  320 . The widget template and schema in step  310  may be provided by the parent process as files, data streams, or other means known to software practitioners. The widget parameter values in step  320  may be provided after being generated by a parent process, e.g., What You See Is What You Get (WYSIWYG) widget editor tool, test case generator, text editor, etc. 
         [0029]    Step  330  validates the widget parameter values against the provided schema. In step  330 , the constraints or other rules defined in the schema are used to check each of the input parameter values from step  320 . If all the values comply with the constraints defined in the schema, then the process may continue onto step  340 . In some embodiments, if one or more parameter values do not comply with the schema, then the process may abort and an error handling process may be invoked. 
         [0030]    In step  340 , the validated input parameter values may be used to replace the corresponding default (placeholder) parameter values in the widget template which were created during widget template and schema definition, such as those created in step  210 . Replacement of the parameter values in step  340  may occur via direct replacement in a memory structure, using a call interface, or any other suitable means. The replacement of the parameter values in step  340  may be capable of making the overall widget instantiation process more efficient than other methods that require the recompilation of code. 
         [0031]    In step  350 , the instantiated widget may be made available to the parent process for use (e.g., widget template creation, template certification, template customization, etc.). 
         [0032]    As shown in  FIG. 4 , the process for certifying a widget template and schema may be started in step  405 . In step  410 , a widget template and associated schema generated during the widget template and schema creation process depicted in  FIG. 2  may be selected for certification. 
         [0033]    In some embodiments, testing statistics may be initialized in step  420 . Step  420  may include specifying a target value for the acceptable defective rate ( 9 ) and initializing other variables appropriate for controlling and tracking the tests in step  420 . 
         [0034]    A set of parameter values may be generated based on the associated schema in step  430 . This set of parameter values may include a randomly generated value for each required parameter. These values may be randomly generated from the set of all possible parameter values that are legal per the schema, or randomly generated using a subset distribution of values reflecting those likely to be used by widget developers in practice. This latter distribution may be reflected in the associated schema or by additional constraints. 
         [0035]    In step  440 , a widget is instantiated using the parameter values generated in step  430 . The instantiation step may be accomplished in the same manner as the depiction in  FIG. 3 . Given the nature of the instantiation process (i.e., parameter value replacement versus recompilation), step  440  may be executed very quickly and allow thousands of test cases to be run in a reasonable amount of time. 
         [0036]    In step  450 , the resulting widget may be tested for defects. If a defect is found in step  460  (Defect?=Y), then a determination may be made in step  465  to fix the widget template and update the associated schema as necessary and processing returns to step  420 . Such a fix may involve modifying the widget template source code and recompiling it into a widget template binary that includes replaceable parameter values. Alternatively, if a defect is found in step  460 , testing may continue in step  470  as additional tests are generated and run. This exemplary embodiment may avoid the need to make changes (and possibly introduce other defects) when the overall defect rate may be acceptable in step  480 . For example, if the first few tests fail in step  460 , but the next thousand tests pass in step  470 , the widget template may be certifiable as the defect probability and testing statistics from step  470  and the defect probability rate in  480  are below the accepted defect rate necessary to certify the widget template and schema in step  490 . Step  450  may be automated by, for example, using SIAD trees, SOAD (“Symbolic Output Attribute Decomposition”) trees, or similar techniques capable of adequately assessing the pass/fail status of the tests. Given SSTM (“Statistical Software Testing Methodology”) automatic test case generation, test cases need not be stored and rerun after the application fixes defects. Rather, new cases can be automatically generated as needed. Storing and reusing previously-generated cases, especially cases that caused failures, may be desirable for regression testing, auditing, and analysis purposes. 
         [0037]    If the current test case passes in step  460  (Defect?=N), then new defect probability and test statistics may be calculated as indicated by step  470 . If the defect probability is not acceptable, processing may return to step  430  and a new set of widget parameter values may be randomly generated. If the defect probability is deemed acceptable in step  480 , then the widget template and schema may be certified in step  490  and the certification process may stops in step  495 . 
         [0038]    The configuration of the certification environment may reflect the key variables relevant to successful deployment of the widgets that result from instantiation. This allows widget developers and those deploying the widgets to have high confidence in the reliability and success of widgets verified in this environment. Such configurations may also take into account key network components, characteristics of target CPE devices (including actual or representative mixes of components), and other considerations relevant to deployment environments in order to account for pertinent interactions and potential fault modes. For example, the certification environment may include components that simulate a large number of CPE devices connected to the network and their behaviors in the face of device reboots and network failures when upstream out-of-band traffic exceeds channel capacity. 
         [0039]    The certification process depicted in  FIG. 4  may utilize a Statistical Software Testing Methodology (SSTM), which may be based on Cho, C. K., “Statistical Methods Applied to Software Quality Control,” in  Software Quality Assurance,  2 nd Edition , Shulmeyer, G. and J. McManus, eds., Van Nostrand Reinhold, New York, 1992 and as extended by Chu, H. D., Dobson, J. E., and Liu, I. C., “FAST: A Framework for Automating Statistics-based Testing,”  Software Quality Journal , Springer, 1997, wherein the defect ratio for generated widgets can be driven as low as desired (e.g., less than 1 in 10,000) using automatically-generated test cases. Assessment of test results can also be automated. Time invested in SSTM testing at template-creation time enables instantiated widgets to be created and deployed with little or no additional testing, providing for rapid widget deployment and minimal operational costs. 
         [0040]    SSTM is a statistical testing methodology that can be employed to ensure that the population defective rate, θ, over P, the population of widget applications that may be instantiated from valid widget customization parameters, is below an acceptable defective rate θ a . This is possible given that constraints on widget customization parameters may be defined by a suitable schema and that a validating parser is run to assure widget customization parameters satisfy all constraints. Such a schema may be defined by an XML Schema document (XSD), a SIAD Tree, an extended XML Schema document, or similar constructs. If an XSD is used, then the validating parser may be a standard XML parser. 
         [0041]    Sampling (random sampling is assumed) from P, we can estimate θ, defined by 
         [0000]    
       
         
           
             
               θ 
               = 
               
                 D 
                 N 
               
             
             , 
           
         
       
     
         [0000]    where D is the number of defective widget applications in P, and N is the number of possible widget applications in P, using the binomial distribution. The probability function of the binomial distribution is given by: 
         [0000]    
       
         
           
             
               b 
                
               
                 ( 
                 x 
                 ) 
               
             
             = 
             
               
                 ( 
                 
                   
                     
                       n 
                     
                   
                   
                     
                       x 
                     
                   
                 
                 ) 
               
                
               
                 
                   
                     θ 
                     x 
                   
                    
                   
                     ( 
                     
                       1 
                       - 
                       θ 
                     
                     ) 
                   
                 
                 
                   n 
                   - 
                   x 
                 
               
             
           
         
       
     
         [0042]    This gives the probability of getting x defectives in a sample of n units taken from a population having a defective rate of θ. The mean and variance of the distribution are given by: 
         [0000]      μ=nθ
 
         [0000]      σ 2   =n θ(1−θ)
 
         [0043]    Once the initial sample is taken and inspected, the defective rate θ 0  of the sample may be computed by θ 0 =d/n, where d is the number of defects in the sample. 
         [0044]    The defective rate of the population can then be estimated from d. The estimate may be expressed in an interval called the 100c % confidence interval, where 0≦c≦1. An approximate 100c % confidence interval of the population defective rate may be computed by: 
         [0000]    
       
         
           
             ⌊ 
             
               
                 
                   θ 
                   0 
                 
                 - 
                 
                   
                     t 
                     
                       
                         n 
                         - 
                         1 
                       
                       , 
                       
                         a 
                         / 
                         2 
                       
                     
                   
                    
                   
                     
                       
                         
                           θ 
                           0 
                         
                          
                         
                           ( 
                           
                             1 
                             - 
                             
                               θ 
                               0 
                             
                           
                           ) 
                         
                       
                     
                     n 
                   
                 
               
               , 
               
                 
                   θ 
                   0 
                 
                 + 
                 
                   
                     t 
                     
                       
                         n 
                         - 
                         1 
                       
                       , 
                       
                         a 
                         / 
                         2 
                       
                     
                   
                    
                   
                     
                       
                         
                           θ 
                           0 
                         
                          
                         
                           ( 
                           
                             1 
                             - 
                             
                               θ 
                               0 
                             
                           
                           ) 
                         
                       
                     
                     n 
                   
                 
               
             
             ⌋ 
           
         
       
     
         [0000]    where t n−1,a/2  is called the value of the Student t-distribution at n−1 degrees of freedom and a=−c is called a risk factor. By means of explanation, a binomial distribution in statistics can be approximated by a normal distribution. In the normal distribution, there is a value represented by z a/2 , which is the number of standard normal deviations such that the area to its right under the normal curve is a/2. The value of t n−1,a/2  is the same as z a/2  if n is large, e.g., n≧30. A Student t-distribution table from which t n−1,a/2  can be found when n is small, e.g., n&lt;30, is available in many statistics books. 
         [0045]    The accuracy of the estimates may depend on the sample size. In general, the larger the size, the more accurate the estimate. The value of n may be computed by: 
         [0000]    
       
         
           
             n 
             = 
             
               
                 
                   z 
                   2 
                 
                  
                 
                   ( 
                   
                     1 
                     - 
                     θ 
                   
                   ) 
                 
               
               
                 
                   a 
                   2 
                 
                  
                 θ 
               
             
           
         
       
     
         [0000]    where a is the desired accuracy factor such that |θ−θ 0 |=aθ, and z is the value of z a/2 . 
         [0046]    Since the population defective rate θ is unknown, the determination of n may take several iterations. The sample defective rate θ 0   i , found at iteration i is used as θ in computing n at iteration i+1. If n i+1  is less than n i , the total number of units in the sample already taken, then the sampling is completed. The final sample defective rate is then used to estimate μ and σ 2 . 
         [0047]    The above discussion about the SSTM process is deterministic. Given a procedure for generating random valid widget customization parameter values, the entire testing process to determine if θ&lt;θ a  may be automated, subject to the automation of a widget application testing procedure to identify widget application defects across the relevant target deployment environments (e.g., EBIF user agents). Since the SSTM methodology may test fully instantiated widget applications, not just the widget templates or parameter values used to instantiate them, this methodology validates and verifies the instantiation process and the resulting widgets under the assumption that widget customization parameter values are correctly validated according to the defined parameter schema. 
         [0048]    In certain applications, widget customization parameter values may include images. It may or may not be reasonable to expect the widget customization parameter schema to define all image types, or for validating parsers to recognize valid image data. Nevertheless, the WYSIWYG nature of the preferred customized widget creation and deployment process depicted in  FIG. 5 , and the availability of immediate instantiation and execution of the widget applications on target deployment platforms or emulators within the customization environment, ensure that all image files are valid. 
         [0049]    As shown in  FIG. 5 , the process of creating and deploying customized widgets may comprise the steps of starting the process in step  505 , selecting a certified widget template to customize in step  510 , defining parameter values appropriate to a particular application compliant with the associated schema in step  520 , instantiating the widget template using the defined parameter values in step  530 , deploying the customized widget in step  540 , and stopping the process in step  550 . 
         [0050]    In step  510 , a certified widget template may be selected to be customized. Selection may be accomplished using a WYSIWYG tool that allows searching and browsing through a collection of available certified templates. 
         [0051]    In step  520 , widget parameter values may be defined based on the schema associated with the selected template. These values may be defined manually using text editing, image management, image editing, and other such tools, or by ad hoc access to assets from a computer file system. Alternatively, parameter values may be defined by linking to and picking values from preexisting data sources such as advertiser databases, ad management systems, customer databases, image databases, video databases, and the like. Associated tools may automatically assure that parameter values are compliant with the corresponding schema as the values are defined or selected. Tools may also be provided to facilitate the proper association and synchronization of widget content with underlying video programming content. 
         [0052]    In step  530 , the widget template may be instantiated with the parameter values defined in step  520 . The instantiation process from  FIG. 3  may be used. Widgets may be automatically instantiated and immediately available for inspection using software that emulates the target deployment platforms for review by widget developers. 
         [0053]    In step  540 , the customized widget may be deployed to customers via multiple system operators (MSOs) or other distributors. One example of a customer is a television viewer. Deployment may involve, but is not limited to, encapsulating a resulting widget file as an EBIF binary in a CoDF wrapper and transmitting it to a cable network&#39;s broadcast or ad insertion system for deployment using a data carousel. Alternatively, the process may produce an XML or other file containing the desired parameter values, and send that file separately from the template for instantiation with the proper template nearer the final distribution point. Such parameter files may also be stored and managed distinctly from ready-to-run widgets for reuse, editing, auditing, and other purposes. The process is stopped in step  550 . 
         [0054]    The rapidity and reliability of widget instantiation depicted in  FIG. 5  may allow widget creation and deployment to occur in late-binding, local insertion scenarios. In some embodiments of the invention, widget content may even be inserted in real time during live TV broadcasts. 
         [0055]    It will be readily understood by those persons skilled in the art that the present invention is susceptible to broad utility and application. Many embodiments and adaptations of the present invention other than those herein described, as well as many variations, modifications and equivalent arrangements, will be apparent from or reasonably suggested by the present invention and foregoing description thereof, without departing from the substance or scope of the invention.