Indian Patents. 269657:A SYSTEM FOR PROVIDING COMMUNICATION AND FEEDBACK BETWEEN MULTIPLE COMMUNICATION LAYERS IN A NETWORK

Title of Invention	A SYSTEM FOR PROVIDING COMMUNICATION AND FEEDBACK BETWEEN MULTIPLE COMMUNICATION LAYERS IN A NETWORK
Abstract	A system for providing communication and feedback between multiple communication layers in a network having an optimization subsystem and at least one tuning layer for each layer of communication.

Full Text	FORM - 2 THE PATENTS ACT, 1970 (39 of 1970) & THE PATENTS RULES, 2003 PROVISIONAL Specification (See section 10 and rule 13) PROTOCOL STACKS (a) TATA CONSULTANCY SERVICES LIMITED an Indian Company of Bombay House, 24, Sir Homi Mody Street, Mumbai 400 001, Maharashtra, India; and (b) INDIAN INSTITUTE OF TECHNOLOGY, BOMBAY an Indian Institute of Powai, Mumbai 400 076, Maharashtra, India THE FOLLOWING SPEC IFICATION DESCRIBES THE INVENTION. This invention relates to wireless networks. Particularly, this invention relates to protocol stacks. Still particularly, this invention relates to interaction between protocol stacks and interaction between layers within a protocol stack. A protocol stack is a device or a system which enables one or more devices to communicate with one or more other devices using protocols. A protocol stack is a particular implementation of a computer networking protocol suite. The suite is the definition of the protocols, and the stack is the implementation of them. Individual protocols within a suite are often designed with a single purpose in mind. This modularization makes design and evaluation easier. Because each protocol module usually communicates with two others, they are commonly imagined as layers in a stack of protocols. The lowest protocol always deals with "low-level", physical interaction of the hardware. Every higher layer adds more features. User applications usually deal only with the topmost layers. In practical implementation, protocol stacks are often divided into three major sections, for media, transport, and applications. A particular operating system or platform will often have two well-defined interfaces: one between the media and transport layers, and one between the transport layers and applications. 2 The media-to-transport interface defines how transport protocol makes use of particular media and hardware types ("card drivers"). For example, this interface level would define how TCP/IP transport would talk to Ethernet hardware. The application-to-transport interface defines how applications make use of the transport layers. For example, this interface level would define how a web browser program would talk to TCP/IP transport. Examples of these interfaces include Berkeley sockets and System V streams in the Unix world, and Winsock in the Microsoft world. General protocol suite description: [A] [B] [C] Imagine three computers: A, B, and C. A and B both have radio equipment, and can communicate via the airwaves using a suitable network protocol (like IEEE 802.11). B and C are connected via a cable, using it to exchange data (again, with the help of a protocol, for example Ethernet). However, neither of these two protocols will be able to transport information from A to C, because these computers are conceptually on different networks. One, therefore, needs an inter-network protocol to "connect" them. One could combine the two protocols to form a powerful third, mastering both cable and wireless transmission, but a different super-protocol would be needed for each possible combination of protocols. It is easier to leave the base protocols alone, and design a protocol that can work on top of any of them (the Internet Protocol is an example.) This will make two stacks of two protocols each. The inter-network protocol will communicate with each of the 3 base protocol in their simpler language; the base protocols will not talk directly to each other. A request on computer A to send a chunk of data to C is taken by the upper protocol, which (through whatever means) knows that C is reachable through B. It therefore instructs the wireless protocol to transmit the data packet to B. On this computer, the lower layer handlers will pass the packet up to the internetwork protocol, which, on recognizing that B is not the final destination, will again invoke lower-level functions. This time, the cable protocol is used to send the data to C. There, the received packet is again passed to the upper protocol, which (with C being the destination) will pass it on to a higher protocol or application on C. Often an even higher-level protocol will sit on top, and incur further processing. A commonly used protocol stack looks like this: \| HTTP \| I TCP \| I IP I I Ethernet \| A protocol's implementation in an operating system [such as Linux] consists of a set of protocol procedures and data structures. A protocol's data structures have two major components - control data structures and data (or protocol 4 data unit) data structures. The control data structures determine the behavior of a protocol. For example, control data structures are used for implementing the state machine of a protocol. Some examples of control data structures are: timers controlling behavior of MobilelP, retransmit timer in TCP, and fragmentation threshold in 802.11 (IEEE Wireless Local Area Network standard). Using TCP as an example, and the linux operating system, it is seen that TCP's protocol data structures are implemented in specific files. These data structures are accessed by procedures implemented in another set of files. There are several important control data structures for TCP, for instance tcp_opt. Various fields occur in tcpopt and TCP procedures read and write to these fields during execution. The values in these and other fields determine TCP behavior during execution. For example, TCP retransmits packets when the retransmission timeout timer expires. The value in some of these fields is used for setting for instance, TCP's retransmission time out. The values in the control data structures of various layers can be changed to modify the behavior the protocols. Applications using traditional protocol stacks (for example, TCP/IP) from wired networks do not function efficiently in mobile wireless scenarios. This is primarily due to the layered architecture and implementation of protocol stacks. One of the mechanisms of improving the performance of these stacks in wireless networks is Cross layer feedback. For example, transport layer 5 retransmissions can be reduced by making it aware of network disconnections or hand-off events. Related cross layer applications are US Patents: 6999432 [Zhang, et al]; 6816471 [Ludwig, et al]; 6798764 [Jiang]; 6463035 [Moore]; 5566225 [Haas]; 5115432 [Haas]; WO 03/028228 [Vanderschaar, et al]; UK 2418566 [Dodgson, Sdralia] However, since the protocol stack is an integral part of the operating system, any cross layer modification to the stack should not have an impact on its correctness, efficiency and maintainability. Therefore one of the desired objects in the art is that a modification in the architecture of the protocol stack must satisfy the aforesaid criteria. The device/system of this invention manipulates control data structures of the various protocols to change their behavior. A principal object of this invention is to provide a system within or cooperating with a protocol stack which enables inter action between protocol stacks and between layers within a protocol stack without disturbing the integrity of the stack and without having any impact on its correctness, efficiency and maintainability. Another object of this invention is to provide a cross layer feedback mechanism in protocol stacks which is efficient, in that it ensures minimum execution overheads. 6 Yet another object of the invention is to provide a cross layer feedback mechanism in protocol stacks which has minimum intrusion, in that it ensures minimum changes to the existing stack. Still another object of the invention is to provide a cross layer feedback mechanism in protocol stacks which permits rapid prototyping, in that it enables easy deployment of new cross layer feedback optimizations. Another object of the invention is to provide a cross layer feedback mechanism in protocol stacks which has portability, in that it enables porting to multiple operating systems with minimum changes. Still one more object of the invention is to provide a cross layer feedback mechanism in protocol stacks which permits any to any layer communication, thereby to allow communication between a layer and any other layer in the stack. The device/system of the present invention satisfies each one of the aforesaid objects, singularly and jointly in a synergistic manner. According to this invention there is provided a system/device for enabling interaction between various layers of a protocol stack, comprising a. Tuning Layers for each layer in the protocol stack, and b. Optimizing subsystem for effecting changes to the protocols through cross layer means. Typically, the Tuning Layer manipulates the control data structures of the protocols. 7 BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING The invention will now be described with reference to the accompanying drawings, in which Figure 1: Cross layer architecture overview in accordance with this invention Figure 2: Cross layer architecture details in accordance with this invention Figure 3: Types of cross layer feedback Figure 4: Cross layer architecture with core. Referring to the drawings, the system in accordance with this invention, provides one Tuning Layer (TL) for each layer of the stack (Figure 1). The TLs do not interact with each other directly. A TL provides an interface to a protocol's control data structures. TLs are used by the Optimizing Subsystem (OSS). A TL monitors a protocol's control data structures for the current state of the protocol. The TL is aware of the implementation details (control data structures) of a protocol's data structures. The OSS uses TLs to manipulate protocol behavior by effecting changes to the protocol's accessible control data structures. The Tuning Layers for a typical protocol stack are: Physical Tuning Layer, MAC Tuning Layer, Network Tuning Layer, Transport Tuning Layer and Application Tuning Layer. A User Tuning Layer is also provided for allowing user interaction with the protocol stack. Each TL contains appropriate components for each protocol within the layer. For example, MAC TL contains 802.11 TL for 802.11 and GPRS TL for GPRS. Similarly, Network TL contains IP and Mobile-IP TL; Transport TL contains TCPTL, UDPTL, etc; Application TL contains application specific TLs. 8 Each TL is subdivided into a generic and implementation specific sublayer as particularly seen in figure 2 of the accompanying drawings. This is useful, since the implementation of protocols is different across different operating systems, even though they conform to the protocol standards. For example, the TCP data structure names are different in NetBSD and Linux. The OSS uses the generic API of TLs. The generic interface invokes the implementation specific API for a particular OS. The OSS determines the cross layer optimizations as particularly seen in figure 2 of the accompanying drawings. The OSS contains many protocol optimizers (POs). A PO contains the algorithms and data structures for a specific cross layer optimization. A PO registers with a TL for event information from a particular protocol layer. In figure 2 this registration is depicted as a dashed line with hollow arrow head. The PO's procedure determines the cross layer optimizing action. The PO invokes the appropriate TL's generic API for modifying the control data structure, and consequently the behavior, of the target protocol. Figure 1 depicts this optimizing action by a solid line with a solid arrow head. An ellipsis next to a TL (example, UDPTL) represents additional TLs at a layer. An ellipsis within the OSS represents additional POs. Figure 3 shows various types of cross layer feedback. The adaptation at a layer, when it receives cross layer feedback, may be synchronous i.e. embedded within the protocol's algorithm, or asynchronous i.e. executed in parallel to the protocol's execution. Further, the adaptation may be required for (a) each packet i.e. protocol adapts behavior for each packet, (b) per flow i.e. separate adaptation is done for each established connection, or (c) across flows 9 i.e. common adaptation is done for all the established connections. This defines the granularity of adaptation. Per packet is the finest granularity while across flows is the coarsest. Hence, per packet adaptation can be used for per flow or across flows adaptation also. However, per flow or across flows adaptation cannot be used for per packet adaptation. In accordance with a preferred embodiment of this invention, the ideal architecture is asynchronous and should not enforce per packet adaptation. This is because per packet adaptation or synchronous adaptation would lead to decreased stack performance. The system in accordance with this invention is particularly suited for asynchronous type of cross layer feedback, since its components are not embedded within the protocol layers. However, the system in accordance with this invention is not restricted from being used for synchronous cross layer feedback. In accordance with another aspect of the invention, any cross layer mechanism will impose execution overheads on the protocol stack. Therefore it is envisaged that the system of this invention has a Core to reduce these overheads as seen in figure 4 of the accompanying drawings. The Core is a set of cross layer data items (or information at a layer) that offers the maximum gains, as compared to other data items, if used for cross layer feedback. There are multiple data items (information at a layer) which could be useful for cross layer feedback. Data items, which provide higher performance improvement as compared to other data items, are termed as critical data items. In accordance with yet another aspect of this invention there is provided a sub-architecture, in which the set of critical data items is partitioned into two sub- 10 sets. One of these subsets is termed as core. The partitioning is based on the cost for cross layer feedback of a data item. This cost could be the power required for reading a data item from another layer and the power required to make a data item available to other layers. A data item is placed in core if the cost of cross layer feedback for the data item is lower when it is placed in the core. The sub-architecture would aid in further increasing the benefit achieved through cross layer feedback, by decreasing the cost of cross layer feedback of the core items. The performance improvement or utility provided by a data item can be estimated by the frequency of its use by the various layers. This is based on the concept that items which are accessed frequently must be items which offer higher performance improvement. Means are provided within the ambit and scope of the invention for determining the core of the cross layer architecture and the useful cross layer data items are determined. It should be understood that the programs, processes, methods and systems described herein are not related or limited to any particular type of computer or network system (hardware or software), unless indicated otherwise. Various types of general purpose or specialized computer systems may be used with or perform operations in accordance with the teachings described herein. In view of the wide variety of embodiments to which the principles of the present invention can be applied, it should be understood that the illustrated embodiments are exemplary only. The illustrated embodiments should not be taken as limiting the scope of the present invention. For example, the interactions between the components may be taken in sequences other than 11 those described, and more or fewer elements may be used in the block diagrams. While various elements of the preferred embodiments have been described as being implemented in software, in other embodiments hardware or firmware implementations may alternatively be used, and vice-versa. Dated this 22nd day of December, 2006. MOHAN DEWAN OF R.K.DEWAN & COMPANY APPLICANTS' PATENT ATTORNEY 12

