Porting from Uno to 101 to use BLE features?

I posted this in the 101 section, but project guidance may be more appropriate. I have a project working fine with my Unos, but it might not be feasible to port to the 101. (Or add bluetooth to the Uno.)

First, here's a description of my EXISTING project (Uno):

I own a driving school for teens, and we have 5 vehicles. In each car, I have audio/video surveillance and a DVR. (Occasionally I review recordings to assure quality service.) Some students object to surveillance and since legally we must have consent, I needed to give instructors the ability to turn surveillance off, but only for limited time periods, and/or for a limited number of hours per day. (Because my employees don't like surveillance either, and might otherwise "forget" to turn surveillance back on.)

The project includes an Uno with a "clean" 9V power supply, two relays which are triggered by opening doors or turning the key (either of which turns on the Uno power supply) a module with two more relays controlled by the Uno to route power to the surveillance, and to the Uno itself. (So the Uno can hold its own power supply on for a time period after the doors have been closed and the key is not turned.) It also includes a small display and a button on the dashboard. Further, there is a realtime clock with a battery. The time of day isn't relevant, but the clock allows the system to handle "continuing" the current state after being powered down, as the most recent status and the time such status should expire is stored in EEPROM.

All this is working just fine.

Now here's what I'd like to add with a 101
I'd like to be able to unlock the cars using any previously-recognized phone with bluetooth. That is... When the phone gets in range, the doors unlock. When out of range, they lock. (Ideally, with no phone app required, they'd just have to leave bluetooth on.) This would involve swapping the Uno for a 101 and adding two more relays. (And a lot of tinkering)

In case you're wondering why: Key fobs for electric locks are a logistical problem for us, because instructors take cars home, and I have a fleet runner who rotates the vehicles once a week... Usually late at night. He has to have access to all vehicles, and also keep each key with each vehicle (along with a fob or other means of opening the car), and yet the vehicles must also be secure. Even though I have a spare for each key and fob, I don't have 5 spares of everything. So, using a "lock box" outside each instructor's home is the most obvious solution. But there are issues with such boxes being broken into, and instructors have a tendency to take keys into their homes, forgetting to use the lockbox. (And requiring employees to mount something outside their house isn't cool.)

The scenario I prefer is: The key stays in the vehicle. (Hidden under the dash with a short chain.) No fob at all. Just an Arduino watching for previously-recognized phones to come into or out of range, locking and unlocking doors as appropriate. Every car can be opened by every listed phone in this manner. If an employee leaves the company, I can remove his/her phone from the recognized lists in each car. The Arduino doesn't have to connect to the phones (necessarily)... It just has to see them, recognize them, and respond.

I haven't really done any sketches for 101 yet, but I have already read these pages:

Finally, my concerns (which you can read as questions) are these:

  1. Unless I'm mistaken, the 101 would be the peripheral device, not the central device. As such, the phone isn't broadcasting the advertisements. But...

  2. Maybe the phone could auto-connect such that the 101 could recognize its presence upon connection. Problem with that is, it has to either stay connected (which could interfere with connecting to other devices, such as the car's built-in bluetooth) or repeatedly attempt to connect to recognize that it goes out-of-range.

  3. The range might be too long. (Such that if an instructor is working in his garage with his phone at night, the doors could unlock without his knowledge.)

  4. The range might be too short. (I need it to behave consistently and painlessly, without forcing employees to wave their phone around to establish a connection.)

  5. The time delay to observe the phone may be too long. (If an instructor is within 30 feet, he could be at the car within 2-3 seconds. Will he have to wait another few seconds for his phone to be recognized and the doors to unlock?)

General thoughts or experience would be much appreciated.