Sign In to Follow Application
View All Documents & Correspondence

“Reconfiguration System And Method Of Reconfiguration Thereof”

Abstract: ABSTRACT RECONFIGURATION SYSTEM AND METHOD OF RECONFIGURATION THEREOF Conventionally, fault tolerance in 1553B communication systems involves multi-level nested condition checks for numerous parameters, making reconfiguration time-consuming, complex and less maintainable. Altering these parameters is difficult and error prone. A reconfiguration method according to the present invention includes creation and update of data records (109 and 113) including statuses of fault tolerance parameters by the first and second systems (104 and 106) in their memories (108 and 112) respectively. The first and second systems (104 and 106) initialize timer and communication threads. The first system (104) schedules messages for the RTs (102). The second system (106) monitors BC-RT communication. The first and second systems (104 and 106) monitor the fault tolerance parameters and update the statuses in their data records (109 and 113), which is checked against predefined values to initiate reconfiguration. The method simplifies initiation of reconfiguration, reduces development effort, improves maintainability and reliability of the communication system. Ref. Fig.: Figure 1

Get Free WhatsApp Updates!
Notices, Deadlines & Correspondence

Patent Information

Application #
Filing Date
24 March 2020
Publication Number
40/2021
Publication Type
INA
Invention Field
ELECTRICAL
Status
Email
info@krishnaandsaurastri.com
Parent Application
Patent Number
Legal Status
Grant Date
2024-01-16
Renewal Date

Applicants

BHARAT ELECTRONICS LIMITED
OUTER RING ROAD, NAGAVARA, BANGALORE

Inventors

1. Chinta Rajalakshmi
BEL Software Technology Centre (BSTC) Bharat Electronics Limited, Jalahalli, Bangalore-560013
2. Sridevi S
BEL Software Technology Centre (BSTC) Bharat Electronics Limited, Jalahalli, Bangalore- 560013

Specification

DESC:FORM 2
THE PATENTS ACT, 1970
(39 OF 1970)
&
THE PATENTS RULES, 2003

COMPLETE SPECIFICATION
[SEE SECTION 10, RULE 13]

RECONFIGURATION SYSTEM AND
METHOD OF RECONFIGURATION THEREOF

BHARAT ELECTRONICS LIMITED
WITH ADDRESS:
OUTER RING ROAD, NAGAVARA, BANGALORE 560045, INDIA

THE FOLLOWING SPECIFICATION PARTICULARLY DESCRIBES THE INVENTION AND THE MANNER IN WHICH IT IS TO BE PERFORMED.
FIELD OF INVENTION
[0001] The present disclosure relates generally to fault tolerance systems and particularly to reconfiguration of Bus Monitor (BM) and Bus Controller (BC).

BACKGROUND
[0002] A multiplex data bus system as per MIL-STD-1553 or MIL-STD-1553B protocols includes a Bus Controller (BC) and a plurality of Remote Terminals (RTs) interconnected by a data bus providing a single data path between the BC and all the RTs. There may be one or more Bus Monitor (BM), connected on the data bus to only capture the data for analysis and cannot initiate any data transfer. The BC controls the data transfer on the data bus. In system to be fault tolerant where redundancy is catered on event of failure of the BC, the BM must take over the control of the data transfer over the data bus to ensure system availability.
[0003] Fault Tolerance in 1553B interface in real time systems involves consideration of numerous statuses to initiate timely reconfiguration of the BC and BM. This requires multi-level nested condition checks at multiple interface points, making the reconfiguration process time-consuming, complex, error prone and less maintainable.
[0004] In a widely used technique, a nested loop is used to identify the failure conditions for reconfiguration. In the nested loop technique, the reconfiguration is initiated for the BC and BM based on statuses of a set of parameters including scheduling statuses of the BC, communication statuses of the BC with the RTs, and scheduling/communication status of BC with RTs observed by BM and status of links between the redundant systems (also referred to as “Inter Processor Link (IPL)”). These statuses are checked in combinations in nested loops to identify the need for reconfiguration. This approach is cumbersome, time consuming, and error prone as independent variables are used for storing the statuses of the above said parameters. Further, altering the parameters considered for reconfiguration is difficult and more error prone in the nested loop technique of reconfiguration.
[0005] A conventional technique disclosed in Indian patent application no. 743/DEL/2014 relates to storage systems and, more specifically, to high performance and availability of data in a cluster of storage systems. However, it does not relate to reconfiguration of 1553B devices in real-time systems. In this technique, reconfiguration is initiated using meta data stored in a Non-volatile Random Access Memory (NVRAM) of partner node.
[0006] A conventional technique disclosed in Indian patent application no. 201641038583 relates to security in electronic devices. However, it does not relate to reconfiguration of 1553B devices in real-time systems. In this technique, reconfiguration is with respect to permission on application / electronic device based on the type of gesture performed by the user.
[0007] A conventional technique disclosed in Indian patent application no. 4303/DELNP/2006 relates to networked file servers and more particularly to the takeover by one file server of another panicking or failed file server in a cluster of networked file servers. However, it does not relate to reconfiguration of 1553B devices. In this technique, reconfiguration is based on several "failover" functions including a failover monitor in each filer and a cluster interconnect between filers that provides a communication pathway in the event of a panic or failure.
[0008] A conventional technique disclosed in Indian patent application no. 201947023141 relates to reconfiguration for wireless communication and is not related to reconfiguration of 1553B devices. In the technique, reconfiguration is based on command and response between one configuration device to another.
[0009] There is still a need for an efficient system and method for reconfiguration of the BC and BM in real time systems.

