Results found. No results found – Searches, in my opinion, have more to it than the outcome. As a searcher, of course, there are strategies and tactics involved to get to the result (or the lack of it), but there’s much more to it.
It also involves the to and fro with the client, picking the right strategy, helping them decide whether the project needs more time spent on it, acting on feedback and making sure this is not a one-time project but clients are served in a way that would ensure repeat work. After all, according to research, it costs five times more to attract a new client when compared to retaining existing ones. One of the key goals thus is ensuring customer satisfaction throughout the process, irrespective of the outcome.
How do you ensure satisfaction?
Get them those results, you say.
But what if there are no results available. Is it still possible to win a client?
The short answer to the question is yes. How? Time for the long answer.
They asked us to perform a feasibility study in the Gaming industry
We were recently approached by Martha*, a patent engineer who was closely involved in various patent monetization activities for her company GameOn*, which operated in the gaming domain.
Before giving a project, Martha asked us to perform a preliminary analysis for a patent infringement case she was working on to get our views on feasibility. She had already identified strong leads that Zynga poker was infringing one of their patents. However, to establish infringement, they had one link missing, i.e. during an online gaming, they needed to prove that user terminal communicates with two distinct servers – user account management server (responsible for accounting players coins/credit required for playing the poker game) and gameplay server (responsible for actual play of the games). They had already performed an extensive infringement analysis and testing; however, they were unable to identify the missing link.
We had quite a good experience of working on such projects. Our initial view was we should be able to find some evidence by monitoring the network communication while playing the Zynga poker on a browser. Various network monitoring tools such as Wireshark and many browsers’ inbuilt developer tools help in analyzing such network communication.
We started with the feasibility check, i.e. the preliminary analysis, by analyzing the network communication happening while playing the Zynga poker game on a browser. For this, we used the browser’s developer tool – Inspect element.
However, Network communication data was huge and it was getting difficult to decipher it. So we roped in one of the teammates from the software development team to make sense of data. He helped us decipher how to use the tool, and with his help, we were able to navigate through the clutter and focus on relevant data.
Martha, in the meanwhile, was kept updated on the approach being used to check overlap. She was hopeful we might be able to find clues leading to the missing link. So were we.
During testing, we observed that network communication was happening using WebSockets. For the uninitiated, WebSockets are dedicated bidirectional tunnels between client and server for exchanging the information. Websockets create a layer of abstraction and makes it difficult to analyze server-side communication.
Abstraction is an issue so we decided to try and avoid the WebSocket. How to do that?
We decided to play the game using an older version of internet explorer as they do not support WebSockets. Any network communication should fall back to the non-WebSocket mode and might reveal details that could help us locate the missing piece.
However, this plan didn’t work as expected. The game didn’t run at all on the old browser! <Sigh>
We were cornered and had to look for ways to inspect the WebSockets. One of the approaches used was to build a few test cases to run and observe the responses to figure out the details. Our thought process was if we could isolate the payment communication and gameplay communication, and observe which servers or WebSockets were handling it, we will be able to get some leads.
This gave us some initial success. We observed different WebSockets connections were established in these two communications. However, this success was short-lived. Few more test runs exposed the loopholes in the observations, and we were back to square one.
Our conclusion was – though multiple WebSocket connections are being established with different servers, each WebSocket connection is independently doing either or both payment and gameplay communication. Therefore, establishing both payment and gameplay communication are happening with distinct server become bleak.
We shared this with Martha but didn’t want to give up yet. We tried a few more strategies like:
- decompiling the APK and analyzing its code to see if it can provide any leads and
- emulating the app communication.
However, it was all in vain.
This was a feasibility study and we had tried every tactic possible, with the deadline soon approaching.
We concluded the search, documented all the observations and findings, and shared it with Martha. Having knowledge of all the strategies explored during the search, she was convinced that the chances of finding the missing link were near to zero.
During the wrap-up call, Martha appreciated our thought process and efforts. She mentioned that she liked our transparency in putting forward our observations. Though this task didn’t result in a project, nonetheless, we were able to make a very good impression with her. She is now in talks with her higher management who makes business decisions on how they can engage us for other projects.
Authored by: Anoop Singh Chauhan, Manager, Patent Infringement.
