Bookmark table design pattern

Our matter management system uses the following core mechanism for B2B messaging:

There is a dedicated database view for each B2B interface. Each row aggregates a potential message to be sent in the next batch processing cycle. The logic goes as follows:

1. Local business transaction inserts a new bookmark row in the bookmarks table
2. Existence of a bookmark row promotes the corresponding message in the view
3. Scheduled job picks batch of rows from the view and sends the SOAP requests
4. Successful return removes the bookmarks

This is of course simplified description. The real implementation involves database triggers, complex conditions and interface locking, but the bookmark principle is still the same. The bookmark concept is convenient to intercept with the batch processing process if necessary. For example it's easy to manually remove or re-create the bookmark if something goes wrong. It is also general concept applying to various integrations.

I wonder how did the original developers came up with this design. Is this a known design pattern? I would like to know more about this solution.