The present invention relates to a drive for use in a computer or a reproduction device for accessing a record carrier, to a computer or a reproduction device having such a drive, to a method of simulating the insertion of a new record carrier and to a computer program for implementing said method.
In certain circumstances it may be needed to initiate a “dialog” with an application or a user to perform specific actions. An example related to, for instance, a special MRW disc (Mount Rainier disc of rewritable type), which is playable in CE (consumer equipment) devices, is that after changing the file content of a disc, a dialog must be started to ask the user if he likes to make his disc compliant with a legacy video player. There are several solutions known to start such a dialog. For example, the insertion of a medium can generate an insert notification to the operating system, which triggers the operating system to retrieve the file system information, after which an auto-run file could start a particular application. Another option is that the user starts such a dialog manually by means of an appropriate program, such as the Microsoft Explorer, after the disc insertion. However, sometimes this can not be done, for example when the drive does not contain a piece of media to start this process from this program.
It is an object of the present invention to provide a solution to the above described problem, in particular to provide a drive for use in a computer or a reproduction device, a device, in particular a computer or a reproduction device, having such a drive and a method of simulating the insertion of a new record carrier into the drive of a computer or a reproduction device which enable the start of an application or any other action even if no auto-run file is available on the disc or if no disc is available at all in the drive.
The object is achieved according to the present invention by a drive as claimed in claim 1 comprising:
The object is further achieved by a device, in particular a computer or a reproduction device, as claimed in claim 9 having:
Further, the object is achieved by a method of simulating the insertion of a new record carrier into a drive of a computer or a reproduction device as claimed in claim 10 comprising the steps of:
A computer program for implementing said method is defined in claim 11. Preferred embodiments of the invention are defined in the dependent claims.
The present invention is based on the idea that the drive mimics the insertion and, preferably, content of a piece of media, including the file system on the disc and its file content. The result can be seen as a virtual disc. According to the invention, based on the occurrence of a new media inserted trigger event, which can be different events as defined in the dependent claims, the drive generates a new media inserted message signalling to the operating system of the computer (also called “host”) or the reproduction device that a new media has been inserted. However, according to the invention, this signal is generated irrespective of the physical insertion of a new media but only based on said trigger event.
Thus, if such an event occurs, even if no new media has been inserted physically into the drive, said new media inserted message will be outputted by the drive after which the operating system of the computer (or the reproduction device) sends a request to the drive to return file system data from a particular location of the record carrier. The drive will then return the requested file system data, which it takes from the requested location of the record carrier, if there is any record carrier present in the drive, or from a separate memory of the drive. The operating system may then evaluate the returned file system data and issue a further read request to the drive, for instance to access a different location of the record carrier, where, for instance, further file system data, an auto-run file or an application file are stored which may then be returned and executed by the computer (or the reproduction device).
For instance, an auto-run file can be started which may include a link to a certain application or perform any other action desired by the user or which is predetermined, for instance, by the manufacturer or the vendor of the drive. This process is thus controlled by the drive according to the present invention.
As mentioned above, the event that triggers the output of said new media inserted message can be different. Preferred embodiment for trigger registration means which check the occurrence of said event are defined in dependent claims and are adapted to the different embodiments of said events. For instance, said event could be an eject command given by a user to eject an inserted media from the drive, or the drive could have an internal timer or an internal clock so that said event is that a predetermined time duration has been elapsed or that a predetermined point in time has been reached.
Another event could be that a particular type of record carrier or a particular record carrier, for instance identified by a unique identifier, has been inserted into the drive whereupon a particular action shall be started, as for instance predetermined by the vendor of said record carriers. Thus, on said record carriers for example data or files could be stored in a special area which can be detected by the trigger registration means as said event whereupon the new media inserted message is outputted by the drive to the operating system.
In another embodiment the carrier access means is operative for reading data from a predetermined location from said record carrier when a trigger event appears. For instance, if special data is written at a certain location on the disc, the occurrence of the trigger event results in the drive generating the “new media inserted” signal. The drive may then change the offset of logical block address 0 such that logical block 16, for example, now lays inside the special data at the mentioned location on the disc. In practice the value for the offset could be written on the disc in a special table which could be stored at a certain predetermined location on the disc, or the value for the offset could be predefined by the vendor or producer of the drive. The user will experience this as a separate view on the disc.
According to another embodiment a user interface is provided in the drive which allows the user to input a trigger command, which may be a user button on the outside of the drive. If the user pushes the button the drive uses the trigger ability provided according to the invention to signal to the operating system that a new record carrier has been inserted and thereupon to contact, for example, the web-site of the vendor of the drive or the vendor of the PC (or the reproduction device) in order to download new firmware or update of programs for the drive or the PC (or the reproduction device).
According to another embodiment the event that triggers the output of said new media inserted message may be detection of an error during execution of a command by the disk drive, and/or the detection by the disk drive of an unknown command, and/or detection that a predetermined time of day/date has been reached. This type of event may be used for example to trigger an automatic download of new firmware for the drive via the Internet.
According to a further embodiment memory means are provided in the drive for storing file system data, which are outputted by the drive in response to a read request from the operating system of the PC. Thus, in case no disc is physically inserted in the drive, after occurrence of a trigger event and after signalling this to the operating system, file system data will be requested by the operating system which will, in this embodiment, be taken from the memory of the drive. Even further, the file system data may include a link to a data file, in particular to an auto-run file or an application file, and said data file itself can also be stored in said memory means. Also an application started by said auto-run file may be provided in the memory of the drive. This memory could be either a ROM or some form of non-volatile memory. The latter would allow to change the behavior of the virtual auto-run ability during the life of the PC drive, while a ROM memory does not allow that.
The invention will now be explained in more detail with reference to the drawings in which
In the schematic diagram of
The operation of a method for running an auto-run file in the computer 1 as proposed according to the invention will be explained with reference to the flow chart shown in
The operating system 3 will also check if an auto-run file is available on the record carrier which will be executed if present. Such an auto-run file may then start running a particular application or performing a particular action as specified in the auto-run file. A user can also start the auto-run file and/or the application manually by means of a particular program such as the Microsoft Explorer after the insertion of the new record carrier. However, when no new record carrier is inserted into the drive 2 or when the record carrier does not contain an auto-run file, this can not be done.
According to the invention a trigger event check unit 23 (also called trigger registration means) is provided in the drive 2 by which the occurrence of a new media inserted trigger event is checked (step S1). Such trigger events can be different events and are used according to the invention to cause the output of a “new media inserted” message (step S2) by the input/output unit 21 of the drive 2 to the operating system 3 (the host). Since such a message is automatically issued by the drive 2 when a new record carrier has in fact physically been inserted into the read/write unit 20, the event check unit 23 does not check such physical insertion as a relevant trigger event, but checks other trigger events as specified in advance. Such trigger events can, for instance, be that a user pushes the button 24, that a predetermined time duration is elapsed or a predetermined point in time has been reached or that a specified type of record carrier or a specified piece of record carrier has been inserted into the read/write unit 20. The drive 2 thus mimics, by issue of the new media inserted message to the operating system 3, the insertion of a new record carrier and thus gets the attention of the operating system 3, although physically a new record carrier has not necessarily been inserted into the drive 2. However, generally when the event is triggered by the insertion of a specified type of record carrier or a specified piece of record carrier, there is a new record carrier inserted into the drive.
The operating system 3 will then (step S3) in response to said new media inserted message issue a read request for reading and returning file system data of said new record carrier in order to know which kind of file system is used on the record carrier. For instance, the operating system 3 will request to read sector 16 which is the file system start address (also called anchor) for an ISO 9660 compliant disc. Further, there might also be different file systems used on the disc having different file system start addresses. In case, the operating system 3 does not get valid or usable file system data in response to the first read requests further read request will be sent to the drive asking the drive to read data from other locations where file system data are typically stored in order to check the presence of valid and usable file system data.
In response to said one or more read requests (S3) the requested file system data will be outputted (step S4) by the drive 2 to the operating system 3. In case no record carrier is present in the read/write unit 20 of the drive 2 such file system data will be taken from the memory 22 of the drive storing file system data for this particular purpose. In another case where a particular type of record carrier or a particular record carrier is present in the read/write unit 20 which triggered the issue of the new media inserted message and which comprises file system data, such file system data might be outputted or, alternatively, file system data stored in the memory 22.
As an example, the drive outputs a piece of data that contains an ISO 9660 file system that, in this example, points to different files, in particular to an auto-run file, to an application and/or an html file, which can also be stored in the memory 22 or, if present, on the record carrier. The operating system 3 will then start reading and running the auto-run file (step S5), which is mimicked by the drive 2 by giving the sectors with the file system data and the auto-run file itself. The auto-run file thereafter (step S6) may have the result that the operating system starts performing certain action, such as e.g. starting certain applications and reading data (e.g. an html file) for that application etc., which are, preferably, also provided to the operating system 3 from the drive 2.
The following example explains the steps of the method in more detail:
In the special case where an auto-run file (“autorun.inf”) shall be executed, the following happens:
The operating system will check the files present on the disc. If in the root directory a file with the name “autorun.inf” is found, the operating system will react by reading the data of that file and tries to execute the commands that are listed in that autorun.inf file.
As a particular example of an application, the computer might then contact the web-site of the vendor of the drive or the vendor of the computer. On this web-site information on new products, interesting documents, downloads (e.g. firmware or updates of program that were delivered with the drive) could be available.
In an embodiment a simulated autorun.inf file may be arranged to command the computer to contact a predetermined Internet address to download and install a firmware update in the drive itself. The downloaded firmware may be stored in a flash EEPROM of the drive for example, for subsequent use when commands are sent to the drive. This type of firmware update may be triggered manually, by a command from a user, or automatically by the drive itself.
Local processor circuit 30 has an interface 38 coupled to the PC (not shown) to receive drive commands. In response to such a drive command the local processor circuit 30 retrieves information from the firmware memory 32 that informs the local processor circuit 30 what to do in response to the command. For example, the local processor circuit 30 may start executing instructions from the firmware memory 32, starting from an address that is determined by the drive command. Preferably, the local processor circuit 30 (or some additional error detection circuit (not shown) in the disk drive) is programmed to detect an unexpected error during execution of the instructions (e.g. that the instructions loop for more than a predetermined time, or that an error exception occurs in during execution of an instruction by local processor circuit etc.). In response to detection the local processor circuit 30 sends the “new media inserted” message to the PC and simulates a medium with an autorun file that causes the PC to download new firmware from a predetermined Internet address into the firmware memory of the disk drive.
As an alternative the local processor circuit 30 may be arranged to send such a “new media inserted” message to the PC when it has received a command from the PC for which no information is yet available in the firmware memory. As another alternative the disk drive may contain a timer circuit that triggers the local processor circuit 30 to send such a “new media inserted” message to the PC when a programmed date or time has been reached. In this way periodic firmware updates may be realized. These alternatives may be used singly or in any combination.
In one embodiment the firmware is downloaded into an EEPROM firmware memory 32 of the disk drive. Alternatively the disk drive may be arranged to load its firmware into a volatile firmware memory 32 from a storage device of the PC (e.g. from a hard disk) each time when the disk drive is reset the firmware, or at start up. In this case a small non-volatile firmware memory may be provided that contains sufficient information to enable the local processor circuit 30 to respond to any command after reset by loading the firmware into the volatile memory 32. Alternatively, this response to a command after reset may include generation of a “new media inserted” message to the PC and simulation of an autorun file that causes the PC to load the firmware into the firmware memory 32 from the PC. In this case firmware downloads are stored in the PC.
Further examples are that as an application a certain view on the disc is shown, that a disc is made compliant with a legacy reproduction device and so on. For instance, an application or service could be started to check on a legacy bridge availability in the case of a special Mount Rainier disc that needs to have a bridge file system on the disc to make the disc playable in a legacy video player. Installed as a service or driver, the service can keep track of changes in the special Mount Rainier disc drag & drop user space and when content has changes that are playable on video recorders. When the disc is ejected the service can start a dialog if needed using the method proposed according to the invention.
According to the invention via a specific action, supervised by the drive, the drive mimics the presence of a disc by sending a disc insertion message to the host. After that the drive will give the host (the virtual) file system contents of the virtual disc, which, for instance, contains a link to an auto-run file. This auto-run file tells the host to perform certain actions, such as going to the specified Internet site or executing a file from the virtual disc. Such a drive can be implemented in a computer, but also in a reproduction device such as a disc player.
Number | Date | Country | Kind |
---|---|---|---|
04100761.8 | Feb 2004 | EP | regional |
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/IB05/50569 | 2/14/2005 | WO | 8/21/2006 |