A straightforward extension of your algorithm would be to partition the pattern set into groups of size , where p is the number of patterns. Then you only need to rebuild the automaton for pattern strings. Queries will also be slower by a factor of .

Forget the algorithm below, since it's not working.

Here's a variant that uses hashing to achieve poly-logaritmic time:

1. For all strings you ever see, precompute a rolling hash for the string, so that you can compare any substrings, even from different strings, in O(log n) where n is the minimum of the lengths of those substrings.
2. Keep a balanced binary search tree of all the patterns.
3. Given a query string s, for every suffix s[i..|s|], locate its neighbors in the BBST and check whether one of them is a prefix of the suffix.

The total runtime is quadratically logarithmic in the input size. It would be interesting to see a variant of this that doesn't rely on hashing. It would also be interesting to see whether we can shave of one of the log factors.

Is this a real problem somewhere? I'd like to try an implementation of this.

If you are not looking for the "online" solution, just look at the problem 163E - Электронное правительство and its editorial.

What about this solution:

Let's say that we're looking for all strings s from the set S that are prefixes of string T (T is a suffix of our input string, and we can do this for all suffixes independently). If a string s_i matches, and a string s_j longer than s_j matches, then s_i must be a prefix of s_j. So if we could bin-search the longest prefix that's "good" somehow, like the longest prefix that's common with some string from S, we could just get the complete information from it...

The most obvious first choice is storing the hashes of all string in S and bin-searching the longest prefix of T which has the same hash as one of the stored ones. Well, for that to work, we need all prefixes of all strings in S, and after thinking a bit, we can find out that it's better to store the strings of S in a trie, store hashes of all vertices and bin-search the deepest vertex. Since we're just adding strings and extending the trie, we can update the map of (hash,vertex) easily when adding a string to S.

This "prefix to trie vertex" method is cool, because it allows us to replace a substring by an interval (corresponding to a subtree of the trie). Still, it's not of much use if the question's about the number of occurences or number of strings from S that occur in the input string — the trie's dynamic, so standard approaches (standard interval tree, LCA preprocessing or HLD) fail on it. I still wonder if there's a solution to that. Luckily, the question here is just about some occurence.

Let's add one more information to the trie: each vertex will have a dead/alive status. A dead vertex corresponds to a prefix that has a string from S as a (possibly equal) substring. This status is inherited — if we add a vertex, it'd have the same status as its son. Also, after adding a string to the trie, we must mark its end vertex as dead, and mark all its successors as dead as well — we can just traverse the subtree by DFS, plus utilize the property that if a vertex was dead before, then its whole subtree was dead before, so we don't need to go deeper. In order to do that efficiently, we'd also keep a list of just living sons for every vertex; when marking the top node of a subtree as dead, we can just remove the link from its parent, and we can DFS by those special links. Note that we also need a separate list of all sons, for standard "add a string to the trie" operation.

With this, we can easily check if some string from S occurs in T as a substring — iff the vertex we found was dead, the answer's yes. The answer for the whole string is yes iff the answer for some suffix T is yes.

We only mark a node as dead at most once, and we mark every node traversed in the DFS as dead, so if the total length of strings from operations 1 is L₁, the total and maximum lengths from op. 2 are L₂ and l, then the time complexity is .

I wonder if this actually works — it just looks really simple compared to suffix whatever structures and Aho-Corasick.

There is a solution using AC Automaton.

When we have N strings in the set, maintain logN AC Automatons : the ith automaton contains the first 2^k_i strings not included in previous automatons, where k_i is position of the ith highest 1 in binary representation of N. For example when N = 19, we have 3 automatons : {S₁..S₁₆}, {S₁₇..S₁₈} and {S₁₉}.

The first type of operation can solved by traversing the logN automatons using the given string.

When adding a string, first construct a automaton using the single string, and while there are two automatons with the same number of strings, we merge them by construct a new automaton using brute force. It's easy to see the property in the first paragraph keeps, and the complexity of the algorithm is , where SumL is the total length of all strings, and N is the number of insert operations.