Nonono! Table Scans mean that SQL Server is scanning through the entire table to select the subset of rows that match the results of your query. Your indexes are clearly NOT being utilized.
Typically, you'll have two types of indexed access in SQL Server -- Index Scan and Index Seek.
Index Scan is a quick scan across the values in an index column to extract the subset of rows that match your query. An Index Scan is necessary when selecting nonsequential rows over an indexed column, whether it's the primary key column or not.
Non-primary/unique/sorted indexes are stored by SQL Server in it's own internal tables, which is why they're called "non-integrated" indexes. The storage for the index table is not "built-in" to the actual table. These index tables keep a sorted copy of the index column with row pointers to the corresponding rows in your original table. When SQL Server performs index scans, it uses these internal index tables to quickly return the subset of row pointers that match your query.
Index Seek occurs when SQL Server needs to select a single, continuous set of rows using an "integrated index" (typically just the primary key column, integrated indexes can be over several columns as long as the values are sorted and unique). WHERE clauses over a sorted, unique, set of columns only require one or two seeks for the whole table. These seeks locate "bookmark" rows that form the endpoints of a query.
If your where clause specifies x > Y or X < Y, you'll only need one bookmark to specify the first or last rows, respectively. In the X > Y case, the last row in the table is the end point of your result rowset. Conversely, in the X < Y case, the first row in the table is the start point of your result rowset. This is guaranteed because column X is already sorted.
If you have X = Y, your query will use two index seeks, one for the first row and one for the last. If your WHERE clause covers the entire index, and therefore each row is unique, SQL Server might only issue a single index seek to find the unique row.
Sorry if this is too much information, but I thought you might like to know what all the different scans and seeks mean.
As always, you can search the net for more info. MSDN actually has a LOT of documentation (some of it is even good!) on SQL Server and the SQL language.