TECHNICAL FIELD
The present invention relates to the field of device detection and autonomic
information exchange between two or more devices. These devices may be
any devices including, but not limited to phones, smartphones, PCs, payment
devices, laptops, automobiles, scooters, internet of things (IOT) devices,
parking sensors etc.
BACKGROUND TO THE INVENTION:
Establishing a simple unsecured communication link for an exchange of data
from one mobile device to another can be difficult and can also cause
losslhacking of the useful information which can be an banking information,
secret emails or request to access the other device.
For trusted and secure communications with another device, there is a need
for a mechanism that can initiate a communication channel between the
independent devices so that a private data may be exchanged.
A recent technology for transferring data between two devices requires
establishing a communication between a first device and a second device
based on at least one of the devices being shaken and in consequence of
which receiving an indication of a selected data to be transferred from the first
device to the second device, wherein the selected data comprises a non-user
contact, a photo, or a video from the first device and transferring the selected
data to thg second device. Still in existing technologies data transfer is not
reliable and secure.
Accordingly, there remains a need for a system that can efficiently and
securely detect independent devices and exchange information between
them.
SUMMARY
According to the one embodiment of the present invention a system for faceoff
detection and validation comprises a first device having at least one
proximity sensor;
a second device also having at least one proximity sensor;
a server in communication with the first device an; the second device
adapted to:
(i) establish a face-off between the first device and the second device;
(ii) collect a first set of data from the sensor of the first device and a second
set of data from the sensor of the second device:
(iii) authenticate the face-off of the first device with the second device wherein
the authentication involves evaluating the first set of data and the second set
of data: and
(iv) transfer information from the first device to the second device.
According to another embodiment of the invention, the face-off between the
first device and the second device comprises receiving by the second device
a "Face-off Validation Request" from the first device;
receiving by the first device a potential face-off status report from the second
device; wherein the status reports are synchronously or asynchronously
analyzed to have been sent at similar time, that is within a predetermined
interval of time, and the devices are determined to be in similar place, that is
within a predetermined distance limit;
matching of validation request and status report to determine whether the
Face-off is validated:
sending by the server a "Potential Face-off Validation Confirmation" signal to
the first device.
According to yet another embodiment of the present invention, an
autonomous system for exchange of information between a first independent
device and a second independent device comprises initiating a non-contact
face-off by the first device with the second device using the first device
proximity sensor;
detecting the non- contact face-off by the second device based on a second
proximity sensor ;
sending a "Face-off Validation Request" from the first device to the second
device;
sending a "Face-off status report" by the second device to the first device
matching and analyzing by the server synchronously or asynchronously the
status reports and the face of validation request to determine whether the
validation request and the status report have been sent at similar time, that is
within a predetermined interval of time, and the devices are determined to be
in similar place, that is within a predetermined distance limit;
wherein if a match is detected and the Face-off is said to be validated and the
server send a "Potential Face-off Validation Confirmation" signal to the first
device and to the second device,
if there is no match, then the Face-off is said to rejected and server send a
"Face-off Rejection" signal to the first device and to the second device
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 illustrates the different phases of "face-off' method between two or
more than two devices establishing one-way communication
FIG. 2 illustrates the different phases of "face-off method between two or
more than two devices establishing two-way communication
FIG. 3 illustrates the exemplary method for the device clock synchronization
with an eventual third party device clock.
FIG. 4 illustrates the schematic diagram of the device using face-off method
FIG. 5 illustrates the elements of Face-off Status Report of a device which is
sent to server when a potential face-off is detected by a device. When the
"Face-Off Validation Request Flag" is set to positive, the Face-off Status
Report is then also referred to as Face-off Validation Request.
FIG. 6(A) illustrates an exemplary procedure for establishing one-way
communication from device Dl to device D2.
FIG. 6(B) illustrates an exemplary procedure for duplex (two-way)
establishment of communication between the two devices.
FIG. 7 (A) illustrates synchronous face-off method establishing one-way
communication from device Dl to device D2.
FIG. 7 (B) illustrates synchronous face-off duplex (two-way) establishment of
communication between the two devices Dl and D2.
FIG. 7 (C) illustrates synchronous face-off simplex (one-way) establishment of
communication between two devices Dl and D2 in presence of a third device
D3 where the face-off is between device Dl and D2 in presence of device D3
that also sent "Face-off Validation Request" to the server.
FIG. 7 (D) illustrates synchronous face-off simplex (one-way) establishment of
communication between two devices Dl and D2 in presence of a third device
D3 where the face-off is between device Dl and D2 in presence of device D3
that also sent Face-off Status Report to the server.
FIG. 7 (E) illustrates synchronous face-off duplex (two-way) establishment of
communication between two devices Dl and D2 in presence of a third device
D3 where the face-off is between device Dl and D2 in presence of device D3
that also sent "Face-off Validation Request" to the server.
FIG. 7 (F) illustrates synchronous face-off duplex (two-way) establishment of
communication between two devices Dl and D2 in presence of a third device
D3 where the face-off is between device Dl and D2 in presence of device D3
that also sent Face-off Status Report to the server.
FIG. 8 illustrates the asynchronous face-off between two devices Dl and D2
with server S.
FIG. 9 illustrates the exemplary model of device orientation which may be
used during proximity detection.
FIG. 10 illustrates the exemplary mechanism of using complementary device
orientation of the devices Dl and D2 for Face-off validation which may or may
not be used in addition to the other Face-off validation mechanisms.
FIG. 11 illustrates the "Face-off Request Clearing" in the presence of multiple
devices at different location and timestamps during proximity detection
DETAILED DESCRIPTION
A "face-off occurs when two devices interact with each other to autonomically
establish communication for transferring information, files, money, permission
to unlock devices, permission to unlock vehicles, billing and so on. The
devices are intended to have a "face-off" with each other by determining their
proximity, within a given time period in a synchronous or asynchronous
manner without any initial direct device to device communication, and
subsequently establishing communication, once Face-off is established.
A "face-off may be initiated when the two device are brought close to each
other to trigger their proximity sensors. "Face-off method is a process which
includes but not limited to proximity detection, "face-off" validation request to
server, "face-off' validation request clearing and "face-off validation. In
certain cases, the face-off may be validated by complimentary orientation of
the devices.
FIG. 1 illustrates the different phases of "face-off method between the two or
more than two devices establishing one-way communication. The "face-OW'
method comprises of the four phases shown in 100. Phase 1: Proximity
detection by the two devices 105, Phase 2: "Face-off Validation Request" sent
to server by first device Dl and Face-off Status Report sent to server by
second device D2 110, Phase 3: "Face-off Status Reports" clearing by server
115, Phase 4: Face-off validationlrejection communication to devices 120. In
Phase 1, the face-off is initiated when at time t l , the proximity sensor of
device Dl detects another entity in vicinity, which could be device D2. In
similar time t2=tI 00, D2 also detects another entity in vicinity, which could be
device Dl. In Phase 2, device Dl sends "Face-off Validation Request" to
server. Also in Phase 2, device D2 eventually sends "Face-off Status Report"
to server at the same time or at a different time. In Phase 3, the server
receives the "Face-off Validation Request" from device Dl and validates
potential Face-off based on matching of Face-off Status Reports from device
Dl and device D2 as mentioned in FIG. 6(A). On the basis of the result in
Phase 3, the server sends the potential Face-off Validation or Face-off
Rejection message to device Dl.
FIG. 2 illustrates the different phases of "face-off" method between the two or
more than two devices establishing two-way communication. The "face-off'
method comprises the four phases shown in 100. Phase 1: Proximity
detection by the two devices 105, Phase 2: "Face-off Validation Request" sent
to server by both first device Dl second device D2 110, Phase 3: "Face-off
Validation Request" clearing by server 115, Phase 4: Face-off
validation/rejection communication to devices 120. In Phase 1, the face-off is
initiated when at time t l , the proximity sensor of device Dl detects another
entity in vicinity, which could be device D2. In similar time t2=t1 0 0, D2 also
detects another entity in vicinity, which could be device Dl. In Phase 2, device
Dl sends "Face-off Validation Request" to server. Also in Phase 2, device D2
eventually sends "Face-off Validation Request" to server at the same time or
at a different time. In Phase 3, the server receives the "Face-off Validation
Request" from both device Dl and device D2 and validates potential Face-off
based on matching of Face-off Status Reports from device Dl and device D2
as mentioned in FIG. 6(B). On the basis of the result in Phase 3, the server
sends the potential Face-off Validation or Face-off Rejection message to both
device Dl and device D2.
FIG. 3 illustrates the exemplary method for the device clock synchronization
with an eventual third party device clock. In 200, C1 is the device clock of
device Dl. In 210, C2 is the device clock of device D2. In 205, C3 is the
device clock of the 3rd party device. The 3rd party clock could be the server
clock, Internet of Things (IOT) devices clock, a global clock, mobile telephony
network clock or any other deviceldevices clock. The device clock C1 is
synchronized with C3 through one or more than one intermediate clock/clocks
which could be CIA, C12, Clj where i=l to n. The device clock C2 is
synchronized with C3 through one or more than one intermediate clocklclocks
which could be C21, C22, C2j where j=l to m.
FIG. 4 illustrates the schematic diagram of the device using face-off method.
In FIG. 4 Device Dl 320 and Device D2 310 are in proximity to each other.
345 Device Dl is facing towards the proximity sensor of Device D2. 350
Device D2 is facing towards the proximity sensor of Device Dl. The
synchronous or asynchronous "face-off' 325 is initiated when both devices are
at a distance d 340 where d is the distance less than the distance that triggers
their respective proximity sensors. Device Dl sends "Face-off Validation
Request" to the server. Device D l and D2 both send Face-off Status Reports
to Server 305. The Face-off Status Reports could be sent from both devices
to the server through modes such as Mobile Internet, Wi-Fi Internet, SMS etc.
The server uses information in the Face-off Status Reports to validate
potential "face-off" between the devices. If the "face-off' is successfully
validated by the Server, it may be used as a trigger for other actions involving
the two devices such as transfer of information through the server, payment
between the devices, unlocking of deviceldevices, trigger~ng of alarm,
switching on the third device etc.
FIG. 5 illustrates the elements of Face-off Status Report of a device which is
sent to server when a potential face-off is detected by a device. When the
"Face-Off Validation Request Flag" is set to positive, the Face-off Status
Report is then also referred to as Face-off Validation Request. The Face-off
Status Report may include "Face-off Validation Request" Flag 411, Time 415,
Position 425, Communication mode 430 and other additional information 435.
"Face-off Validation Request Flag" determines whether the device sends
"Face-off Validation Request" or Face-Off Status Report. The "Face-off
Validation Request" flag may be set to " Y or ON". A Face-off Status Report
with "Face-off Status Report" flag set to " Y may also be referred to as "Faceoff
Validation Request". The time of a Face-off Status Report is the timestamp
of the device clock when the "face-off' is initiated. The device clock may be
synced with the 3'* party device clock as mentioned in FIG.3. The timestamp
is registered in the Face-off Status Report as the time, when the proximity to
an entity was detected. The position in the device's Face-off Status Report is
the location of the device when the "face-off" is initiated. The Communication
mode in the Face-off Status Report contains information of the medium or
combination of mediums to be used by the server to communicate with the
device. The communication mode could be any mode such as Mobile Internet,
Wi-Fi Internet, Bluetooth, SMS etc. to be sent to the server. The information in
the communication mode is presented as an indication. Other additional
information may include one or many parameters such as complimentary
device orientation, sound, whistle signature, acceleration, Wi-Fi signal
strength, unique id, unique key, fingerprint information of the device user, etc.
An additional optional parameter of complementary device orientation may
also be used. The device orientation is the orientation of the device during the
"face-off. The orientation of the device is the device position relative to the
three axis (commonly known as the X, Y and Z axis of the device coordinates)
- horizontal, vertical and Z axis which points towards the outside of the front
face of the screen. Device orientation may be estimated using device
accelerometer, gyroscope, device alignment relative to gravity, linear
acceleration etc.
FIG. 6 (A) illustrates an exemplary procedure for establishing one-way
communication from device Dl to device D2. Step 500 and the step 506 are
optional opt-in steps respectively where the devices may opt-in to begin the
"face-off' process. The step 502 is the proximity detection step for device Dl
where at time t l , the proximity sensor of device Dl detects another entity,
which could be device D2. The step 508 is the proximity detection step for the
device D2 where at time t2=tlUU, the proximity sensor of device D2 detects
another entity in its vicinity, which could be device Dl. The steps 502 and 508
are the phase "proximity detection" of the face-off method. In step 504, device
Dl sends "Face-off Validation Request" and Face-off Status Report to server.
In step 510, device D2 sends Face-off Status Reports to server. The steps
512, 513, 515,516 are of the phase "Face-off Status Report Clearing" of faceoff
method. The step 512 checks the timestamp in the Face-off Status Report
of both device Dl and D2. The timestamps in the two Face-off Status Reports
need to be within a pre-specified time period O of each other. The step 513
checks if the both devices are in the similar place/location and within a
specific radius. The step 515 checks the additional information provided in the
Face-off Status Reports or in the face-off request. The order of steps 512,
513, 514, 515, 516 is not fixed and may or may not be changed. For
example:- step 516 could be initiated after step 513. Position estimates may
come from global navigational satellite system (GNSS) receiver or through
GPS or through mobile network. The timestamp may be estimated using
FIG.3. The step 516 and 517 are the steps of phase "Potential Face-off
Validation ConfirmationIRejection communication to devices" of the face-off
method. In step 516, based on the outcome of 512 and 513, the server
validates potential Face-off. Confidence level of the validation may be
authenticated by output of additional information step 515. If step 516
concludes potential Face-off validation, then step 517 sends potential Face-off
validation confirmation to device Dl. If step 516 concludes potential Face-off
Rejection, then step 517 sends potential Face-off rejection response to device
Dl.
FIG. 6 (B) illustrates an exemplary procedure for duplex (two-way)
establishment of communication between the two devices. Step 520 and the
step 526 are optional opt-in steps respectively where the devices may opt-in
to begin the "face-off' process. The step 522 is the proximity detection step for
device Dl where at time t l , the proximity sensor of device Dl detects another
entity, which could be device D2. The step 528 is the proximity detect~ons tep
for the device 02 where at time t2=tlUO, the proximity sensor of device D2
detects another entity, which could be device Dl. The step 522 and 528 are
the phase "proximity detectron" of the face-off method. In step 524, device Dl
sends "Face-off Validation Request" to server. In step 530, device D2 sends
"Face-off Validation Request" to server. The steps 532, 533, 535, 536 are of
the phase "Face-off Status Report Clearing" of face-off method. The step 532
checks the timestamp in the Face-off Status Report of both devices Dl and
D2. The timestamps in the two Face-off Status Reports need to be within a
pre-specified time period. The step 533 checks if the both devices are in the
similar place/location and within a specific radrus. The step 535 checks the
additional information provided in the Face-off Status Reports or in the faceoff
request. The order of steps 532, 533, 534, 535, 536 is not fixed and may or
may not be changed. For example: - step 536 could be initiated after step
533. Position estimates may come from global navigational satellite system
(GNSS) receiver or through GPS or through mobile network. The timestamp
may be estimated using FIG.2. The step 536 and 537 are the steps of phase
"Potential Face-off Validation Confirmation/Rejectron communication to
devices" of the face-off method. In step 536, based on the outcome of 532
and 533, the server validates potential Face-off. Confidence level of the
validation may be authenticated by output of additional information step 535. If
step 536 concludes potential Face-off validation, then step 537 sends
potential Face-off validation confrrmation to both device Dl and device D2. If
step 536 concludes potential Face-off Rejectron, then step 537 sends
potential Face-off rejection to both device Dl and device D2.
FIG. 7 (A) illustrates synchronous face-off method establishing one-way
communication from device Dl to device D2. The horizontal axis is the x axis
which represents the time t as measured by a 3rd party reference clock. The
vertical axis is the y-axis which represents the time taken for the devices to
communicate with the server. The line 600 represents the "Face-off Validation
Request" from the device Dl at time TI1 to the server. The line 610
represents the Face-off Status Report being sent from device D2 at time T21
to the server. The difference between the T21 and TI1 may be in the range
from 0 to 0, where is the time-difference in the proximity detection between
the device Dl and D2 plus the time difference due to lag in clock
synchronization between the device clocks and the 3rd party clock. The line
630 represents the potential Face-off validation/rejection response from the
server to the device Dl at time T12. Here, device Dl and D2 sends "Face-off
Validation Request" and "Face-off Status Report" respectively to the server
immediately after the proximity detection with a maximum time lag of 0.
FIG. 7 (B) illustrates synchronous face-off duplex (two-way) establishment of
communication between the two devices Dl and D2. The horizontal axis is
the x axis which represents the time t as measured by a 3rd party reference
clock. The vertical axis is the y-axis which represents the time taken for the
devices to communicate with the server. The line 600 represents the "Face-off
Validation Request" from the device Dl at time TI 1 to the server. The line 610
represents the "Face-off Validation Request" being sent from device D2 at
time T21 to the server. The difference between the T21 and TI 1 may be in
the range from 0 to 0, where 0 is the time-difference in the proximity
detection between the device Dl and D2 and the trme difference due to lag in
clock synchronization between the device clocks and the 3rd party clock. The
line 630 and 640 represents the potential Face-off validationlrejection
response from the server to both device Dl at time TI2 and D2 at time T22
where the difference between the time T22 and TI1 may be from 0 to A,
where A is the time tag for the device to receive the request due to any
reasons such as mobile internet connectivity, mobile network connectivity and
so on. Here, device Dl and D2 sends "Face-off Validation Request" and
Face-off Status Report to the server immediately after the proximity detection
with a maximum time lag of b.
FIG. 7 (C) illustrates synchronous face-off simplex (one-way) establishment of
communication between two devices Dl and D2 in presence of a third device
D3 where the face-off is between device Dl and D2 in presence of device D3
that also sent "Face-off Validation Request" to the server. The horizontal axis
is the x-axis which represents the time t as measured by a 3rd party reference
clock. The vertical axis is the y-axis, which represents the time taken for the
devices to communicate with the server. The line 655 represents the "Face-off
Validation Request" from the device Dl at time TI 1 to the server. The line 660
represents the Face-off Status Report being sent from the device D2 at time
T21 to the server. The line 665 represents the "Face-off Validation Request"
from the device D3 at time T31 to the server. The difference between T21 and
TI 1 and also between T31 and T21 may be in the range from 0 to 0, where o
is the time-difference in the proximity detection between the device Dl-D2
and/or D2-D3 and the time difference due to lag in clock synchronization
between the device clocks and the 3rd party clock. The Face-off Status
Reports of the device Dl and D2 have a greater match than the Face-off
Status Reports of device D3 and D2. The Face-off Status Report of D3 may
differ in terms of one or more parameters such as : timestamp - not valid in
given timestamp range; location - not valid in given location range;
complimentary device orientation - D3 device orientation may not be
complementary to the device orientation of Dl and/or other additional
information contained in the Face-off Status Report. In the synchronous faceoff,
it is assumed that all the three devices - Dl, D2 and D3 have active
communication medium such as Mobile Internet, Wi-Fi-internet, SMS etc. to
the server. When the server receives the Face-off Status Reports of device
D2 and Face-off Validation Request of device Dl and D3, it executes the
""Face-off Validation Request" clearing by Server" phase. Let's assume, the
server successfully val~dates the face-off between Dl and D2 and rejects
Face-off validation with D3 due to invalid matching of D3 Face-off Status
Report w~th Dl Face-off Status Report, then the server sends Face-off
Validation Confirmation to Dl at time TI2 as represented in line 670 and
considers the "Face-off Validation Request" from D3 as an orphan request.
After the predetermined per~od of time, if there is no match found for the
"Face-off Validation Request" for D3, then server sends Face-off Validation
Rejection as represented in line 675.
FIG. 7 (D) illustrates synchronous face-off simplex (one-way) establishment of
communication between two devices D l and D2 in presence of a third device
D3 where the face-off is between device Dl and D2 in presence of device D3
that also sent Face-off Status Report to the server. The horizontal axis is the x
axis which represents the time t as measured by a 3rd party reference clock.
The vertical axis is the y-axis which represents the time taken for the devices
to communicate with the server. The line 655 represents the "Face-off
Validation Request" from the device Dl at time TI 1 to the server. The line 660
represents the Face-off Status Report being sent from the device D2 at time
T21 to the server. The line 665 represents the Face-off Status Report from the
device D3 at time T31 to the server. The Face-off Status Reports of the
device Dl and D2 have a greater match than the Face-off Status Reports of
device Dl and D3. The Face-off Status Report of D3 may differ in terms of
one or more parameters such as : timestamp - not valid in given timestamp
range; locat~on - not valid in given location range; complimentary device
orientation - D3 device orientation may not be complementary to the device
orientation of Dl and/or other additional information contained in the Face-off
Status Report. In the synchronous face-off, it is assumed that all the three
devices - Dl, D2 and D2 have active communication medrum such as Mobile
Internet, Wi-Fi-Internet, SMS etc. to the server. When the server receives the
Face-off Status Reports of D2 and D3 and Face-off Validation Request from
Dl, it executes the "Face-off Validation Clearing" phase. Let's assume, the
server successfully validates the face-off between Dl and D2, then the server
sends Face-off Validation Response to Dl. The server rejects val~dation of
Face-off with D3 due to invalid matching of D3 Face-off Status Report and
considers it as orphan. if there is no match for it for predetermined period of
time, then the D3 Face-Off Status Report is discarded from the server.
FIG. 7 (E) illustrates synchronous face-off duplex (two-way) establishment of
communication between two devices Dl and D2 in presence of a third device
D3 where the face-off is between device Dl and D2 in presence of device D3
that also sent "Face-off Validation Request to the server. The horizontal axis
is the x-axis which represents the time t as measured by a 3rd party reference
clock. The vertical axis is the y-axis, which represents the time taken for the
devices to communicate w~thth e server. The line 655 represents the "Face-off
Validation Request" from the device Dl at time TI 1 to the server. The line 660
represents the "Face-off Validation Request" being sent from the device D2 at
time T21 to the server. The line 665 represents the "Face-off Validation
Request" from the device D3 at time T31 to the server. The difference
between T21 and TI1 and also between T31 and T21 may be in the range
from 0 to U, where is the t~me-differencein the proximity detection between
the device 'Dl and D2' andlor 'D2 and D3' and the time difference due to lag
in clock synchronization between the device clocks and the 3rd party clock.
The Face-off Status Reports of the device Dl and D2 have a greater match
than the Face-off Status Reports of device D3 and D2. The Face-off Status
Report of D3 may differ in terms of one or more parameters such as :
timestamp - not valid in given timestamp range; location - not valid in given
location range; complimentary device orientation - D3 device orientation may
not be complementary to the device orientation of Dl andlor other additional
information contained in the Face-off Status Report. In the synchronous faceoff,
it is assumed that all the three devices - Dl, D2 and D3 have active
communication medium such as Mobile Internet, Wi-Fi-internet, SMS etc, to
the server. When the server receives the Face-off Validation Request of
device Dl, D2 and D3, it executes the "Face-off Status Reports" clear~ng by
server" phase. Let's assume, the server successfully validates the face-off
between Dl and D2 and rejects Face-off validation with D3 due to invalid
matching of D3 Face-off Status Report with Dl Face-off Status Report or D2
Face-off Status Report, then the server sends Face-off Validation
Confirmation to Dl at time TI2 and D2 at t~meT 22 as represented in line 670
and and 675 respectively and considers the "Face-off Validation Request"
from D3 as an orphan request. After the predetermined period of time, if there
is no match found for the "Face-off Validation Request" for D3, then server
sends Face-off Validation Rejection as represented in line 680.
FIG. 7 (F) illustrates synchronous face-off duplex (two-way) establishment of
communication between two devices D l and D2 in presence of a third device
D3 where the face-off is between device Dl and D2 in presence of device D3
that also sent Face-off Status Report to the server. The horizontal axis is the x
axis which represents the time t as measured by a 3rd party reference clock.
The vertical axis is the y-axis which represents the time taken for the devices
to communicate with the server. The line 655 represents the "Face-off
Validation Request" from the device Dl at time TI 1 to the server. The line 660
represents the "Face-off Validation Report" being sent from the device D2 at
time T21 to the server. The line 665 represents the Face-off Status Report
from the device D3 at time T31 to the server. The Face-off Status Reports of
the device D l and D2 have a greater match than the Face-off Status Reports
of device Dl and D3. The Face-off Status Report of D3 may differ in terms of
one or more parameters such as : timestamp - not valid in given timestamp
range; location - not valid in given location range; complimentary device
orientation - 03 device orientation may not be complementary to the device
orientation of D l andlor other additional information contained in the Face-off
Status Report. In the synchronous face-off, it is assumed that all the three
devices - Dl, D2 and D2 have active communication medium such as Mobile
Internet, Wi-Fi-Internet, SMS etc. to the server. When the server receives the
Face-off Status Reports of D3 and Face-off Validation Request from Dl and
D2, it executes the "Face-off Validation Clearing" phase. Let's assume, the
server successfully validates the face-off between Dl and D2, then the server
sends Face-off Validation Response to Dl and D2 as represented in line 670
and 675. The server rejects validation of Face-off with D3 due to invalid
matching of D3 Face-off Status Report and considers it as orphan. If there is
no match for it for predetermined period of time, then the 03 Face-Off Status
Report is discarded from the server.
FIG. 8 illustrates the asynchronous face-off between two devices Dl and D2
with server S. The horizontal axis is the x-axis which represents the time t as
measured by a 3rd party reference clock. The vertical axis is the y-axis, which
represents the time taken for the devices to communicate with the server. The
proximity detection took place between the device Dl and device D2 at time
T. The line 700 represents the "Face-off Validation Request" from the device
Dl to the server at time TI 1. The line 710 represents the "Face-off Validation
Request" from the device D2 to the server at time T21. The "Face-off
Validation Request" for both of the devices Dl and D2 are sent
asynchronously. Asynchronous face-off between device D l and device D2
may be described using following use cases. A) TI 1 is equal to time T and
T21 is T+A : In this case, the communication mode is active for device Dl at
time T but not active for D2 to the server at time t during the proximity
detection. The communication mode could be the mobile internet, Wi-Fi
internet, SMS etc. The timestamp in the Face-off Status Report of Dl may be
equal to the timestamp of "Face-off Validation Request" of Dl to the server
T11. The timestamp in the Face-off Status Report of D2 is T and the
timestamp of "Face-off Validation Request" of D2 to the server is T21= T + A,
where A is the time delay till the communication mode is active for D2. As
soon as the communication mode is active in D2, then the "face-off request" is
submitted to the server for D2. Hence, The time difference between the time t
till time when the communication mode is active is A. B) TI 1 is T+O and T21
is T+A : In this case, the communication mode is not active for both device Dl
and D2 to the server during proximity detection. The timestamp of "Face-off
Validation Request" of Dl to the server is T11= T+O, where is the time
delay till the communication mode is active on the device Dl. The timestamp
of "Face-off Validation Request" of D2 to the server is T21=T+ A, where A is
the time delay till the communication mode is active for D2. C) TI 1 is T+O and
T21 is T: In this case, the communication mode is active for D2, but not active
on Dl to send the "Face-off Validation Request" to the server. The timestamp
of "Face-off Validation Request" for D2 (T21) is equal to the timestamp in the
Face-off Status Report of D2. The timestamp of "Face-off Validation Request"
for Dl is T+n, where 0 is the time delay till the communication mode is active
in the device Dl to the server. In all the three use cases mentioned above, the
face-off requests are submitted to the server at the timestamp which could be
T or T+n or T+ A as mentioned above. Once the "Face-off Validation
Request" is received at the server end, the "Face-off Status Report Clearing"
phase is executed. The line 730 and 740 represents the "Face-off Validation
ConfirmationIRejection" from the server to the devices Dl and D2 at time TI2
and T22 respectively. The response could be the information exchange,
confirmation request etc.
FIG. 9 illustrates the exemplary model of complementary device orientation
which may be used during proximity detection. The device Dl orientation is
represented along the 3 axls in the coordinates frame : x, y and z. The x-axis
820 represents the east-west direction of the device Dl. The y-axis 800
represents the north-south direction of the device Dl. The z-axis 810
represents the up-down direction of the device Dl, perpendicular to the
ground. The device orientation is determined using one or more parameters
such as the device accelerometer, gravity orientation, magnetometer,
gyroscope etc.
FIG. 10 illustrates the exemplary mechanism of using complementary device
orientation of the devices Dl and D2 for face-off validation which may or may
not be used in addition to the other face-off validation mechanisms. The
device orientation may or may not be included in face-off validation. Axis 900,
910 and 920 represents the x, y and z axis of the device Dl orientation
coordinate frame. Axis 930, 940 and 950 represents the x, y and z axis of the
device D2 orientation coordinate frame. The x, y and z axis of the coordinate
frame of the device is explained in FIG. 8. 960 represents the proximity
detection of the device Dl and D2 where both devices detects the proximity
sensor of each other. When the devices D l and D2 detect each other using
proximity detection at the time t, then the device orientation gets stored in the
Face-off Status Report or "Face-off Validation Request" of device Dl and
device D2 respectively. At the time t, both devices could be at any angle and
at position complimentary to each other. For example: Dl and D2 could be at
complimentarily horizontal inclined to each other or could be diagonally
inclined or could be vertically inclined towards each other. When the server
checks the device orientation of the devices during the "Face-Off Request
Clearing'' phase of face-off, then it may or may not check the device
orientation with various cases, which may include but is not limited to:
complimentary orientation of the devices D l and D2 along.^, y and z axes
andlor complimentary orientation of Dl and D2 along either two of the three
axes of the device coordinate frame and/or complimentary orientation of Dl
and D2 along one of the three axes of the device coordinate frame. The
device orientation may be the orientation of the device relative to the gravity
vector and/or accelerometer and/or gyroscope andlor rotation and/or
magnetometer and the like.
FIG. I 1 illustrates the "Face-off Request Clearing" in the presence of multiple
devices at different location and timestamps during proximity detection. Here,
device Dl, D2, D3 and D4 are present at the same location L1. Device D5
and D6 are present at the location L2. The proximity detection occurs
between Dl and D2 at time t, and also between D2 and D3 at time t2, both at
location L1. At L2, the proximity detection occurs between D5 and D6 at time
t3. The "Face-off Validation Clearing" phase of face-off method checks the
timestamp range, location and other additional information such as
complimentary device orientation, whistle signature, light sensor and so on.

