Obviousness

Obviousness Analysis under 35 U.S.C. § 103 for US12279116

To determine the obviousness of US patent 12279116 under 35 U.S.C. § 103, we must consider whether the differences between the claimed invention and the prior art would have been obvious to a person having ordinary skill in the art (POSA) at the time of the invention. This analysis involves the Graham Inquiries: (1) determining the scope and content of the prior art, (2) identifying the differences between the claimed invention and the prior art, and (3) assessing the level of ordinary skill in the pertinent art. Additionally, secondary considerations of non-obviousness are considered if presented. The Supreme Court case KSR International Co. v. Teleflex Inc. provides a flexible "common sense" approach, stating that a combination of familiar elements according to known methods is likely to be obvious, even without an explicit teaching, suggestion, or motivation in the prior art.

The priority date of US12279116 is July 16, 2013. [cite: https://patents.google.com/patent/US12279116/en] Therefore, prior art predating this date is relevant.

Prior Art References

The patent US12279116 itself references U.S. Pat. No. 7,656,870 as containing similar functionality to its "function block". This patent is titled "SYSTEM AND METHOD FOR PEER-TO-PEER HYBRID COMMUNICATIONS" and was filed on March 15, 2005. [cite: https://patents.google.com/patent/US12279116/en]

Combination of Prior Art

A strong case for obviousness could be made by combining U.S. Pat. No. 7,656,870 with general knowledge in the art regarding application programming interfaces (APIs) and the desire to improve user experience and resource efficiency on computing devices, particularly mobile devices.

1. U.S. Pat. No. 7,656,870 ("the '870 patent"):
The '870 patent, "System and method for peer-to-peer hybrid communications," describes functionality similar to the "function block" of US12279116. [cite: https://patents.google.com/patent/US12279116/en] This includes capabilities such as instant messaging, presence, audio, video, collaboration, file transfer, and conferencing. [cite: https://patents.google.com/patent/US12279116/en] The '870 patent focuses on peer-to-peer hybrid communication systems, which blend elements of client-server models with P2P architecture, where some peers have special roles or provide centralized services while still allowing direct peer-to-peer communication.

2. General Knowledge of APIs and Software Development:
At the time of the invention (priority date July 16, 2013), APIs were a well-established mechanism for different software components or applications to communicate and share functionality. Software development kits (SDKs) were also common for providing developers with tools and libraries to integrate specific functionalities into their applications.

3. Motivation for Combination:
A person having ordinary skill in the art (POSA) in software development for computing devices, especially mobile devices, would have been motivated to combine the functionalities disclosed in the '870 patent with existing applications via an API for several reasons:

• Improved User Experience: The background section of US12279116 highlights the disruption and inefficiency caused by context switching between applications on mobile devices for tasks like email, video calls, or joining meetings. [cite: https://patents.google.com/patent/US12279116/en] A POSA would recognize that integrating communication and collaboration features (as taught by the '870 patent) directly into a "superblock application" would eliminate the need for context switching, leading to a more seamless and productive user experience.
• Resource Efficiency (especially on Mobile Devices): US12279116 explicitly states that context switching on mobile devices impacts performance and battery life due to memory swapping and processor load. [cite: https://patents.google.com/patent/US12279116/en] A POSA would understand that embedding a "function block" (with capabilities similar to the '870 patent's endpoint) directly within the memory space of a "superblock application" would minimize these resource overheads compared to running separate applications. The patent notes that including the function block instructions within the superblock instructions minimizes the likelihood of separation in memory. [cite: https://patents.google.com/patent/US12279116/en]
• Modularity and Reusability: Providing functionality via a "function block" and an API promotes modularity. The '870 patent describes an "endpoint" with various communication functionalities. A POSA would find it obvious to package such well-defined functionalities into a reusable module (a "function block") that could be easily integrated into different "superblock applications" via a standardized API, reducing development time and effort for new applications. The patent explicitly states that the function block can be provided as an SDK or independent module and used with many different applications and platforms via an API. [cite: https://patents.google.com/patent/US12279116/en]
• Meeting Market Demands: As mobile devices became increasingly prevalent, there was a growing demand for richer, more integrated application experiences. Providing advanced communication features (like those in the '870 patent) directly within existing applications, without forcing users to switch contexts, would address a clear market need.

Conclusion on Obviousness:

Claims 1, 10, and 16 of US12279116 describe a system and method where a "function block" provides additional capabilities to a "superblock application" via an API, with these functions being accessible within the superblock application's display without requiring context switching. Given that the '870 patent already disclosed a system with similar communication and collaboration functionalities, and considering the well-known practices of using APIs for software integration and the recognized problems of context switching on computing devices (especially mobile devices) prior to the priority date, a POSA would have been motivated to combine these elements.

The integration of the '870 patent's endpoint-like functionalities into an existing application via an API to avoid context switching and improve resource utilization would have been a predictable result of combining known elements according to known methods. The stated problems in the background of US12279116 (disruptive context switching, impact on performance and battery life on mobile devices) represent long-felt needs in the art, which a POSA would have sought to address using available technical solutions. The solution proposed in US12279116, while addressing these needs, utilizes components and integration methods that would have been evident to a skilled artisan.