Obviousness

Obviousness Analysis of US Patent 9270744 under 35 U.S.C. § 103

This analysis identifies combinations of prior art references that would render the independent claims of US Patent 9270744 (the '744 patent) obvious to a person having ordinary skill in the art (POSITA) as of the priority date of July 16, 2013. The motivation for combining these references stems from recognized problems in the art, such as improving user experience, enhancing efficiency, and reducing resource consumption on mobile devices, which are explicitly detailed in the background section of the '744 patent.

The '744 patent aims to provide additional functionality to an existing "superblock application" in an integrated manner, without requiring context switching to another application. This additional functionality is provided by a "function block" that interacts with the superblock application via an Application Programming Interface (API) and can leverage external services. The '744 patent itself explicitly references US Pat. No. 7,656,870 ("US7656870B2") as disclosing functionality similar to its "function block."

Identified Prior Art References:

1. US Pat. No. 7,656,870 (Chaturvedi et al.) – "System and method for peer-to-peer hybrid communications" (Priority Date: March 15, 2005).

   • Disclosure: This patent describes an "endpoint" that provides various communication functionalities in a peer-to-peer hybrid communication environment, including instant messaging, presence, audio, video, collaboration, and file transfer. The '744 patent explicitly 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". This reference teaches establishing connections with external devices (peers, servers) via a network interface for communication services.

2. US Pat. No. 5,818,447 (Staples et al.) – "System and method for in-place editing of an electronic mail message using a separate program" (Priority Date: June 6, 1996).

   • Disclosure: This patent describes a system where a user can edit an email message "in-place" within one application (e.g., a word processor) using the functionality of a separate program (e.g., an email client) without switching the user's primary focus or "context" away from the original application. This is achieved by embedding or integrating the functionality.

3. US Pat. No. 6,148,336 (Agnew et al.) – "Ordering of multiple plugin applications using extensible layered service provider with network traffic filtering" (Priority Date: March 13, 1998).

   • Disclosure: This patent describes a system for managing and integrating "plugin applications" through an "extensible layered service provider." It teaches dynamically loading and ordering functionality provided by these plugins to an application, enhancing its capabilities. The use of plugins is a well-known method for adding functionality to existing software.

Obviousness Arguments:

Combination: US7656870B2 in view of US5818447A and US6148336A

A POSITA, motivated to address the known problems of context switching, inefficiency, and limited functionality in mobile applications (as described in the '744 patent's background), would have found it obvious to combine the communication capabilities of an endpoint as taught by US7656870B2 with the principles of in-place functionality integration from US5818447A and the plugin architecture from US6148336A.

Motivation for Combination:
The background of the '744 patent explicitly states the problems it seeks to solve: "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 "switching between applications (e.g., switches contexts), the device 100 may have to swap instructions into and out of physical memory, which impacts performance and battery life." Furthermore, it notes that using "another application to provide the desired functionality... is disruptive, difficult to manage, and pulls the user away from the superblock application."

A POSITA, seeking to overcome these challenges, would be motivated to integrate specialized functionalities directly into a main application to provide a seamless user experience, improve performance, and conserve resources. US5818447A provides a direct teaching of performing operations "in-place" within one application using a "separate program" to avoid context switching. US6148336A teaches the general concept of adding functionality to an existing application using "plugin applications" and an "extensible layered service provider," which represents a well-known architectural pattern for extending software. It would be a straightforward engineering decision to apply this known plugin/in-place integration methodology to specialized communication functionalities.

Obviousness of Independent Claim 1 (Mobile Device - Request-Driven):

Claim 1 describes a mobile device where a function block receives a request for a communication service from a superblock application, determines the need for an external device, establishes a connection, and provides the service without context switching.

1. "receiving, by a function block stored in the memory of the mobile device, a request for a communication service from a superblock application stored in the memory of the mobile device, wherein the superblock application is configured to access the function block for functionality that is lacking in the superblock application;"

   • US7656870B2 describes an "endpoint" with various communication services (IM, audio, video, etc.) that can communicate with other devices/servers. A POSITA would readily understand that an "endpoint" or communication module would receive requests for such services. The concept of an application lacking certain functionality and seeking it from a specialized module (like the function block) is a basic principle of software design, particularly evident in plugin architectures taught by US6148336A. The interaction via an API is a standard method for such requests.

2. "determining, by the function block, that providing the communication service to the superblock application requires access to an external device;"

   • US7656870B2's "peer-to-peer hybrid communications" system inherently involves communication with "peers" or "servers," which are external devices. A communication endpoint (function block) would logically determine if a requested service (e.g., an audio call) requires connecting to an external party. This is a fundamental aspect of networked communication.

3. "establishing, by the function block, a connection with the external device via the network interface to support the communication service, wherein the establishing is not supported by the superblock application;"

   • US7656870B2's endpoint is designed to "establish" communication sessions over a network. It is well-understood in the art that core applications often delegate complex network connection management to specialized libraries, modules, or services. The '744 patent itself states the superblock "lacks" this functionality, implying the delegation of such tasks to the function block.

4. "providing, by the function block, the communication service to the superblock application, wherein the steps of receiving, determining, establishing, and providing are performed without switching context from the superblock application to another application on the mobile device."

   • The core novelty claimed here is performing these steps "without switching context." US5818447A directly teaches the integration of functionality from a "separate program" into a main application (e.g., in-place email editing) specifically to avoid context switching and its associated user disruption. US6148336A further reinforces the concept of "plugin applications" that extend the functionality of a host application. A POSITA would be motivated to apply the "in-place" integration methodology (US5818447A) to the communication services (US7656870B2) through a plugin/module architecture (US6148336A) to achieve the stated benefits of improved user experience and efficiency, especially in resource-constrained mobile environments. The function block, being an SDK or independent module that can be "compiled or otherwise included" in the superblock (Description, FIGS. 2A, 2B), facilitates this integrated, non-context-switching operation.

Obviousness of Independent Claim 15 (Mobile Device - Notification-Driven):

Claim 15 describes a mobile device where a function block receives a request (notification) from an external device for a communication session, notifies the superblock application within its display window, establishes a connection upon approval, and provides the session without context switching.

1. "receiving, by a function block stored in the memory of the mobile device, a request from an external device for a communication session with a superblock application that is stored in the memory of the mobile device and is currently being displayed within a display window of the superblock application on a display screen of the mobile device, wherein the function block is configured to provide functionality for the communication service to the superblock application;"

   • US7656870B2's endpoint inherently handles incoming communication sessions (e.g., call notifications, IMs) from external devices. The function block providing functionality to the superblock application is consistent with a plugin architecture (US6148336A) and the explicit relationship described in the '744 patent itself.

2. "notifying, by the function block, the superblock application that the communication session is being requested by the external device, wherein the notification occurs within the display window of the superb lock application;"

   • Integrating notifications into the existing application's display window, rather than launching a new application or context, is a direct application of the "in-place" concept from US5818447A. This aligns with the motivation to avoid disruptive context switches and keep the user within the primary application, a known problem articulated in the '744 patent. Displaying an incoming call notification within an existing application's UI is a common and desirable feature.

3. "establishing, by the function block, a connection with the external device via the network interface to support the communication session only after receiving an approval from the superblock application to establish the communication session, wherein the establishing is not supported by the superblock application;"

   • As with Claim 1, US7656870B2 provides the capability for establishing connections. Requiring approval from the main application (superblock) for external interaction is a standard security and user control feature in computing. Delegating the actual connection establishment to the specialized function block (because the superblock "is not supported" to do so) is consistent with sound software architecture.

4. "providing, by the function block, the communication session to the superb lock application, wherein the steps of receiving, notifying, establishing, and providing are performed without switching context from the superblock application to another application on the mobile device."

   • Again, the "without switching context" feature is rendered obvious by US5818447A's teaching of "in-place" functionality to avoid context shifts, applied to the communication services of US7656870B2 through a plugin model (US6148336A). The '744 patent itself describes providing a "video window for the phone call within the display of the superblock application" as an example of this integrated, non-context-switching approach.

Obviousness of Independent Claim 20 (Method - Request-Driven):

Claim 20 describes a method corresponding to the mobile device of Claim 1. The method elements (receiving, determining, establishing, providing a communication service without context switching) are the same as those discussed for Claim 1. Therefore, the same combination of US7656870B2, US5818447A, and US6148336A would render the method steps obvious for the same reasons: leveraging known communication endpoint capabilities, applying established in-place integration techniques to avoid context switching, and utilizing a standard plugin architecture to extend application functionality.

Conclusion:

Based on the explicit reference to US7656870B2 in the '744 patent itself, and the teachings of US5818447A and US6148336A, it would have been obvious for a person having ordinary skill in the art to combine these references to arrive at the inventions claimed in US9270744B2. The motivation to do so would be to overcome the well-known problems of inefficiency, performance degradation, and poor user experience associated with context switching in mobile environments, as directly acknowledged in the '744 patent's background. These references disclose the core elements of communication services, adding functionality via modules/plugins, and specifically performing functions "in-place" to avoid context switching.