SUMMARY
[0010] This summary is provided to introduce concepts related to a reconfiguration system and a method for reconfiguration of nodes in a communication network. This summary is neither intended to identify essential features of the present invention nor is it intended for use in determining or limiting the scope of the present invention.
[0011] In an embodiment of the present invention, a method for reconfiguration in a communication network is provided. The method is performed by a first system and a second system in the communication network. The method includes updating and storing a data record in a memory. The data record has a plurality of status values corresponding to a plurality of fault tolerance parameters of the communication network. A timer thread and a communication thread are initialized. The first and second systems monitor one or more fault tolerance parameters of the communication network. The first and second systems update the status values in the data record. The first and second systems execute a reconfiguration routine based on the value of the data record that matches with predefined failure cases from either of the timer or communication threads.
[0012] In an embodiment of the present invention, a reconfiguration system in a communication network is provided. The reconfiguration system includes a plurality of Remote Terminals (RTs), a first system, and a second system. The first system includes a memory and a processor. The second system includes a memory and a processor. The memories store a data record having a plurality of status values corresponding to a plurality of fault tolerance parameters of the communication network. The processors initialize a timer thread and a communication thread. The processors monitor one or more fault tolerance parameters of the communication network. The processors update the status values of the fault tolerance parameters in the data record. The processors execute a reconfiguration routine based on the value of the data record that matches with predefined failure cases from either of the timer or communication threads.
[0013] In an exemplary embodiment, the first system is a Bus Controller (BC). The first system schedules a plurality of messages for one or more RTs. After executing the reconfiguration routine, the first system isolates itself from the communication network.
[0014] In an exemplary embodiment, the second system is a Bus Monitor (BM). The second system monitors the messages communicated between the first system and the RTs. The second system reconfigures as the BC on failure of the first system and continues scheduling of the messages to the RTs in the communication network.
[0015] In an exemplary embodiment, the data record includes a bit-weighted value of the fault tolerance parameters of the communication network. The bit weighted value has values within a predefined set of values indicating failure and non-failure cases of the communication network.
[0016] In an exemplary embodiment, the bit weighted values are customizable based on requirements of number of fault tolerance parameters and types of fault tolerance parameters. The customization is by alteration in only two places of the bit weighted value. This enhances maintainability.
[0017] In an exemplary embodiment, updating the status values in the data record includes alteration in one or more bits of the bit-weighted value based on current statuses of the fault tolerance parameters of the communication network.

BRIEF DESCRIPTION OF ACCOMPANYING DRAWINGS
[0018] The detailed description is described with reference to the accompanying figures.
[0019] Figure 1 illustrates a schematic block diagram of a reconfiguration system in accordance with an embodiment of the present invention.
[0020] Figure 2 illustrates a schematic logic diagram of a Bus Controller (BC) and a Bus Monitor (BM) in accordance with an embodiment of the present invention.
[0021] Figures 3-4 illustrate a flowchart of a method for reconfiguration of BC and BM in accordance with an embodiment of the present invention.
[0022] Figure 5 illustrates a format of a data record in accordance with an embodiment of the present invention.
[0023] Figures 6-7 illustrate exemplary bit weighted values for exemplary reconfiguration cases in accordance with an embodiment of the present invention.
[0024] Figure 8 illustrates a flowchart of a reconfiguration method in accordance with an embodiment of the present invention.
[0025] It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative systems embodying the principles of the present invention.
[0026] Similarly, it will be appreciated that any flow chart, flow diagram, and the like represent various processes which may be substantially represented in computer readable medium and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.

