FIELD OF THE INVENTION
[0001] The present invention relates generally, to the field of
optimizing the transfer of data chunks, and more particularly to the field of
optimizing the transfer of the data chunks pertaining to electronic data
files, between client devices interspersed in a Collaborative Work
Environment, using RF signals.
BACKGROUND
[0002] The proliferation of networks such as intranets,
extranets, and the internet has made way for newer corporate
environments based on Information & Communication Technology that
facilitate delocalized development, completion and execution of projects.
One such preferred environment is a Collaborative Work Environment
which allows persons and/ or entities to participate, contribute and develop
projects synchronously, irrespective of their geographical locations.
Person skilled in the art would appreciate that since the Collaborative
4 of 63
Work Environment is premised on the principle of synchronizing the efforts
of members working on the projects, it is highly likely that the projects
implemented in the Collaborative Work Environment may possess
developmental contingencies, that is, information and/ or data generated
by, or available with a particular professional working on a particular
project, may serve as inputs, or may have utility in accomplishing tasks
assigned to one other professional also working on that particular project.
[0003] Thus prompt and efficient sharing of files bearing
data/ information relevant to the projects (henceforth called “electronic
data files”) between client devices through which the project members
operate, is indispensable to the Collaborative Work Environment because
without it there would be no meeting of the developmental contingencies in
a timely fashion, which in turn would lead to failure to synchronize the
efforts of the professionals, and subsequent failure to execute the projects.
[0004] Various solutions have been devised and developed
to facilitate prompt and efficient transfer of the electronic data files
between the client devices in the Collaborative Work Environment. One
such preferred solution is based on the technique of data chunking which,
in the broadest sense, breaks down the electronic data files destined for
transfer into data chunks, that is, smaller fragments obtained from the
electronic data files themselves, transmits the data chunks across the
5 of 63
Collaborative Work Environment to the client devices destined to receive
them, and, reconstitutes the data chunks received at the client devices
destined to receive them, to obtain back the electronic data files.
[0005] The transferring of the data chunks across the
Collaborative Work Environment and the subsequent reconstitution to
obtain back the electronic data files, instead of transferring the entire
electronic data files between the client devices, does away with delays
and/ or lags in transfer, degradation of quality of content, distortion of
content, and such other problems. Further, the transferring of data chunks
instead of the entire electronic data files also does away with the problem
of complete failure to transfer which arises in special circumstances where
the client devices destined to receive the electronic data files have file
systems that disallow the receiving of electronic data files beyond a size
threshold. For example, the size threshold of the client devices with FAT
32 file systems is 4GB. Therefore, there would be a complete failure to
transfer the electronic data files greater than 4GB to such client devices.
[0006] While transferring the data chunks is the most suitable
way for transferring the electronic data files across the Collaborative Work
Environment, said transferring of the data chunks may bring with it a
different problem of traffic mismanagement. Person skilled in the art would
appreciate that the division of the electronic data files into the data chunks
6 of 63
drastically increases the number of items to be transferred across the
Collaborative Work Environment, which if not managed properly, may lead
to traffic congestions, misdirection of the data chunks to client devices not
destined to receive them, and/ or loss of the data chunks.
[0007] This invention, therefore, is directed to address the
aforesaid problem and offer a solution that optimizes the movement of the
data chunks between the client devices in the Collaborative Work
Environment, and particularly minimizes the traffic congestion in the
Collaborative Work Environment and prevents the data chunks from
getting lost or reaching Client devices not destined to receive them.
SUMMARY OF THE INVENTION
[0008] The present invention is intended to address at least
the above mentioned problems and/or disadvantages and to provide a
suitable solution. Accordingly, an aspect of the present invention is to
provide a system and a method for regulating transfer of data chunks
between client devices interspersed in a Collaborative Work Environment.
[0009] In accordance with an aspect of the present invention,
a system is provided to optimize the transfer of data chunks between client
7 of 63
devices interspersed in the Collaborative Work Environment using a
transfer administrator, wherein the optimization is accomplished by
performing Radio frequency (RF) signal based handshakes.
[0010] In accordance with one other aspect of the present
invention a method is provided for optimizing the transferring of data
chunks between client devices interspersed in the Collaborative Work
Environment, in conjunction with the system stated above, wherein the
optimizing is accomplished by performing Radio frequency (RF) signal
based handshaking.
[0011] Other aspects, advantages and salient features of the
invention will become apparent to those skilled in the art from the following
detailed description, which, taken in conjunction with the annexed
drawings, discloses exemplary embodiments of the invention.
BRIEF DESCRIPTION OF DRAWINGS
[0012] The above and other aspects, features and
advantages of certain exemplary embodiments of the present invention
will be more apparent from the detailed description that follows taken in
conjunction with the accompanying drawings, wherein:
8 of 63
[0013] Fig.1 illustrates a Collaborative Work Environment,
[0014] Fig. 2 illustrates a block diagram of the client device,
[0015] Fig.3 illustrates a block diagram of the RF signal generation
module,
[0016] Fig.4 illustrates an exemplary RF reference file,
[0017] Fig.5 illustrates the activities performed at the RF signal
generation module and the components therein,
[0018] Fig.6 illustrates a block diagram of the transfer
administrator,
[0019] Fig.7 illustrates the working of the RF signal interpretation
module,
[0020] Fig.8 illustrates the determination of the shortest path tree
set (sptset) in the Collaborative Work Environment,
9 of 63
[0021] Fig. 9 illustrates the calculation of time/ cost complexity
between each pair of client devices in the shortest path tree
set (sptset) having a direct path between them; and
[0022] Fig.10 illustrates the identification of the optimal path
between the Source Device and the Destination Device.
DETAILED DESCRIPTION OF THE INVENTION
[0023] Advantages and features of the present invention and
methods of accomplishing the same may be understood more readily by
referring to this detailed description of preferred embodiments and the
accompanying drawings. The present invention may, however, be
embodied in many different forms and should not be construed as being
limited to the embodiments set forth herein. Rather, these embodiments
should be considered for thorough and complete disclosure of the
invention and for fully conveying the concept of the invention to those
skilled in the art. For the sake of simplicity various aspects of the preferred
system and method embodiments are referred using numerals which refer
to the same aspects throughout the specification.
10 of 63
[0024] The terminology used herein is for the purpose of
describing particular embodiments only and is not intended to limit the
invention. As used herein, the singular forms “a”, “an” and “the” are
intended to include the plural forms as well, unless the context clearly
indicates otherwise. It will further be understood that the terms
“comprises” and/or “comprising”, when used in this specification, specify
the presence of stated features, integers, steps, operations, elements,
and/or components, but do not preclude the presence or addition of other
features, integers, steps, operations, elements, and/or components.
[0025] Various techniques and mechanisms of the present
invention will sometimes be described in singular form for clarity. Such
singular descriptions of techniques and mechanisms may however include
multiple iterations of that technique and/ or multiple instantiations of that
mechanism, respectively, unless the context suggests otherwise.
Furthermore, various techniques and mechanisms of the present invention
will sometimes describe a connection between two entities. It should be
noted that the connection between two entities does not necessarily mean
a direct, unimpeded connection, as a variety of other entities may reside
between the two entities. These entities may include without limitation,
network peripherals including routers, bridges, modems, hubs, amplifiers,
switches, repeaters or a combination thereof. Further the connection
between any two entities disclosed in the invention should not only be
11 of 63
construed as being dedicated hard wired connections, but should also
include virtual and/ or wireless connections.
[0026] It will be understood that, although the terms first,
second, third etc., may be used herein to describe some elements,
components, regions, layers and/or sections, these elements,
components, regions, layers and/or sections should not be limited by
these terms. Thus, a first element, component, region, layer and/ or
section disclosed in the description could be termed as a second element,
component, region, layer and/ or section, or vice versa, without departing
from the teachings of the present invention.
[0027] Unless otherwise defined, the terms (including
technical and scientific terms) used herein shall have the same meaning
as commonly understood by one of ordinary skill in the art. Further, the
terms defined in commonly used dictionaries should be interpreted and
construed in a manner consistent with their dictionary meaning, and
should not be interpreted in an idealized or overly formal sense unless
expressly defined.
[0028] Fig.1 to Fig.10, discussed below are non limiting illustrations
which have been used to explain and describe the invention disclosed
herein. Persons skilled in the art will appreciate that the purpose of these
12 of 63
figures is to provide clarity to the concepts associated with the various
technical embodiments of the invention and not to limit the invention.
These figures include without limitation, block diagrams, flowcharts,
schematics and/ or other simplistic representations that explain the various
aspects of the invention with ease and effectiveness.
[0029] Referring now to drawings, and first to Fig.1, a
Collaborative Work Environment is designated by the numeral 100 which
comprises Source Devices 200, that is, client devices 150 carrying the
data chunks destined for transfer, Destination Devices 300, that is, client
devices 150 intended to receive the data chunks transferred from the
Source Devices 200, and a transfer administrator 400 for facilitating the
transfer of the data chunks between the Source Devices 200 and the
Destination Devices 300. In accordance with the invention this
Collaborative Work Environment 100 may be implemented on wired
networks, wireless networks or a combination thereof, wherein the
networks may include without limitation Local Area Networks, Metropolitan
Area Networks, Wide Area Networks, and the internet, if required. Person
skilled in the art would appreciate that the choice of the networks for
implementing a particular Collaborative Work Environment 100 would
depend on the territorial cover/ span that the particular Collaborative Work
Environment 100 has to achieve in order to connect the Source Devices
200, the Destination Devices 300 and the transfer administrator 400.
13 of 63
Further the Collaborative Work Environment 100 also comprises RF
communication channels 500 for facilitating the transfer of RF signals
through the Collaborative Work Environment 100, and data
communication channels 600 for facilitating the transfer of non RF data/
information (e.g. data chunks) through the Collaborative Work
Environment 100, wherein the RF communication channels 500 and the
data communication channels 600 may be wired, wireless or in
combination, and may implement enroute, network peripherals including
routers, bridges, modems, hubs, amplifiers, switches, repeaters or a
combination thereof for efficient transfer.
[0030] In accordance with the invention the Source Devices
200 and the Destination Devices 300 are client devices 150 which
comprise a client side data historian 160 selected from amongst digital
databases, cloud databases, on premise databases, relational databases
including Oracle RDBMS, Microsoft SQL Server, IBM DB2, MySQL and
PostgreSQL, NOSQL databases, ERPs, CRM systems, and/ or a
combination thereof, that store the data/ information at discrete tuples
which may access, operate, federate, combine, sync, and link with the
other discrete tuples therein; client side processors 165 with specialized
client side processing units including integrated system (bus) controllers,
memory management control units, floating point units, graphics
processing units, digital signal processing units, or a combination thereof,
14 of 63
that invoke a metadata resolution module 170, a RF signal generation
module 175 and a first receipt - dispatch module 180. As per the invention,
the client side processors 165 may be designed and developed from
scratch or obtained by substantially reconstructing preexisting processors
including embedded processors such as Application- Specific Integrated
Circuits (ASICs), Digital Signal Processors (DSPs), Field Programmable
Gate Arrays (FPGAs), or microprocessors such as AMD Athlon, AMD
Duron, AMD Opteron, ARM’s range of micro processors, IBM PowerPC,
Intel Core, Intel Itanium, Intel Xeon, Intel Celeron or a combination thereof.
[0031] Fig. 2 illustrates a block diagram of the client device
150 described above. As emphasized in forgoing paragraphs, the client
devices 150 may be configured as the Source Devices 200 or the
Destination Devices 300 for each round of transfer, such that based on the
configuration, the activities performed by client slide data historian 160,
the client side processors 165, the metadata resolution module 170, the
RF signal generation module 175 and the first receipt - dispatch module
180, at the client devices 150 may vary.
[0032] The invention described and claimed herein is
initiated at the Source Devices 200 where the data chunks pertaining to
the electronic data files destined for transfer are stored at a first set of
discrete tuples in the client side data historian 160. After storing the data
15 of 63
chunks, the client side processors 165 invoke the metadata resolution
module 170 that determines the “SRC” metadata value, that is, the MAC/
Network Address of the Source Device 200 where the data chunks
destined for transfer are stored, and further determines the “DSTN”
metadata value, that is, the MAC/ Network Address of the Destination
Device 300 where the data chunks stored at the Source Device 200
bearing the “SRC” metadata value determined thereof, are destined to be
received.
[0033] The “SRC” metadata value and the “DSTN” metadata value
determined thereof, are thereafter, either directly forwarded to the RF
signal generation module 175 for further processment and/ or use, or
stored at a second set of discrete tuples in the client side data historian
160 and then forwarded therefrom to the RF signal generation module
175. Person skilled in the art would appreciate that while the storing of the
“SRC” metadata value and the “DSTN” metadata value at the second set
of discrete tuples in the client side data historian 160 is not essential to the
working of the invention, it is still preferred, because in case the “SRC”
metadata values and/ or the “DSTN” metadata values are lost or altered
during the course of the working of the invention, particularly while being
forwarded to the RF signal generation module 175, a backup copy of the
“SRC” metadata value and the “DSTN” metadata value may be obtained
from the second set of discrete tuples in the client side data historian 160
16 of 63
to reinitiate the working of the invention from that point onwards instead of
starting from scratch.
[0034] The “SRC” metadata value and the “DSTN” metadata
value determined and forwarded from the metadata resolution module 170
or the second set of discrete tuples in the client side data historian 160, as
the case may be, are received at the RF signal generation module 175.
The RF signal generation module 175, in the broadest sense, utilizes the
“SRC” metadata value and the “DSTN” metadata value to generate RF
signals of specific amplitudes and specific wavelengths destined for
transmittal to the transfer administrator 400 wherein the RF signals convey
thereat that there are data chunks of a particular electronic data file at the
Source Device 200 sending the RF signal which are ready to be
transferred to a particular Destination Device 300.
[0035] Fig.3 illustrates a block diagram of the RF signal
generation module 175 which comprises a RF waveform generator 176,
an amplitude tuner 177, and a wavelength tuner 178. In accordance with
the invention, the amplitude tuner 177 and the wavelength tuner 178 are
communicatively connectible with a RF reference file 700. Person skilled
in the art would appreciate that the RF reference file has been referenced
by the numeral 700 since it is a virtual reference document present in the
client devices 150, as well as the transfer administrator 400. At the client
17 of 63
devices 150 configured as the Source Devices 200, the RF reference file
700 is referred for determining the amplitude and the wavelength to be
kept for the RF signals generated therein, and at the transfer administrator
400, the RF reference file 700 is referred to determine the “SRC” metadata
value and “DSTN” metadata value based on the amplitude and the
wavelength of the RF signals received therein.
[0036] Fig. 4 illustrates the RF reference file 700. As may be
seen in the illustration, the RF reference file 700 is a tabulation of
amplitudes and wavelengths, and more particularly a tabulation providing
an unique amplitude for each client device 150 in the Collaborative Work
Environment 100 which is configured to act as the Source Device 200, and
an unique wavelength for each client device 150 in the Collaborative Work
Environment 100 which is configured to act as the Destination Device 300.
The RF reference file 700 illustrated in the figure is for the Collaborative
Work Environment 100 having five client devices 150, namely C1, C2, C3,
C4 & C5. Accordingly, this RF reference file 700 sets out the amplitude
and wavelength to be maintained for each of C1, C2, C3, C4 & C5 acting
as the Source Devices 200 or the Destination Devices 300 for each round
of transfer. Thus in a particular instance of transfer if the data chunks are
to be transferred from C1 to C5 then the amplitude (Amp) of the RF signal
would be 100 Å, and the wavelength (λ) of the of the RF signal would be
500 Å. Likewise, if data chunks are to be transferred from C5 to C1, then
18 of 63
the amplitude (Amp) of the RF signal would be 500 Å, and the wavelength
(λ) of the of the RF signal would be 100 Å. Person skilled in the art would
appreciate that the illustration has been given a textual outlook to explain
the contents therein. In actuality the RF reference file 700 is a log file, or a
combination of log files that contain the requisite information which is
readable and interpretable by the client devices 150 and the transfer
administrator 400 within the Collaborative Work Environment 100.
[0037] In accordance with the invention, when the RF signal
generation module 175 is invoked then firstly the RF waveform generator
176 generates a standard waveform of a specific amplitude (Amp) and a
specific wavelength (λ). In a preferred characterization, the choice of the
standard waveform to be generated, and the choice of the amplitude and
the wavelength to be set for the standard waveform may be obtained from
registered users of the Collaborative Work Environment 100, wherein the
choice of the standard waveform to be generated maybe made from
amongst sine waveforms, square waveforms, sawtooth waveforms, and
triangle waveforms.
[0038] The RF waveform generated at the RF waveform
generator 176 is then subjected to the amplitude tuner 177 comprising
amplitude conditioning units that performs a two - fold operation. Firstly, it
obtains the “SRC” metadata value either from the metadata resolution
19 of 63
module 170 directly, or from the second set of discrete tuples in the client
side data historian 160, as the case may be, and thereafter sets the
amplitude of the RF waveform as per the amplitude fixed for the Source
Device 200 bearing the “SRC” metadata value obtained thereof, by
referring to the RF reference file 700.
[0039] The RF waveform with set amplitude is then subjected
to the wavelength tuner 178 containing wavelength conditioning units that
also performs a two – fold operation. Firstly, it obtains the “DSTN”
metadata value either from the metadata resolution module 170 directly, or
from the second set of discrete tuples in the client side data historian 160,
as the case may be, and thereafter sets the wavelength of the RF
waveform with set amplitude, as per the wavelength fixed for the
Destination Device 300 bearing the “DSTN” metadata value obtained
thereof, by referring to the RF reference file 700.
[0040] Thus, the final outcome after the execution of the RF
waveform generator 176, the amplitude tuner 177 and the wavelength
tuner 178, at the Source Device 200, is the RF signal whose amplitude
equals the amplitude set for the particular Source Device 200 which
contains the data chunks to be transferred, and whose wavelength equals
the wavelength set for the particular Destination Device 300 where the
data chunks from the particular Source Device 200 are destined to be
20 of 63
received, wherein the amplitude which is set for the particular Source
Device 200, and the wavelength which is set for the particular Destination
Device 300 are obtained by referring to the RF reference file 700.
[0041] Fig.5 illustrates the activities performed at the RF
signal generation module 175, and more particularly the components 176,
177, 178 therein. The illustration shows how a particular RF signal is
generated at the RF signal generation module 175 of the Source Device
200 which has data chunks to be transferred to the Destination Device
300, wherein the “SRC” metadata value and “DSTN” metadata value of C2
and C5, respectively, are stored at the second set of discrete tuples in the
client side data historian 160.
[0042] In accordance with the figure, firstly the RF waveform
is generated at the RF waveform generator 176 having Amplitude (Amp),
say 600 Å, and Wavelength (λ) say 600 Å. This RF waveform is then
subjected to the amplitude tuner 177 that learns the “SRC” metadata value
for C2 from the second set of discrete tuples in the client side data
historian 160, and thereafter refers to the RF reference file 700 to
determine the amplitude to be set, which in case of C2 is 200 Å. Post
determination of amplitude, the amplitude tuner 177 sets the amplitude of
the RF waveform accordingly.
21 of 63
[0043] The RF waveform with set amplitude is then subjected
to the wavelength tuner 178 that learns the “DSTN” metadata value for C5
from the second set of discrete tuples in the client side data historian 160,
and thereafter refers to the RF reference file 700 to determine the
wavelength to be set, which in case of C5 is 500 Å. Post determination of
wavelength, the wavelength tuner 178 sets the wavelength for the RF
waveform with set amplitude, accordingly.
[0044] Person skilled in the art would appreciate that for the
purpose of this invention the setting of the amplitude of the RF waveform
by the amplitude tuner 177 and the setting of the wavelength of the RF
waveform with set amplitude by the wavelength tuner 178 implies
performing mathematical functions and/ or operations that enhance or
reduce the amplitude and/ or wavelength of the RF waveform on a per
requirement basis.
[0045] Once the RF signal is generated at the RF signal
generation module 175 of the Source Device 200, it is forwarded to the
first receipt – dispatch module 180, or alternatively, stored at a third set of
discrete tuples in the client side data historian 160 and then forwarded
therefrom to the first receipt – dispatch module 180. Person skilled in the
art would appreciate that while the storing of the RF Signal at the third set
of discrete tuples in the client side data historian 160 is not essential to the
22 of 63
working of the invention, it is still preferred, because in case the RF signal
is lost or altered during the course of the working of the invention,
particularly while being forwarded to the first receipt – dispatch module
180, a backup copy of the RF signal may be obtained from the third set of
discrete tuples in the client side data historian 160 to reinitiate the working
of the invention from that point onwards instead of starting from scratch.
[0046] The RF Signal forwarded from the RF signal
generation module 175 or the third set of discrete tuples in the client side
data historian 160, as the case may be, are received at the first receipt –
dispatch module 180 that transfers the RF signal to the transfer
administrator 400 through the RF communication channels 500 which
implement, enroute, network peripherals such as routers, bridges,
modems, hubs, switches, or a combination thereof, enroute, to ensure
proper and efficient transfer of the RF signal through the RF
communication channels 500, and network peripherals such as amplifiers,
repeaters or a combination thereof, enroute, to prevent attenuation and
strength loss of the RF signal and maintain it at its original state during its
course of transfer.
[0047] Fig.6 illustrates a block diagram of the transfer
administrator 400. As per the illustration the transfer administrator 400 at
least comprises a server side data historian 410 and server side
23 of 63
processors 420 containing server side processing units, wherein the
server side processors 420 and the server side processing units therein,
invoke a RF signal interpretation module 430, an optimal path
determination module 460 and a second receipt – dispatch module 490.
Based on the illustration, person skilled in the art would appreciate that the
server side data historian 410 and the server side processors 420
containing the server side processing units, are constituted and organized
just like the client side data historian 160 and the client side processors
165, however the server side components 410, 420 have very different
functions and purpose as compared to the client side components 160,
165.
[0048] When the RF signal transmitted from a particular
Source Device 200 is received at the transfer administrator 400, then
firstly the server side processors 420 trigger a locking operation which
bars the entry of any further RF signals at the transfer administrator 400
until the activities for the RF signal received therein are completed at/ in
relation to the transfer administrator 400. After locking the transfer
administrator 400, the server side processors 420 invoke the RF signal
interpretation module 430 which performs a two – fold operation. Firstly,
the RF signal interpretation module 430 calculates the amplitude and the
wavelength of the RF signal by applying mathematical functions and/ or
operations. After calculating the amplitude and the wavelength of the RF
24 of 63
signal, the RF signal interpretation module 430 refers the RF reference file
700 for determining, with the help of amplitude calculated thereof, the
“SRC” metadata value, that is, the MAC address/ Network address of the
Source Device 200 wherein the data chunks destined for transfer are
stored, and for determining, with the help of the wavelength calculated
thereof, the “DSTN” metadata value, that is, the MAC address/ Network
address of the Destination Device 300 which is destined to receive the
data chunks stored at the Source Device 200 determined thereof. Person
skilled in the art may appreciate that in accordance with the invention, the
RF reference file 700 may be located anywhere within the transfer
administrator 400 including within one of the modules 430, 460,
[0049] Fig. 7 illustrates the working of the RF signal
interpretation module 430. As seen in the illustration, the RF signal
received therein is, firstly, subjected to mathematical functions and/ or
operations that calculate the amplitude and the wavelength of the RF
signal. As per the illustration, the amplitude (Amp) calculated for the RF
signal is 400 Å, and the wavelength (λ) calculated for the RF signal is 200
Å. The RF signal interpretation module 430 thereafter refers to the RF
reference file 700 to determine the MAC/ Network Address of that Source
Device 200 that has amplitude (Amp) of 400 Å and to determine the MAC/
Network Address of that Destination Device 300 that has wavelength (λ) of
200 Å. As per the illustration, after referring to the RF reference file 700
25 of 63
the MAC/ Network Address of the Source Device 200 is determined as 00-
37-48-E6-12-B5, and the MAC/ Network Address of the Destination
Device 300 is determined as 00-1A-CC-23-1B-90.
[0050] The MAC/ Network Address of the Source Device 200, that
is, the value of the “SRC” metadata, and the MAC/ Network Address of the
Destination Device 300, that is, the value of the “DSTN” metadata,
determined at the RF Signal interpretation module 430 are then either
directly forwarded to the optimal path determination module 460, or
alternatively, stored at a first set of discrete tuples in the server side data
historian 410 and then forwarded therefrom to the optimal path
determination module 460. Person skilled in the art would appreciate that
while the storing the “SRC” metadata value and the “DSTN” metadata
value at the first set of discrete tuples in the server side data historian 410
is not essential to the working of the invention, it is still preferred, because
in case the RF signal is lost or altered during the course of working of the
invention, particularly while being forwarded to the optimal path
determination module 460, a backup copy of the “SRC” metadata value
and the “DSTN” metadata value may be obtained from the first set of
discrete tuples in the server side data historian 410 to reinitiate the
working of the invention from that point onwards instead of starting from
scratch.
26 of 63
[0051] The “SRC” metadata value and the “DSTN” metadata
value determined thereof, are forwarded to the optimal path determination
module 460 either directly from the RF Signal interpretation module 430 or
from the first set of discrete tuples in the server side data historian 410, as
the case may be, wherein the optimal path determination module 460, in
the broadest sense determines an optimal path between the Source
Device 200 and the Destination Device 300 bearing the “SRC” metadata
value forwarded thereto, and the “DSTN” metadata value forwarded
thereto, respectively.
[0052] In accordance with the invention, the optimal path
determination module 460, performs a three – fold operation. Firstly, it
determines a shortest path tree set (sptset) within the Collaborative Work
Environment 100 wherein the shortest path tree set (sptset) comprises the
client devices 150 in the Collaborative Work Environment 100 and the
direct paths between them, wherever applicable.
[0053] Person skilled in the art would appreciate that it may
not always be possible for the client devices 150 in the Collaborative Work
Environment 100 to have dedicated one to one paths between them due
to technical, geographical and often economical constraints, and therefore
many times, the transfer between a particular Source Device 200 and a
particular Destination Device 300 is carried out using intermediary client
27 of 63
device(s) 150. In such cases, whenever data chunks are to be transferred
then the Source Device 200 destined to transfer the data chunks sends
the data chunks to the intermediary client device(s) 150 which then route
the same to the Destination Device 300 destined to receive the data
chunks routed thereof. Accordingly, for the purpose of this invention,
whenever a particular Source Device 200 and a particular Destination
Device 300 transfer data chunks between themselves, directly, that is,
without using intermediary client device(s) 150 then they will be deemed to
have a “direct path” between them, and whenever a particular Source
Device 200 and a particular Destination Device 300 transfer data chunks
between themselves, indirectly, that is, by using intermediary client
device(s) 150 then they will be deemed to have an “indirect path” between
them.
[0054] In light of the forgoing explanation, when optimal path
determination module 460, determines a shortest path tree set (sptset)
within the Collaborative Work Environment 100 then the shortest path tree
set (sptset) comprises the client devices 150 in the Collaborative Work
Environment 100 and those paths between the client devices 150 that are
one to one and unimpeded, and which do not require intermediate client
device(s) 150 for transferring.
28 of 63
[0055] Fig.8 illustrates the determination of the shortest path
tree set (sptset) for a particular Collaborative Work Environment 100. As
may seen in the illustration, the Collaborative Work Environment 100 with
client devices 150 “A” to “I” is demonstrated at the upper portion of the
illustration, for which, the shortest path tree set (sptset) is demonstrated at
the lower portion wherein, the shortest path tree set (sptset) highlights all
the client devices 150 and the direct paths between them, wherever
applicable (e.g. path between A&B, A&C, C&E etc.).
[0056] After the shortest path tree set (sptset) is determined,
the optimal path determination module 460 performs the next operation of
calculating the time/ cost complexity between the client devices 150 in the
shortest path tree set (sptset) having direct paths between them. In a
preferred embodiment, the optimal path determination module 460 may
calculate the time/ cost complexity between each pair of client devices 150
connected by the direct path, by transmitting a single bit of sample data
between the pair of client devices 150, and assessing the time and/ or
resources consumed to complete the transmission of the single bit of
sample data through the direct path between them.
[0057] Fig.9 illustrates the calculation of time/ cost complexity
between each pair of client devices 150 in the shortest path tree set
(sptset) having the direct path between them. Accordingly in the illustration
29 of 63
the shortest path tree set (sptset) for client devices 150 “A” to “I”
highlighting the direct paths (e.g. path between A&B, A&C, C&E etc.) is
shown on the upper portion of the illustration, and the corresponding time/
cost complexity for the pairs of client devices 150 having the direct paths
between them is shown on the lower portion of the illustration (e.g. time/
cost complexity between A&B is 4 units, time/ cost complexity between
A&C is 8 units, etc.).
[0058] Lastly, the optimal path determination module 460,
obtains the “SRC” metadata value and the “DSTN” metadata value from
the RF Signal interpretation module 430, or from the first set of discrete
tuples in the server side data historian 410, as the case may be, and
identifies an optimal path between the Source Device 200 and the
Destination Device 300 bearing the “SRC” metadata value obtained
thereof and the “DSTN” metadata value obtained thereof, respectively. In
accordance with the invention, the optimal path is that direct path or the
combination of direct paths between the Source Device 200 bearing the
“SRC” metadata value obtained thereof and the Destination Device 300
bearing the “DSTN” metadata value obtained thereof, that has the lowest
time/ cost complexity, and has none or nominal traffic congestion. Person
skilled in the art would appreciate that the optimal path may be direct path
as well as indirect path, and further appreciate that there is no specific
priority of choosing direct paths and/ or indirect paths as optimal paths.
30 of 63
That is to say that if the indirect path between two Client devices 150 has
lower time / cost complexity than the direct path between them, then the
optimal path would be based on the indirect path. Person skilled in the art
would also appreciate that if the indirect path between two client devices
150 is identified as the optimal path then the optimal path will retain the
MAC/ Network Address of the intermediary client device(s) 150 as well.
[0059] In accordance with the invention, the optimal path
determination module 460, after obtaining the “SRC” metadata value and
the “DSTN” metadata value, identifies the optimal path between the
Source Device 200 and the Destination Device 300 by contextual
application of Dijkstra’s shortest path evaluation model and/ or Prim’s
shortest path evaluation model and/ or any other suitable path evaluation
models.
[0060] Fig.10 illustrates the identification of the optimal path
between the Source Device 200 and the Destination Device 300 whose
“SRC” metadata value and the “DSTN” metadata value, respectively are
obtained from the first set of discrete tuples in the server side data
historian 410. As per the illustration, the optimal path determination
module 460, obtains the “SRC” metadata value and the “DSTN” metadata
value, that is, the MAC Address/ Network Address 150 of the Source
Device 200 and the Destination Device 300, respectively, from the first set
31 of 63
of discrete tuples in the server side data historian 410, which as per the
illustration are 00-AD-CC-23-AF-4F and 00-37-48-E6-12-B5 respectively.
The “SRC” metadata value and the “DSTN” metadata value obtained
thereof are then searched in the shortest path tree set (sptset) to
determine the Source Device 200 and the Destination Device 300 in the
Collaborative Work Environment 100, which as per the illustration are
Client Device 150 “A” and Client Device 150 “H” respectively. Once the
Source Device 200, that is, Client Device 150 “A” and the Destination
Device 300, that is, Client Device 150 “H” are determined, then the optimal
path determination module 460 applies the Dijkstra’s shortest path
evaluation model and/ or Prim’s shortest path evaluation model and/ or
any other suitable path evaluation model on the shortest path tree set
(sptset) to determine the optimal path between the client device 150 “A”
and client device 150 “H”, which has been shown in bold lines in the
description and has an overall time/ cost complexity of 11 units.
[0061] The optimal path identified thereof, is thereafter, either
directly forwarded to the second receipt – dispatch module 490 for further
processment and/ or use, or stored at a second set of discrete tuples in
the server side data historian 410 and then forwarded therefrom to the
second receipt – dispatch module 490. Person skilled in the art would
appreciate that while the storing of the values of the optimal at the second
set of discrete tuples in the server side data historian 410 is not essential
32 of 63
to the working of the invention, it is still preferred, because in case the
optimal path is lost or altered during the course of the working of the
invention, particularly while being forwarded to the second receipt –
dispatch module 490, a backup copy of the optimal path may be obtained
from the second set of discrete tuples in the server side data historian 410
to reinitiate the working of the invention from that point onwards instead of
starting from scratch.
[0062] The second receipt – dispatch module 490, on
receiving the optimal path forwarded to it, transmits the optimal path back
to the Source Device 200 which sent the RF signal to the transfer
administrator 400 in the first place. In order to transmit the optimal path
back to the Source Device 200, the second receipt – dispatch module 490
uses the data communication channels 600 which implement, enroute,
network peripherals such as routers, bridges, modems, hubs, switches, or
a combination thereof to ensure proper and efficient transfer of the optimal
path through the data communication channels 600, and network
peripherals such as amplifiers, repeaters or a combination thereof,
enroute, to prevent attenuation and strength loss of the optimal path and
maintain it at its original state during its course of transfer.
[0063] As soon as the optimal path is transmitted to the
Source Device 200 from whom the RF signal was originally received at the
33 of 63
transfer administrator 400, the lock placed on transfer administrator 400 is
lifted, thereby allowing the next RF signal to enter the transfer
administrator 400 and get processed in the same manner and order as
described above.
[0064] The optimal path transmitted back from the transfer
administrator 400 is received at the Source Device 200 and thereafter
moved to the first receipt – dispatch module 180 which in the broadest
sense, forwards the data chunks to the contextual Destination Device 300
using the optimal path transmitted therein, through the data
communication channels 600 which implement, enroute, network
peripherals such as routers, bridges, modems, hubs, switches, or a
combination thereof to ensure proper and efficient transfer of the data
chunks through the data communication channels 600, and network
peripherals such as amplifiers, repeaters or a combination thereof,
enroute, to prevent attenuation and strength loss of the data chunks and
maintain them at their original state throughout their course of transfer.
[0065] Once the data chunks pertaining to a particular
electronic data file, transmitted from the Source Device 200, are received
at the Destination Device 300 through their optimal path, they get
subjected to reconstitution operations triggered by the client side
processors 165 therein to obtain back the particular electronic data file for
34 of 63
immediate use, or get subjected to storage operations, also triggered by
the client side processors 165 therein to store the data chunks at the first
set of discrete tuples in the client data historian 160 for later reference and
retrieval.
[0066] As per a preferred embodiment, a method for
optimizing the transferring of data chunks between the Source Device 200
and the Destination Device 300 in the Collaborative Work Environment
100 using the system described above, is referred by the numeral 800. As
per the method 800, the first step is triggered at the Source Device 200
using the client side processors 165 therein, which is storing the data
chunks destined for transfer at the first set of discrete tuples in the client
side data historian 160, if not already stored therein 810.
[0067] After storing the data chunks 810, the method 800
triggers the next step at the Source Device 200 which is determining the
“SRC” metadata value of the Source Device 200 where the data chunks
destined for transfer are stored, and the “DSTN” metadata value of the
Destination Device 300 where the data chunks stored at the Source
Device 200 bearing the “SRC” metadata value determined thereof are
destined to be received, wherein the “SRC” metadata value and the
“DSTN” metadata value are the MAC address and/ or the Network
35 of 63
Address of the Source Device 200 and the Destination Device 300,
respectively 820.
[0068] The “SRC” metadata value and the “DSTN” metadata
value determined thereof 820, are thereafter, either directly subjected to
the next step of the method 800 for further processing and/ or using, or in
the alternative subjected to an optional step of storing the “SRC” metadata
value and the “DSTN” metadata value, to the second set of discrete tuples
in the client side data historian 160 and then using the “SRC” metadata
value and the “DSTN” metadata value therefrom for further processing
and/ or using 830. Person skilled in the art would appreciate that while the
storing of the “SRC” metadata value and the “DSTN” metadata value at
the second set of discrete tuples in the client side data historian 160, 830
is not essential to the working of the invention, it is still preferred, because
in case the “SRC” metadata value and/ or the “DSTN” metadata value are
lost or altered during the working of the invention, a backup copy of the
“SRC” metadata value and the “DSTN” metadata value may be obtained
from the second set of discrete tuples in the client side data historian 160
for reinitiating the working of the invention from that point onwards instead
of starting from scratch.
[0069] Once the step of determining the “SRC” metadata
value and the “DSTN” metadata value 820, and the optional step of storing
36 of 63
them at the second set of discrete tuples in the client side data historian
160, 830 are completed, the method 800 triggers the next step of
generating, at the Source Device 200, using the client side processors 165
therein, a RF Signal based on the “SRC” metadata value and the “DSTN”
metadata value obtained directly in pursuance of the step 820 explained
above, or obtained from the second set of discrete tuples in the client side
data historian 160, due to step 830 explained above, and transmitting the
RF signal generated thereof to the transfer administrator 400, 840.
[0070] As per a preferred embodiment, the step of
generating the RF signal at the Source Device 200, and transmitting it to
the transfer administrator 400, 840 may involve multiple sub steps, the first
sub step being generating the standard waveform of specific amplitude
and specific wavelength wherein the choice of the standard waveform and
the choice of its values of amplitude and wavelength may be obtained
from the registered users of the Collaborative Work Environment 100, and
wherein the choice of the standard waveform may be made from amongst
sine waveforms, saw tooth waveforms, triangle waveforms, and square
waveforms 841.
[0071] The standard waveform of the specific amplitude and the
specific wavelength obtained from the sub step 841, is subjected to the
next sub step which is setting the amplitude of the RF waveform as per the
37 of 63
amplitude fixed for the Source Device 200 bearing the “SRC” metadata
value determined thereof, in the RF reference file 700, 842.
[0072] The RF waveform with set amplitude obtained from the sub
step 842, is subjected to the next sub step which is setting the wavelength
of the RF waveform with the set amplitude as per the wavelength fixed for
the Destination Device 300 bearing the “DSTN” metadata value
determined thereof, in the RF reference file 700, 843, thereby obtaining
the RF signal.
[0073] The RF Signal, that is, the RF waveform with set amplitude
and set wavelength, obtained from the sub step 843, is thereafter either
directly subjected to the next sub step within the step 840 for further
processing and/ or using, or in the alternative subjected to an optional sub
step of storing the RF signal, to the third set of discrete tuples in the client
side data historian 160 and then using the RF Signal therefrom for further
processing and/ or using 844. Person skilled in the art would appreciate
that while the storing of the RF Signal at the third set of discrete tuples in
the client side data historian 160, 844 is not essential to the working of the
invention, it is still preferred, because in case the RF Signal is lost or
altered during the working of the invention, a backup copy of the RF Signal
may be obtained from the second set of discrete tuples in the client side
38 of 63
data historian 160 for reinitiating the working of the invention from that
point onwards instead of starting from scratch.
[0074] Once the sub steps of obtaining the RF signal from the RF
waveform with set amplitude 843, and the optional sub step of storing it at
the third set of discrete tuples in the client side data historian 160, 844 are
completed, the step 840 of the method 800, triggers the last sub step of
transmitting the RF signal to the transfer administrator 400 through the RF
communication channels 500 having network peripherals enroute to
maintain the integrity and strength of the RF signal, wherein the network
peripherals are selected from a plurality of bridges, modems, hubs,
amplifiers, switches, repeaters or a combination thereof 845.
[0075] Once the RF signal is received at the transfer
administrator 400, pursuant to the step 840, more particularly, the sub step
of 845, the method 800, using the server side processors 420 therein, may
trigger an optional step of locking the transfer administrator 400 for barring
the entry of other RF signals, and unlocking the transfer administrator 400
locked thereof only when the activities at/ in relation to the RF signal
received at the transfer administrator 400 are completed 850. Once the
step 850 is completed, the method 800 triggers the next step which is
generating, at the transfer administrator 400, using the server side
processors 420 therein, the optimal path based on the RF signal
39 of 63
transmitted from the Source Device 200, and transmitting the optimal path
generated thereof back to the Source Device 200, 860.
[0076] In a preferred embodiment this step of generating the
optimal path based on the RF signal transmitted from the Source Device
200, and transmitting the optimal path generated thereof to the Source
Device 200, 860, comprises multiple sub steps, the first being calculating
the amplitude and the wavelength of the RF signal received therein 861.
Person skilled in the art would appreciate that this calculating of amplitude
and wavelength of the RF signal 861 would require the application of
mathematical functions and/ or operations.
[0077] Once the amplitude and the wavelength of the RF signal are
calculated pursuant to sub step 861, the step 860 of the method 800,
triggers the next sub step of determining the “SRC” metadata value of the
Source Device 200 having data chunks destined for transfer, by
comparing the amplitude calculated thereof against the contents of the RF
reference file 700, and the “DSTN” metadata value of the Destination
Device 300 destined to receive the data chunks transferred from the
Source Device 200 bearing the “SRC” metadata value determined thereof,
by comparing the wavelength calculated thereof against the contents of
the RF reference file 700, wherein the “SRC” metadata value and the
“DSTN” metadata value are the MAC address and/ or the Network
40 of 63
address of the Source Device 200 and the Destination Device 300,
respectively 862.
[0078] The “SRC” metadata value and the “DSTN” metadata value,
determined from the sub step 862, are thereafter either directly subjected
to the next sub step within the step 860 for further processing and/ or
using, or in the alternative subjected to an optional sub step of storing the
“SRC” metadata value and the “DSTN” metadata value at the first set of
discrete tuples in the server side data historian 410 and then using the
“SRC” metadata value and the “DSTN” metadata value therefrom for
further processing and/ or using 863. Person skilled in the art would
appreciate that while the storing of the “SRC” metadata value and the
“DSTN” metadata value at the first set of discrete tuples in the server side
data historian 410, 863 is not essential to the working of the invention, it is
still preferred, because in case the “SRC” metadata value and the “DSTN”
metadata value are lost or altered during the working of the invention, a
backup copy of the RF Signal may be obtained from the first set of
discrete tuples in the server side data historian 410 for reinitiating the
working of the invention from that point onwards instead of starting from
scratch.
[0079] Once the sub steps of determining the “SRC” metadata
value and “DSTN” metadata value 862, and the optional sub step of
41 of 63
storing them at the first set of discrete tuples in the server side data
historian 410, 863 are completed, the step 860 of the method 800, triggers
the sub step of determining the shortest path tree set (sptset) within the
Collaborative work environment 100 wherein the shortest path tree set
(sptset) comprises the client devices 150 in the Collaborative Work
Environment 100 and the direct paths between them, wherever applicable
864. It is re-iterated in this context that two client devices 150 would be
deemed to be have direct path between them if they transfer data chunks
through unimpeded one to one connection, and two client devices 150
would have indirect path between them if they transfer the data chunks
between themselves using intermediary client device(s) 150.
[0080] In light of the forgoing explanation, when the step 860 of the
method 800 triggers the sub step of determining the shortest path tree set
(sptset) within the Collaborative Work Environment 100 then the shortest
path tree set (sptset) would comprise the client devices 150 in the
Collaborative Work Environment 100 and those paths between them 864
that are one to one and unimpeded, and which do not require intermediate
client device(s) 150 for transferring.
[0081] After determining the shortest path tree set (sptset) 864, the
step 860 of the method 800 triggers the next sub step of calculating the
time and/ or cost complexity between those client devices 150 in the
42 of 63
shortest path tree set (sptset) having the direct paths between them 865.
In a preferred embodiment, the calculating of the time/ cost complexity
between each pair of client devices 150 connected by direct path 865 may
be achieved by transmitting single bit of sample data between the pair of
client devices 150, and assessing the time and/ or resources consumed to
complete the transmitting of the single bit of sample data through the
direct path between them.
[0082] After calculating the time/ cost complexity between each pair
of client devices 150 connected by a direct path 865, the step of 860 of the
method 800 triggers the sub step of utilizing the “SRC” metadata value
and “DSTN” metadata value from the proceeds of the sub step 862
directly, or from the first set of discrete tuples in the server side data
historian 410 due to the sub step 863, and identifying the optimal path
between the Source Device 200 bearing the “SRC” metadata value and
the Destination Device 300 bearing the “DSTN” metadata value, wherein
the optimal path is that direct path or the combination of direct paths
between the Source Device 200 bearing the “SRC” metadata, and the
Destination Device 300 bearing the “DSTN” metadata that has the lowest
time/ cost complexity, and has none or nominal traffic congestion, and
wherein the identifying the optimal path between the Source Device 200
and the Destination Device 300, 866 may be achieved, inter alia, by
43 of 63
applying Dijkstra’s shortest path evaluation model and/ or Prim’s shortest
path evaluation model and/ or any other suitable path evaluation models.
[0083] The optimal path identified pursuant to the sub step
866, is thereafter either directly subjected to the next sub step within the
step 860 for further processing and/ or using, or in the alternative
subjected to an optional step of storing the optimal path, at the second set
of discrete tuples in the server side data historian 410 and then using the
optimal path therefrom for further processing and/ or using 867. Person
skilled in the art would appreciate that while the storing of the optimal path
at the second set of discrete tuples in the server side data historian 410,
867 is not essential to the working of the invention, it is still preferred,
because in case the optimal path is lost or altered during the working of
the invention, a backup copy of the optimal path may be obtained from the
second set of discrete tuples in the server side data historian 410 for
reinitiating the working of the invention from that point onwards instead of
starting from scratch.
[0084] Once the sub steps of utilizing the “SRC” metadata value
and the “DSTN” metadata value for identifying the optimal path 866, and
the optional sub step of storing it at the second set of discrete tuples in the
server side data historian 410, 867 are completed, the step 860 of the
method 800, triggers the sub step of transmitting the optimal path
44 of 63
determined thereof through the data communication channels 600 that
have network peripherals enroute to maintain the integrity of the optimal
path, wherein the network peripherals are selected from a plurality of
bridges, modems, hubs, amplifiers, switches, repeaters or a combination
thereof 868.
[0085] Once the optimal path is received at the Source
Device 200 from the transfer administrator 400 pursuant to the step 860,
particularly the sub step 868, the method 800 triggers the next step which
is forwarding, from the Source Device 200, though the client side
processors 165 therein, the data chunks stored at the first set of discrete
tuples in the client side data historian 160 therein, to the Destination
Device 300, using the data communication channels 600 that follow the
optimal path received therein, wherein the data communication channels
600 have network peripherals enroute to maintain the integrity and the
strength of the data chunks, and wherein the network peripherals are
selected from a plurality of bridges, modems, hubs, amplifiers, switches,
repeaters or a combination thereof 870.
[0086] Thereafter, the method 800 triggers the last step of
receiving, at the Destination Device 300, through the client side
processors 165 therein, the data chunks forwarded from the Source
Device 200, 880. In a preferred characterization, the receiving of the data
45 of 63
chunks at the Destination Device 300, may further trigger concatenating
the data chunks for obtaining back the electronic data file for immediate
reference and/ or use 881, or trigger storing of the data chunks received
therein at the first set of discrete tuples in the client data historian 160
therein for future reference and/ or use 882.
[0087] While the present invention has been particularly shown and
described with reference to exemplary embodiments thereof, it will be
understood by those of ordinary skill in the art that various changes in form
and details may be made therein without departing from the spirit and
scope of the present invention as defined by the following claims.

