Product Testing to prove the patent infringement by a leading dating app

Samuel (a Patent Attorney at a leading law firm in the USA) was exploring DatingArc (a famous dating app) as a potential infringer on one of his client’s patents. Despite his best efforts, he wasn’t been able to gather enough evidence to prove his case. That’s when he turned to GreyB’s infringement team.

Initially, what seemed a standard patent infringement search request turned into an interesting investigation to prove the infringement by this famous dating app.

How did we manage to prove that the app in question was infringing on our client’s patent? Buckle up and join us as we take you through the entire process, step-by-step.

From collecting evidence to building a solid case, we’ll share all the challenges and successes we encountered along the way. So, are you ready to delve into the nitty-gritty of this case study?

Let’s dive in!

An overview of our investigation into DatingArc

The subject patent discussed communication technology via text, voice, and video calls. I understand that many apps nowadays provide this option. However, the catch was that the communication server ensured neither user could access the other party’s personal information (e.g., name, address, etc.) while establishing a call connection.

Since the technology seemed generic and essential for an IM/Chat application that highly regards privacy/anonymity, DatingArc had a high probability of infringing upon the client’s patent.

Note: The name of the dating app is replaced due to confidentiality reasons.

But first, I needed to take a closer look at the technology discussed in the subject patent.

The subject technology in detail

As per the patent, the user device that wants to initiate a voice/video call will share a “first request code” with the server to implement anonymity.

Following the first request code, the server will send a “second request code” to the second user, asking for their consent to join the voice/video call.

Eventually, a “response code” is shared with the server based on the second user’s response, and the server will establish a voice/video connection between both devices.

The terms “first and second request code” seemed a bit cryptic. So I dived deep into the patent specification to understand the meaning and scope of a “request code.”

How the patent’s claim served as my first challenge

Usually, when a patent claim contains terminology which can be interpreted in different ways, the definitions are present in the patent specification or file wrapper. As a result, we can get a clear picture of the scope of those terminologies.

Now that’s where my first challenge appeared.

The subject patent’s specification/description lacked any examples or definitions of the term “request code” that could define its scope. I even double-checked the file wrapper, but there was no discussion between the examiner and applicant regarding the meaning/scope of “request codes.”

So, if I didn’t know the constituents and format of a “request code,” how could I find it in DatingArc for infringement?

Taking a peek at the DatingArc’s literature

Though the patent literature did not help in this patent infringement case, I decided to check DatingArc instead and find evidence that could fit the term “request code” most appropriately according to our subject patent’s context.

I started looking for request/response codes to anonymize a user’s identity by referring the user to a unique ID. Additionally, I had to search for an operation for sharing that unique id with the server.

Eventually, the server would search for the user with that unique ID and then initiate/forward a request regarding the initiation of a voice/video call.

But that wasn’t a smooth sail either. In my attempt to locate something in the product literature, I encountered another challenge. Unfortunately, the target application disclosed very minimal documentation on its working.

As a result, there were very few details regarding their backend working on how they establish a voice/video connection between two users.

Limitations of standard product searching techniques

After conducting a thorough examination of the product in question, it became clear why Samuel had turned to GreyB for assistance. It was evident that a surface-level investigation would not be sufficient in this case.

As we dug deeper, we faced a significant challenge in identifying a request code that could potentially fit the patent claim. We scoured product manuals, developer forums, and documentation, but to no avail. The solution? We had to resort to a more unconventional method: product testing using a packet/network analyzer.

This way, I could check whether the request message initiated from a user device has a code/identifier, something that fits the term “request code.”

I shared these observations with Samuel to let him know why I must do product testing to confirm patent infringement and got the go-ahead to perform the testing.

The Product Testing

Having received the heads-up, I laid out a test plan and the objectives. Now, in order to capture requests/data packets sent to DatingArc’s server, I had to intercept the user’s network traffic.

I selected MITMProxy to intercept HTTPS traffic and help analyze/dissect captured traffic data. The target application uses HTTPS to communicate with its server, which makes MITMProxy an ideal tool for intercepting/capturing data originating and received at DatingArc.

Additionally, having performed multiple product tests for our clients, I knew this tool was a Swiss army knife for debugging, testing, privacy measurements, and penetration testing. It can intercept, inspect, modify, and replay web traffic such as HTTP/1, HTTP/2, WebSockets, or any other SSL/TLS-protected protocols.

To initiate the whole process, I reached out to one of my colleagues, Hanisha Arora, from Product Development Team, a network penetration tester. She instantly agreed to guide me through the testing process. Eventually, we had the process in place.

I installed the DatingArc app onto the system. It would simulate app functions like finding a suitable partner nearby and conversing with them via text, voice, or video through the app’s messaging section.
Next, to use MITMProxy, Hanisha installed it on a separate system that would act as a middleman (proxy) between the user device with DatingArc installed and the network.
She ensured the proxy was configured so that DatingArc could trust it as a communication channel between the user device and the server.
Next, I made intercepting requests from the user’s device to the server to initiate a voice or video call with the second user.
Eventually, I aimed to analyze the captured packets to check whether they contained a code/identifier that appropriately suited the context of the patent’s claim.
Then a similar process was performed at the second user’s end, who will receive the voice/video call request from the first user.

After successfully performing every step of the plan, we located a unique ID in the captured request messages.

This unique ID served the purpose of anonymity as described in the subject patent. Additionally, the found ID played a part in initiating a call while remaining unique to each user.

And Voila! I had clear proof that DatingArc was, in fact, infringing upon the subject patent.

Conclusion

Patent Infringement cases are not always going to be a straight line. It requires thinking out of the box and following different routes to get that breakthrough. Do you know we could even build a strong case to license a patent that had no infringement?