WE CLAIM:
1) A system for face-off detection and validation comprising:
a first device having at least one proximity sensor;
a second device also having at least one proximity sensor;
a server in communication with the first device and the second device
adapted to:
(i) establish a face-off between the first device and the second device;
(ii) collect a first set of data from the sensor of the first device and a second
set of data from the sensor of the second device;
(iii) authenticate the face-off of the first device with the second device wherein
the authentication involves evaluating the first set of data and the second set
of data; and
(iv)transfer information from the first device to the second device.
2) The system as claimed in claim 1, wherein the first device and the second
device are selected from, but not limited to phones, smartphones, PCs,
laptops, vehicles, Internet of Things (IOT) devices.
3) The system as claimed in claim 1 or 2, wherein the data collected from the
sensor of the first device includes time stamp, orientation, position,
communication mode and/or other additional information.
4) The system as claimed in any one of claims 1 to 3, wherein the data
collected from the sensor of the second device includes time stamp,
orientation, position, communication mode and/or other additional information.
5) The system as claimed in any one of claims 1 to 4, wherein the information
transferred from the first device to the second device is a data file, a payment
exchange details or an instruction to unlock a vehicle.
6) The system as claimed in any one of claims 1 to 5, wherein the face-off
between the first device and the second device is synchronous.
7) The system as claimed in any one of claims 1 to 5, wherein the face-off
between the first device and the second device is asynchronous.
8) The system as claimed in claim 1 wherein face-off between the first device
and the second device comprises:
receiving by the second device a "Face-off Validation Request" from the first
device;
receiving by the first device a potential face-off status report from the second
device; wherein the status reports are synchronously or asynchronously
analyzed to have been sent at similar time, that is within a predetermined
interval of time, and the devices are determined to be in similar place, that is
within a predetermined distance limit;
matching of validation request and status report to determine whether the
Face-off is validated;
Sending by the server a "Potential Face-off Validation Confirmation" signal to
the first device.
9. The system as claimed in claim 8 wherein the matching of the "Face-off
Validation Request" and Face-off Status Report further include comparing
other additional information such as , but not limited to, complimentary device
orientation, complementary pictures from the screens of the devices, sound,
motion etc.
10) The system as claimed in claims 1-9 wherein the first device, based on
the Potential Validation Face-off confirmation received from the server, may
further confirm the occurrence of the face-off with the second device, and may
send a frnal Face-off confirmation message to the server and/or to the second
device.
11) The system as claimed in claims 1-9 wherein the first device, after
receiving the Potential Validation Face-off Confirmation from the server, may
reject the occurrence of the face-off with the second device, and may send a
final Face-off rejection message to the server and/or to the second device.
12) The system as claimed in claim 1-9 wherein the "Face-off Validation
Request" from first device and the Face-off Status report from the second
device may include the device orientation information and the server may use
the complementary orientation of the two devices as a basis for arriving at a
Match of the reports and for therefore deciding potential face-off validation.
13) The system as claimed in claim 1-12 wherein Based on the Face-off
confirmation signal, the first device transfers the information, data file, money
or any other electronic communication to the second device, either directly or
through the server or through any other communication mechanism that may
or may not be captured in the "Face-off Validation Request" andlor in the
Face-off Status report or in any other communication between the devices
andlor the server or based on pre-determined communication protocols.
14) The system as claimed in claim 1-12 wherein based on the Face-off
confirmation signal, the second device transfer information, data file, money
or any other electronic communication to the first device, either directly or
through the server or through any other communication mechanism that may
or may not be captured in the "Face-off Validation Request" andlor in the
Face-off Status report or in any other communication between the devices
and/or the server or based on pre-determined communication protocols.
15) An autonomous system for exchange of information between a first
independent device and a second independent device comprising:
initiating a non-contact face-off by the first device with the second device
using the first device proximity sensor;
detecting the non-contact face-off by the second device based on a second
proximity sensor
sending a "Face-off Validation Request" from the first device to the second
device;
sending a "Face-off status report" by the second device to the first device
matching and analyzing by the server synchronously or asynchronously the
status reports and the face of validation request to determine whether the
validation request and the status report have been sent at similar time, that is
within a predetermined interval of time, and the devices are determined to be
in similar place, that is within a predetermined distance limit;
wherein if a match is detected and the Face-off is said to be validated and the
server sends a "Potential Face-off Validation Confirmation" signal to the first
device and to the second device,
if there is no match, then the Face-off is said to rejected and server sends a
"Face-off Rejection" signal to the first device and to the second device.
16) The system as claimed in claim 15 wherein the matching between the
"Face-off Validation Request" of first device and with Face-off Status Report
of second device may further include comparing other additional information
such as , but not limited to, complementary d6vice orientation, complementary
pictures from the screens of the devices, sound, motion and so on.
17) The system as claimed in claim 15 wherein the first device, based on the
"Validation Face-off Confirmation" from the server, may further confirm the
occurrence of the face-off with the second device, and may send a final Faceoff
confirmation response to the server and/or to the second device.
18) The system as claimed in claim 15 wherein the first device, after receiving
the Potential Validation Face-off Confirmation from the server, may reject the
occurrence of the face-off with the second device, and may send a final Faceoff
rejection response to the server andlor to the second device.
19) The system as claimed in claim 15 wherein the second device, based on
the Potential Validation Face-off Confirmation from the server, may further
confirm the occurrence of the face-off with the first device, and may send a
final Face-off confirmation message to the server and/or to the first device.
20) The system as claimed in claim 15 wherein the second device, after
receiving the Potential Validation Face-off Confirmation from the server, may
reject the occurrence of the face-off with the first device, and may send a final
Face-off rejection message to the server and/or to the first device.
21) The system as claimed in claim 16-20 wherein based on the Face-off
confirmation, the first device may transfer information, data file, money or any
other electronic communication to second device, either directly or through
the server.
22) The system of claim 16-20 wherein based on the Face-off confirmation,
second device may transfer information, data file, money or any other
electronic communication to first device, either directly or through the server.
23) The system of claim 1-22 wherein If the "Face-off Validation Request"
stays pending at the server for more than a predetermined time, the request
will be treated as an orphaned request and will be timed-out and may not be
considered for further processing in future.