We claim:
1. A system to optimize the transfer of data chunks between a Source
Device 200 and Destination Device 300 in a Collaborative Work
Environment 100 using a transfer administrator 400 wherein the
system is characterized to –
store, at the Source Device 200, more particularly at a first
set of discrete tuples in the Client Side Data Historian 160,
the data chunks destined for transfer;
determine, at the Source Device 200, through client side
processors 165 therein, a “SRC” metadata value of the
Source Device 200 where the data chunks destined for
transfer are stored, and a “DSTN” metadata value of the
Destination Device 300 where the data chunks at the Source
Device 200 bearing the “SRC” metadata value determined
thereof, are destined to be received;
generate, at the Source Device 200, through the client side
processors 165 therein, a RF signal based on the “SRC”
metadata value and the “DSTN” metadata value determined
47 of 63
thereof, and transmit the RF signal generated thereof to the
transfer administrator 400;
generate, at the transfer administrator 400, through server
side processors 420 therein, an optimal path based on the
RF signal transmitted therein, and transmit back the optimal
path generated thereof to the Source Device 200;
forward, from the Source Device 200, through the client side
processors 165 therein, the data chunks stored in the first
set of discrete tuples in the client side data historian 160 to
the Destination Device 300, pursuant to the optimal
path transmitted therein, through the data communication
channels 600 that have network peripherals enroute to
maintain the integrity and strength of the data chunks,
wherein the network peripherals are selected from a plurality
of bridges, modems, hubs, amplifiers, switches, repeaters or
a combination thereof; and
receive, at the Destination Device 300, through the client
side processors 165 therein, the data chunks forwarded from
the Source Device 200.
48 of 63
2. The system as claimed in claim 1 wherein the system determines,
at the Source Device 200, through the client side
processors 165 therein, the “SRC” metadata value of the Source
Device 200 and the “DSTN” metadata value of the Destination
Device 300, by invoking a metadata resolution module 170.
3. The system as claimed in claim 1 wherein the system determines,
at the Source Device 200, through the client side
processors 165 therein, the “SRC” metadata value of the Source
Device 200 and the “DSTN” metadata value of the Destination
Device 300, and thereafter stores the “SRC” metadata value and
the “DSTN” metadata value determined thereof at a second set of
discrete tuples in the client side data historian 160, for backup and/
or other exigencies.
4. The system as claimed in claim 1 wherein the system generates, at
the Source Device 200, through the client side
processors 165 therein, the RF signal based on the “SRC”
metadata value and the “DSTN” metadata value determined
thereof, and transmits the RF signal generated thereof to the
transfer administrator 400, by –
a RF signal generation module 175, comprising -
49 of 63
a RF waveform generator 176 that generates a standard
waveform of a specific amplitude and a specific wavelength
wherein the choice of the standard waveform and the choice
of the specific values of amplitude and wavelength of the
standard waveform chosen thereof, may be obtained from
registered users of the Collaborative Work Environment 100,
further wherein the choice of the standard waveform may be
made from amongst sine waveforms, saw tooth waveforms,
triangle waveforms, and square waveforms,
an amplitude tuner 177 comprising amplitude conditioning
units that set the amplitude of the RF waveform obtained
from the RF waveform generator 176, as per the amplitude
fixed for the Source Device 200 bearing the “SRC” metadata
value determined thereof, in the RF reference file 700, and
a wavelength tuner 178 comprising wavelength conditioning
units configured to set the wavelength of the RF waveform
with set amplitude, obtained from the amplitude tuner 177,
as per the wavelength fixed for the Destination
Device 300 bearing the “DSTN” metadata value determined
thereof, in the RF reference file 700; and
50 of 63
a first receipt – dispatch module 180 that transfers the RF signal
generated thereof to the transfer administrator 400 through the RF
communication channels 500 that have network peripherals enroute
to maintain the integrity and strength of the RF signal, wherein the
network peripherals are selected from a plurality of bridges,
modems, hubs, amplifiers, switches, repeaters or a combination
thereof.
5. The system as claimed in claim 1 wherein the system generates, at
the Source Device 200, through the client side
processors 165 therein, the RF signal based on the “SRC”
metadata value and the “DSTN” metadata value determined
thereof, and thereafter stores the RF signal generated thereof at a
third set of discrete tuples in the client side data historian 160, for
backup and/or other exigencies, before transmitting the RF signal
generated thereof to the transfer administrator 400.
6. The system as claimed in claim 1, wherein before the system
generates, at the transfer administrator 400, through server side
processors 420 therein, the optimal path based on the RF signal
transmitted therein, the system locks the transfer administrator 400
to bar the entry of other RF signals and unlocks the transfer
51 of 63
administrator 400 locked thereof only when the activities at/ in
relation to the RF signal transmitted at the transfer administrator
400 are completed.
7. The system as claimed in claim 1 wherein the system generates, at
the transfer administrator 400, through server side processors 420
therein, the optimal path based on the RF signal transmitted
therein, and transmits back the optimal path generated thereof to
the Source Device 200, by -
a RF signal interpretation module 430 that –
calculates the amplitude and the wavelength of the RF signal
transmitted therein,
determines the “SRC” metadata value of the Source
Device 200 having data chunks destined for transfer, by
comparing the amplitude calculated thereof against the
contents of the RF reference file 700, and
determines the “DSTN” metadata value of the Destination
Device 300 destined to receive the data chunks transferred
from the Source Device 200 bearing the “SRC” metadata
52 of 63
value determined thereof, by comparing the wavelength
calculated thereof against the contents of the RF reference
file 700;
an optimal path determination module 460, communicatively
connectible with the RF signal interpretation module 430 that –
determines a shortest path tree set (sptset) within the
Collaborative work environment 100 wherein the shortest
path tree set (sptset) comprises the client devices 150 in the
Collaborative Work Environment 100 and direct paths
between them, further wherein the direct path refers to that
path between two client devices 150 which is one to one and
unimpeded, and does not require intermediary client
device(s) 150 between them to transfer data chunks,
calculates time and/ or cost complexity between the client
devices 150 in the shortest path tree set (sptset) having
direct paths between them,
obtains the “SRC” metadata value and the “DSTN” metadata
value determined thereof, and
53 of 63
identifies an optimal path between the Source
Device 200 bearing the “SRC” metadata value obtained
thereof, and the Destination Device 300 bearing the “DSTN”
metadata value obtained thereof; and
a second receipt – dispatch module 490, communicatively
connectible with the optimal path determination module 460 that
transmits the optimal path determined thereof back to the Source
device 200 which sent the RF signal to the transfer
administrator 400 originally, wherein the second receipt – dispatch
module 490 transmits the optimal path through the data
communication channels 600 that have network peripherals enroute
to maintain the integrity and strength of the optimal path, further
wherein the network peripherals are selected from a plurality of
bridges, modems, hubs, amplifiers, switches, repeaters or a
combination thereof.
8. The system as claimed in claim 7 wherein the system generates, at
the transfer administrator 400, the optimal path by invoking the RF
signal interpretation module 430 which after determining the “SRC”
metadata value of the Source Device 200 having data chunks
destined for transfer, and after determining the “DSTN” metadata
value of the Destination Device 300 destined to receive the data
54 of 63
chunks transferred from the Source Device 200 bearing the “SRC”
metadata value determined thereof, stores the “SRC” metadata
value and the “DSTN” metadata value determined thereof at a first
set of discrete tuples in the server side data historian 410, for
backup and/ or other exigencies.
9. The system as claimed in claim 7 wherein the system generates, at
the transfer administrator 400, the optimal path by invoking the
optimal path determination module 460 which after identifying the
optimal path between the Source Device 200 and the Destination
Device 300, stores the optimal path identified thereof at a second
set of discrete tuples in the server side data historian 410, for
backup and/ or other exigencies.
10. The system as claimed at claim 1 wherein the system receives, at
the Destination Device 300, through the client side
processors 165 therein, the data chunks forwarded from the Source
Device 200 and thereafter either concatenates the data chunks
received therein to obtain the electronic data file for immediate
reference and/ or use, or stores the data chunks received therein at
the first set of discrete tuples in the client data historian 160 for
future reference and/ or use.
55 of 63
11. A method for optimizing the transferring of data chunks between
Source Device 200 and Destination Device 300 in Collaborative
Work Environment 100, in conjunction with the system claimed in
claim 1 to claim 10, 800 wherein the method is characterized by –
storing, at the Source Device 200, more particularly at the
first set of discrete tuples in the Client Side Data
Historian 160, the data chunks destined for transfer 810;
determining, at the Source Device 200, through client side
processors 165 therein, the “SRC” metadata value of the
Source Device 200 where the data chunks destined for
transfer are stored, and the “DSTN” metadata value of the
Destination Device 300 where the data chunks at the Source
Device 200 bearing the “SRC” metadata value determined
thereof are destined to be received 820;
generating, at the Source Device 200, through the client side
processors 165 therein, the RF signal based on the “SRC”
metadata value and the “DSTN” metadata value determined
thereof, and transmitting the RF signal generated thereof to
the transfer administrator 400, 840;
56 of 63
generating, at the transfer administrator 400, through server
side processors 420 therein, the optimal path based on the
RF signal transmitted from the Source Device 200, and
transmitting the optimal path generated thereof to the Source
Device 200, 860; and
forwarding, from the Source Device 200, though the client
side processors 165 therein, the data chunks stored in the
first set of discrete tuples in the client side data
historian 160 to the Destination Device 300, pursuant to the
optimal path transmitted therein, through the data
communication channels 600 that have network peripherals
enroute to maintain the integrity and strength of the data
chunks, wherein the network peripherals are selected from a
plurality of bridges, modems, hubs, amplifiers, switches,
repeaters or a combination thereof 870; and
receiving, at the Destination Device 300, through the client
side processors 165 therein, the data chunks forwarded from
the Source Device 200, 880.
57 of 63
12. The method as claimed in claim 11 wherein the system after
determining, at the Source Device 200, the “SRC” metadata value
and the “DSTN” metadata value 820, may trigger the step of
storing, at the Source Device 200, the “SRC” metadata value and
the “DSTN” metadata value determined thereof at the second set of
discrete tuples in the client side data historian 160, for backup and/
or other exigencies 830.
13. The method as claimed in claim 11 wherein the generating, at the
Source Device 200, through the client side processors 165 therein,
the RF signal based on the “SRC” metadata value and the “DSTN”
metadata value determined thereof, and the transmitting of the RF
signal generated thereof to the transfer administrator 400, 840
comprises the sub steps of -
generating the standard waveform of specific amplitude and
specific wavelength wherein the choice of the standard
waveform and the choice of its values of amplitude and
wavelength may be obtained from the registered users of the
Collaborative Work Environment 100, further wherein the
choice of the standard waveform may be made from
amongst sine waveforms, saw tooth waveforms, triangle
waveforms, and square waveforms 841;
58 of 63
setting the amplitude of the RF waveform as per the
amplitude fixed for the Source Device 200 bearing the “SRC”
metadata value determined thereof, in the RF reference
file 700, 842;
setting the wavelength of the RF waveform with set
amplitude, as per the wavelength fixed for the Destination
Device 300 bearing the “DSTN” metadata value determined
thereof, in the RF reference file 700, 843 to obtain the RF
signal;
storing the RF signal generated thereof at the third set of
discrete tuples in the client side data historian 160 for
backup and/ or other exigencies 844; and
transmitting the RF signal generated thereof to the transfer
administrator 400 through the RF communication channels
500 having network peripherals enroute to maintain the
integrity and strength of the RF signal, wherein the network
peripherals are selected from a plurality of bridges, modems,
hubs, amplifiers, switches, repeaters or a combination
thereof 845.
59 of 63
14. The method as claimed in claim 11 wherein the generating of the
optimal path and the transmitting of the optimal path generated
thereof to the Source Device 200, 860, is initiated by receiving the
RF signal transmitted from the Source Device 200, at the transfer
administrator 400, through the server side processors 420 therein,
and followed by locking the transfer administrator 400 for barring
the entry of other RF signals and unlocking the transfer
administrator 400 locked thereof only when the activities at/ in
relation to the RF signal received therein are completed at the
transfer administrator 400, 850.
15. The method as claimed in claim 11 wherein the generating, at the
transfer administrator 400, through server side processors 420
therein, the optimal path based on the RF signal transmitted from
the Source Device 200, and transmitting of the optimal path
generated thereof to the Source Device 200, 860 comprises the sub
steps of -
calculating the amplitude and the wavelength of the RF
signal received therein 861;
60 of 63
determining the “SRC” metadata value of the Source
Device 200 having data chunks destined for transfer, by
comparing the amplitude calculated thereof against the
contents of the RF reference file 700, and determining the
“DSTN” metadata value of the Destination
Device 300 destined to receive the data chunks transferred
from the Source Device 200 bearing the “SRC” metadata
value determined thereof, by comparing the wavelength
calculated thereof against the contents of the RF reference
file 700, 862;
storing the “SRC” metadata value and the “DSTN’ metadata
value determined thereof at the first set of discrete tuples at
the server side data historian 410, for backup and/ or other
exigencies 863;
determining the shortest path tree set (sptset) within the
Collaborative work environment 100 wherein the shortest
path tree set (sptset) comprises the client devices 150 in the
Collaborative Work Environment 100 and the direct paths
between them, further wherein the direct path refers to that
path between two client devices 150 which is one to one and
61 of 63
unimpeded, and does not require intermediary client
devices 150 between them to transfer data chunks 864;
calculating the time and/ or cost complexity between the
client devices 150 in the shortest path tree set (sptset)
having the direct paths between them 865;
utilizing the “SRC” metadata value and the “DSTN” metadata
value determined thereof for identifying the optimal path
between the Source Device 200 bearing the “SRC”
metadata value determined thereof and the Destination
Device 300 bearing “DSTN” metadata value determined
thereof 866; and
storing the optimal path identified thereof at the second set
of discrete tuples at the server side data historian 410, for
backup and/ or other exigencies 867;
transmitting the optimal path determined thereof through the
data communication channels 600 that have network
peripherals enroute to maintain the integrity and strength of
the optimal path, wherein the network peripherals are
62 of 63
selected from a plurality of bridges, modems, hubs,
amplifiers, switches, repeaters or a combination thereof 868.
16. The method as claimed in claim 11 wherein the receiving, at the
Destination Device 300, through the client side
processors 165 therein 890, the data chunks forwarded from the
Source Device 200, is either followed by concatenating the data
chunks received therein for obtaining back the electronic data file
for immediate reference and/ or use 891, or followed by storing the
data chunks received therein at the first set of discrete tuples in the
client data historian therein for future reference and/ or use 892.