U.S. patent application number 16/927058 was filed with the patent office on 2020-11-05 for system and method for supporting data communication in a heterogeneous environment.
This patent application is currently assigned to SZ DJI TECHNOLOGY CO., LTD.. The applicant listed for this patent is SZ DJI TECHNOLOGY CO., LTD.. Invention is credited to Bing XUE, Zhongqian YOU.
Application Number | 20200351354 16/927058 |
Document ID | / |
Family ID | 1000004957535 |
Filed Date | 2020-11-05 |
United States Patent
Application |
20200351354 |
Kind Code |
A1 |
XUE; Bing ; et al. |
November 5, 2020 |
SYSTEM AND METHOD FOR SUPPORTING DATA COMMUNICATION IN A
HETEROGENEOUS ENVIRONMENT
Abstract
Systems and methods for supporting data communication in a
heterogeneous environment, the method including receiving, by a
first device, an identifier value from a second device that is
associated with a software platform installed on the second device;
identifying the software platform based on the identifier value;
determining a device type of the second device based on the
identified software platform; configuring the first device to be in
a host mode or an accessory mode based on the determined device
type of the second device; and establishing data communication
between the first device and the second device via a communication
interface associated with the determined device type of the second
device.
Inventors: |
XUE; Bing; (Shenzhen,
CN) ; YOU; Zhongqian; (Shenzhen, CN) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
SZ DJI TECHNOLOGY CO., LTD. |
Shenzhen City |
|
CN |
|
|
Assignee: |
SZ DJI TECHNOLOGY CO., LTD.
Shenzhen City
CN
|
Family ID: |
1000004957535 |
Appl. No.: |
16/927058 |
Filed: |
July 13, 2020 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
16150488 |
Oct 3, 2018 |
10721309 |
|
|
16927058 |
|
|
|
|
15349151 |
Nov 11, 2016 |
10116753 |
|
|
16150488 |
|
|
|
|
PCT/CN2015/086991 |
Aug 14, 2015 |
|
|
|
15349151 |
|
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04L 67/20 20130101;
H04L 67/12 20130101; H04W 4/80 20180201; H04L 67/141 20130101; H04L
67/146 20130101 |
International
Class: |
H04L 29/08 20060101
H04L029/08 |
Claims
1-30. (canceled)
31. A method for supporting data communication in a heterogeneous
environment, the method comprising: receiving, by a first device,
an identifier value from a second device, wherein the identifier
value is associated with a software platform installed on the
second device; identifying, by the first device, the software
platform installed on the second device based on whether the
identifier value matches a predetermined value corresponding to the
software platform; determining, by the first device, a device type
of the second device based on the identified software platform;
configuring the first device to be in a host mode or an accessory
mode based on the determined device type of the second device for
handling a data communication between the first device and the
second device; and establishing the data communication between the
first device and the second device via a communication interface
associated with the determined device type of the second
device.
32. The method of claim 31, further comprising: transmitting a
message from the first device to the second device to initiate the
data communication, when the first device is configured to be in
the host mode.
33. The method of claim 32, further comprising: exchanging data via
the communication interface, when an acknowledgement message in
response to the message is received from the second device; or
ignoring the second device, when the acknowledgement message is not
received from the second device or an error message is received
from the second device.
34. The method of claim 31, further comprising: switching the first
device from the host mode into the accessory mode, when the first
device is configured to be in the host mode and the second device
is determined to be in a particular device type.
35. The method of claim 34, further comprising: sending a role
switching message from the first device to the second device; and
receiving, by the first device, a message from the second device to
initiate the data communication.
36. The method of claim 31, further comprising: connecting the
first device to the second device using a socket of the first
device, wherein the socket supports connections with different
types of devices associated with different installed software
platforms.
37. The method of claim 36, wherein the socket is adapted to serve
as a charging interface that is associated with different types of
devices.
38. The method of claim 31, wherein the identifier value is a
device descriptor including at least one of a vendor identifier
(VID) or a product identifier (PID).
39. An apparatus for supporting data communication in a
heterogeneous environment, the apparatus comprising: a controller;
and a memory associated with the controller, wherein the memory
stores instructions and the controller is configured to execute the
instructions to: receive an identifier value from a device
connected to the apparatus, wherein the identifier value is
associated with a software platform installed on the device;
identify the software platform installed on the device based on
whether the identifier value matches a predetermined value stored
in the memory corresponding to the software platform; determine a
device type of the device based on the identified software
platform; configure the apparatus in a host mode or an accessory
mode based on the determined device type of the device for handing
a data communication between the apparatus and the device; and
establish the data communication between the apparatus and the
device via a communication interface associated with the determined
device type of the device.
40. The apparatus of claim 39, wherein the controller is configured
to execute the instructions to: transmit a message to the device to
initiate the data communication, when the apparatus is configured
to be in the host mode.
41. The apparatus of claim 40, wherein the controller is configured
to execute the instructions to: exchange data via the communication
interface, when an acknowledgement message in response to the
message is received from the device; or ignore the device, when the
acknowledgement message is not received from the device or an error
message is received from the device.
42. The apparatus of claim 39, wherein the controller is configured
to execute the instructions to: switch the apparatus from the host
mode into the accessory mode, when the apparatus is configured to
be in the host mode and the device is determined to be in a
particular device type.
43. The apparatus of claim 42, wherein the controller is configured
to execute the instructions to: send a role switching message to
the device; and receive a message from the device to initiate the
data communication.
44. The apparatus of claim 39, further comprising: a socket
configured to be connected to the device, wherein the socket
supports connections with different types of devices associated
with different installed software platforms.
45. The apparatus of claim 44, wherein the socket is adapted to
serve as a charging interface that is associated with different
types of devices.
46. The apparatus of claim 39, wherein the identifier value is a
device descriptor including at least one of a vendor identifier
(VID) or a product identifier (PID).
47. A non-transitory computer-readable medium with instructions
stored thereon, that when executed by a processor, perform steps
comprising: receiving, by a first device, an identifier value from
a second device, wherein the identifier value is associated with a
software platform installed on the second device; identifying, by
the first device, the software platform installed on the second
device based on whether the identifier value matches a
predetermined value corresponding to the software platform;
determining, by the first device, a device type of the second
device based on the identified software platform; configuring the
first device to be in a host mode or an accessory mode based on the
determined device type of the second device for handing the data
communication between the first device and the second device; and
establishing a data communication between the first device and the
second device via a communication interface associated with the
determined device type of the second device.
48. The non-transitory computer-readable medium of claim 47, when
executed by the processor, further perform the steps comprising:
transmitting a message from the first device to the second device
to initiate the data communication, when the first device is
configured to be in the host mode.
49. The non-transitory computer-readable medium of claim 48, when
executed by the processor, further perform the steps comprising:
exchanging data via the communication interface, when an
acknowledgement message in response to the message is received from
the second device; or ignoring the second device, when the
acknowledgement message is not received from the second device or
an error message is received from the second device.
50. The non-transitory computer-readable medium of claim 47, when
executed by the processor, further perform the steps comprising:
switching the first device from the host mode into the accessory
mode, when the first device is configured to be in the host mode
and the second device is determined to be in a particular device
type; and sending a role switching message from the first device to
the second device.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation application of
International Application No. PCT/CN2015/086991 filed on Aug. 14,
2015, the content of which is hereby incorporated by reference in
its entirety.
BACKGROUND OF THE INVENTION
[0002] The disclosed embodiments relate generally to information
technologies and more particularly, but not exclusively, to data
communication.
[0003] The success of mobile technologies such as the smart phone
and tablet leads to the explosive development of new technologies,
e.g. smart hardware and the Internet of Things (IoT). For example,
smart hardware, which includes the smart home appliances, smart
monitoring devices and unmanned aerial vehicles (UAVs), can be used
along with the different mobile platforms to achieve better user
experience.
[0004] Various wireless technologies can be used for connecting
devices to a network resource such as the Internet. The
communication link may be established using Wi-Fi technology, e.g.
via a wireless network access point. The Wi-Fi link, which is based
on a client/server model, is easy to develop and can provide
sufficient bandwidth that is enough for supporting a large
variation of applications. For example, the communication can be
established over a network with external routers using standard
sockets based on the Wi-Fi technology.
[0005] However, the Wi-Fi technology may require a full-fledged
operating system for supporting the TCP/IP transport protocol.
Thus, the device based on the Wi-Fi technology may need to have a
processor with high performance capability for supporting this
operating system, which may consume substantial amount of resource
available to the device.
[0006] Additionally, the Wi-Fi technology is not ideal for
application with high security requirements. Using the Wi-Fi
technology, the devices may be exposed on the network, which is
prone to malicious attacks. Also, the Wi-Fi technology may not be
suitable for transporting large amount of data in real time (e.g.
performing video broadcasting), since the wireless protocols (like
other wireless protocols) is easy to be interfered and may suffer
delay in data transport. Moreover, the high energy consumption by
the Wi-Fi technology may significant reduce the battery life of the
smart devices.
[0007] Alternatively, the Bluetooth technology can be used for
supporting short-range low-volume data communication. The Bluetooth
communication connection is simple to implement and easy to
establish network. Also, the Bluetooth technology consumes
relatively lower power and enjoys high communication security.
[0008] However, the Bluetooth technology is not suitable for
performing real-time high-volume data transmission, since the
bandwidth is small (e.g. around 1 Mbit). Also, the Bluetooth
protocol stack is complex and difficult to handle, usually requires
the purchase of a Bluetooth module (i.e. involving extra hardware
cost). In addition, the user experience for the Bluetooth
technology is not ideal, since the devices need to be paired before
the actual usage.
[0009] Hence, there is a need for easily, reliably and securely
connecting the smart devices with different mobile platforms to
achieve better user experience. This is the general area that
embodiments of the invention are intended to address.
BRIEF SUMMARY OF THE INVENTION
[0010] Described herein are systems and methods that can support
data communication in a heterogeneous environment. The system can
establish a connection between a first device and a second device,
wherein the connection is based on a protocol, which associates a
host mode or an accessory mode with one or more connected devices.
Furthermore, a controller on the first device can determine a
device type associated with the second device, and can configure
the first device to be in either the host mode or the accessory
mode, based on the determined device type associated with the
second device, to handle data communication between the first
device and the second device.
[0011] Other objects and features of the present invention will
become apparent by a review of the specification, claims, and
appended figures.
BRIEF DESCRIPTION OF THE DRAWINGS
[0012] The novel features of the invention are set forth with
particularity in the appended claims. A better understanding of the
features and advantages of the present invention will be obtained
by reference to the following detailed description that sets forth
illustrative embodiments, in which the principles of the invention
are utilized, and the accompanying drawings briefly described
herein.
[0013] FIG. 1 is an exemplary illustration of establishing data
communication between different devices, in accordance with various
embodiments of the present invention.
[0014] FIG. 2 is an exemplary illustration of supporting data
communication in a heterogeneous environment, in accordance with
various embodiments of the present invention.
[0015] FIG. 3 is an exemplary illustration of determining a device
type for a connected device, in accordance with various embodiments
of the present invention.
[0016] FIG. 4 is an exemplary illustration of a third party device
using an accessory mode for connecting with an IOS device in a
heterogeneous environment, in accordance with various embodiments
of the present invention.
[0017] FIG. 5 is an exemplary illustration of a third party device
using a host mode for connecting with an ANDROID device in a
heterogeneous environment, in accordance with various embodiments
of the present invention.
[0018] FIG. 6 shows a flowchart of supporting data communication in
a heterogeneous environment, in accordance with various embodiments
of the present invention.
DETAILED DESCRIPTION OF THE INVENTION
[0019] The invention is illustrated, by way of example and not by
way of limitation, in the figures of the accompanying drawings in
which like references indicate similar elements. It should be noted
that references to "an" or "one" or "some" embodiment(s) in this
disclosure are not necessarily to the same embodiment, and such
references mean at least one.
[0020] The description of the invention as following uses a
universal serial bus (USB) protocol as example for a data
communication protocol. It will be apparent to those skilled in the
art that other types of data communication protocols can be used
without limitation.
[0021] In accordance with various embodiments of the present
invention, the system and method can handle the connection between
a device, e.g. a third party smart hardware, with devices based on
different mobile platforms, such as the Android platform and the
IOS platform.
[0022] FIG. 1 is an exemplary illustration of establishing data
communication between different devices, in accordance with various
embodiments of the present invention. As shown in FIG. 1, a data
communication environment 100 includes a device 101 and a device
102, which can exchange data via a connection 110.
[0023] The connection 110 can be based on a data communication
protocol 120, e.g. the Universal Serial Bus (USB) protocol. The USB
protocol, which uses a USB bus, allows only one device on the USB
bus to be in the host mode, and the device in the host mode powers
the bus and enumerates other devices that connect with the device
in the host mode.
[0024] The USB protocol has the advantage of high-bandwidth,
low-latency, and low-cost. Thus, the USB protocol can be used for
supporting high-volume real-time data transmission, such as
real-time video broadcasting. Additionally, the USB bus supports
hot-plug and flexible power supply, and can be used for supporting
processor peripherals
[0025] Furthermore, the connection 110 can be based on other
communication protocols, such as the Wi-Fi protocol and the
Bluetooth protocol. Also, the USB interface can be used as a
charging interface
[0026] As shown in FIG. 1, the device 101 can include a controller
103, which controls the state of the connection 110 that is related
to the device 101. For example, the state can be either a host mode
(e.g. the HOST mode as prescribed by the USB protocol) or an
accessory mode (e.g. the DEVICE mode) that can be associated with
the connected devices 101-102.
[0027] In accordance with various embodiments of the present
invention, once the device 102 is physically connected with the
device 101, the controller 103 can determine a device type
associated with the device 102. For example, the controller 103 can
determine the device type associated with a device based on a
device descriptor, such as a vendor identifier (VID) and/or a
product identifier (PID).
[0028] Based on the determined device type associated with the
device 102, the controller 103 can configure the device 101 in
either a host mode or an accessory mode for handling data
communication between the first device and the second device. For
example, the device 101 can be configured in a host mode (e.g. the
USB HOST MODE) as default.
[0029] Then, via the connection 110, the device 101 can send one or
more video data to an application 104 on the device 102, and
receive one or more commands from the application 104 on the device
102.
[0030] FIG. 2 is an exemplary illustration of supporting data
communication in a heterogeneous environment, in accordance with
various embodiments of the present invention. As shown in FIG. 2, a
device 201 can be connected with different types of devices in a
heterogeneous environment 200.
[0031] In accordance with various embodiments of the present
invention, these different types of devices (or terminals) may use
different USB interfaces. Due to the differences between the
various USB interfaces, a third-party hardware may need to provide
different types of connectors for connecting to the different types
of devices (or terminals), which increases the difficulty for
industrial design and causes more hardware cost.
[0032] For example, the ANDROID devices may use the sockets based
on the MICRO USB standard, while the IOS devices use the sockets
based on the LIGHTNING standard. In order to support both the MICRO
USB interface and the LIGHTNING interface, a third-party hardware
may need to provide different sockets: a MICRO USB socket for
connecting to the ANDROID devices and a LIGHTNING socket for
connecting to the IOS devices.
[0033] In accordance with various embodiments of the present
invention, the system can use the same socket for connecting a
device 201 with different types of devices in the heterogeneous
environment 200.
[0034] As shown in FIG. 2, the device 201 can use a socket 220 for
connecting with an IOS device 203 and an Android device 202. For
example, the device 201 can be a third-party accessory that
provides an external physical interface, e.g. a USB TYPE A socket.
Also, the device 201 can have a processor with USB On-The-Go (OTG)
peripheral, with the USB OTG be configured in the USB HOST
MODE.
[0035] A USB cable can be used for connecting the ANDROID device
202 with the device 201, with a connector 212 plugged into a MICRO
USB socket 211 and a connector 213 plugged into a USB TYPE A socket
220. Alternatively, a different USB cable can be used for
connecting the IOS device 203 with the device 201, with a connector
222 plugged into a LIGHTNING type socket 211 and a connector 223
plugged into the USB TYPE A socket 220.
[0036] Additionally, it is beneficial for a third-party device 201
to use a socket, such as the USB TYPE A socket 220, which may also
be used as a charging interface, since a user can use an original
charging cable for connecting the different mobile devices 202-203
with the third-party device 201.
[0037] After the device 201 is connected with the Android device
202, the device 201 can use a communication interface, e.g. an
Android Open Accessory (AOA) interface, for exchanging data with
the application 204 on the Android device 202. Also, the device 201
can use a communication interface, e.g. a Made for IOS (MFI)
interface, for exchanging data with the application 205 on the IOS
device 202, after the device 201 is connected with the IOS device
202.
[0038] FIG. 3 is an exemplary illustration of determining a device
type for a connected device, in accordance with various embodiments
of the present invention. As shown in FIG. 3, a controller for a
third party device can detect the device type associated with a
connected device in a heterogeneous environment 300, e.g.
determining whether the connected device is an android device or an
IOS device.
[0039] At step 301, a third party device can detect the plugging-in
of a connector into a socket on the third party device. The
controller on the third party device can (request and) obtain a
device descriptor for the device, such as a vendor identifier (VID)
and/or a product identifier (PID) for the device.
[0040] At step 302, the controller can check whether the detected
descriptor matches the IOS descriptor (e.g. whether the VID is
"05AC"). At step 303, the controller can determine that the device
is an IOS device when the detected descriptor matches IOS
descriptor (i.e. the VID is 05AC).
[0041] In accordance with various embodiments of the present
invention, the system can check whether a connected device is
associated with a closed system, before checking whether the
connected device is associated with an open system. The reason is
that a device for a closed system, such as an IOS system, is likely
to have one or more unique descriptor(s), while the same reasoning
may not always be true for an open system such as the ANDROID
system.
[0042] In other words, a connected device with a device descriptor
other than the IOS descriptor is not an IOS device. On the other
hand, there is a chance that a connected device with a device
descriptor other than the ANDROID descriptor may actually be an
ANDROID device.
[0043] At step 304, when the detected descriptor does not match the
IOS descriptor (i.e. the VID is not "05AC"), the controller can
check whether the detected descriptor matches the ANDROID
descriptor (e.g. whether the VID:PID is "18D1:2D00" or
"18D1:2D01").
[0044] At step 305, the controller can determine that the device is
an ANDROID device, when the detected descriptor matches the ANDROID
descriptor (i.e. when the VID:PID is "18D1:2D00" or
"18D1:2D01").
[0045] Furthermore, since there are chances that the connected
device may actually be an ANDROID device even when the detected
descriptor does not match the ANDROID descriptor. At step 306, the
controller can send an AOA control command to the connected device
to explicitly initiating the communication. Then, at step 307, the
controller can check whether a successful acknowledgment (ACK) is
received from the connected device. If a successful acknowledgment
(ACK) is received, the controller can determine that the device is
an ANDROID device. Otherwise, at step 308, the controller may
ignore the device, and consider the type of the device is
unknown.
[0046] FIG. 4 is an exemplary illustration of a third party device
using an accessory mode for connecting with an IOS device in a
heterogeneous environment, in accordance with various embodiments
of the present invention. As shown in FIG. 4, a device 401 can
connect with a device 402 in a heterogeneous environment 400.
[0047] Furthermore, once the device 402 connects with the device
401, the controller 403 on the device 401 can detect a vendor
identifier (VID) 421 for the device 402. For example, if the VID is
"05AC," then the device 402 is in an IOS device. The IOS device 402
can provide a MFI connection interface for connecting with the
third-party accessory, such as the device 401. The MFI interface
may include several modes: such as DEVICE MODE, HOST MODE, and ROLE
SWITCH.
[0048] The controller 403 on the device 401 can send a ROLE SWITCH
command to the IOS device 402 for instructing the IOS device 402 to
entering into the HOST MODE. Also, the controller 403 on the device
401 can configure the device 401 to be in an accessory mode. For
example, the controller 403 on the device 401 can reverse the USB
OTG role from the default USB HOST MODE to the USB DEVICE MODE.
Then, the device 401 can wait for a host node (i.e. the IOS device
402) to initiate a data communication.
[0049] Thus, the IOS device 402 in the USB HOST MODE can establish
a data connection with the device 401 by taking advantage of the
MFI interface. For example, the IOS application 404 can take
advantage of the MFI EA NATIVE TRANSPORT API interface for
exchanging data with the third-party accessories, such as the
device 401.
[0050] FIG. 5 is an exemplary illustration of a third party device
using a host mode for connecting with an ANDROID device in a
heterogeneous environment, in accordance with various embodiments
of the present invention. As shown in FIG. 5, a device 501 can
connect with a device 502 in a heterogeneous environment 500.
[0051] Furthermore, once the device 502 connects with the device
501, the controller 503 can detect a vendor identifier (VID) 521
for the device 502. For example, if the VID: PID is "18D1:2D00" or
"18D1:2D01," then the device 502 is identified as an Android
device.
[0052] The ANDROID device 502 provides an AOA connection interface
for connecting with the third-party accessories. Also, the Android
AOA connection interface can be provided in an accessory mode, e.g.
using a USB DEVICE mode.
[0053] The device 501, which is in a host mode as default, can send
a message to the ANDROID device 502 for establishing the data
communication, via an API based on the AOA protocol. For example,
the application 504, which is an ANDROID APP, can use the AOA-based
API for supporting data exchange with third-party accessories, such
as the device 501.
[0054] On the other hand, if the VID 521 is not recognizable, then
the device 501 may try to send a control command to the device 502,
for instructing the device 502 to enter into the AOA mode
explicitly. If the acknowledgment (ACK) is successful, then the
controller 503 can assume that the device 502 supports the AOA
mode, and the controller can communicate data with the device 502,
via an AOA related API.
[0055] If the acknowledgment (ACK) is not successful, e.g. if the
device 502 fails to respond to the device 501 or responds with an
error message, the device 501 may decide to ignore the device
502.
[0056] FIG. 6 shows a flowchart of supporting data communication in
a heterogeneous environment, in accordance with various embodiments
of the present invention. As shown in FIG. 6, at step 601, a
connection can be established between a first device and a second
device, wherein the connection is based on a protocol, which
associates a host mode or an accessory mode with one or more
connected devices. Then, at step 602, a controller on the first
device can determine that a device type associated with the second
device. Furthermore, at step 603, the controller on the first
device can configure the first device to be in either the host mode
or the accessory mode, based on the determined device type
associated with the second device, to handle data communication
between the first device and the second device.
[0057] Many features of the present invention can be performed in,
using, or with the assistance of hardware, software, firmware, or
combinations thereof. Consequently, features of the present
invention may be implemented using a processing system (e.g.,
including one or more processors). Exemplary processors can
include, without limitation, one or more general purpose
microprocessors (for example, single or multi-core processors),
application-specific integrated circuits, application-specific
instruction-set processors, graphics processing units, physics
processing units, digital signal processing units, coprocessors,
network processing units, audio processing units, encryption
processing units, and the like.
[0058] Features of the present invention can be implemented in,
using, or with the assistance of a computer program product which
is a storage medium (media) or computer readable medium (media)
having instructions stored thereon/in which can be used to program
a processing system to perform any of the features presented
herein. The storage medium can include, but is not limited to, any
type of disk including floppy disks, optical discs, DVD, CD-ROMs,
microdrive, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs,
DRAMs, VRAMs, flash memory devices, magnetic or optical cards,
nanosystems (including molecular memory ICs), or any type of media
or device suitable for storing instructions and/or data.
[0059] Stored on any one of the machine readable medium (media),
features of the present invention can be incorporated in software
and/or firmware for controlling the hardware of a processing
system, and for enabling a processing system to interact with other
mechanism utilizing the results of the present invention. Such
software or firmware may include, but is not limited to,
application code, device drivers, operating systems and execution
environments/containers.
[0060] Features of the invention may also be implemented in
hardware using, for example, hardware components such as
application specific integrated circuits (ASICs) and
field-programmable gate array (FPGA) devices. Implementation of the
hardware state machine so as to perform the functions described
herein will be apparent to persons skilled in the relevant art.
[0061] Additionally, the present invention may be conveniently
implemented using one or more conventional general purpose or
specialized digital computer, computing device, machine, or
microprocessor, including one or more processors, memory and/or
computer readable storage media programmed according to the
teachings of the present disclosure. Appropriate software coding
can readily be prepared by skilled programmers based on the
teachings of the present disclosure, as will be apparent to those
skilled in the software art.
[0062] While various embodiments of the present invention have been
described above, it should be understood that they have been
presented by way of example, and not limitation. It will be
apparent to persons skilled in the relevant art that various
changes in form and detail can be made therein without departing
from the spirit and scope of the invention.
[0063] The present invention has been described above with the aid
of functional building blocks illustrating the performance of
specified functions and relationships thereof. The boundaries of
these functional building blocks have often been arbitrarily
defined herein for the convenience of the description. Alternate
boundaries can be defined so long as the specified functions and
relationships thereof are appropriately performed. Any such
alternate boundaries are thus within the scope and spirit of the
invention.
[0064] The foregoing description of the present invention has been
provided for the purposes of illustration and description. It is
not intended to be exhaustive or to limit the invention to the
precise forms disclosed. The breadth and scope of the present
invention should not be limited by any of the above-described
exemplary embodiments. Many modifications and variations will be
apparent to the practitioner skilled in the art. The modifications
and variations include any relevant combination of the disclosed
features. The embodiments were chosen and described in order to
best explain the principles of the invention and its practical
application, thereby enabling others skilled in the art to
understand the invention for various embodiments and with various
modifications that are suited to the particular use contemplated.
It is intended that the scope of the invention be defined by the
following claims and their equivalence.
* * * * *