RESTful API for Telecom Services Using URI Resource Models

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing APIs for telecommunication services are often proprietary and non-standard, making it complex for application developers to provision web-based applications with telecom services, as they require knowledge of multiple unique interfaces that do not conform to RESTful principles, increasing the difficulty in accessing and interacting with resources.

Innovation Solution

An API that models telecommunication resources as objects, allowing access through a uniform resource identifier (URI), conforming to RESTful principles, simplifying the interaction by treating resources as objects rather than services, enabling easier integration into web service applications.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If proprietary nonstandard APIs are used to access telecommunication services, then service functionality is provided, but developer complexity and integration difficulty increase

Engineering Contradiction:

Improveservice functionalityVSAvoiddeveloper complexity

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent applies universality by creating a standardized API interface that can access multiple telecommunication services from different providers through a common RESTful framework. The URI-based resource model allows the same interface structure to work across SMS, MMS, voice, and other telecom services, eliminating the need for developers to learn proprietary APIs for each service type.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Solution Approach 2:

The patent changes the parameter structure of API interfaces by transitioning from proprietary parameter names and structures to standardized RESTful parameters. Resources are identified using URIs with consistent path structures (e.g., /services/{service_id}/resources/{resource_id}), and standard HTTP methods (GET, POST, PUT, DELETE) replace service-specific function calls, fundamentally changing how services are accessed.

Inventive Principle:

Principle #35Parameter changes

2Adaptability or versatility

If multiple proprietary APIs are learned to access different telecommunication services, then comprehensive service access is achieved, but ease of operation decreases

Engineering Contradiction:

Improveservice access coverageVSAvoidease of use

Core Design Contradiction:

Adaptability or versatilityVSEase of operation

Solution Approach 1:

The standardized RESTful API provides a universal interface that handles multiple telecommunication services through consistent patterns. Developers use the same URI structure and HTTP methods regardless of which telecom service or provider is being accessed, making the system easy to operate while maintaining broad service coverage.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Solution Approach 2:

The patent segments telecommunication services into discrete resources identified by URIs, where each service (SMS, MMS, voice) and each resource (message, contact, account) can be independently accessed using standardized operations. This segmentation allows comprehensive service access through a unified interface pattern.

Inventive Principle:

Principle #1Segmentation

3Reliability

If resources are modeled as services in proprietary APIs, then service-specific functionality is achieved, but integration difficulty increases

Engineering Contradiction:

Improveservice functionalityVSAvoidintegration difficulty

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The standardized RESTful API acts as an intermediary layer between web applications and telecommunication services. It translates diverse service-specific requests into uniform HTTP operations on resource models, simplifying integration while maintaining reliable access to underlying service functionality through the abstraction layer.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

Instead of modeling services as the primary interface (proprietary approach), the patent inverts the model by treating telecom resources (messages, contacts, accounts) as first-class citizens with standardized URI representations. Services become operations on these resources rather than the resources themselves, fundamentally inverting the traditional service-oriented API model.

Inventive Principle:

Principle #13The other way round (Inversion)

Data Source

PatentUS8656417B2Interface for telecommunication services using uniform resource identifiers

Publication Date: 2014.02.18 DIALOGIC INC

AI summary

An application programming interface (API) provides telecommunication services in the form of a resource modeled as an object, which object can be essentially any coherent and meaningful concept that may be addressed. The API model permits simpler and more intuitive invocation and usage of the API. The object model for the API avoids having to understand service infrastructure for proper API invocation and tends to increase the usability of the service represented by the API. With the object-modeled resource, the device can be made to appear to an application programmer as a webpage, so that interacting with the device is the same as interacting with a webpage, such as by utilizing HTTP requests and responses. The object-model API can increase the ease with which an application programmer can utilize the services offered, as well as increase the ease with which the API may be integrated into an overall communication system.