Patent Application
20060088050
1. Field of the Invention
The present invention relates to a system that enhances revenue and reduces costs by providing interoperability among multiple protocols on the same platform and by integrating services associated with the telecommunication industry.
2. Background of the Technology
The telecommunication industry, such as wire-line, cellular or digital telephone communication, is widespread and continues to grow and evolve rapidly. Providers (interchangeably referred to herein as “carriers” or “operators”) in the telecommunication industry have an enormous task of providing seamless communications to their end-parties (interchangeably referred to herein as “users” or “consumers” or “subscribers”). The telecommunication systems, which form the technological foundation of the telecommunication industry, however, are not currently able to provide operators with the scope of integrated functions and interoperability among themselves that are needed to keep up with the demands of the industry.
The current invention provides convergence across multiple protocols and generates convergent triggers to the service layers, which brings about a truly integrated convergent solutions platform.
For instance, one significant problem faced by the telecommunication industry is integrating signaling services (those that specifically provide wire-line and wireless communication), with administrative services, such as billing and revenue management. The administrative services are typically managed by operations support systems (OSS) (interchangeably referred to herein as the “platform”), which are generally systems that process information supporting various management functions, such as billing, customer care, network management, inventory control, maintenance, trouble ticket reporting, surveillance and service provisioning.
The current technology in the telecommunication field is increasingly encumbered by legacy operating systems that were developed with a compartmentalized, functional view of the providers operations. This also limited the scope of interoperability between various systems, involving multiple protocols. Thus, billing systems are developed in isolation from the network, and signaling plays a limited role in service creation. The net results are highly capable and robust OSS systems that perform well within a limited functional sphere of capabilities. Carriers typically spend great time and resources in bringing these different operational systems into a harmonious optimal relationship. As long as OSS and billing providers continue to take a narrow and compartmentalized perspective to system design, architecture, and performance, sub-optimization will be the norm.
There is an increased awareness and demand for a more integrated OSS protocols and network capabilities. Carriers are increasingly frustrated in being presented with dysfunctional systems that require extensive modifications before they can fully operate. The cost to the carrier can be incurred not only in terms of additional adaptation costs for interoperability but also in lost revenues as new service creation is delayed.
Carriers are also demanding greater real or near real time capabilities in the areas of real time service creation, quality of service optimization, and cost performance management from their OSS/Billing providers. The pressure on carriers to reduce costs, increase return on investment, and increase profitability has never been more severe.
For example, providers typically use numerous applications that may involve multiple protocols and platforms to carry out the plethora of services used by consumers. This approach is inherently flawed and creates disadvantages for the provider mainly because it limits the breadth of the applications. For instance, each application or platform used by the provider is focused on a specific task, thereby forcing the provider to compartmentalize activity. Compartmentalization is believed to be a narrow and inefficient method of addressing the activities of the provider.
Providers are increasingly growing frustrated with the reality of losses in revenue and the lack of available, easy-to-use remedies. For example, currently used technologies attempt to connect the multitude of services offered by providers by implementing extensive modifications to and upgrades of existing systems. This method of upgrading is not generally efficient; rather it has proven to be cost prohibitive due to the high costs associated with system testing, adaptation, and implementation. Moreover, this type of upgrade is commonly associated with numerous delays (due in part to the difficulty synchronizing older systems with newer applications. Delays usually result in additional lost revenue.
The present state of the technology also does not facilitate real-time processing. In particular, providers are limited in the areas of real-time service assessment and integration, quality of service optimization, and cost performance management. The inability to make real-time decisions and optimizations has an effect on the providers' revenue stream. For instance, in some cases, optimizations necessary to capture revenue are not implemented until a significant portion of available revenue is already lost.
It is widely believed that providers fail to collect significant amounts of revenue and that providers have unnecessary overhead that contributes to overall costs of operation. Accordingly, it is believed that providers suffer these losses of revenue, in part, because of 1) an inability of the present technology to accurately assess and collect revenue based on signaling or network use; 2) an inefficient method of processing revenue streams; and 3) unavailability of systems that provide seamless interoperability and thus providing transparent services to the users.
Thus, there remains an unmet need in the prior art for an elegant, intelligent and efficient telecommunication system that provides carriers with a single OSS platform integrating and implementing multiple systems, multiple protocols, services, solutions and applications from third party technology vendors. There also remains an unmet need in the art for an OSS platform that facilitates upgrades, customization, and general usability, while providing an enhancement for revenue collection and cost reduction of services associated with network operation.
The present invention provides an underlying platform layer that can remain a static core that works on multiple protocols; on which newer applications can be built; innovative services can be launched, without having to replace high cost capital infrastructure again and again as the technology matures. Products, services, and applications can become obsolete, but the capital infrastructure should not necessarily become obsolete as well.
Two core elements, which provide the underlying logic for all services—old and new—for the last 20 years and do not change for wireless carriers, are signaling and billing. The present invention provides one such pioneering technology platform and layer, which uniquely combines multiple signaling protocols and real-time rating engines to form a core on which applications can rest. The present invention uses signaling to transmit data, probe network operations, and distribute information in real time, thus creating innovative services, while seamlessly combining rating engines and billing elements to charge for these services in real time.
The present invention, which in one embodiment is referred to as the Next Generation Wireless Intelligent Services Engine (also interchangeably referred to herein as the “system” or simply WISENG), may also provide a robust, multi-layer OSS platform that integrates numerous services offered by a provider into an operational system. WISENG assists providers to maximize revenues and to reduce costs. In particular, the present invention provides a single, advanced real-time and integrated signaling and billing system, which forms the basis for all wireless communications services and associated services. The system integration is provided through the OSS platform, which incorporates signaling protocols to transmit data (e.g., via signaling system 7 (SS7) or C-7 signaling of GSM or CDMA, etc), the probing of network operations, and the distribution of information in real-time. As a result, the system of the present invention seamlessly allows the providers' rating engines and billing elements to charge for communication services in real-time.
In one more aspect of the present invention, the present invention increases the general application and usability of the operation system, in comparison to conventional operating systems. In particular, the system of the present invention is designed to be easily implemented, customized, and upgraded.
The system allows providers to efficiently and cost-effectively implement the system. The system does not require extensive modifications before the system is fully operational, thereby saving the provider from high implementation costs and delays that are typically associated with application upgrades. Moreover, the system can be customized to accommodate the needs of each provider. Thus, the present invention is highly scaleable and provider-specific.
Furthermore, the system of the present invention is fully and conveniently upgradeable. The system provides a static core on which newer applications can be built and innovative services can be launched without having to replace the capital infrastructure over time. Applications can be integrated with the core infrastructure using industry standard connections and protocols, as are generally known in the art.
Generally, the WISENG architecture includes a series of inter-relating layers. The central layers include multi protocol layer, protocol adaptation & inter-working layer, service broker layer, service authentication layer, and service interface layer.
To achieve the foregoing objects, and in accordance with the purpose of the invention as broadly described herein, the present invention provides a platform to enhance the scope of seamless interoperability across various protocols, carrier revenues and reduce network costs. The preferred embodiment of the present invention can be deployed in telecommunication networks.
Additional advantages and novel features of the present invention will become more apparent from the following description.
Other features of the present invention will become apparent from the following detailed description considered in connection with the accompanying drawings, which disclose multiple embodiments of the present invention. It should be understood, however, that the drawings are designed for the purpose of illustration only and not as a definition of the limits of the invention. Additional advantages and novel features of the invention will also become more apparent to those skilled in the art upon examination of the following or upon learning by practice of the invention.
The present invention provides an innovative OSS platform that adapts multiple protocols and provides inter-working among the protocols. Major enhancement in the current invention is that the platform provides convergence across protocols in a true sense. This also allows integrating signaling and billing technologies to allow real-time transactions and system assessment and/or management.
The system of the present invention provides an underlying platform layer that can remain as a static core and that can serve as the capital infrastructure for the provider. The static core generally includes two elements: signaling and billing that provide the underlying logic for most, if not all, services in the telecommunication industry. The present invention uniquely combines multiple protocols and real-time rating engines to form a core on which other applications are built and implemented. This core may also interface with third party applications and hardware. As a result, the present invention seamlessly integrates signaling, which is used to transmit data, probe network operations, and distribute information in real-time, with rating engine service and billing services to permit real-time assessment, management, and accounting of these services. This makes the present invention a comprehensive telecommunication’ solutions platform.
The system can be initially developed with one or more service layers, each of which performs services related to the telecommunication industry. The implementation of the system may be provider-specific to meet the exact needs of each provider.
The static core may be upgraded and expanded to accommodate the changing needs of each provider. For example, products, services, and applications, which can be rendered obsolete over time, can be replaced with state of the art applications on the system of the present invention. Generally, the replacement applications are interfaced with the system of the present invention using industry standard interfaces, which are generally known in the art. Accordingly, the system of the present invention can add multiple service layers to provide additional wireless communication services currently known or developed in the future.
Furthermore, the system of the present invention may be easily added to the existing capital infrastructure without high levels of adaptation or the need to replace significant amounts of hardware. Maintenance of the present system is also facilitated because vendor-specific information for each application and customization may not be required.
For the purposes of this application, Table 1 provides standard abbreviations for terms.
According to
The top layer schematically in
The system of the present invention can run numerous applications. For instance, the system can run an intelligent network based mobile pre-paid platform with great rating flexibility and rapid service creation and deployment functionality, such as Mobile VPN, CUG, Mobile Office, and services generally described in the International Telecommunication Union—Telecommunication Standardization Sector (ITU-T) recommendations IN CS-1, CS-2, and CS-3. The system of the present invention can also run an application for an optimal routing functionality, which can be achieved through quickly and efficiently subscribing to and calling the call management APIs. Other applications capable of running on the system of the present invention include, for example, 3G services, dual IMSI-based roaming, missed call alerts, welcome SMS alerts while roaming, location-based services, mobile prepaid services based on service node technology, mobile pre-paid roaming applications using the call management APIs and rating APIs to provide pre-paid roaming services, SMS, EMS, UMS, and MMS services, postpaid and prepaid billing, and prepaid roaming and non-roaming based on CAMEL phase II, III and IV.
The layer below the application layer 1001 is the application interface layer (AIL) 1002. The AIL 1002 provides the published application programming interfaces (APIs), such as call management and rating, which are generally known in the telecommunication arts. In one embodiment, the APIs are derived from industry standards, such as Parlay and XML.
The AIL 1002 is developed using the concepts of inter-operability and scalability. For example, in one variation of the present invention, interoperability is facilitated by using Common Object Request Broker Architecture (CORBA®). CORBA® is a vendor-independent architecture and infrastructure that computer applications use to work together over networks. Using the standard protocol IIOP, a CORBA-based program from any vendor, on almost any computer, operating system, programming language, and network, can interoperate with a CORBA-based program from the same or another vendor, on almost any other computer, operating system, programming language, and network. Other examples of interoperability include XML, java native interface (JNI), and Interface Definition Language (IDL).
The AIL 1002 may interface with the layers below via industry standard interfaces, such as IDL, OSA, and XML. In one embodiment, the APIs are derived from industry standards, such as Parlay and XML.
In an embodiment of the present invention according to
The applications register and subscribe to the services offered by the NBL 1003. The NBL 1003 is capable of addressing various protocols under signaling. In one variation, the 3G related applications are registered and subscribed to telecom access components. To support 3G requirements, for example, both SS7 and IP protocols are subscribed to and registered by applications.
Additionally, the NBL 1003 interfaces with vendor-specific APIs transparent to the application (e.g. NetStructure, manufactured by Intel of Santa Clara, Calif. and Opencall manufactured by Hewlett Packard of Palo Alto, Calif.). Additionally, in one variation, the NBL 1003 also supports network management functionality, so as to ensure that proper fault and alarm reporting is carried out apart from having the flexibility in managing and fixing faults. In another variation, the NBL 1003 also provides network statistics based on the applications subscribed thereon.
Schematically below the network broker layer 1003 shown in to
As shown in
According to
The top layer schematically in
The system of the present invention can run numerous applications, under the service logic layer 5001. For instance, the system can run an intelligent network based mobile pre-paid platform with great rating flexibility and rapid service creation and deployment functionality, such as Mobile VPN, CUG, Mobile Office, and services generally described in International Telecommunication Union—Telecommunication Standardization Sector (ITU-T) recommendations IN CS-1, CS-2, and CS-3. The system of the present invention can also run an application for an optimal routing functionality, which can be achieved through quickly and efficiently subscribing to and calling the call management APIs. Other applications capable of running on the system of the present invention include, for example, 3G services, dual IMSI-based roaming, missed call alerts, welcome SMS alerts while roaming, location-based services, mobile prepaid services based on service node technology, mobile pre-paid roaming applications using the call management APIs and rating APIs to provide pre-paid roaming services, SMS, EMS, UMS, and MMS services, postpaid and prepaid billing, and prepaid roaming and non-roaming based on CAMEL phase II, III, and IV.
The layer below the service logic layer 5001 is the service interface layer 5002. The service interface layer 5002 provides the programming interfaces (APIs) to the host and external applications, such as call management, rating, etc., which are generally known in the telecommunication arts. In one embodiment, the APIs are derived from industry standards, such as Parlay and XML.
The service interface layer 5002 may interface with the layers below via industry standard interfaces, such as Interface Definition Language (IDL), Open Services Access (OSA), and Extensible Markup Language (XML).
In an embodiment of the present invention according to
In an embodiment of the present invention according to
Additionally, the service broker layer 5003 interfaces with vendor-specific APIs transparent to the application. Additionally, in one variation, the service broker layer 5004 also supports network management functionality, so as to ensure that proper fault and alarm reporting is carried out apart from having the flexibility in managing and fixing faults. In another variation, the service broker layer 5004 also provides network statistics based on the applications subscribed thereon.
Schematically below the service broker layer 5004 shown in to
As shown in
Typically the config.ini 2 file stores application information. For example, the config.ini 2 (or an equivalent file) includes the number of applications, the name of applications, and ID for applications. The config.ini 2 file may include stack information, including the type of stack and the protocol used. Example stacks optionally include SS7, TCP/IP, SIP, etc from different vendors.
Additionally, in yet another variation, the config.ini 2 file includes converter information. The converter information may include, for example, the number of converters per stack and the converter type. The converter type information may include the socket and/or pipe.
The config.ini 2 file may also include fail-safe information. The fail-safe information includes stack level fail-safe information (e.g., HP, DK, or ULTICOM) and the converter level fail-safe information. The converter level fail-safe information may include this information for each converter level (e.g., 1, 2, 3, . . . n).
The config.ini 2 file may also include: 1) a broker configuration, which may include information, such as an application ID, protocol ID, application IP address; 2) broker level fail-safe information, which may include the broker ID 3) API information and/or format, which may include interface information, such as the WISENG format; and 4) information on IP addresses, which may include whether the address is active or in stand by.
In decision box 3, the particular vendor and/or protocol for the desired process are selected. The vendor and protocol selections may optionally include, for example, HP 16, DK 12, and ULTICOM 4 (also referred to herein as “UL”).
After a vendor and protocol is selected, the initializer starts the corresponding stacks. For instance, consider ULTICOM 4 is one of the stacks, including protocols, started by the initializer 1. The ULTICOM 4 stack(s) communicate in the SS7 network 5 using, for example, E1/T1 interfaces, via CAP 8 and INAP 10. Accordingly, this leads to UL_CAP 7a and UL_INAP 7b.
For instance, consider DK 12 is one of the stacks, including protocols, started by the initializer 1. The DK 12 stacks communicate in the SS7 network using E1/T1 interfaces, via ISUP 14a and MAP 11a. Accordingly, this leads to DK_ISUP 9a and DK_MAP 9a.
For instance, consider HP 16 is one of the stacks, including protocols, started by the initializer 1. The HP 16 stacks communicate in the SS7 network 5 using E1/T1 interfaces, via ISUP 14b and MAP 11b. Accordingly this leads to HP_ISUP 13a and DK_MAP 13b.
Converters 15a and 15b, for example, receive the message from the various stacks, e.g., UL 4, DK 12, and HP 16, and convert them to configured API formats. In one variation, as shown in
The converters may operate under fail-safe configuration, if configured to do so in the config.ini 2. The number of converters 15a and 15b, as shown in
Once the converters 15a and 15b receive the messages from the stacks and convert them to configured API formats, the API formats are forwarded to the broker 101, as shown in
The system manager 6 (
The broker 101 routes the APIs to the appropriate application 102a, 102b, and 102c based on the application ID, the protocol ID, and the IP address. In one variation, application 102a addresses pre-paid applications. In this variation, the application interfaces with the rating engine 103a with standard SQL statements. In another variation, application 102a is a messaging application. Thus, multiple applications 102a, 102b, and 102c can be developed within the same broker 101.
The following illustrates three examples of implementations and resulting effectiveness of the system of the present invention. The first two examples are comparative examples of conventional systems and the problems associated therewith. The third example is illustrative of the how the system of the present invention assists providers and improves upon the conventional systems.
Comparative Example 1. A large wireless communications provider uses multi-vendor platforms as the infrastructure to support wireless communication and related services. The provider uses numerous services, which are functional on separate hardware. Table 2 lists the services and platforms that are used by the provider.
Table 2 presents a typical case in which the provider uses multiple platforms/equipment to support various services. As a result, the provider must ensure complete and accurate integration of these services with one another to provide 100% optimization to the end user. In the event that the provider is unable to provide 100% optimization, the provider has limited options to address the situation and attempt to reach 100% optimization. For instance, the provider can obtain support from each vendor to determine whether each vendor's services are operational and optimized. However, each vendor is only able to address the problems associated with the vendor-specific application. A vendor of one protocol cannot typically address the problems associated with another protocol. Thus, the provider must rely on numerous vendors for support. By relying on the various vendors for assistance, the provider invests substantial amount of time and resources. In practical terms, addressing problems in this manner (e.g., obtaining expert support from each vendor) is typically associated with significant costs. In addition, the provider is typically unable to obtain information from vendors on how the individual applications should be integrated with one another. Therefore, having multiple platforms/equipment installed at the provider invites huge network integration costs and the likelihood of decreased revenues due to a high turnover of subscribers, i.e., unsubscribing from the services of the carrier.
Comparative Example 2. A large provider uses a single vendor platform as the infrastructure to support various services offered by the provider. Table 3 illustrates the various services offered by the provider and the corresponding platforms used to support the services.
Thus, Table 3 depicts a typical case where the provider installed various services of a single vendor on separate hardware to support those services. In this example, the maintenance costs of such hardware is prohibitively high, and the provider is accordingly extremely dependent on the single vendor. Additionally, the provider is limited to services that are provided by the single vendor, thereby limiting the scope of the providers' services to those offered by the single vendor. Moreover, the problem of limited scope of services is further exacerbated because the single vendor infrastructure does not permit third-party services to be implemented. The net result for the provider includes limited services offered, restricted revenue growth, and a potential loss of customers to market competitors providing a wider scope and range of services.
Example 3. The following example involves a large provider using the platform of the present invention, in accordance with one embodiment, as infrastructure to support various services. In this variation, the infrastructure is hardware and operating system independent, thereby increasing the versatility and applicability of the platform. Table 4 presents the various services provided the provider in this embodiment.
Table 4 depicts a typical case where the Wireless carrier has a single vendor and has installed scaleable hardware that supports various services. The infrastructure provided by the present invention creates an interface that can communicate with (e.g., “plug into”) any numerous third party services that operate in universally accepted formats and industry standard interfaces (e.g., XML, CORBA).
In another example, a large wireless communications provider uses multi-vendor platforms as the infrastructure to support wireless communication and related services. The provider uses numerous services, which are functional on separate hardware.
This example presents a typical case in which the provider uses multiple platforms/equipment to support various services, the provider must ensure complete and accurate integration of these services with one another to provide 100% optimization to the end user. In the event that the provider is unable to provide 100% optimization, the provider has limited options to address the situation and attempt to reach 100% optimization. For instance, the provider can obtain support from each vendor to determine whether each vendor's services are operational and optimized. However, each vendor is only able to address the problems associated with the vendor-specific application. A vendor of one protocol cannot typically address the problems associated with another protocol. Thus, the provider must rely on numerous vendors for support. By relying on the various vendors for assistance, the provider invests substantial amount of time and resources. In practical terms, addressing problems in this manner (e.g., obtain expert support from each vendor) is typically associated with significant costs. In addition, the provider is typically unable to obtain information from vendors on how the individual applications should be integrated with one another. Therefore, having multiple platforms/equipment installed at the provider invites huge network integration costs. The following example involves a large provider using the platform of the present invention, in accordance with one embodiment, as infrastructure to support various services. In this variation, the infrastructure is hardware and network protocol/connectivity independent, thereby increasing the versatility and applicability of the platform. The infrastructure provided by the present invention creates an interface that can communicate with (e.g., “plug into”) any numerous third party services that operate in universally accepted formats and industry standard interfaces (e.g., XML, CORBA).
Thus, with the implementation of the present invention, the provider obtains a number of advantages, including interoperability between multiple network interfaces, decreased maintenance costs and a resulting minimization of network costs. It should be noted that maintenance of the infrastructure does not require vendor-specific assistance or hardware.
The provider also has an option to increase services developed by third parties on the existing platform (single or multiple hardware boxes). This potential for expansion provides the carrier with flexibility to increase services and/or provide additional services to its customers, thereby enhancing revenue and providing a basis for a substantial decrease in network costs.
The present invention allows providers to reduce capital expenses and operational expenses. This reduction in expenses is significant when compared to the industry standard costs for implementing and maintaining a core infrastructure. Accordingly, as the costs decrease, the provider is able to increase revenue, or at the least, pass the financial benefit to the end user maintaining the same similar revenues.
The present invention may be implemented using hardware, software, or a combination thereof and may be implemented in one or more computer systems or other processing systems. In one embodiment, the invention is directed toward one or more computer systems capable of carrying out the functionality described herein. An example of such a computer system is shown in
Computer system 200 includes one or more processors, such as processor 204. The processor 204 is connected to a communication infrastructure 206 (e.g., a communications bus, cross-over bar, or network). Various software embodiments are described in terms of this exemplary computer system. After reading this description, it will become apparent to a person skilled in the relevant art(s) how to implement the invention using other computer systems and/or architectures.
Computer system 200 can include a display interface 202 that transmits graphics, text, and other data from the communication infrastructure 206 (or from a frame buffer not shown) to the display unit 230. Computer system 200 also includes a main memory 208, preferably random access memory (RAM), and may also include a secondary memory 210. The secondary memory 210 may include, for example, a hard disk drive 212 and/or a removable storage drive 214, representing a floppy disk drive, a magnetic tape drive, an optical disk drive, etc. The removable storage drive 214 reads from and/or writes to a removable storage unit 218 in a well-known manner. Removable storage unit 218 may represent a floppy disk, magnetic tape, optical disk, etc., which is read by and written to removable storage drive 214. As will be appreciated, the removable storage unit 218 includes a computer usable storage medium having stored therein computer software and/or data.
In alternative embodiments, secondary memory 210 may include other devices for allowing computer programs or other instructions to be loaded into computer system 200. Such devices may include, for example, removable storage unit 222 and interface 220. Removable storage unit 222 and interface 220 may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an erasable programmable read only memory (EPROM), or programmable read only memory (PROM)) and associated socket, etc., which allow software and data to be transferred from the removable storage unit 222 to computer system 200.
Computer system 200 may also include a communications interface 224. Communications interface 224 allows software and data to be transferred between computer system 200 and external devices. Examples of communications interface 224 may include a modem, a network interface (such as an Ethernet card), a communications port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, etc. Software and data transferred via communications interface 224 are in the form of signals 228, which may be electronic, electromagnetic, optical or other signals capable of being received by communications interface 224. These signals 228 are provided to communications interface 224 via a communications path (e.g., channel) 226. This path 226 carries signals 228 and may be implemented using wire or cable, fiber optics, a telephone line, a cellular link, a radio frequency (RF) link and/or other communications channels. In this document, the terms “computer program medium” and “computer usable medium” are used to refer generally to media such as a removable storage drive 214, removable storage drive 222, RAM, ROM, EPROM, a hard disk installed in hard disk drive 212, and signals 228. These computer program products provide software to the computer system 200. The invention is directed to such computer program products.
Computer programs (also referred to as computer control logic) are stored in main memory 208 and/or secondary memory 210. Computer programs may also be received via communications interface 224. Such computer programs, when executed, enable the computer system 200 to perform the features of the present invention. In particular, the computer programs, when executed, enable the processor 204 to perform the features of the present invention. Accordingly, such computer programs represent controllers of the computer system 200.
In an embodiment where the invention is implemented using software, the software may be stored in a computer program product and loaded into computer system 200 using removable storage drives 214, removable storage drive 222, RAM, ROM, EPROM, hard drive 212, or communications interface 224. The control logic (software), when executed by the processor 204, causes the processor 204 to perform the functions of the invention as described herein. In another embodiment, the invention is implemented primarily in hardware using, for example, hardware components, such as application specific integrated circuits (ASICs). Implementation of the hardware state machine so as to perform the functions described herein will be apparent to persons skilled in the relevant art(s).
In yet another embodiment, the invention is implemented using a combination of both hardware and software.
While there has been described what are at present considered to be preferred embodiments of the present invention, it will be understood that various modifications may be made thereto, and it is intended that the appended claims cover all such modifications as fall within the true spirit and scope of the invention. Other modifications will be apparent to those skilled in the art.
This application is a Continuation-In-Part Application of International Application Serial No. PCT/IB2004/001688, filed May 24, 2004, which claims priority to U.S. Provisional Application No. 60/472,716, filed May 23, 2003, the entire specifications, claims and drawings of which are incorporated herewith by reference.
| Number | Date | Country | |
|---|---|---|---|
| 60472716 | May 2003 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | PCT/IB04/01688 | May 2004 | US |
| Child | 11233405 | Sep 2005 | US |