Full Text

FORM - 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003
PROVISIONAL
Specification
(See section 10 and rule 13)

PROTOCOL STACKS
(a) TATA CONSULTANCY SERVICES LIMITED
an Indian Company
of Bombay House, 24, Sir Homi Mody Street, Mumbai 400 001,
Maharashtra, India; and
(b) INDIAN INSTITUTE OF TECHNOLOGY, BOMBAY
an Indian Institute of Powai, Mumbai 400 076, Maharashtra, India
THE FOLLOWING SPEC IFICATION DESCRIBES THE INVENTION.

This invention relates to wireless networks. Particularly, this invention relates to protocol stacks.
Still particularly, this invention relates to interaction between protocol stacks and interaction between layers within a protocol stack.
A protocol stack is a device or a system which enables one or more devices to communicate with one or more other devices using protocols.
A protocol stack is a particular implementation of a computer networking protocol suite. The suite is the definition of the protocols, and the stack is the implementation of them.
Individual protocols within a suite are often designed with a single purpose in mind. This modularization makes design and evaluation easier. Because each protocol module usually communicates with two others, they are commonly imagined as layers in a stack of protocols. The lowest protocol always deals with "low-level", physical interaction of the hardware. Every higher layer adds more features. User applications usually deal only with the topmost layers.
In practical implementation, protocol stacks are often divided into three major sections, for media, transport, and applications. A particular operating system or platform will often have two well-defined interfaces: one between the media and transport layers, and one between the transport layers and applications.
2