DETAILED DESCRIPTION
[0027] The various embodiments of the present invention provide a reconfiguration system and a method for reconfiguration of 1553 nodes in a communication network.
[0028] In the following description, for purpose of explanation, specific details are set forth in order to provide an understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these details.
[0029] One skilled in the art will recognize that embodiments of the present invention, some of which are described below, may be incorporated into a number of systems.
[0030] However, the systems and methods are not limited to the specific embodiments described herein. Further, structures and devices shown in the figures are illustrative of exemplary embodiments of the present invention and are meant to avoid obscuring of the present invention.
[0031] Furthermore, connections between components and/or modules within the figures are not intended to be limited to direct connections. Rather, these components and modules may be modified, re-formatted or otherwise changed by intermediary components and modules.
[0032] The appearances of the phrase “in an embodiment” in various places in the specification are not necessarily all referring to the same embodiment.
[0033] The present invention provides a reconfiguration system and a method for reconfiguration of systems in a communication network. The communication system is a 1553 multiplex data bus system as per MIL-STD-1553 or MIL-STD-1553B protocols. The communication system includes one or more remote terminals (RTs), a Bus Controller (BC), and a Bus Monitor (BM). In the event of failure of BC, the BM must reconfigure itself to function as a BC and the failed BC must isolate itself from the communication system. The need for reconfiguration arises when one or more faults develop in the communication system. These faults are detected based on one or more fault tolerance parameters of the communication network.
[0034] In the present method of reconfiguration, the BC and BM each store data records. The data records include status values indicative of the fault tolerance parameters. The BC initializes a timer thread and a communication thread. Similar such threads are initialized by the BM as well. The BC schedules messages to the RTs. The communication thread updates the status in data store. Upon receiving a timer trigger for update, the BC updates the status values. Similarly, the BM also updates its status values upon receiving the update timer trigger. Upon receiving the timer trigger for checking reconfiguration condition, the BC and BM compare the values of their data records with the predefined data record values to determine whether there is a fault in the system. The BC and/or BM execute a reconfiguration routine based on the detected fault(s).
[0035] Advantageously, the present method avoids the multilevel nested loops and multiple nested condition checks between the BC and BM. The method provides isolation of the BC based on the bit weighted value instead of the multilevel nested loops. The present method provides node reconfiguration or system takeover in less than 300 milliseconds, for real-time systems having 50msec or lesser periodic 1553B communication.
[0036] The present method also supports alteration of fault tolerance parameters considered for reconfiguration, by alteration of a single bit weighted data record instead of having multiple variables, thereby enhancing the maintainability. The present method also enhances fault tolerance of the communication system, as interlocks are converted into values and chances of missing out conditions, as in nested loop approach, are eliminated.
[0037] Referring now to Figure 1, a reconfiguration system (100) is illustrated in accordance with an embodiment of the present invention. The reconfiguration system (100) includes a plurality of Remote Terminals (RTs), a maximum of 32, (102a - 102n), a first system (104) functioning as a Bus Controller (BC), and a second system (106) functioning as a Bus Monitor (BM), both first and second systems (104 and 106) interconnected by a bus. The first system (104) includes a memory (108), a processor (110), and the BC (111). The second system (106) includes a memory (112), a processor (114), and the BM (115). The memory (108) is configured to store a data record (109) of the first system (104). The memory (112) is configured to store a data record (113) of the second system (106). The first system (104) and the second system (106) are within a communication network. The communication network operates on MIL-STD-1553 or MIL-STD-1553B protocols.
[0038] Figure 2 illustrates a schematic logic diagram of the first system (104) and the second system (106) in accordance with an embodiment of the present invention. The first system (104) includes an application module, a Fault Tolerance (FT) module, device drivers for MIL-1553 and ethernet, a real-time operating system, and hardware. The structure of the second system (106) is similar to the structure of the first system (104) as shown in Figure 2.
[0039] The method of reconfiguration of the first system (104) and the second system (106) uses bit-weighted values. In that, the first system (104) and the second system (106) generate a bit weighted value each including statuses of communication or message scheduling of the second system (106) and the first system (104), link statuses of the second system (106) and the first system (104) with RTs (102a – 102n), observed link statuses of BC (111) and RTs (102) by BM (115), Inter Processor Link (IPL) status between the first and second systems (104 and 106), and other fault tolerance parameters. The present reconfiguration method uses system or auxiliary clock trigger and bit weighted values for reconfiguration of the second system (106) and the first system (104). The method facilitates reconfiguration of the second system (106) to the first system (104) based on a bit weighted value instead of multilevel nested condition checks. It also facilitates isolation of the first system (104) based on the bit weighted value instead of the multilevel nested condition checks. The method ensures that there is a single BC on the 1553B network.
[0040] The method uses a thread or a task as monitoring thread or monitoring task. After initialization and enabling of clock, an Interrupt Service Routine (ISR), also called as interrupt handler which is executed by the processors (110 and 114) of the first system (104) and second system (106) respectively, updates trigger time based on timer tick received from the clock, checks if it matches the monitoring time and suitably sends trigger to the monitoring thread. The method includes generating a data record or a bit weighted status variable to hold the statuses of the fault tolerance parameters. Thereafter, the method includes initializing the 1553B devices. Thereafter, the message queues for the 1553B interface handling and monitoring threads are created. The software mission clock resolution and monitoring trigger time is set. The 1553B interface handling and monitoring threads are spawned. The 1553B messages are scheduled. The scheduling status of the BC and BM is set in the data records of the respective systems (104 and 106). Thereafter, the first system (104) and the second system (106) wait for the monitoring timer trigger. The first system (104) and the second system (106) monitor the communication over BC-RT, BM-RT and IPL and update in the data record. Thereafter, the first system (104) and the second system (106) handle the timer trigger in the monitoring thread and check the bit weighted value to initiate reconfiguration as applicable. Thus, the value-based reconfiguration simplifies the condition check and facilitates timely initiation of reconfiguration to ensure high system availability. The present method supports for reconfiguration of the first and/or second systems (104 and 106). Also, format of the data records may be modified based on the needs of the application. The data records may also be modified to include different number of statuses and different types of statuses.
[0041] Figures 3-4 illustrate a method for reconfiguration of the first system (104) and the second system (106) in accordance with an embodiment of the present invention.
[0042] At step 302, the first system (104) and the second system (106) generate respective data records (also referred to as “data stores”) having bits to hold the status values of various fault tolerance parameters of the communication network.
[0043] At step 304, the first system (104) and the second system (106) create modules/threads for handling timer trigger.
[0044] At step 306, the first system (104) initializes the RTs (102a – 102n) the communication and timer threads.
[0045] At step 308, the first system (104) schedules messages for the RTs (102a – 102n). The second system (106) monitors the BC-RT communication. Both, the first system (104) and the second system (106) wait for the monitoring timer trigger to update the data records (109 and 113) and check for reconfiguration conditions.
[0046] At step 310, the first system (104) and the second system (106) generate the bit weighted value each including statuses of communication the BC (111) and the BM (115), link statuses of the BC with RTs (102a – 102n), observed link statuses of BC and RTs by BM, IPL status between the first and second systems (104 and 106), and other fault tolerance parameters.
[0047] At step 312, the first system (104) and the second system (106) handle the timer trigger in the monitoring thread and check the data records.
[0048] At step 314, the first system (104) and the second system (106) match the read data record value with one or more predefined data record values to determine whether there is a need for reconfiguration.
[0049] If at step 314, a need for reconfiguration is determined, step 316 is executed.
[0050] At step 316, the reconfiguration of the first system (104) and/or the second system (106) is initiated.
[0051] The step 306 of initialization for communication and reconfiguration is further illustrated in Figure 4.
[0052] At step 402, the first system (104) creates message queues for communication and monitoring threads.
[0053] At step 404, the first system (104) initializes the BC (111).
[0054] At step 406, the first system (104) sets software mission clock resolution.
[0055] At step 408, the first system (104) initializes and enables software mission clocks.
[0056] At step 410, the first system (104) spawns the communication and monitoring threads.
[0057] After step 408, the first system (104) periodically performs step 412.
[0058] At step 412, the first system (104) sends timer tick to event handler.
[0059] The steps shown in Fig 4 are executed by the second system (106) also. Figure 5 illustrates a format of a data record in accordance with an embodiment of the present invention.
[0060] The format of the data records may be modified based on the needs of the application. The data records may also be modified to include different number of fault tolerance parameters of the communication network.
[0061] Figures 6-7 illustrate exemplary bit weighted values for exemplary reconfiguration cases in accordance with an embodiment of the present invention.
[0062] Referring now to Figure 6, a first exemplary bit weighted value for a first reconfiguration case is shown in accordance with an implementation of the present disclosure. In Figure 6, the bit weighted value 27 indicates that the communication status of the first system (104) and the second system (106) are OK, IPL status is OK, BM-RT link status is OK, but BC-RT link status is NOTOK. The bit wise split-up of value 27 is shown in Figure 6. The first reconfiguration condition clearly indicates that link between the first system (104) and RT (102) is failed and the second system (106) needs to take over as the first system (104) to continue operations of system. Thus, the check for reconfiguration is simplified by a single value check thereby providing faster implementation.
[0063] Referring now to Figure 7, a second exemplary bit weighted value for a second reconfiguration case is shown in accordance with an implementation of the present disclosure. In Figure 7, the bit weighted value 30 indicates that the communication status of the first system (104) and the second system (106) are OK, BM-RT link status is OK, BC-RT link status is OK, but IPL link status is NOTOK. The bit wise split-up of value 30 is shown in Figure 7. The second reconfiguration condition clearly indicates that communication among the first system (104), the second system (106) and the RT (102) are fine on 1553B network. As failure of IPL link does not impact communication over 1553B network, the reconfiguration need not be initiated.
[0064] Figure 8 illustrates a flowchart of a reconfiguration method in accordance with an embodiment of the present invention.
[0065] At step 802, the data record (109) is stored in the memory (108) of the first system (104). The data record (109) holds the status values corresponding to the fault tolerance parameters of the communication network The same is done by the second system (106).
[0066] At step 804, the first system (104) initializes the timer thread and the communication thread. The same is done by the second system (106).
[0067] At step 806, the first system (104) schedules the messages for the RTs (102a – 102n). The second system (106) monitors the communication between BC (111) and RTs (102).
[0068] At step 808, the first system (104) monitors the fault tolerance parameters. The same is done by the second system (106).
[0069] At step 810, the first system (104) updates the status values in the data record (109). The same is done by the second system (106).
[0070] At step 812, the first system (104) executes the reconfiguration routine based on the value of the data record (109). The same is done by the second system (106).
[0071] Advantageously, the method for reconfiguration of the BC and BM can be implemented for any processor-based system in any domain. The method, typically, may be implemented by the same processor-based system. In the method, the FT parameters considered for reconfiguration may be customized, by alteration in only one or more places, bit weighted value definition and bit weighted value update, enhancing the maintainability. The method enhances reliability of the FT module as interlocks are converted into values, thereby eliminating the chances of missing out conditions, as in the nested loop approach. The method simplifies initiation of reconfiguration using a bit weighted value instead of nested condition checks, thereby reducing development effort, improving code maintainability and software reliability. The value-based reconfiguration simplifies the condition check and timely initiation of reconfiguration to ensure high system availability.
[0072] The foregoing description of the invention has been set merely to illustrate the invention and is not intended to be limiting. Since modifications of the disclosed embodiments incorporating the spirit and substance of the invention may occur to person skilled in the art, the invention should be construed to include everything within the scope of the invention.
,CLAIMS:We Claim:
1. A method of reconfiguration in a communication network, said method performed by a first system and a second system, and said method comprising:
updating and storing a data record in a memory, said data record having a plurality of status values corresponding to a plurality of fault tolerance parameters of the communication network;
initializing a timer thread and a communication thread;
monitoring one or more fault tolerance parameters of the communication network;
updating the status values in the data record; and
executing a reconfiguration routine based on the value of the data record that matches with predefined failure cases from either of the timer or communication threads

