Patent Publication Number: US-8533306-B2

Title: Personal presentity presence subsystem

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
     This application is a continuation of copending U.S. utility application entitled, “Personal Presentity Presence Subsystem,” having Ser. No. 11/524,668, filed Sep. 21, 2006, which is related to abandoned U.S. utility application entitled, “Dynamically Configurable Presence Service,” having Ser. No. 11/525,008, filed Sep. 21, 2006, which are entirely incorporated herein by reference. 
    
    
     TECHNICAL FIELD 
     Embodiments are related to presence services. More particularly, the disclosed subject matter is related to computer-implemented methods, configurations, systems, and computer program products for facilitating support for dynamic grouping and presentation of personally associated presentity types based on their type. 
     BACKGROUND 
     Today&#39;s presence standards, models, and presence service implementations typically do not address dynamic categorization of presentities into presentity groups. Many presence applications allow users to manually group presentities into buddy lists such as “my family”, “my fellow garners”, “my colleagues”, and the like. This may be due to presence services typically assuming a homogeneous presentity population, addressing only one type of presentity, usually persons. 
     On the other hand, computer technology has evolved sufficiently such that “smart” technology is available in many homes today. From appliances to monitoring systems, many devices are capable of performing multiple tasks, interact with users, and communicated over various types of networks. 
     SUMMARY 
     Consistent with embodiments described herein, systems and methods are disclosed for providing support for dynamic categorization and presentation of personally associated presentities based on presentity type(s). Key features or essential features of the claimed subject matter are not necessarily identified in this summary portion. 
     A presence service is arranged to register and maintain updated information on different presentity types. Embodiments are directed to a personal presence subsystem that is capable of dynamically grouping these different presentities for presentation and management purposes based on their presentity type. In particular, the subsystem can identify and group devices and systems personally associated with a user into a “Personal Presentity” group. “Personal Presentity” types may include devices such as monitoring and entry systems that are typically associated with one individual. Presence applications may be provided presentity type information such that they can subscribe to monitor presence information and associated presentities with groups for presentation and management purposes. 
     It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only, and should not be considered restrictive of the scope of the invention, as described and claimed. Further, features and/or variations may be provided in addition to those set forth herein. For example, embodiments of the invention may be directed to various combinations and sub-combinations of the features described in the detailed description. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  illustrates a conceptual diagram of a presence service architecture, where example embodiments may be implemented; 
         FIG. 2  illustrates main components of an example personal presentity presence subsystem architecture; 
         FIG. 3  illustrates action flows in the example personal presentity presence subsystem of  FIG. 2 ; 
         FIG. 4  illustrates a diagram of a personal presentity presence service with personal presentities and a watcher; and 
         FIG. 5  illustrates a logic flow diagram for a process of providing personal presentity presence service according to one embodiment. 
     
    
    
     DETAILED DESCRIPTION 
     As briefly described above, a personal presentity presence service may include real time configurability for different types of personal presentities. In the following detailed description, references are made to the accompanying drawings that form a part hereof, and in which are shown by way of illustrations specific embodiments or examples. These aspects may be combined, other aspects may be utilized, and structural changes may be made without departing from the spirit or scope of the present disclosure. The following detailed description is therefore not to be taken in a limiting sense, and the scope of the present invention is defined by the appended claims and their equivalents. 
     Referring now to the drawings, aspects, exemplary operating environments, and configurations will be described. While the embodiments will be described in the general context of program modules that execute in conjunction with an application program that runs on an operating system on a personal computer, those skilled in the art will recognize that aspects may also be implemented in combination with other program modules. 
     Embodiments may be implemented as a computer process (method), a computing system, or as an article of manufacture, such as a computer program product or computer readable media. The computer program product may be a computer storage media readable by a computer system and encoding a computer program of instructions for executing a computer process. The computer program product may also be a propagated signal on a carrier readable by a computing system and encoding a computer program of instructions for executing a computer process. 
     Generally, program modules include routines, programs, components, data structures, and other types of structures that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that embodiments may be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like. Embodiments may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices. 
       FIG. 1  and the following discussion are intended to provide a brief, general description of a suitable computing environment in which the invention may be implemented. With reference to  FIG. 1 , a conceptual diagram of a presence service architecture  100 , where example embodiments may be implemented, is shown. A presence system allows users to subscribe to each other and be notified of changes in state and, typically, for users to exchange a communication with each other. A presence service has two distinct sets of “clients”. One set of clients, called “presentities”, provides presence information to be stored and distributed. The other set of clients, called “watchers”, receives presence information from the service. 
     Architecture  100  includes at a base level watcher applications  120  and presentities  130  that connect to the backbone of the presence system through IP network  112  or other network(s)  114  of the connectivity and access layer  110 . Watcher applications  120  provide an interface for watcher(s)  122 . There are two kinds of watchers, called “fetchers”  124  and “subscribers”  128 . Fetcher  124  simply requests the current value of some presentity&#39;s presence information from the presence server  102 . In contrast, subscriber  128  may request notification from the presence server  102  about changes in a presentity&#39;s presence information including future changes. A special kind of fetcher  124  is one that fetches information on a regular basis. This is called a “poller”  126 . 
     In a conventional presence system, watcher applications  120  may be executed on computing devices such as cellular phones, Personal Digital Assistants (PDAs), and the like, providing watcher(s)  122  information about the presentities  130  that are typically associated with a particular watcher  122 . In a typical presence system scenario, the presentities  130  may include people in a phone subscriber&#39;s “buddy list” with the system providing information about location or contact information of the people on the buddy list to the subscriber and enabling the subscriber to contact the presentities  130  through various means. Thus, the presentities  130  in a typical presence system are homogeneous (all persons). Furthermore, the presence services generally operate by registering the presentities  130  along with their attributes requiring a reconfiguration of the buddy list when a new presentity is added or one removed. 
     According to some embodiments, presentities  130  may include different types of personal presentities  130  such as interface devices (and applications) that may provide a service to the watcher  122 . For example, a personal presentity  130  may include a monitoring or entry system configured to provide triggering event(s) to the watcher  122  and facilitate actions in response to the triggering event(s) and the watcher&#39;s selection. 
     Connectivity and access layer  110  includes network infrastructure that is used to provide interconnection between presentity/watcher applications and presence applications at application layer  105  of the system. Connectivity layer  110  may include IP network  112  and other network  114  or a combination of networks. These network(s)  112  and/or  114  may include a secure network such as a home network or an enterprise network, or an unsecure network such as a wireless open network. The networks  112  and/or  114  provide communication between the applications described above. By way of example, and not limitation, the networks  112  and/or  114  may include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. 
     Presence services may be a service component deployed within an IP Multimedia System (IMS) framework. Control and session layer  108  is arranged to facilitate communication sessions between the physical devices and the applications, as well as between the applications and any network resources such as data stores of the IMS framework. IMS is an open-systems architecture that supports a range of IP-based services over both packet switch and circuit switch networks, employing both wireless and fixed access technologies. 
     IMS provides services and control such as adding call session control to the packet network, enabling peer-to-peer real-time services such as voice or video over a packet-switched domain, and scalable common service control (based on SIP) for giving the ability to manage parallel user services. In a mixed multimedia environment, IMS may provide the ability to pick and mix various multimedia flows in single or multiple sessions and can handle real-time voice, video, and data. IMS also provides access to IP based services independent of the underlying access technology (mobile or fixed). IMS applications and drivers may include voice telephony (VoIP), video telephony, web browsing, presence-based services, push-to media services (e.g. push-to-talk, push-to-view, push-to-video, etc.), group chat, instant messaging, multimedia conferencing, content sharing/data transfer, and the like. 
     Control and session layer  108  within an IMS framework may include components such as proxy-call state control function (“P-CSCF”), which is typically a first point of contact and may provide privacy control, quality of service (“QoS”), authorization of local services, and similar functionalities. P-CSCF may interacts through SIP with interrogating-call state control function (“I-CSCF”), which may provide an access point functionality to the network and enable protection of a topology and configuration of the network. I-CSCF may interact through SIP with serving-call state control function (“S-CSCF”), which provides session control services such as registration, accounting, and the like. Both I-CSCF and S-CSCF may interact with a home subscriber service (“HSS”), which can be used as a data store service for storing presence information, e.g. where the user can be reached. An IMS architecture may include additional components such as a subscriber locating function, a trunking signaling gateway, a media resource function controller, and the like. Furthermore, control and session layer  108  may also be embodied within a framework other than IMS. 
     At an application layer  105  of architecture  100  are presence server  102 , presence list server  104 , and presentity store  106 . The application layer  105  may also include one or more applications associated with providing additional services to the watchers  122  integrated with the unified presence service. 
     Presence server  102  is arranged to coordinate exchange of information between the presentities  130  and watchers  122 , as well as different data stores of the system. For example, presence server  102  may receive information associated with a location of a watcher  122  and notify the watcher  122  through an application (or device) based on the watcher&#39;s location about status of the watcher&#39;s registered presentities  130 . Presence list server  104  may maintain a list of the presentities  130  associated with each watcher  122  and update presentity store  106 , where information about the presentities  130  and their attributes are stored. 
     According to some embodiments, watcher application  120  may provide one or more user interfaces (“UIs”) to enable the watchers  122  and the presentities  130  to receive and provide information, such as VoIP communications, action selections, alphanumeric entries, and the like. 
     Interface devices executing watcher  122  and presentity  130  applications as well as servers of the application layer  105  may include or may be part of a computing device. Such a computing device may include, but is not limited to, a handheld computer, a Personal Digital Assistant (PDA), a TV, an MP3 player, a smart remote control device, and the like. Computing devices typically include a processing device and a system memory. Computing devices may also include additional processing devices, which may be dedicated processors or enable distributed processing by coordinating with a main processing device. The system memory may be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.) or some combination of the two. System memory typically provides an environment for an operating system to be executed for controlling the operation of the computing device and execution of other programs (applications). The watcher application  120 , a subscriber location application, two-way communication applications, imaging or video communication applications are examples of programs or program modules that may be executed in the system memory. These applications may be an integrated part of a single program or separate applications. They may communicate with other applications running on the computing device or on other devices. 
     The computing devices may have additional features or functionality. For example, the computing devices may also include data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. The system memory and storage devices are examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the computing device. Any such computer storage media may be part of the computing device. 
     Computing devices may also include input devices such as a keyboard, a keypad, a voice input device, a touch input device, a camera etc. Furthermore, output devices such as a display, a speaker, a printer, etc. may also be included. These devices are well known in the art. 
     Communication connections may be included in the computing devices to allow the device to communicate with other computing devices executing above described applications, such as over a network in a distributed computing environment, for example, an intranet or the Internet. Communication connections may include media that may be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and include any information delivery media. 
     By way of example, and not limitation, communication media may include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. The term computer readable media as used herein refers to both storage media and communication media. The implementation of embodiments for interface devices and servers of a personal presentity presence subsystem is not limited to the computing devices described above. Other computing devices with different components, configurations, and the like, may be used to execute computer readable instructions implementing embodiments described herein without departing from a scope and spirit of the disclosed subject matter. 
       FIG. 2  illustrates main components of an example personal presentity presence subsystem  200 . According to some embodiments, a personal presentity presence subsystem  200  may provide for real time configurability of a presence service to dynamically determine and configure the actions that can be taken when a presence notification has been received. In particular, certain presentities  130  are identified as “personal presentities” and are automatically grouped into a personal presentity group. According to other embodiments, the system may support different types (heterogeneous) of presentities  130  which may have different associated service actions. 
     The support for heterogeneous presentities  130  with different associated service actions may be accomplished by employing a presentity manifest. For each presentity a presentity manifest including a type of the presentity, a list of associated actions, a presentity group information, and a list of authorized watchers  122  may be stored and maintained by the presence server  102 . Furthermore, the list of associated actions may include for each action a network address of an application or system to connect to, one or more parameters for the application or system associated with the action, and presentation information (e.g. icons to be used in a UI for the action). 
     In an operation, presence application  232  may monitor presence of presentities such as presentity  130  and update presence server  102  with the status of monitored presentities  130 . Presence application  232  may also register any new presentity type with presentity service management component  234 . Moreover, presence application  232  may optionally register presentities  130  with directory service  236 . 
     Presence service management component  234  may register any applications associated with presentities  130  with presence server  102  as well as register any new presentities  130  with directory service  236 . According to some embodiments, presence service management component  234  may store new presentity types and manifests of the presentities  130  with presentity manifest store  240 . 
     Watcher application  120  may be dynamically reconfigured based on the presentity manifests in presentity manifest store  240 . For example, profiles, associated actions, and icons for each presentity  130  displayed on a watcher application UI may be updated when the presentity manifest is modified in presentity manifest store  240 . Watcher application  120  also subscribes to selected presentities  130  with the presence server  102  and receives updates on presence information (e.g. location, status of a presentity). Watcher application  120  may receive the updates from presence server  102 , directly from presentity store  106 , or from presentity group management component  238 . 
     Presentity group management component  238  is configured to categorize presentities based on their types and manage the groups in coordination with presence server  102 . In addition, directory service  236  may optionally coordinate operations of presentity group management component  238  as well. 
     Presence server  102 , in coordination with directory service  236 , manages presentity store  106  where status information associated with registered presentities  130  is stored. Essentially, presence server  102  enforces rules of the service provider on categorizing presentities, while watcher application  120  enforces client (user) rules. As mentioned above, the interactions between the components of the personal presentity presence subsystem may be facilitated within an IMS framework using SIP sessions. A basic example scenario is provided below for illustration purposes. 
     According to the example scenario, a presence service may support two types of personal presentities  130 : a monitoring system interface device (car alarm equipped with a camera) and entry system interface devices (doorbells equipped with visual and audio communication devices). The presentities  130  are personal presentity, because they are personally associated with the user. They are not a generic resource that may be shared by subscribers of a presence service. Each type of personal presentity has different actions associated with it such as “take picture” for car alarm, and “audio call” or “video call” for the doorbell. Thus, each type of personal presentity has different applications that need to be activated to perform the associated action(s). When the personal presentities are added to the system, their manifests includes their types (e.g. car alarm, doorbell), which identifies them as personal presentity types. The network addresses of the associated applications (e.g. IP addresses for client image acquisition application, VoIP call client, video conference client, and the like), any parameters associated with the applications, and icons for the actions may also be stored in presentity manifest store  240 . 
     Under each type, there may be numerous presentities  130  (e.g. three separate car alarms, front and back doorbells, etc.). Each presentity  130  within a group (type) may have differing configurations, but their essential structure is similar enough to group them together. For example, the front doorbell presence hardware may include a display for video communication, but the back doorbell presence hardware may lack the display. Presence server  102  in coordination with presentity group management  238  may categorize added personal presentities once they are registered with the presence server  102  by presence application  232 . When the presentity manifest store  240  is updated, watcher application  120  may be dynamically updated to reflect the latest configuration for different presentity types. 
     Watcher application  120  then receives updates on the personal presentities from the presence server  102 . In response to the received updates, watcher application  120  may select an associated action (e.g. initiate an audio call with a person at the door in response to the doorbell being rung). Presence server  102  in coordination with presence application  232  may then manage activation of the appropriate client application and facilitate the execution of the action. 
     The architecture and scenarios described in  FIG. 1  and  FIG. 2  are for illustration purposes only and do not constitute a limitation on embodiments. Other configurations of a personal presentity presence subsystem may be implemented without departing from a scope and spirit of the present invention. 
       FIG. 3  illustrates action flows in the example personal presentity presence subsystem of  FIG. 2 . The interactions are between components the doorbell presence service described above in detail. 
     The action flow begins with action  301 , where presence application  232  performs an initial registration of a personal presentity type that includes the manifest information discussed above in conjunction with  FIG. 2 . The presence application  232  registers the personal presentity type with presence service management component  234 . Presence application  232  then stores the manifest information with presentity manifest store  240  in action  302 . Actions  303  and  304  are respective responses of presentity manifest store  240  and presence service management component  234  that registration is complete. Upon receiving the registration complete message, presence application  232  registers a personal presentity with presence service management component  234  in action  305 . In response, presence service management component  234  registers the personal presentity with directory service  236  in action  306 . Following that, directory service  236  registers the personal presentity with presentity store  106  in action  307  and receives a registration complete message in action  308 . The involvement of the directory service  236  is optional according to some embodiments. The registration complete message is forwarded to presence service management component  234  in action  309  and from there to presence application  232  in action  310 . 
     In the meantime, watcher application  120  retrieves personal presentities or other classes of presentities  130  from presentity store  106  in actions  311 . Watcher application  120  then subscribes to presentities  130  by type with presence server  102  in action  312 . Following the subscription, watcher application  120  retrieves the manifest(s) for the subscribed presentities  130  from presentity manifest store  240  in actions  313 . The retrieval of the updated manifests results in dynamic reconfiguration of the watcher application  120  in action  314 , which may include updating one or more UIs, application parameters, links, and the like. 
     According to some embodiments, watcher application  120  may request subscription to a buddy list with group management subsystem  238  in action  315 . Upon receiving this request, group management subsystem  238  may subscribe the watcher application  120  to personal presentities in the requested buddy list in action  316 . This may result in a dynamic reconfiguration of the watcher application  120  based on the types of presentities  130  in the buddy list in action  317 . The term “buddy list” is used herein in a generic sense to describe a group within a particular type of presentities  130 . For example, a user may be authorizes to car alarms for a fleet of automobiles including personal vehicles and vehicles of his organization. The user may then define a “buddy list” of his/her personal cars within the car alarm type of presentities  130 . 
     In action  318 , presentity  130  provides presence application  232  with presence information. This may include information such as a doorbell ringing status, a car alarm status, availability of a person for phone call, and the like. The presence application  232  updates presence server  102  with the information from the personal presentity in action  319 . Presence server  102  then updates watcher application  120  in action  320 . Operations associated with personal presentities are not limited to those described above. Additional actions may be included within the actions described here or after the last action. For example, the user may select an action associated with the received presence information. The selection may then be forwarded to presence application, which may activate one or more applications to execute the user selected action. 
       FIG. 4  illustrates a diagram of a personal presentity presence service with personal presentities  130  and a watcher  122 . Presence server  102  and presentity store  106  are as described in  FIG. 1 . Presence application  232  manages associated personal presentities  130  and facilitates execution of a user selected action in response to provided presence information. Presence server  102 , presentity store  106 , and presence application  232  communicate with each other, with watcher application  120 , and with presentities  130  through presence network  452 . As discussed preivously, presence network  452  may include an SIP session IMS infrastructure, wired or wireless networks, and the like. 
     Presentities  130  may include a number of personal presentities associated with watcher  122  personally. Examples of personal presentities  130  represented in the diagram are doorbell presence hardware  432 , monitoring system  434 , and car alarm  436 . Any other type of device or system that is personally associated with watcher  122  and can provide presence information to the watcher  122  may be a personal presentity  130 . In a conventional presence system, presentities  130  may be persons. Thus presentation of presentities  130  in watcher application  120  may be accordingly. For example, watcher application  120  may provide choices to the watcher to establish a phone call, a video call, or display a location of the presentity person. 
     On the other hand, presentation of personal presentities  130  may be associated with significantly different choices for the watcher  122 . The selection of actions in response to presence information may typically depend on capabilities and features of a specific personal presentity. For example, a monitoring system may be set up to monitor several equipment and processes. Thus, personal presentities within the group of monitoring presentities may have different features depending on what is being monitored. A test equipment monitoring device may provide results of tests, duration of tests, and the like. Associated actions may include recording the readings, resetting the test equipment, modifying parameters of the test equipment, and the like. In another example, the personal presentity may include a weather monitoring device that provides automatic updates on weather conditions such as temperature, humidity, precipitation, and the like. Upon registering the type of presentity  130  and subscribing the watcher to it, the presence server  102  may reconfigure the watcher application  120  (or the watcher application can automatically reconfigure itself) to present a selection of actions associated with the weather monitoring presentity. The actions may include resetting modules of the presentity  130 , changing recording parameters, and the like. 
     According to some embodiments, users may override or regroup personal presentities identified by the system into customizable groups for presentation and/or management purposes. In the other words, the system may identify personal presentities and place them into the user&#39;s personal presentity group or into subgroups like “office”, “home”, and the like. 
     The claimed subject matter also includes methods. These methods can be implemented in any number of ways, including the structures described in this document. One such way is by machine operations, of devices of the type described in this document. 
     Another optional way is for one or more of the individual operations of the methods to be performed in conjunction with one or more human operators performing some. These human operators need not be collocated with each other, but each can be only with a machine that performs a portion of the program. 
       FIG. 5  illustrates a logic flow diagram for a process  500  of providing personal presentity presence service according to one embodiment. Process  500  may be implemented in presence server  102 . 
     Process  500  begins with operation  502 , where presence service management component  234  registers a personal presentity type in response to receiving a request for registering the presentity type from presence application  232 . The registration may include storing information associated with the presentity type such as name of the type, addresses of applications associated with related actions, icons to be presented in a watcher application UI for the presentity type, and the like. Processing moves from operation  502  to operation  504 . Presence service management component  234  may register the information with presentity manifest store  240 . 
     At operation  504 , the presence service management component  234  registers a presentity  130  of a registered type with presentity store  106  in response to a request to register a new presentity  130  from the presence application  232 . Processing moves from operation  504  to operation  506 . 
     At operation  506 , presentity store  106  provides a list of available presentities and groups of categorized presentities to watcher application  120 . According to some embodiments, presence application  232  may filter the list based on an authorization attribute associated with each presentity  130 . For example, personal presentities may be made available only to users associated with those personal presentities. Watcher application  120  may then provide a request for subscription to selected presentities  130 . Processing moves from operation  506  to operation  508 . 
     At operation  508 , the presence service management component  234  subscribes the watcher application  120  with the requested personal presentities in presentity store  106  and confirms the subscription to the requesting watcher application  120 . Processing moves from operation  508  to operation  510 . 
     At operation  510 , presentity manifest store  240  provides the manifests of the personal presentities in the list of subscribed presentities to the watcher application  120 . Upon receiving the manifests of the personal presentities, the watcher application  120  may be dynamically configured based on the types of presentities  130  in the subscribed list. Processing moves from operation  510  to optional operation  512 . 
     At optional operation  512 , the presence service management component  234  subscribes the watcher application  120  with one or more requested buddy lists comprising a plurality of personal presentities and confirms the subscription to the requesting watcher application  120 . Processing moves from optional operation  512  to optional operation  514 . 
     At optional operation  514 , presentity manifest store  240  provides the manifests of the personal presentities in the subscribed buddy list to the watcher application  120 . Upon receiving the manifests of the personal presentities in the buddy list, the watcher application  120  may be dynamically reconfigured based on the types of presentities  130  in the subscribed buddy list. Processing moves from optional operation  514  to operation  516 . 
     At optional operation  516 , presence server  102  provides updates received from various presentities  130  to presence application  232 , which in turn provides them to watcher application  120 . The updates may include presence information such as location or availability of a presentity  130 , a trigger event associated with the presentity  130 , and the like. Processing moves from operation  516  to operation  518 . 
     At operation  518 , presence application  232  facilitates an action selected by the watcher  122  in response to the updated presence information. Facilitating the action may include, as described previously, activating one or more client applications that perform tasks such as establishing communications, activating controls, and the like. After operation  518 , processing moves to a calling process for further actions. 
     The operations included in process  500  are for illustration purposes. Providing personal presentity presence service may be implemented by similar processes with fewer or additional steps, as well as in different order of operations using the principles described herein. 
     The above specification, examples and data provide a complete description of the manufacture and use of the composition of the embodiments. Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims and embodiments.