The media-to-transport interface defines how transport protocol makes use of particular media and hardware types ("card drivers"). For example, this interface level would define how TCP/IP transport would talk to Ethernet hardware.
The application-to-transport interface defines how applications make use of the transport layers. For example, this interface level would define how a web browser program would talk to TCP/IP transport. Examples of these interfaces include Berkeley sockets and System V streams in the Unix world, and Winsock in the Microsoft world.
General protocol suite description:
[A] [B] [C]
Imagine three computers: A, B, and C. A and B both have radio equipment, and can communicate via the airwaves using a suitable network protocol (like IEEE 802.11). B and C are connected via a cable, using it to exchange data (again, with the help of a protocol, for example Ethernet). However, neither of these two protocols will be able to transport information from A to C, because these computers are conceptually on different networks. One, therefore, needs an inter-network protocol to "connect" them.
One could combine the two protocols to form a powerful third, mastering both cable and wireless transmission, but a different super-protocol would be needed for each possible combination of protocols. It is easier to leave the base protocols alone, and design a protocol that can work on top of any of them (the Internet Protocol is an example.) This will make two stacks of two protocols each. The inter-network protocol will communicate with each of the
3

base protocol in their simpler language; the base protocols will not talk directly to each other.
A request on computer A to send a chunk of data to C is taken by the upper protocol, which (through whatever means) knows that C is reachable through B. It therefore instructs the wireless protocol to transmit the data packet to B. On this computer, the lower layer handlers will pass the packet up to the internetwork protocol, which, on recognizing that B is not the final destination, will again invoke lower-level functions. This time, the cable protocol is used to send the data to C. There, the received packet is again passed to the upper protocol, which (with C being the destination) will pass it on to a higher protocol or application on C. Often an even higher-level protocol will sit on top, and incur further processing.
A commonly used protocol stack looks like this:
| HTTP |
I TCP |
I IP I
I Ethernet |
A protocol's implementation in an operating system [such as Linux] consists of a set of protocol procedures and data structures. A protocol's data structures have two major components - control data structures and data (or protocol
4

data unit) data structures. The control data structures determine the behavior of a protocol. For example, control data structures are used for implementing the state machine of a protocol. Some examples of control data structures are: timers controlling behavior of MobilelP, retransmit timer in TCP, and fragmentation threshold in 802.11 (IEEE Wireless Local Area Network standard).
Using TCP as an example, and the linux operating system, it is seen that TCP's protocol data structures are implemented in specific files. These data structures are accessed by procedures implemented in another set of files. There are several important control data structures for TCP, for instance tcp_opt. Various fields occur in tcpopt and TCP procedures read and write to these fields during execution. The values in these and other fields determine TCP behavior during execution. For example, TCP retransmits packets when the retransmission timeout timer expires. The value in some of these fields is used for setting for instance, TCP's retransmission time out. The values in the control data structures of various layers can be changed to modify the behavior the protocols.
Applications using traditional protocol stacks (for example, TCP/IP) from wired networks do not function efficiently in mobile wireless scenarios. This is primarily due to the layered architecture and implementation of protocol stacks.
One of the mechanisms of improving the performance of these stacks in wireless networks is Cross layer feedback. For example, transport layer
5