2. The method as claimed in claim 1, wherein the first system is a Bus Controller (BC), and wherein the method comprises:
scheduling, by the first system, a plurality of messages for one or more Remote Terminals (RTs); and
after executing the reconfiguration routine, isolating, by the first system, itself from the communication network.

3. The method as claimed in claim 2, wherein the second system is a Bus Monitor (BM), and wherein the method comprises:
monitoring, by the second system, the messages communicated between the first system and the RTs; and
reconfiguring as the BC, by the second system, on failure of the first system and continuing scheduling of the messages to the RTs in the communication network.

4. The method as claimed in claim 3, wherein the data record includes a bit-weighted value of the fault tolerance parameters, said bit weighted value having values within a predefined set of values indicating failure and non-failure cases of the communication network.

5. The method as claimed in claim 4, wherein the bit weighted values are customizable based on requirements of number of the fault tolerance parameters and types of the fault tolerance parameters by alteration in only two places of the bit weighted value, thereby enhancing maintainability.

6. The method as claimed in claim 4, wherein updating the status values in the data record includes alteration in one or more bits of the bit-weighted value based on current statuses of the fault tolerance parameters of the communication network.

7. A reconfiguration system in a communication network, said reconfiguration system comprising:
a plurality of Remote Terminals (RTs); and
a first system including a memory and a processor;
a second system including a memory and a processor; wherein:
the memories are configured to store respective data records having a plurality of status values corresponding to a plurality of fault tolerance parameters of the communication network; and
the processors are configured to:
initialize a timer thread and a communication thread,
monitor one or more fault tolerance parameters of the communication network,
update the status values in the data record, and
execute a reconfiguration routine based on the value of the data record that matches with predefined failure cases from either of the timer or communication threads.

