Obviousness

To analyze the obviousness of US patent 9578092 under 35 U.S.C. § 103, we will examine Independent Claims 1 and 9, which represent the core inventive concepts, in light of the explicitly referenced prior art and the general knowledge of a person having ordinary skill in the art (PHOSITA) at the time of the patent's priority date (July 16, 2013).

Independent Claims to be Analyzed

• Independent Claim 1 (Method Claim): This claim describes a method for providing additional functionality to an existing software application (superblock application) on a computing device. The method involves storing a function block within the superblock application, where the function block provides capabilities not originally possessed by the superblock application. These capabilities are accessed via an API and are provided and utilized within the display of the superblock application without switching context to another application.
• Independent Claim 9 (System Claim): This claim describes a computing device comprising a processor, network interface, and memory storing a superblock application. The superblock application includes a function block that provides additional capabilities, accessible via an API. Crucially, the function block is integrated such that these capabilities are available for use within the display of the superblock application without switching context to another application.

The central inventive concept in both claims is the integrated provision of additional functionality within a primary application's display, specifically to avoid the performance and usability issues associated with context switching.

Primary Prior Art Reference

The US9578092 patent itself explicitly incorporates by reference and draws a direct functional link to:

• U.S. Pat. No. 7,656,870 (the '870 patent): Entitled "SYSTEM AND METHOD FOR PEER-TO-PEER HYBRID COMMUNICATIONS," filed on March 15, 2005, and issued on February 9, 2010.

The US9578092 patent states that its "function block 200 may contain functionality similar to that of an endpoint as described in detail in U.S. Pat. No. 7,656,870". It further suggests that "the graphical user interface (GUI) of the endpoint may be replaced with the API 202 of FIG. 2". This direct reference establishes the '870 patent as a foundational source for the functionalities provided by the "function block" in US9578092. The '870 patent, having a filing date well before the priority date of US9578092, qualifies as prior art.

Known Problem and Motivation for Combination

The US9578092 patent explicitly identifies a significant problem in the background section:

• "The manner in which functionality is accessed in certain environments, such as mobile device environments, may impact performance and/or battery life."
• It highlights that existing solutions, such as launching or switching context to another application to access desired functionality (e.g., email or video calls from within a primary application), are "disruptive, difficult to manage, and pulls the user away from the superblock application," "inefficient and frustrating for the user," and "wastes time, and lowers productivity."
• The patent states that this process "negatively impacted on the mobile device more than would occur on larger devices having more resources."

A person having ordinary skill in the art (PHOSITA) in 2013 would have been acutely aware of these limitations and highly motivated to develop solutions that mitigate the performance overhead, battery drain, and poor user experience caused by frequent context switching on mobile devices.

Obviousness Analysis

Independent Claims 1 and 9 of US9578092 describe a system and method where a "function block" providing additional capabilities (like instant messaging, presence, audio, video, collaboration, file transfer, and email) is integrated within a "superblock application" and accessed via an API, thereby enabling these capabilities to be used and displayed within the superblock application's display without switching context.

1. Existence of Functionality in Prior Art ('870 Patent): The '870 patent describes an "endpoint" that provides a rich set of communication functionalities. The US9578092 patent itself acknowledges this by stating that its "function block 200 may contain functionality similar to that of an endpoint as described in detail in U.S. Pat. No. 7,656,870". This indicates that the core capabilities (e.g., voice, video, IM, file transfer) offered by the function block were known in the prior art through the '870 patent's teachings.

2. General Knowledge of Modular Software Development and APIs: By 2013, the use of Software Development Kits (SDKs), libraries, and Application Programming Interfaces (APIs) was a well-established and common practice in software engineering. Developers routinely used SDKs/libraries to incorporate diverse functionalities into their applications without having to develop those functionalities from scratch. APIs were the standard means to programmatically access the features offered by such modules. The US9578092 patent notes that the "function block 200 may be provided as a software developer's kit (SDK) or as an otherwise independent module by a developer".

3. Motivation to Integrate and Avoid Context Switching: Faced with the well-documented and recognized problems of context switching on mobile devices, a PHOSITA would have a clear and strong motivation to integrate external functionalities directly into existing applications. The concept of taking a standalone application's features (such as those of the '870 patent's "endpoint") and repackaging them as an embeddable module (e.g., an SDK) that could be linked into a primary application was a logical step to achieve greater integration and avoid the penalties of context switching.

Combination Rationale:

A PHOSITA, seeking to overcome the aforementioned problems in mobile environments, would find it obvious to combine the functional teachings of the '870 patent with the well-known principles of modular software design and API development. Specifically, a PHOSITA would be motivated to:

• Refactor the communication functionalities of the '870 patent's "endpoint" into an embeddable software module (the "function block") suitable for integration into other applications. This would involve "replac[ing] the graphical user interface (GUI) of the endpoint with the API 202" to allow programmatic control.
• Integrate this "function block" module directly "within" a "superblock application" (e.g., by compiling or linking the module as part of the superblock application's instructions). This integration would enable the superblock application to directly invoke the capabilities of the function block via its API.
• Ensure that the functionality is provided "within a display of the superblock application without switching context to another application". This would be the natural and intended outcome of embedding the function block directly. By integrating the functionality as a module within the existing application's process and memory space, its visual components or data presentation could be rendered directly within the host application's UI, thereby achieving the desired seamless user experience and avoiding context switches.

This combination of known elements—the functionality from the '870 patent, standard modular programming techniques, and the recognized need to avoid context switching on mobile devices—would have rendered the claimed invention obvious to a PHOSITA at the time of invention. The specific implementation of the "function block" within the "superblock application" and its interaction via an API, leading to in-app display without context switching, would be a predictable result of applying known solutions to a known problem with a readily available set of tools and technologies.