Context-Aware Layer for Presence Information Abstraction

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current presence-aware applications face complexity and inefficiency due to direct coupling with presence metadata, leading to increased memory footprint, processing power consumption, and network bandwidth usage, as well as interoperability issues from differing interpretations of presence information.

Innovation Solution

A context-aware layer abstracts presence information, applying contextual rules and policies to derive presence aspects, reducing complexity and enhancing interoperability by integrating presence, location, and generic context awareness mechanisms within a network-based platform.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If presence-aware applications directly couple with presence metadata, then they can access detailed presence information, but complexity and resource consumption increase

Engineering Contradiction:
Improvepresence information accuracyVSAvoidapplication complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent introduces an intermediary layer between presence-aware applications and presence metadata that abstracts and simplifies the interaction. This intermediary processes raw presence information and presents simplified presence aspects to applications, reducing complexity while maintaining information accuracy.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent segments the presence information processing into distinct layers: raw presence metadata collection, presence aspect derivation, and application-specific presence awareness. This segmentation allows each layer to handle specific tasks independently, reducing overall system complexity.

Inventive Principle:
Principle #1Segmentation

2Loss of information

If presence-aware applications process raw presence metadata directly, then they obtain detailed context information, but memory footprint and processing power consumption increase

Engineering Contradiction:
Improvecontext information completenessVSAvoidprocessing power consumption
Core Design Contradiction:
Loss of informationVSUse of energy by moving object

Solution Approach 1:

The patent extracts only the essential presence aspects needed by applications from the complete raw presence metadata. By deriving and presenting only relevant presence information (such as reachability, availability, contactability) rather than all raw metadata, the system reduces processing power consumption while maintaining contextual completeness.

Inventive Principle:
Principle #2Taking out (Extraction)

3Adaptability or versatility

If multiple applications interpret presence information differently, then each application can optimize for its specific needs, but interoperability issues arise

Engineering Contradiction:
Improveapplication-specific optimizationVSAvoidinteroperability consistency
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The patent creates a universal presence aspect framework that defines standardized presence aspects (reachability, availability, contactability) that can be consistently interpreted across different applications. This universal layer enables interoperability while allowing individual applications to optimize their specific implementations based on these consistent foundations.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Data Source

PatentEP2281363B1Method and server for adding an aspect trigger to an aspect
Publication Date: 2017.09.20 BLACKBERRY LTD
  • EP2281363B1 patent drawingFigure 1
  • EP2281363B1 patent drawingFigure 2
  • EP2281363B1 patent drawingFigure 3

AI summary

A method within a computing execution environment for adding an aspect trigger for an aspect, an aspect being an application level abstraction relevant to a source or service, along with the execution environment, where the method includes defining service aspects; inserting or encapsulating the service aspects as named aspects into an abstraction layer in the computing execution environment; and associating the named aspects with the aspect trigger, wherein the abstraction layer is configured to associate aspect triggers for a plurality of client applications.