retransmissions can be reduced by making it aware of network disconnections or hand-off events.
Related cross layer applications are US Patents: 6999432 [Zhang, et al]; 6816471 [Ludwig, et al]; 6798764 [Jiang]; 6463035 [Moore]; 5566225 [Haas]; 5115432 [Haas]; WO 03/028228 [Vanderschaar, et al]; UK 2418566 [Dodgson, Sdralia]
However, since the protocol stack is an integral part of the operating system, any cross layer modification to the stack should not have an impact on its correctness, efficiency and maintainability. Therefore one of the desired objects in the art is that a modification in the architecture of the protocol stack must satisfy the aforesaid criteria.
The device/system of this invention manipulates control data structures of the various protocols to change their behavior.
A principal object of this invention is to provide a system within or cooperating with a protocol stack which enables inter action between protocol stacks and between layers within a protocol stack without disturbing the integrity of the stack and without having any impact on its correctness, efficiency and maintainability.
Another object of this invention is to provide a cross layer feedback mechanism in protocol stacks which is efficient, in that it ensures minimum execution overheads.
6

Yet another object of the invention is to provide a cross layer feedback mechanism in protocol stacks which has minimum intrusion, in that it ensures minimum changes to the existing stack.
Still another object of the invention is to provide a cross layer feedback mechanism in protocol stacks which permits rapid prototyping, in that it enables easy deployment of new cross layer feedback optimizations.
Another object of the invention is to provide a cross layer feedback mechanism in protocol stacks which has portability, in that it enables porting to multiple operating systems with minimum changes.
Still one more object of the invention is to provide a cross layer feedback mechanism in protocol stacks which permits any to any layer communication, thereby to allow communication between a layer and any other layer in the stack.
The device/system of the present invention satisfies each one of the aforesaid objects, singularly and jointly in a synergistic manner.
According to this invention there is provided a system/device for enabling interaction between various layers of a protocol stack, comprising
a. Tuning Layers for each layer in the protocol stack, and
b. Optimizing subsystem for effecting changes to the protocols through
cross layer means.
Typically, the Tuning Layer manipulates the control data structures of the
protocols.
7

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING
The invention will now be described with reference to the accompanying
drawings, in which
Figure 1: Cross layer architecture overview in accordance with this invention
Figure 2: Cross layer architecture details in accordance with this invention
Figure 3: Types of cross layer feedback
Figure 4: Cross layer architecture with core.
Referring to the drawings, the system in accordance with this invention, provides one Tuning Layer (TL) for each layer of the stack (Figure 1). The TLs do not interact with each other directly. A TL provides an interface to a protocol's control data structures. TLs are used by the Optimizing Subsystem (OSS). A TL monitors a protocol's control data structures for the current state of the protocol. The TL is aware of the implementation details (control data structures) of a protocol's data structures. The OSS uses TLs to manipulate
protocol behavior by effecting changes to the protocol's accessible control data structures.
The Tuning Layers for a typical protocol stack are: Physical Tuning Layer, MAC Tuning Layer, Network Tuning Layer, Transport Tuning Layer and Application Tuning Layer. A User Tuning Layer is also provided for allowing user interaction with the protocol stack. Each TL contains appropriate components for each protocol within the layer. For example, MAC TL contains 802.11 TL for 802.11 and GPRS TL for GPRS. Similarly, Network TL contains IP and Mobile-IP TL; Transport TL contains TCPTL, UDPTL, etc; Application TL contains application specific TLs.
8

