Source: http://www.google.com/patents/US7707278?dq=oakley+D523,461&ei=qiI4T-CjGqXf0QHz_PSUCA
Timestamp: 2015-01-31 09:23:42
Document Index: 666247776

Matched Legal Cases: ['Application No. 0011954', 'application no. 0011954', 'art 10', 'art� 20', 'art� 10', 'art 10', 'art 10', 'application No. 0011954']

Patent US7707278 - Reconfiguration management architectures for mobile communication systems - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsA reconfiguration management architecture for a mobile communications system which includes a network and at least one software-definable terminal comprises a configuration management part (10) within the or each terminal and a configuration control part (20). The configuration management part (10) implements...http://www.google.com/patents/US7707278?utm_source=gb-gplus-sharePatent US7707278 - Reconfiguration management architectures for mobile communication systemsAdvanced Patent SearchPublication numberUS7707278 B2Publication typeGrantApplication numberUS 10/432,293Publication dateApr 27, 2010Filing dateNov 20, 2001Priority dateNov 22, 2000Fee statusLapsedAlso published asDE60143851D1, EP1338161A1, EP1338161B1, US20040049561, WO2002043422A1Publication number10432293, 432293, US 7707278 B2, US 7707278B2, US-B2-7707278, US7707278 B2, US7707278B2InventorsRahim Tafazolli, Klaus Moessner, Seiamak VahidOriginal AssigneeUniversity Of SurreyExport CitationBiBTeX, EndNote, RefManPatent Citations (14), Non-Patent Citations (9), Referenced by (6), Classifications (7), Legal Events (4) External Links: USPTO, USPTO Assignment, EspacenetReconfiguration management architectures for mobile communication systemsUS 7707278 B2Abstract A reconfiguration management architecture for a mobile communications system which includes a network and at least one software-definable terminal comprises a configuration management part (10) within the or each terminal and a configuration control part (20). The configuration management part (10) implements a proposed configuration to reconfigure the terminal provided the configuration control part (20) validates the proposed configuration.
1. A computer-readable medium having thereon computer-executable instructions implementing a reconfiguration management architecture for a mobile communications system including a network and at least one software-definable terminal, said architecture comprising a configuration manager located within said terminal to define a proposed configuration for the terminal� and a configuration controller located within the network, wherein
Open terminal platforms and software reconfigureability are the crucial technologies to realise software-definable radios (soft-radios) and re-configureable network nodes (e.g. base stations). Terminals are evolving towards all-purpose radios that can implement a variety of different standards or protocols through re-programming. Elements at the physical and MAC layers are already programmable in different ways (http://www.ifn.et.tu-dresden.de/)eg. programmable encoders/decoders (via sets of parameters) and other blocks e.g. equalizer implementations. They need these additional capabilities to serve the increasing roaming and service delivery demands of future mobile applications. To support this new paradigm of communications (anytime, anywhere, whatever), terminals will need to be reconfigureable to different air interface standards. Early implementations of these multi-mode terminals used the �Velcro-approach� in which the operational mode is merely switched between two (or more) independent implementations of air interface standards within a single terminal. More recent developments are aiming at truly reconfigureable software architectures within network nodes; here the goal is to define any node by software only. Examples of research in this area include the OSAF (OMI Software Architecture Forum) project described by A. Kung in �A Model for Reusability Based on Java and Cobra� Trialog Whitepaper, Paris, 1997 (http://www.trialog.com/papaerreuse.html) and the efforts ongoing within the SDR Forum (Software Definable Radio Forum) (http://www.sdrforum.org), which both aim to specify reconfigureable open platforms. OPtIMA (Open Protocol Programming Interface Model & Architecture) described in our co-pending UK Patent Application No. 0011954.5 and IEEE P1520 described by Biswas J. et al in �Application Progamming Interfaces for Networks�, Working Group on IEEE P 1520 on APIs for Networks, IEEE Communication Magazine, Vol 36, No 10, pp 64-70, October 1998 are examples of projects for reconfigureability of protocol stacks and finally MExE described in �Digital cellular telecommunications system (Phase 2+): Mobile Station Application Execution Environment (MExE)�, ETSI TS 101 741 V7.1.0, 1999 and the MASE are delivering reconfigureability for application support (MExE is the Mobile Application Execution Platform currently being specified by 3GPP and the MASE a Mobile Application Support Environment, specified by the ACTS projects �on the Move� (http://www.sics.se/-onthemove/) and �MOVE� (http://www.uk.infowin.org/ACTS/RUS/PROJECTS/prtitm.htm)
Reconfigureability may be pursued in different ways: 1) using parameterised radio modules, 2) exchange of (a) single component(s) within a module and 3) exchange of complete radio modules. Complete reconfigureability of the protocol stack, for example, calls for introduction of flexible interfaces between protocol layers i.e. Protocol Programming Interfaces (PPIs) that replace the rather static service access points (see patent application no. 0011954.5). The example of OPtIMA enables reconfigureability through introduction of programming interfaces between protocol strata, providing the possibility to write both single protocols or whole protocol stacks in a manner similar to the way applications are written in high level programming languages (e.g. Java applications use different APIs which are part of the class libraries with binding at runtime�this means that the functionality is out-sourced to the API and the application simply defines the sequence and determines the parameters passed to methods within the APIs). This, or comparable/similar design principles will need to be applied to enable reconfiguration in future network nodes/soft terminals.
In a preferred implementation of the invention, the configuration management means is arranged to generate a definition of the proposed configuration. This definition (referred to hereinafter as a configuration tag-file) may include information representing configuration rules determined to be permitted by the network for rconfiguration of the terminal type and information identifying the location of software required to implement the proposed configuration. The configuration tag-file provides the basis for a test procedure (referred to hereinafter as �virtual configuration�) which is either terminal or network-based and is designed to simulate operation of the proposed configuration, enabling acceptability of the proposed configuration to be assessed and validated. For example, the test procedure may be designed to test for compliance with the afore-mentioned open interfaces of the terminal. The configuration management means will only implement the proposed configuration if, as a result of the test procedure, it is validated by the reconfiguration control means in the network.
The configuration management part 10 comprises a local software repository 11, a configuration rule repository 12, a �tag-file� handler 13, a plurality of reconfiguration module controllers 14, a security manager 15, a middleware based configuration software bus 16 and a configuration manager 17.
Reconfiguration management is, as mentioned, a shared responsibility between network and terminal. Furthermore, the complete management system consists of a number of parts (as shown in FIG. 1). In this embodiment, the necessary influence of a network authority is reflected in the network counterpart of the reconfiguration process, i.e. a re-configuration supporting entity has to be available/resident within the network. This, �SDR Terminal�(Network) Configuration Control Part� 20 consists of a server 21 (i.e. an AcA server), which, in this embodiment, validates new configurations by executing the virtual configuration procedure. Such a unit may be resident within the access network or in the backbone network. The core of the reconfiguration management system is the �Configuration Manager� 17 within the �SDR Terminal��Configuration Management Part� 10. This core unit co-ordinates all other parts (within and outside the terminal) of the reconfiguration management sub-system and implements the reconfiguration protocol (assuming that it has been validated).
Reconfiguration management is not only distributed between terminal and network, but also within the terminal itself; the local �Reconfiguration Management Controllers� (RMC) 14 implement the reconfiguration (initiated by the Configuration Manager) in the individual modules of the �SDR Terminal�modules� 30 (i.e. the reconfigureable communication part of the terminal such as the protocol stack module). The same concept applies for external peripherals of the terminal (e.g. personal space utilities 18 such as use of a TV screen as a display, etc.), where reconfiguration will be managed on a �External Module Controller� (EMC) 19. Furthermore, there are the additional, supportive units within the SDR Terminal�Configuration Management Part 10. The local software repository 11 stores all software necessary for terminal configuration, the configuration rule repository 12 stores the list of reconfiguration classes/degrees allowed by the network provider for the used terminal type 12, the �tag-file� handler 13 keeps, reads, generates and alters �tag-files� and the security manager 15 is responsible for establishing, maintaining and terminating secure connections between the different management units and to prevent malicious reconfiguration requests.
Software for reconfiguration purposes may be obtained from various internal/external sources and methods of download could include OTA download, specific vendor outlets, the Internet or smart card downloads as described, for example, in Terminal reconfiguration: �The Software Download Aspect� by K. Moessner, R. Tafazolli, First International Conference on 3G Technology, IEE-3G2000, London, Mar. 19-23, 2000 or self obtained software (e.g. self written). Reconfiguration Management has to ensure the reliability and trustworthiness of any software element, independent of its source.
The terminals or rather their configurations, are defined, using a script (languages such as Java-Script, HTML or XML�or other possible customised subsets of these may be used for this purpose). These scripts, referred to herein as configuration tag-files contain information about the complete terminal software configuration and the structure of how single software entities are employed. The original (the �boot�) tagfile defines the initial terminal configuration and is accessed during the �boot� period of the terminal, and in case the terminal undergoes a reconfiguration, a new tag-file, containing all information necessary for the new configuration, is generated. Tag-files need to contain, inter alia, information about software name, version and location of the source from which the software entity was/is obtained (e.g. an URL or other resource locator).
If a reconfiguration request arrives, the Configuration Manager 17 first requests the configuration rules (which will depend on type of terminal and reconfiguration, etc.), obtains the software necessary to undertake the reconfiguration and then generates the new tag-file (i.e. the �new� SDR Terminal description). After generation of the new tag-file the Configuration Manager initiates a virtual configuration (VC) procedure. In the case of a network-controlled VC, the terminal-resident Configuration Manager 17 forwards the tag-file to the network-resident counter-part of the Configuration Management Part, i.e. the reconfiguration controller shown in FIG. 2. Within the AcA server, the tag-file is interpreted and a virtual configuration takes place, prior to which the tag-file delivers all information necessary to obtain the reconfiguration software from whichever source. In the event that the software cannot be obtained from �public� sources, an upload has to be initiated, indicating user-initiated nature of the configuration procedure. Once all software entities necessary are available at the server, the virtual configuration can take place, whereby all software modules listed in the tag-file are required to simulate the proposed configuration of the terminal. If the virtual configuration fails, the terminal Configuration Manager must halt the reconfiguration process and revert to the old (current) configuration. Otherwise, the reconfiguration procedure can continue.
(1) Terminal-controlled, network-assisted In this case, a virtual configuration takes place within the terminal whereby the required software element(s) are presumed to have been downloaded, though not yet integrated. As shown in FIG. 3, the VC takes place immediately after the software download sequence. Upon completion of the virtual configuration procedure, a message �req_reconf_perm � is delivered to the network seeking permission to proceed with the actual reconfiguration to the new/modified element/layer/stack. Upon receiving a positive response from the network, the reconfiguration is executed and the new tag-file is forwarded to the network. (2) Network-controlled, terminal-assisted In this case a virtual configuration takes place within the network (e.g. AcA server) whereby the required element(s) are presumed downloaded/available. As shown in FIG. 4, upon reception of message �req_recon_perm � the AcA server initiates the virtual reconfiguration procedure and returns the results to the terminal in the message �reconf_perm_res �. In case of failure, the message will indicate possible reasons with an error code. In a particular implementation, the VC procedure verifies compliance/conformance of the new/downloaded code to published/open interfaces. The compliance test is carried out by passing (via the interfaces) a number of dummy parameters and observing the resulting response from the software element (object).
1. Terminal initiates a mutual authentication sequence to establish a secure channel between terminal and AcA (this �sub-sequence� is not defined here). 2. Terminal requests the set of rules for the intended reconfiguration. The parameters to be passed describe: reconfiguration depth, radio module and terminal type. 3. AcA acknowledges the request and forwards the reconfiguration rules according to depth and terminal type. 4. The terminal then downloads the software from the intended source (i.e. from a local storage element, from a URL via the network, from the AcA server). 5. The Configuration Management Part 10 within the terminal performs aVC and the results of the operation are reported back to the network in message �reconfiguration-request-permission�. 6. Request for permission for terminal reconfiguration; the message forwarded from the Terminal to the AcA server carries a tag-file, if applicable, the self-obtained software element or the URL of the source from which the element was obtained and additionally the outcome of the VC process, as parameters. 7. The AcA server responds with a �reconfiguration-request-response message-the outcome of the request and possible error messages are parameters of this message. 8. Once the reconfiguration within the terminal is implemented, the terminal will send a �reconfiguration-registration-request� containing the new tag-file to the AcA server to register the current set-up of the terminal. 9. AcA responds with an acknowledgement to the registration message. 10. The secure connection between terminal and AcA becomes terminated. The sequence for a network-controlled, terminal-assisted sequence shown in FIG. 4 corresponds in most parts to the terminal-controlled procedure; however, the main difference is that the VC is now carried out within the AcA server.
Re-Configuration process control and validation is performed within the network�in this embodiment, within the AcA-Server (in the case of network controlled VC). The AcA-Server provides multiple functions including:
Authentication/Authorisation/Encryption: the server ensures that reconfiguration software has been obtained from trusted sources only, or that the subscriber has authorised the download of this software module. Furthermore, it ensures the secure and possibly encrypted download of approved software (i.e. software provided by the network provider). Virtual configuration: the AcA server performs the virtual configuration indicated in the tag-file delivered from the configuration manager within the SDR-terminal to the �re-configuration-controller� unit with the AcA server, and issues an either positive or negative acknowledgement to the configuration manager unit. Accounting/Billing for service provision: software download and reconfiguration of terminals is a costly service, and network operator/service providers will need the facility to charge for these value added services. The AcA server may collect resource consumption data to support trend analysis, cost allocation, auditing, and billing. Functionality and interactions of the described reconfiguration management system are represented in the form of a finite state machine (FSM). The state machine controls and maintains reconfiguration procedures and current settings, respectively. Once a reconfigureable soft terminal is switched on, it undergoes a boot-process and assumes the last known configuration (as defined in the last known tag-file). The reconfiguration manager will then be in an idle state until any external event triggers or requests a reconfiguration procedure, as shown in FIG. 5.
IDLE�Once the boot process is accomplished and the last known (validated) configuration is assumed, the configuration manager unit assumes idle state, it maintains the current configuration and merely awaits any request/triggers for reconfiguration from either outside or within the terminal. Possible transitions from this state are triggered by either internal or external requests for reconfiguration or by system failures (i.e. failures are treated like requests for reconfiguration).
REQUEST VALID�Is the state in which a request for reconfiguration, or the failure of a part of the system, is recognised. Requests may be discarded for either not being valid or not being classifiable to one of the recongised reconfiguration categories.
RECONFIGURATION VALID�This state can only be assumed when the requested reconfiguration has been compared with and complies to both configuration rules and terminal capability list. The reconfiguration manager accesses a database containing these configuration rules to identify whether the terminal is capable of supported the requested reconfiguration.
CONFIGURATION-TAG-FILE PREPARATION�A configuration tag-file is generated containing the detailed description and source locators for the software units for the intended configuration. All software units are either resident within the terminal's local memory or are to be obtained externally via a download sequence.
SW DOWNLOAD�Strictly, SW download is not a real state, but is the abstraction of a complete sub-state machine executing software download. It is a core part of reconfiguration management, the basic functionality and task is to obtain software entities from sources other than the local SW store and to provide references of these SW entities to the reconfiguration manager, and also to ensure the trustworthiness and reliability of the obtained software entities.
VC PROCESS�Any terminal configuration needs to be approved and tested before it can be applied. This prevents fraudulent interference of possible malicious third parties during reconfiguration and also ensures that the terminal complies with the requirements and standards of the radio interface.
OLD CONFIGURATION�The state �old configuration� represents the current active configuration of the terminal. The terminal reverts to/remains in this configuration if the new configuration fails the conformance evaluation or design rule check. The reconfiguration manager then has either to re-initiate the reconfiguration process or has to abandon the reconfiguration, and the terminal continues operation in the old configuration.
NEW CONFIGURATION�Once the design rules are validated and conformance of the new configuration is ensured, the configuration manager has to inform the requesting network and local entity about the reconfiguration of the terminal and has to register the tag-file with the AcA server.
Design�and identification of required functional elements�of a reconfiguration management architecture capable of supporting a reconfiguration protocol.
Distribution of reconfiguration management functions for SDR terminals, between the network and terminal. This distributed reconfiguration management system consists of a terminal-resident �Reconfiguration Manager Unit� and a network resident �Reconfiguration Controller Unit�.
The introduction of the functional aspects of a �Configuration Manager� unit (as proposed initially in patent application No. 0011954.5) responsible for:
Managing the distributed nature of the various functional blocks within the �SDR Terminal-Configuration Management Part� of a soft terminal. These include (see FIG. 1): (1) a repository for reconfiguration rules, (2) a local SW element repository, (3) a configuration tag-file generator and interpreter, (4) various �RMC-interface� units, (5) a (possibly CORBA based) configuration software bus and (6) a Configuration Manager Unit controlling and managing the aforementioned functional blocks (1-5). Authentication and authorisation of the source of reconfiguration request (user initiated process: user-specified source e.g. a URL, open source, user-designed/defined software or network-initiated process: from the software repository within the mobile network. Validation of feasibility of the intended reconfiguration request (via terminal capability negotiation). Download of the necessary software updates/elements from source to the AcA server in the network if initiated by the user; otherwise the required software may be assumed resident/available in the AcA server. Generate the proposed/new configuration tag-file according to the intended configuration. Forward the tag-file to the network AcA server (the server is required to maintain a copy of the last configuration tag-file. In the case of a network-controlled, terminal-assisted process, the virtual configuration takes place within the AcA server, and the result of the process is forwarded to the terminal. If the VC procedure response was positive, then the terminal enters into a reconfiguration phase under the control of Configuration Manager and executes reconfiguration to the new settings. If the reconfiguration process is not successfully completed or does not result in a working configuration, an error-log is generated and stored within the terminal. A return to the old/working configuration is now necessary (using the original configuration tag-file) whereafter the error-log is transmitted back to the network for diagnosis and further analysis. The introduction of functional aspects of a �Reconfiguration Controller� unit�at the network side�, responsible for:
Provision of configuration rules provided according to the different SDR-T types and possible configuration categories. The rules may vary depending on the platform used and the degree to which the terminal is affected by a reconfiguration. Execution and control of a �virtual reconfiguration� (VC) procedure that takes place within the network/or in the terminal and performs a functional test of the intended configuration. Software elements necessary to complete this VC are listed in the tag-file delivered from the Configuration Manager within the SDR-Terminal. The Configuration Control Part notifies the Configuration Manager within the SDR-T about the result of the �virtual configuration�. Registration of the terminal configuration after completion of the reconfiguration process within the terminal. Introducing the concept of a �configuration tag-file, containing a definition of the current state/configuration of a SDR Terminal.
Authentication/Authorisation (for software download from different sources). Encryption/decryption (secure transmission of code and control messages). A �sandbox-approach� to provide a secure/isolated environment during the execution of the VC protocol. A �firewall mechanism� to protect the architecture from manipulation by external/unauthorised sources/entities. Introduction and application of �Reconfiguration Module Controllers� (RMC) that provide the means for reconfiguration management within the single reconfigureable modules of the �SDR Terminal�Module Part�.
Introduction of an AcA-server as functional block within the �SDR Terminal-Configuration Control Part� providing multiple functionalities:
Authentication/Authorisation/Encryption/Decryption (providing a firewall mechanism to prevent unauthorised access). Virtual Configuration (based on the above mentioned sandbox-approach). Accounting and billing. Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS5699350 *Oct 6, 1995Dec 16, 1997Canon Kabushiki KaishaReconfiguration of protocol stacks and/or frame type assignments in a network interface deviceUS5999990May 18, 1998Dec 7, 1999Motorola, Inc.Communicator having reconfigurable resourcesUS6052600 *Nov 23, 1998Apr 18, 2000Motorola, Inc.Software programmable radio and method for configuringUS6278449 *Sep 3, 1998Aug 21, 2001Sony CorporationApparatus and method for designating information to be retrieved over a computer networkUS6535979 *Jan 28, 1999Mar 18, 2003Nokia Mobile Phones LimitedMethod of ciphering data transmission, and cellular radio systemUS6721872 *Jan 18, 2000Apr 13, 2004Lucent Technologies Inc.Reconfigurable network interface architectureUS6954634 *Apr 19, 2000Oct 11, 2005Koninklijke Philips Electronics N.V.Reconfigurable communication networkUS6988133 *Oct 31, 2000Jan 17, 2006Cisco Technology, Inc.Method and apparatus for communicating network quality of service policy information to a plurality of policy enforcement pointsUS7151925 *Feb 14, 2002Dec 19, 2006Industrial Technology Research InstituteSoftware defined radio (SDR) architecture for wireless digital communication systemsUS7404074 *Jul 14, 2003Jul 22, 2008Sca Technica, Inc.Self-booting software defined radio moduleUS20010029529 *Mar 22, 2001Oct 11, 2001Ikuko TachibanaRemote maintenance apparatus, terminal connected to the apparatus and computer readable medium for realizing the apparatus and the terminalGB353918A Title not availableGB2350749A * Title not availableWO2001088707A2May 16, 2001Nov 22, 2001Univ SurreyProtocol stacks* Cited by examinerNon-Patent CitationsReference16.0 Software Download Implementation Recommendation, SDRF Technical Report 2.2, Nov. 1999, pp. 1-77, Chapter 6, Rev. 3.2Biswas et al., IEEE P1520 Application Programming Interfaces for Networks: An Introduction http://www.ieee-pin.org/; The IEEE P1520-A presentation at OpenArch Conference, New York; Mar. 27, 1999.3Biswas et al., The IEEE P1520 Standards Initiative for Programmable Network Interfaces, IEEE Communications Magazine, Oct. 1998, pp. 64-70.4Cummings et al., Mode Switching and Software Download for Software Defined Radio: The SDR Forum Approach, IEEE Communications Magazine, Aug. 1999, pp. 104-106, IEEE Service Center, vol. 37, No. 8.5Digital cellular telecommunications systems (Phase 2+); Mobile Station Application Execution Environment (MexE); Service description; Stage 1 (GSM 02.57 version 7.1.0 Release 1998), ETSI TS 101 741, Aug. 1998, pp. 1-21, v 7.1.0, 1998.6Kung, A Model for Reusability Based On Java and Corba, 1997, pp. 1-15, Trialog, Paris, France.7Mitola, The Software Radio Architecture, IEEE Communications Magazine, May 1995, pp. 26-31, IEEE Service Center, vol. 33, No. 5.8Moessner et al., Terminal Reconfigureability-The Software Download Aspect, Mobile Communication Technologies, 2000, pp. 326-330, No. 471.9Moessner et al., Terminal Reconfigureability�The Software Download Aspect, Mobile Communication Technologies, 2000, pp. 326-330, No. 471.Referenced byCiting PatentFiling datePublication dateApplicantTitleUS7873984 *Jan 31, 2002Jan 18, 2011Brocade Communications Systems, Inc.Network security through configuration servers in the fabric environmentUS8230394 *Oct 4, 2007Jul 24, 2012Hewlett-Packard Development Company, L.P.Managing data settings in a computer operating systemUS8245191 *Jul 3, 2008Aug 14, 2012International Business Machines CorporationPolicy application rules for automated configuration of software componentsUS20100005451 *Jul 3, 2008Jan 7, 2010International Business Machines CorporationPolicy application rules for automated configuration of software componentsUS20100083244 *Sep 26, 2008Apr 1, 2010Nokia CorporationMethods, apparatuses, and computer program products for repurposing computing devicesUS20140003451 *Dec 18, 2012Jan 2, 2014Mahesh WaghArchitected Protocol For Changing Link Operating Mode* Cited by examinerClassifications U.S. Classification709/221, 717/121, 713/100International ClassificationG06F15/177, H04W8/24Cooperative ClassificationH04W8/245European ClassificationH04W8/24NLegal EventsDateCodeEventDescriptionJun 17, 2014FPExpired due to failure to pay maintenance feeEffective date: 20140427Apr 27, 2014LAPSLapse for failure to pay maintenance feesDec 6, 2013REMIMaintenance fee reminder mailedJun 24, 2003ASAssignmentOwner name: SURREY, UNIVERSITY OF, UNITED KINGDOMFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:TAFAZOLLI, RAHIM;MOESSNER, KLAUS;VAHID, SEIAMAK;REEL/FRAME:013755/0926;SIGNING DATES FROM 20030605 TO 20030616Owner name: SURREY, UNIVERSITY OF,UNITED KINGDOMFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:TAFAZOLLI, RAHIM;MOESSNER, KLAUS;VAHID, SEIAMAK;SIGNED BETWEEN 20030605 AND 20030616;US-ASSIGNMENT DATABASE UPDATED:20100427;REEL/FRAME:13755/926Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:TAFAZOLLI, RAHIM;MOESSNER, KLAUS;VAHID, SEIAMAK;SIGNING DATES FROM 20030605 TO 20030616;REEL/FRAME:013755/0926RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services