Extensible Digital Assistant Service Actions

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Digital assistants are limited by closed platforms, restricting their ability to expand services into new domains and integrate with third-party services, leading to limited interoperability and increased costs for service expansion.

Innovation Solution

An extensible digital assistant architecture is developed, allowing developers to create and deploy service actions that integrate with native services, using resources like templates and SDKs, and providing a framework for proactive and reactive invocation, with metrics and diagnostic tools for monitoring and debugging.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If digital assistants use closed platforms with native services only, then system stability and security are maintained, but service expansion capability and interoperability are limited

Engineering Contradiction:

Improveservice expansion capabilityVSAvoidplatform architecture complexity

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The digital assistant platform is segmented into native services and third-party service actions. Native services provide core functionality while service actions extend capabilities through modular integration. This segmentation allows the system to maintain stability from native services while enabling flexible expansion through independent service action modules that can be added without affecting the core architecture.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

A service action framework acts as an intermediary layer between the digital assistant and third-party services. This framework includes standardized interfaces, invocation mechanisms, and integration protocols that enable third-party services to connect with the digital assistant without requiring changes to the core platform architecture, thus maintaining stability while enabling expansion.

Inventive Principle:

Principle #24Intermediary (Mediator)

2Adaptability or versatility

If digital assistants integrate with third-party services, then service diversity and user functionality are improved, but system complexity and integration difficulty increase

Engineering Contradiction:

Improveservice diversityVSAvoidintegration difficulty

Core Design Contradiction:

Adaptability or versatilityVSEase of manufacture

Solution Approach 1:

The service action framework provides universal integration mechanisms that work across multiple third-party services. Standardized interfaces, common invocation patterns, and unified data formats enable the same integration infrastructure to support diverse services from different providers, reducing the need for custom integration code for each service and simplifying the overall integration process.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Solution Approach 2:

The framework allows service actions to be configured through parameter changes rather than code modifications. Developers can customize service behavior by adjusting invocation parameters, data formats, and integration settings, making the system adaptable to different services without increasing integration complexity through standardized configuration mechanisms.

Inventive Principle:

Principle #35Parameter changes

3Adaptability or versatility

If digital assistants provide extensive services through third-party integration, then user functionality and convenience are enhanced, but cost for service expansion increases

Engineering Contradiction:

Improveuser functionalityVSAvoidinfrastructure resource consumption

Core Design Contradiction:

Adaptability or versatilityVSQuantity of substance

Solution Approach 1:

Third-party service actions are designed to be self-contained with their own execution infrastructure. Each service action includes its own logic, data handling, and integration mechanisms, eliminating the need for the digital assistant to provide separate infrastructure for service execution. This self-service approach reduces the digital assistant's infrastructure resource consumption while still enabling extensive user functionality through diverse third-party services.

Inventive Principle:

Principle #25Self-service

Data Source

PatentUS11785016B2Service actions for digital assistants

Publication Date: 2023.10.10 MICROSOFT TECHNOLOGY LICENSING LLC

AI summary

In representative embodiments, a digital assistant is extended by service activities. A service activity executes as a service as part of the digital assistant. A service activity specifies a set of user data to be provided when invoked, at least one insight used to invoke the service activity in a proactive way and at least one intent used to invoke the service activity in a reactive way, and executable code that is executed when the service activity is invoked. A development environment provides templates to ease development of service activities. Service activities in development can be deployed alongside production services with access to service activities in development restricted to a set of authorized users.