8. The system as claimed in claim 7, wherein the first system is a Bus Controller (BC) and wherein the processor of the first system is configured to:
schedule a plurality of messages for one or more RTs, and
after executing the reconfiguration routine, isolate the first system from the communication network.

9. The system as claimed in claim 7, wherein the second system is a Bus Monitor (BM) and wherein the processor of the second system is configured to:
monitor the messages communicated between the first system and the RTs; and
reconfigure on failure of the first system and continue to schedule the messages to the RTs in the communication network.

10. The system as claimed in claim 7, wherein the data record includes a bit-weighted value of the fault tolerance parameters, said bit weighted value having values within a predefined set of values indicating failure and non-failure cases of the communication network.

11. The system as claimed in claim 7, wherein the bit weighted values are customizable based on requirements of number of fault tolerance parameters and types of fault tolerance parameters.

12. The system as claimed in claim 7, wherein updating the status values in the data record includes alteration in one or more bits of the bit-weighted value based on current statuses of the fault tolerance parameters of the communication network.
Dated this 24th day of March, 2020
For BHARAT ELECTRONICS LIMITED,
By their Agent,

D. MANOJ KUMAR (IN/PA-2110)
KRISHNA & SAURASTRI ASSOCIATES LLP

Documents

Application Documents

# Name Date
1 202041012883-PROVISIONAL SPECIFICATION [24-03-2020(online)].pdf 2020-03-24
2 202041012883-FORM 1 [24-03-2020(online)].pdf 2020-03-24
3 202041012883-DRAWINGS [24-03-2020(online)].pdf 2020-03-24
4 202041012883-FORM 3 [29-05-2020(online)].pdf 2020-05-29
5 202041012883-ENDORSEMENT BY INVENTORS [29-05-2020(online)].pdf 2020-05-29
6 202041012883-DRAWING [29-05-2020(online)].pdf 2020-05-29
7 202041012883-CORRESPONDENCE-OTHERS [29-05-2020(online)].pdf 2020-05-29
8 202041012883-COMPLETE SPECIFICATION [29-05-2020(online)].pdf 2020-05-29
9 202041012883-FORM-26 [21-06-2020(online)].pdf 2020-06-21
10 202041012883-FORM-26 [24-06-2020(online)].pdf 2020-06-24
11 202041012883-Proof of Right [18-09-2020(online)].pdf 2020-09-18
12 202041012883-Correspondence_Form1_28-09-2020.pdf 2020-09-28
13 202041012883-FORM 18 [27-06-2022(online)].pdf 2022-06-27
14 202041012883-FER.pdf 2022-11-23
15 202041012883-OTHERS [23-05-2023(online)].pdf 2023-05-23
16 202041012883-FER_SER_REPLY [23-05-2023(online)].pdf 2023-05-23
17 202041012883-COMPLETE SPECIFICATION [23-05-2023(online)].pdf 2023-05-23
18 202041012883-CLAIMS [23-05-2023(online)].pdf 2023-05-23
19 202041012883-ABSTRACT [23-05-2023(online)].pdf 2023-05-23
20 202041012883-PatentCertificate16-01-2024.pdf 2024-01-16
21 202041012883-IntimationOfGrant16-01-2024.pdf 2024-01-16
22 202041012883-FORM-27 [15-09-2025(online)].pdf 2025-09-15

Search Strategy

1 SearchStrategyE_23-11-2022.pdf

ERegister / Renewals

3rd: 16 Apr 2024

From 24/03/2022 - To 24/03/2023

4th: 16 Apr 2024

From 24/03/2023 - To 24/03/2024

5th: 16 Apr 2024

From 24/03/2024 - To 24/03/2025

6th: 20 Mar 2025

From 24/03/2025 - To 24/03/2026