Each TL is subdivided into a generic and implementation specific sublayer as particularly seen in figure 2 of the accompanying drawings. This is useful, since the implementation of protocols is different across different operating systems, even though they conform to the protocol standards. For example, the TCP data structure names are different in NetBSD and Linux. The OSS uses the generic API of TLs. The generic interface invokes the implementation specific API for a particular OS.
The OSS determines the cross layer optimizations as particularly seen in figure 2 of the accompanying drawings. The OSS contains many protocol optimizers (POs). A PO contains the algorithms and data structures for a specific cross layer optimization. A PO registers with a TL for event information from a particular protocol layer. In figure 2 this registration is depicted as a dashed line with hollow arrow head. The PO's procedure determines the cross layer optimizing action. The PO invokes the appropriate TL's generic API for modifying the control data structure, and consequently the behavior, of the target protocol. Figure 1 depicts this optimizing action by a solid line with a solid arrow head. An ellipsis next to a TL (example, UDPTL) represents additional TLs at a layer. An ellipsis within the OSS represents additional POs.
Figure 3 shows various types of cross layer feedback. The adaptation at a layer, when it receives cross layer feedback, may be synchronous i.e. embedded within the protocol's algorithm, or asynchronous i.e. executed in parallel to the protocol's execution. Further, the adaptation may be required for (a) each packet i.e. protocol adapts behavior for each packet, (b) per flow i.e. separate adaptation is done for each established connection, or (c) across flows
9

