Looks like it's one of several API-specific (ODBC, OLE DB, etc...) system function for...handling a cursor

MSDN has this to say about that...

API System Stored Procedures

Users running SQL Profiler against ADO, OLE DB, ODBC, and DB-Library applications may notice the use of system stored procedures that are not covered in the Transact-SQL Reference. These stored procedures are used by the Microsoft OLE DB Provider for SQL Server, the SQL Server ODBC driver, and the DB-Library dynamic-link library (DLL) to implement the functionality of a database API. These stored procedures are simply the mechanism the provider or drivers use to communicate user requests to SQL Server. They are intended only for the internal use of the OLE DB Provider for SQL Server, the SQL Server ODBC driver, and the DB-Library DLL. Calling them explicitly from an SQL Server application is not supported.

The complete functionality from these stored procedures is made available to SQL Server applications through the API functions they support. For example, the cursor functionality of the sp_cursor system stored procedures is made available to OLE DB applications through the OLE DB API cursor properties and methods, to ODBC applications through the ODBC cursor attributes and functions, and to DB-Library applications through the DB-Library Cursor Library.

These system stored procedures support the cursor functionality of ADO, OLE DB, ODBC, and the DB-Library Cursor Library:

sp_cursor sp_cursorclose sp_cursorexecute
sp_cursorfetch sp_cursoropen sp_cursoroption
sp_cursorprepare sp_cursorunprepare

Believe that is when a client is creating a cursor.
It creates a cursor then fetches the data from it. You will often find spid stuck on a cursorfetch if the clint is very slow at receiving the data.
You should find in the trace the query that is being used to create the cursor.

======================================
Cursors are useful if you don't know sql.
DTS can be used in a similar way.
Beer is not cold and it isn't fizzy.