First issue: IN transactions go device to host, not host to device. The host polls for them, certainly, but the transaction results in data going in to the host. Though I guess the token itself actually does go "host to device"...but anyway.
Now, my guess as to why you might not see a token every 9 milliseconds: The device might not have data ready and has NAK'd the request. This not unrecoverable and the host will simply poll again after
bInterval, but data is not received. That is probably why you are only seeing an IN token every 35ms: The device only has data ready to send every 35ms (as for an idea why your analyzer might not be showing you the NAK'd IN tokens, stay tuned). The
bInterval setting gives it the opportunity to send data every 9ms, but it is not obligated to do so. This provides the "guaranteed latency" feature of INTERRUPT endpoints.
NAKing like this is completely normal and in fact, many devices will continuously NAK the request until something actually happens (especially in the case of HID).
Now for a bit of speculation: If you are using a software protocol analyzer, it will probably only capture completed transactions which would mean that your IN tokens would only show up once the device actually sends data. You likely won't be able to see the NAKs, unless it has interfaced fairly deeply with the host USB controller or at least the dark underbelly of the OS. A hardware protocol analyzer (such as a TotalPhase Beagle or one of those Teledyne LeCroy Voyager/Mercury/Advisor devices) would probably show you NAKs, so if you are using one of those perhaps you can configure it to show them to you to verify that the device is actually NAKing every 3 or 4 pollings?
Now, if you actually are seeing NAK'd IN tokens and they only occur every 35ms then I'm completely wrong. You should see a NAK every 9ms (on a hardware analyzer) if my guess above is correct.