i.e. common adaptation is done for all the established connections. This defines the granularity of adaptation. Per packet is the finest granularity while across flows is the coarsest. Hence, per packet adaptation can be used for per flow or across flows adaptation also. However, per flow or across flows adaptation cannot be used for per packet adaptation.
In accordance with a preferred embodiment of this invention, the ideal architecture is asynchronous and should not enforce per packet adaptation. This is because per packet adaptation or synchronous adaptation would lead to decreased stack performance. The system in accordance with this invention is particularly suited for asynchronous type of cross layer feedback, since its components are not embedded within the protocol layers. However, the system in accordance with this invention is not restricted from being used for synchronous cross layer feedback.
In accordance with another aspect of the invention, any cross layer mechanism will impose execution overheads on the protocol stack. Therefore it is envisaged that the system of this invention has a Core to reduce these overheads as seen in figure 4 of the accompanying drawings. The Core is a set of cross layer data items (or information at a layer) that offers the maximum gains, as compared to other data items, if used for cross layer feedback. There are multiple data items (information at a layer) which could be useful for cross layer feedback. Data items, which provide higher performance improvement as compared to other data items, are termed as critical data items.
In accordance with yet another aspect of this invention there is provided a sub-architecture, in which the set of critical data items is partitioned into two sub-
10

sets. One of these subsets is termed as core. The partitioning is based on the cost for cross layer feedback of a data item. This cost could be the power required for reading a data item from another layer and the power required to make a data item available to other layers. A data item is placed in core if the cost of cross layer feedback for the data item is lower when it is placed in the core. The sub-architecture would aid in further increasing the benefit achieved through cross layer feedback, by decreasing the cost of cross layer feedback of the core items. The performance improvement or utility provided by a data item can be estimated by the frequency of its use by the various layers. This is based on the concept that items which are accessed frequently must be items which offer higher performance improvement.
Means are provided within the ambit and scope of the invention for determining the core of the cross layer architecture and the useful cross layer data items are determined.
It should be understood that the programs, processes, methods and systems described herein are not related or limited to any particular type of computer or network system (hardware or software), unless indicated otherwise. Various types of general purpose or specialized computer systems may be used with or perform operations in accordance with the teachings described herein.
In view of the wide variety of embodiments to which the principles of the present invention can be applied, it should be understood that the illustrated embodiments are exemplary only. The illustrated embodiments should not be taken as limiting the scope of the present invention. For example, the interactions between the components may be taken in sequences other than
11

those described, and more or fewer elements may be used in the block diagrams. While various elements of the preferred embodiments have been described as being implemented in software, in other embodiments hardware or firmware implementations may alternatively be used, and vice-versa.
Dated this 22nd day of December, 2006.

MOHAN DEWAN
OF R.K.DEWAN & COMPANY APPLICANTS' PATENT ATTORNEY

12

Documents:

http://ipindiaonline.gov.in/patentsearch/GrantedSearch/viewdoc.aspx?id=2sKXEcfzFXffatZjJHMjdg==&loc=vsnutRQWHdTHa1EUofPtPQ==

« Previous Patent

Next Patent »

Patent Number

269657

Indian Patent Application Number

2117/MUM/2006

PG Journal Number

45/2015

Publication Date

06-Nov-2015

Grant Date

30-Oct-2015

Date of Filing

22-Dec-2006

Name of Patentee

TATA CONSULTANCY SERVICES LTD.

Applicant Address

NIRMAL BUILDING, 9TH FLOOR NARIMAN POINT, MUMBAI 400021. MAHARASHTRA, INDIA

Inventors:

#	Inventor's Name	Inventor's Address
1	RAISINGHANI VIJAY	TATA CONSULTANCY SERVICE LTD.,BOMBAY HOUSE,24, SIR HOMI MDY STREET,MUMBAI 400001,
2	IYER SRIDHAR	INDIAN INSTITUTE OF TECHNOLOGY, BOMBAY, POWAI, MUMBAI 400076

PCT International Classification Number

H04Q7/38

PCT International Application Number

N/A

PCT International Filing date

PCT Conventions:

#	PCT Application Number	Date of Convention	Priority Country
1			NA