Title: Method of and apparatus for communicating data structures between devices in a networking environment
Abstract: An architecture, a system and a method monitors data structures over an IEEE 1394-1995 serial bus network. The data structures are portions of entries posted and stored to a descriptor mechanism. A resource request is submitted by a requesting control device to an AV/C resource schedule bulletin board subunit, where request data is stored and posted. The requesting control device submits a corresponding notify command data frame to the AV/C bulletin board subunit. When a competing control device performs a specified type of access activity on a specified data structure, the bulletin board subunit sends a notify response frame to the original requesting control device. The notify response frame provides an alert to the original requesting control device that the specified access activity has been performed on the specified data structure by a competing control device.
Patent Number: 6,901,444 Issued on 05/31/2005 to Brelin
| Inventors:
|
Brelin; Jon Ebbe (Campbell, CA)
|
| Assignee:
|
Sony Corporation (Tokyo, JP);
Sony Electronics Inc. (Park Ridge, NJ)
|
| Appl. No.:
|
610100 |
| Filed:
|
June 30, 2000 |
| Current U.S. Class: |
709/224; 340/531; 370/232; 709/223 |
| Intern'l Class: |
G06F 015/17.3 |
| Field of Search: |
709/223,224,318
713/320
|
References Cited [Referenced By]
U.S. Patent Documents
| 4780821 | Oct., 1988 | Crossley.
| |
| 5077732 | Dec., 1991 | Fischer et al.
| |
| 5117070 | May., 1992 | Ueno et al.
| |
| 5367679 | Nov., 1994 | Khaira.
| |
| 5394522 | Feb., 1995 | Sanchez-Frank et al.
| |
| 5422883 | Jun., 1995 | Hauris et al.
| |
| 5446733 | Aug., 1995 | Tsuruoka.
| |
| 5471474 | Nov., 1995 | Grobicki et al.
| |
| 5499018 | Mar., 1996 | Welmer.
| |
| 5500934 | Mar., 1996 | Austin et al.
| |
| 5548722 | Aug., 1996 | Jalalian et al.
| |
| 5555413 | Sep., 1996 | Lohman et al.
| |
| 5557724 | Sep., 1996 | Sampat et al.
| |
| 5574867 | Nov., 1996 | Khaira.
| |
| 5682489 | Oct., 1997 | Harrow et al.
| |
| 5719942 | Feb., 1998 | Aldred et al.
| |
| 5724646 | Mar., 1998 | Ganek et al.
| |
| 5781703 | Jul., 1998 | Desai et al.
| |
| 5793366 | Aug., 1998 | Mano et al.
| |
| 5815678 | Sep., 1998 | Hoffman et al.
| |
| 5933430 | Aug., 1999 | Osakabe et al.
| |
| 5991520 | Nov., 1999 | Smyers et al.
| |
| 6055641 | Apr., 2000 | Konaka et al.
| |
| 6094681 | Jul., 2000 | Shaffer et al.
| |
| 6141702 | Oct., 2000 | Ludtke et al.
| |
| 6160796 | Dec., 2000 | Zou.
| |
| 6169725 | Jan., 2001 | Gibbs et al.
| |
| 6233611 | May., 2001 | Ludtke et al.
| |
| 6288716 | Sep., 2001 | Humpleman et al.
| |
| 6292624 | Sep., 2001 | Saib et al.
| |
| 6359557 | Mar., 2002 | Bilder.
| |
| 6363434 | Mar., 2002 | Eytchison.
| |
| 6370688 | Apr., 2002 | Hejna, Jr.
| |
| 6401119 | Jun., 2002 | Fuss et al.
| |
| 6438110 | Aug., 2002 | Rai et al.
| |
| 6466971 | Oct., 2002 | Humpleman et al.
| |
| 6513064 | Jan., 2003 | Horiguchi et al.
| |
| 6516416 | Feb., 2003 | Gregg et al.
| |
| 6546295 | Apr., 2003 | Pyötsiäet al.
| |
| 6584502 | Jun., 2003 | Natarajan et al.
| |
| Foreign Patent Documents |
| 0 577 054 | Jun., 1993 | EP.
| |
| 0 631 247 | Jun., 1994 | EP.
| |
| 0 789 502 | Aug., 1997 | EP.
| |
Other References
Michael Teener et al., "A Bus on a Diet—The Serial Bus Alternative, An
Introduction to the P1394 High performance Serial Bus" Apple Computer, Inc. Santa
Clara, CA, Pub. Date.: Feb. 24, 1992, pp. 316-321.
P1394 Standard For A High Performance Serial Bus, IEEE, 1995.
"The IEEE-1394 High Speed Serial Bus," R.H.J. Bloks, Philips Journal Of Research,
vol. 50, No. 1/2, pp. 209-216, 1996.
|
Primary Examiner: Winder; Patrice
Assistant Examiner: Wang; Liang-che
Attorney, Agent or Firm: Haverstock & Owens LLP
Claims
1. An architecture for monitoring access of descriptors over a network, the architecture
comprising a descriptor mechanism for posting and storing descriptors and corresponding
notify command frames submitted from networked control devices, wherein each descriptor
comprises a unique node address identifying the control device submitting the descriptor
and wherein the corresponding notify command frame instructs the descriptor mechanism
to monitor access of data contained within the descriptor accessed by a competing
control device, wherein the descriptor mechanism is a bulletin board subunit and
the descriptor is a data entry, wherein the bulletin board subunit comprises a
resource schedule bulletin board and wherein the data entries are resource schedule
entries each comprising a start time, a duration time, and an interval time, and
further wherein the resource schedule bulletin board substantially conforms to
an AV/C standard protocol.
2. The architecture of claim 1, wherein the network comprises an IEEE 1395-1995
serial bus and wherein data entries are submitted to the bulletin board subunit
through the network comprising the IEEE 1395-1995 serial bus.
3. The architecture of claim 1, wherein the bulletin board subunit stores a node
address of the competing control device.
4. The architecture of claim 3, wherein the node address of the competing control
device is posted within node ID data fields of the corresponding notify command frames.
5. The architecture of claim 1, wherein the bulletin board subunit generates
a response data frame and sends the response data frame to a unique node address
corresponding to the data entry when the competing control device accesses the
data entry.
6. The architecture of claim 5, wherein the response data frame comprises response
data that includes a node address of the competing device.
7. The architecture of claim 3, wherein the bulletin board subunit records and
further stores access activity of a competing control device when the competing
control device performs at least one activity selected from a group consisting
of reading the data entry, deleting the data entry and modifying a data structure
within the data entry.
8. The architecture of claim 7, wherein activity data is posted within a data
field of the corresponding notify command frame.
9. The architecture of claim 1, wherein the descriptor mechanism stores portions
of the descriptor that are accessed by the competing control device.
10. The architecture of claim 9, wherein the descriptor mechanism stores portions
of data that are accessed by the competing control device within a data field of
the notify command frame.
11. The architecture of claim 10, wherein the notify command frame corresponding
to the unique node address of the data entry is accessible by the control device
identified by the unique node address.
12. The architecture of claim 1, wherein corresponding notify command frames
are submitted after descriptors from networked control devices.
13. A method of monitoring a descriptor posted over a network from a remote control
device, wherein the descriptor comprises a unique node address identifying the
remote control device and wherein the descriptor is stored to a descriptor mechanism,
the method comprising:
a. submitting a notify command to the descriptor mechanism, wherein the notify
command instructs the descriptor mechanism to monitor the descriptor for access
activity by competing control devices; and
b. issuing a notify response to the remote control device when a competing device
accesses the descriptor
wherein the descriptor mechanism is a bulletin board subunit and the descriptor
is a data entry, and further wherein the bulletin board subunit is an AV/C resource
schedule bulletin board and further wherein the data entry is a resource request
comprising a start time, a duration time, and an interval time.
14. The method of claim 13, further comprising recording and storing node addresses
of the competing device accessing the descriptor.
15. The method of claim 14, wherein the node addresses of the competing device
is recorded within a data field of the notify command frame.
16. The method of claim 14, wherein the notify response comprises data that encodes
for the node addresses of the competing device.
17. The method of claim 13, wherein the notify response is issued when the competing
device performs at least one activity selected from a group consisting of reading
the data entry, deleting the data entry and modifying a data structure within the
data entry.
18. The method of claim 13, further comprising recording the access activity
of competing devices.
19. The method of claim 18, wherein the access activity of the competing device
is recorded within a data field of the notify command.
20. The method of claim 13, wherein the notify command frame is submitted after
the descriptor.
21. The method of claim 13, wherein the network substantially complies with a
version of an IEEE 1395-1995 standard.
22. A system for monitoring schedule entries posted to an AV/C resource schedule
bulletin board subunit, the system comprising:
a) a resource device including a dedicated AV/C resource schedule bulletin board
subunit; and
b) a plurality of control devices in communication with the resource device and
capable of posting the schedule entries to the AV/C bulletin board subunit wherein
each of the schedule entries include a unique node address corresponding to the
control device posting the request and wherein the control devices are further
capable of submitting notify command frames with schedule entries, wherein each
notify command frame identifies a corresponding schedule entry, and further wherein
the notify command frame instructs the resource device to monitor access of the
schedule entry by the control device.
23. The system of claim 22, wherein the resource device records and stores node
addresses of control devices accessing schedule entries after the schedule entries
are posted to the resource schedule bulletin board.
24. The system of claim 22, wherein the resource device generates a notify response
and sends the notify response to the unique node address of the schedule entry
when the schedule entry is accessed by one of the control devices.
25. The system of claim 24, wherein the notify response is sent when the corresponding
data entry is read, deleted or otherwise modified by a control device having a
node address that does not correspond to the unique node address of the schedule entry.
26. The system of claim 22, wherein the resource device comprises a video receiver
and transmitter.
27. The system of claim 22, wherein the posting device and the resource device
are coupled together through a network which substantially complies with a version
of an IEEE 1394 standard.
Description
FIELD OF THE INVENTION
The present invention relates to an architecture, a system and a method for communicating
data structures between networked devices. More specifically, this invention relates
to an architecture, system and method for communicating data structures between
devices that are networked with an IEEE 1394 serial bus.
BACKGROUND OF THE INVENTION
The IEEE standard, "IEEE Std 1394-1995 Standard For A High Performance Serial
Bus," is an international standard for implementing an inexpensive high-speed serial
bus architecture which supports both asynchronous and isochronous format data transfers.
Isochronous data transfers are real-time transfers which take place such that the
time intervals between significant instances have the same duration at both the
transmitting and receiving applications. Each packet of data transferred isochronously
is transferred in its own time period. An example of an ideal application for the
transfer of data isochronously would be from a video recorder to a television set.
The video recorder records images and sounds and saves the data in discrete chunks
or packets. The video recorder then transfers each packet, representing the image
and sound recorded over a limited time period, during that time period, for display
by the television set. The IEEE 1394-1995 serial bus architecture provides multiple
channels for isochronous data transfer between applications. A six bit channel
number is broadcast with the data to ensure reception by the appropriate application.
This allows multiple applications to simultaneously transmit isochronous data across
the bus structure. Asynchronous transfers are traditional data transfer operations
which take place as soon as possible and transfer an amount of data from a source
to a destination.
The IEEE 1395-1995 standard provides a high-speed serial bus for interconnecting
digital devices thereby providing a universal I/O connection. The IEEE 1395-1995
standard defines a digital interface for the applications thereby eliminating the
need for an application to convert digital data to analog data before it is transmitted
across the bus. Correspondingly, a receiving application will receive digital data
from the bus, not analog data, and will therefore not be required to convert analog
data to digital data. The cable required by the IEEE 1395-1995 standard is very
thin in size compared to other bulkier cables used to connect such devices. Devices
can be added and removed from an IEEE 1395-1995 bus while the bus is active. If
a device is so added or removed the bus will then automatically reconfigure itself
for transmitting data between the then existing nodes. A node is considered a logical
entity with a unique address on the bus structure. Each node provides an identification
ROM, a standardized set of control registers and its own address space. Because
of these advantages, the IEEE 1394-1995 standard provides for a unique networking
structure that is capable of incorporating audio/video devices, media play/record
devices and computing/display devices.
A diverse range of products can be implemented with the ability to connect to
an
IEEE 1395-1995 serial bus network. These devices can have capabilities and functionality
ranging from very simple to very complex. Specifically, a variety of audio/video
devices, media play/record devices and computing/display devices are capable of
being linked together over an IEEE 1395-1995 serial bus networking structure to
support asynchronous and isochronous data transfers between the devices.
The IEEE 1395-1995 serial bus allows a collection of devices to work together
in a high bandwidth, distributed environment to maximize the overall efficiency
and functionality of the network. This allows manufacturers to remove expensive
pieces of functionality from one device and locate that functionality in another
device on the network, instead of duplicating this functionality in all devices
on the network. While some of the devices have limited functionality and are relatively
inexpensive, such devices require the support and interaction of other devices
in order to bring the full functionality of the devices within the network to the user.
The AV/C Digital Interface Command Set is a command set used for data transactions
between consumer audio/video equipment over an IEEE 1395-1995 serial bus. Neither
the IEEE 1395-1995 serial bus nor the AV/C command set provide a master-slave relationship
between the devices coupled within the IEEE 1395-1995 serial bus network. Instead,
both the IEEE 1395-1995 serial bus and the AV/C command set operate based on a
cooperative peer-to-peer coexistence of devices within the network. Discrete AV/C
command and response data packets are transferred between networked devices over
an IEEE 1395-1995 serial bus in an asynchronous data stream. The AV/C command and
response data packets are typically formatted according to the AV/C protocol outlined
in the AV/C Digital Interface Command Set. Transfers of AV/C command and response
data packets over the IEEE 1395-1995 serial bus network are supported by an AV/C
architecture. The AV/C architecture is comprised of lists and tables that help
devices create, process and/or transmit AV/C command and response data packets.
The AV/C architecture includes an AV/C bulletin board subunit that is typically
dedicated to a resource device subunit such as a tuner, receiver or recoding unit.
An AV/C bulletin board subunit is an information structure that is shared between
devices networked over an IEEE 1395-1995 serial bus network. A resource schedule
bulletin board is also an information structure that supports information shared
between coupled devices within a network. The resource schedule bulletin board
provides the organizational structure through which shared data is organized and
communicated. The resource schedule bulletin board contains sub-boards of lists
with entry descriptors that represent encoded data that can be shared between devices
within the network via descriptor commands. A dedicated AV/C bulletin board subunit
typically supports the information architecture between that device and all compatible
posting devices within an IEEE 1395-1995 serial bus network. A posting device writes
a request entry to a write enabled list within the resource schedule bulletin board
specifying when it will use the resource.
Neither the IEEE 1395-1995 serial bus nor the AV/C Command Set provide a
master-slave relationship between the devices coupled within the IEEE 1395-1995
serial bus network. Instead, both the IEEE 1395-1995 serial bus and the AV/C Command
Set operate based on the cooperative peer-to-peer coexistence of devices within
the network transmitting data formatted in accordance with the AV/C protocol. The
communicating devices exchange command and response data directly with each other
without the intervention of a systems resource manager. Each device or device subunit
is responsible for managing scheduling affairs and storing resource requests.
Within the current AV/C protocol, resource time of a resource device is made
available to any requesting control device. Within this protocol a device competing
for use of a resource device can acquire the right to use the resource device by
reserving the resource device, even though another client device may have previously
submitted an entry to the resource schedule board requesting the resource device
at the same time. Devices may modify or delete data contained within the schedule
entries submitted by other requesting control devices without acknowledging to
the other requesting control devices that their respective schedule entries are
being or have been modified. Thus, within the current AV/C protocol there is no
method to allow control devices within a network to monitor schedule data or to
provide a peer-to-peer review of schedule modifications.
SUMMARY OF THE INVENTION
The method of and apparatus for communicating data structures between devices
in a networking environment of the present invention is an architecture, a method
and a system for monitoring data structures written to and stored in a descriptor
mechanism. The invention is particularly useful for monitoring data structures
submitted to a bulletin board subunit from networked control devices. Preferably,
the control devices are networked together with an IEEE 1395-1995 serial bus network
and the bulletin board subunit is an AV/C resource bulletin board subunit that
is dedicated to a resource device, such as a VCR or other audio video device. The
data structures are preferably resource schedule entries, or portions thereof,
posted to acquire resource time from a resource subunit of the resource device.
Each schedule entry stored to the AV/C resource bulletin board subunit specifies
the node address of the requesting control device, the resource subunit that is
being requested and the time or times that the resource is being scheduled. According
to the current invention, schedule entries are monitored for access activity after
being stored to the AV/C resource schedule bulletin board subunit by an original
requesting control device. In the event that the schedule entry is accessed by
a competing control device after it has been stored to the resource schedule bulletin
board, a notify response is sent to the node address of the original requesting
control device which notifies the original requesting control device that the schedule
entry has been accessed by the competing control device.
Preferably, the original requesting control device specifies the data
structure or data structures within the schedule entry that are to be monitored.
The original requesting control device specifies the data structures that are monitored
by providing a corresponding notify command with the schedule entry when the resource
request is submitted to the AV/C resource schedule bulletin board. However, it
is considered to be within the scope of the invention that the original requesting
control device also submits notify commands to the resource schedule bulletin board
at any time that schedule entries are stored in the AV/C resource schedule bulletin
board subunit of the resource device. It is also preferable that requesting control
devices specify the type of access activity that is to be monitored. For example,
when a requesting control device submits a write notify command with a schedule
entry, then the schedule entry is monitored for write access activity by competing
control devices. In the event that a competing control device writes data or deletes
portions of the specified data structure within the schedule entry, then a write
notify response is sent to the node address of the requesting control device. Similarly,
when a requesting control device submits a read notify command with a schedule
entry, then the schedule entry is monitored for read access activities by competing
control devices. In the event that a competing control device reads the specified
data structure within the monitored schedule entry, then a read notify response
is be sent to the node address of the requesting control device.
According to another embodiment of the present invention, schedule entries
are automatically monitored for access activity that is performed by competing
control control devices. Anytime that a competing control device reads a schedule
entry, writes to a schedule entry or otherwise modifies a schedule entry that is
stored in the AV/C resource schedule bulletin board subunit, a notify response
is sent to the original requesting control device to notify the original requesting
control device that the schedule entry has been accessed. The original requesting
control device is provided an opportunity to review any modifications made to the
schedule entry by the competing control device.
A notify command data frame, according to the present invention, contains a data
field that captures the address of a competing device that accesses the specified
data field of the monitored schedule entry. Further, the notify command data frame
contains a data field that captures portions of the specified data structure accessed
by the competing control device and provides codes representative of the access
activity performed by the competing device. The data contained within the notify
command frame is preferably stored in the memory unit of the AV/C resource bulletin
board subunit to provide a detailed history of the schedule entry and access activities
relating thereto.
A notify response data frame of the present invention provides an alert message
to an original requesting control device when the specified data structure of a
monitored schedule entries is accessed by a competing control device. According
to an alternative embodiment of the present invention, a notify response command
also provides the original requesting control device with information about a competing
control device and access activity performed on the monitored schedule entry. Accordingly,
notify response data frames contain data fields that post the node address of the
competing control device and portions of the specified data structure accessed
or modified by the competing control device.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 illustrates a block diagram of an exemplary IEEE 1395-1995 serial bus
network including a computer system and a video camera.
FIG. 2 illustrates a block diagram of the internal components of the computer
system 10.
FIG. 3 illustrates a block diagram of a network system within an IEEE 1394-1995
Serial Bus Network according to the present invention.
FIG. 4 shows a control device schedule request and a resource device schedule
entry at a target device.
FIG. 5 shows a detailed resource schedule sub-entry.
FIG. 6 illustrates a block diagram of a system with control devices capable
of posting schedule entries to an AV/C bulletin board subunit of a coupled resource device.
FIG. 7
a illustrates a requesting control device submitting a schedule
entry with a write notify command to an AV/C resource schedule bulletin board subunit
according to the present invention.
FIG. 7
b illustrates a competing control deleting a portion of the schedule
entry posted by the original requesting control device in FIG. 7
a.
FIG. 7
c illustrates the AV/C resource schedule bulletin board subunit
sending a write notify response to the original requesting control device according
to the present invention.
FIGS. 8
a-b show write notify command frames submitted to an AV/C resource
schedule bulletin board subunit according to the present invention.
FIGS. 9
a-b show read notify command frames submitted to an AV/C resource
schedule bulletin board subunit according to the present invention.
FIG. 10 illustrates a flow diagram for monitoring a schedule data structure
according to the preferred embodiment of the present invention.
DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT
A block diagram of an exemplary IEEE 1395-1995 serial bus network including a
computer
system and a video camera is illustrated in FIG.
1. The computer system
10 includes an associated display
12 and is coupled to the video
camera
14 by the IEEE 1395-1995 serial bus cable
16. Video data and
associated data are sent between the video camera
14 and the computer
10
over the IEEE 1395-1995 serial bus cable
16.
A block diagram of the internal components of the computer system
10 is
illustrated in FIG.
2. The computer system
10 includes a central
processor unit (CPU)
23, a main memory
21, a video memory
25,
a mass storage device
24 and an IEEE 1394-1995 interface circuit
19,
all coupled together by a conventional bidirectional system bus
29. The
interface circuit
19 includes the physical interface circuit
17 for
sending and receiving communications over the IEEE 1395-1995 serial bus. The physical
interface circuit
17 is coupled to the camera
14 over the IEEE 1395-1995
serial bus cable
16. In the preferred embodiment of the present invention,
the interface circuit
19 is implemented on an IEEE 1395-1995 interface card
within the computer system
10. However, it should be apparent to those skilled
in the art that the interface circuit
19 can be implemented within the computer
system
10 in any other appropriate manner, including building the interface
circuit onto the motherboard itself. The mass storage device
24 may include
both fixed and removable media using any one or more of magnetic, optical or magneto-optical
storage technology or any other available mass storage technology. The system bus
29 contains an address bus for addressing any portion of the memory
25
and
21. The system bus
29 also includes a data bus for transferring
data between and among the CPU
23, the main memory
21, the video
memory
25, the mass storage device
24 and the interface circuit
19.
The computer system
10 is also coupled to a number of peripheral input
and output devices including the keyboard
26, the mouse
28 and the
associated display
12. The keyboard
26 is coupled to the CPU
23
for allowing a user to input data and control commands into the computer system
10. A conventional mouse
28 is coupled to the keyboard
26
for manipulating graphic images on the display
12 as a cursor control device.
A port of the video memory
25 is coupled to a video multiplex and shifter
circuit
11, which in turn is coupled to a video amplifier
27. The
video amplifier
27 drives the display
12. The video multiplex and
shifter circuitry
11 and the video amplifier
27 convert pixel data
stored in the video memory
25 to raster signals suitable for use by the
display
12.
FIG. 3 illustrates a system of devices
30 coupled within an IEEE 1394-1995
serial bus
33 according to the present invention. The video monitoring devices
31 and
35 are audio/video devices and are coupled to a video recording
and media playing device
37 by the IEEE 1395-1995 serial bus
33,
as shown. A computing unit
32 is also coupled to the video recording and
media playing device
37 by the IEEE 1395-1995 serial bus
33. When
a user enters a scheduling request to the computer system
32, the computer
system
32 transmits appropriate scheduling request information to the resource
schedule board maintained by the video recording and media playing device
37.
The schedule information is stored in a posted schedule entry in an AV/C resource
schedule bulletin board. FIG. 3 is illustrative only and there are number of system
configurations and a diverse range of devices that can be supported within an IEEE
1395-1995 serial bus to provide point-to-point data stream transmissions. Further,
there is no systems limitation that all the devices coupled within the IEEE 1395-1995
serial bus need to be used in order to practice the invention.
FIG. 4 illustrates an exemplary network of devices including a posting device
41 and a target device
43. In an embodiment of the invention, resource
schedule entries
44, as shown in FIG. 4 contain schedule information for
resources. Resource request entries are generated from networked client or scheduling
devices
41 using any suitable method known in the art, such as a scheduling
protocol supplied with a typical VCR device. The resource request entries are used
by a target device
43 which includes the bulletin board subunit including
a resource schedule board (RSB)
45 to build a resource schedule according
to resource times that are allocated to various resource subunits for the requesting
networked client devices. In one embodiment of the current invention, the scheduling
data and scheduling architecture is transparent to the user and provides information
to coordinate data transfer between devices at a systems level. In another embodiment
of the current invention scheduling data and resource schedules are accessible
to the users over the network. In further embodiments of the invention, viewable
scheduling menus and resource schedules are generated by a graphical user interface.
A schedule entry is generated by entering schedule data into a scheduling menu
and submitting the data as a resource request from the posting device
41
to the target device
43 over the network. Resource requests for all the
requesting client devices are stored in a memory unit at a central location and
the graphical user interface generates viewable resource schedules therefrom. The
internal data structure and the graphical interface used for supporting the scheduling
menus is application and device dependent.
Again referring to FIG. 4, resource requests are made by entering schedule
data including a start time and date, a duration time, repeat information including
an interval value and a number of events value, if appropriate, and a resource
indicator in the resource request entry box
42. A resource request containing
the scheduling data shown in the box
42 is submitted over the network and
transferred to or used to make a new resource schedule entry
44. The resource
schedule board
45 includes one or more entries
44, each representing
a received resource request and specification indicating that the posting device
intends to utilize the resource device according to the information specified in
the resource schedule entry
44. In accordance with an alternative embodiment
described above, field values in the resource schedule entries
44 are used
to provide a graphical user interface with scheduling data needed to generate a
resource schedule accessible over the network.
FIG. 5 illustrates a view
50 of a high level schedule entry section
51
detailing the schedule entries that are input from a posting or scheduling device
to provide a complete resource request. The start time is input in the entry block
57, the duration time is input in the entry block
59, and resource
device information is input in the entry block
58. The repeat-time sequences
are input in the entry blocks
55 and
52. Only one of the entry blocks
55 and
52 will be used in each entry, as appropriate. The entry block
52 is used for resource schedule entries to be repeated on a weekly basis.
The entry block
55 is used for resource schedule entries to be repeated
on a specific interval basis.
In order to specify the repeat-time sequence entries, a number of events value
and a repeat interval are required. The number of events value can be equal to
any appropriate number, including one, and specifies the number of times the entry
is to be repeated. The repeat interval is the time between events and can be daily,
weekly, monthly or any appropriate interval. For example, in the entry block
52,
intervals such as daily, weekly or monthly are input along with a number in the
number_of_events field which specifies the number of events value and represents
the number of times that the request is to be executed, and thus defines the overall
duration. Also, certain days of the week can be blocked out or not included within
the schedule. By blocking out dates within an overall duration, the resource can
be more efficiently used by other client devices. For example, a schedule request
can contain field values that indicate a resource is needed every day for two weeks
except for Tuesday of the second week. Thus, by viewing the resource schedule,
other client or scheduling devices can see that the resource is available on that
Tuesday and schedule resource time accordingly. It is convenient to provide day
selections such as Monday, Thursday etc., as shown in block
52, wherein
when a user schedules the resource for a particular day, the resource will automatically
be scheduled for that selected day for the overall duration of the schedule entry.
The entry block
55 shows an entry form used for resource schedule entries
to be repeated on a specific interval basis. In the entry line
56 a time
interval is input, which is either a regular time interval (such as an hour or
a day) or an irregular time interval that does not follow a naturally repeating
block of time. On the entry line
54, the number of events value is input
specifying the number of times the resource request is to be executed. For example,
if a user inputs a schedule entry with an interval value corresponding to one hour
and 20 minutes and a number of events value equal to nine, then the shared resource
will be scheduled for nine one hour and 20 minute intervals, starting at a time
specified in the entry block
57, with a duration as specified in the duration
entry block
59.
The time data fields for resource requests and schedule entries are chosen to
reflect appropriate application of the system. For example, when scheduling audio/video
equipment for home or entertainment it is typically sufficient to specify the hours,
minutes and seconds of the request such as those shown in block
59. However,
there are particular applications where the time data fields need to be expanded
to encompass greater or smaller increments of time. For example, an astronomical
study of deep space, may require that audio/video equipment be scheduled for very
precise periods of time over the course of a year or more. Therefore, the time
data fields that are shown in blocks
57 and
59 are only exemplary
and it is understood that they can be expanded to encompass any increment of time
that is suitable for the application at hand.
FIG. 6 illustrates a system
60 with a resource device
63, two
posting control devices
65 and
67 and an AV/C bulletin board subunit
61 according to the present invention. The solid lines
110 and
111
represent lines of content transmission from the resource subunits
62 and
64, respectively. The dashed lines
112,
113,
114 and
115 represent lines of control data transmission from the control devices
65 and
67 and from the resource subunits
62 and
64
to the AV/C resource schedule board subunit
61. The AV/C resource schedule
board subunit
61 has an AV/C bulletin board
66 and a memory/CPU unit
69, wherein schedule entries and scheduling data is organized and stored.
Control devices
65 and
67 submit resource requests
68 and
68′ to the resource schedule bulletin board
66, where the
requests are organized and posted as schedule entries and stored in the memory
69 of the subunit
61. Organized schedule entries within the AV/C
resource schedule bulletin board provide a resource calendar. Resource time from
each of the resource subunits
62 and
64 is allocated to the requesting
control devices
65 and
67 according to the resource schedule calendar.
Again referring to FIG. 6, the AV/C bulletin board subunit
61 is preferably
transparent to the user and the schedule calendar is updated or modified at the
systems level. However, it is considered to be within the scope of the present
invention that the AV/C bulletin board subunit
61 is supported by a graphical
user interface program (not shown) that provides for direct user participation
with device scheduling.
Still referring to FIG. 6, the resource requests
68 and
68′
submitted by the control client devices
65 and
67 are accompanied
with corresponding notify commands. According to a preferred embodiment of the
present invention, the notify commands instruct the resource schedule bulletin
board subunit
61 to monitor schedule entries posted to the bulletin board
66 and stored in the memory unit
69.
FIG. 7 shows a system with a requesting control device
76 and a competing
150 control device
78. The requesting control device
76 and
the competing control device
78 are both capable of posting schedule entries,
such as those illustrated by blocks
72 and
74, to the resource schedule
bulletin board
73. The bulletin board subunit
73 is preferably an
AVIC resource schedule bulletin board subunit that is dedicated to an audio/video
resource device, such as described in FIG.
6. The bulletin board subunit
73 has a memory unit (not shown) for storing the posted schedule entries
72,
73 and
75. Each of the schedule entries
72,
73
and
75 contain data fields with data that identifies the requesting control
device, specifies a resource subunit being scheduled and the time or times that
the resource subunit is being requested.
Again referring to FIG. 7
a, the requesting control device
76
submits a resource request
70 over a network to the bulletin board
71
where the request
70 is posted as the schedule entry
75. Preferably,
the original requesting control device
76 and the competing control device
78 are coupled to the node including the bulletin board subunit
73
by an IEEE 1395-1995 serial bus. According to the present invention, the requesting
control device
76 submits a corresponding notify command
77 with
the schedule request
70 to the bulletin board subunit
73 instructing
the bulletin board subunit
73 to monitor the schedule entry
75 for
a specified access activity.
Now referring to FIG. 7
b, the competing control device
78 accesses
the schedule entry
75 and performs an access activity
70′.
The access activity
70′ includes either deleting the schedule entry
75, reading the schedule entry
75 or otherwise modifying the schedule
entry
75. The bulletin board subunit
73 determines if the access
activity
701 performed by the competing control device
78 is on the
same descriptor specified within the notify command
77 submitted by the
original requesting device
76.
Now referring to FIG. 7
c, if the access activity
70′ performed
by the competing control device
78 is on the same descriptor that is specified
by the notify command
77, then the bulletin board subunit
73 sends
a response notify command
77′ to the requesting control device
76.
The response notify command
77′ informs the control device
76
that the schedule entry
75 has been accessed by a competing device
78.
According to an embodiment of the present invention, the notify response
77′
provides data that specifies the access activity
70′ performed by
the competing control device
78 and identifies the node address of the competing
control device
78 within the network.
Again referring to FIG. 7
a, according to the preferred embodiment of
the invention the requesting control device
76 submits a notify command
77 to a bulletin board subunit
73 concurrently with a corresponding
schedule request
70. While it is preferred that the notify command
77
is submitted immediately after the resource request
70, it is considered
to be within the scope of the current invention that the notify command
77
is submitted to the bulletin board subunit
73 at any time during the time
period that the schedule entry
75 is stored or maintained within the subunit
73.
The write notify command preferably has the following format:
- WRITE DESCRIPTOR, ctype=NOTIFY
A read notify command preferably has the following format:
- READ DESCRIPTOR, ctype=NOTIFY
As described herein, both the write notify command and the read notify command
are submitted to a descriptor mechanism, such as the bulletin board subunit, by
an original requesting device. If a competing control device then accesses the
specified descriptors, the descriptor mechanism notifies the original requesting
device, in response to the write or read notify command.
Schedule entries, such as those described in FIGS. 4 and 5, contain descriptor
data structures and information data structures. Descriptor data structures provide
data that specifies the requesting control device or the resource subunit that
is being scheduled. The information data structures provide data that specifies
the schedule action such as the start time and the duration time. It is preferred
that notify commands submitted with schedule requests according to the present
invention specify the data structure being monitored within the corresponding schedule
entry. Thus, according to the preferred embodiment of the present invention, both
the access activity monitored and the data structure monitored are specified by
the notify command.
FIG. 8
a illustrates a write descriptor notify command frame
80
in accordance with the present invention. The command frame
80 is submitted
to a bulletin board subunit with a schedule request and instructs the bulletin
board subunit to monitor a specified descriptor data field contained within the
corresponding schedule entry for write access activity by a competing control device.
The descriptor data of the specified descriptor data field is duplicated within
the descriptor_specifier data field
81 of the notify command frame
80.
The subfunction data field
83 contains data that encodes for the type of
write access activity that was performed on the descriptor data by the competing
control device. For example, when descriptor data is changed, replaced, inserted,
deleted, partially replaced or any combination thereof, by the competing control
device, the subfunction data field
83 within the notify command frame
80
will provide the data that encodes for the activity. The node_ID data field
82
provides identification data of the competing control device that has accessed
the specified descriptor data. The data_length data field
84 codes the command
frame
80 for a change in the length of the descriptor data within the specified
descriptor data field as a result of the write access activity performed by the
competing control device and the address data field
79 provides data that
codes for the descriptor address where the change occurred.
FIG. 8
b, illustrates a write information block notify command frame
85
in accordance with the present invention. Similar to the command frame
80,
illustrated in FIG. 8
a, the command frame
85 is submitted to a bulletin
board subunit with a resource request and instructs the bulletin subunit to monitor
a specified information data field contained within the corresponding schedule
entry for a write access activity by a competing control device. The information
data of the specified information data field is duplicated within the info_block_reference_path
data field
87 of the notify command frame
85. The subfunction data
field
89 contains data that encodes for the type of write access activity
that was performed on the information data by a competing device. For example,
when information data is changed, replaced, inserted, deleted, partially replaced,
or any combination thereof, by the competing control device, the subfunction data
field
89 will provide the data that encodes for the type of write access
activity performed by the competing control device. The node_ID data field
86
provides identification data of the competing control device that accessed the
specified information data field. The data_length field
88 codes the command
frame
85 for a change in the length of the information data within the specified
information data field as a result of the write access activity performed by the
competing control device and the address data field
189 provides data that
codes for the descriptor address corresponding to the location where the write
activity began.
FIG. 9
a, illustrates a read descriptor notify command frame
90
in accordance with the current invention. The command frame
90 is submitted
to a bulletin board subunit and instructs the bulletin subunit to monitor a specified
descriptor data field contained within a corresponding schedule entry for read
access activity by a competing control device. The descriptor data of the specified
descriptor data field is duplicated within the descriptor_specifier data field
91 of the notify command frame
90. The node_ID data field
93
provides identification data of the competing control device that accessed the
specified descriptor data field. The datalength field
92 codes the
