New! Search for patents from more than 100 countries including Australia, Brazil, Sweden and more

US20130346880A1 - Distributed multi-user mashup - Google Patents

Distributed multi-user mashup Download PDF

Info

Publication number
US20130346880A1
US20130346880A1 US13/888,064 US201313888064A US2013346880A1 US 20130346880 A1 US20130346880 A1 US 20130346880A1 US 201313888064 A US201313888064 A US 201313888064A US 2013346880 A1 US2013346880 A1 US 2013346880A1
Authority
US
UNITED STATES OF AMERICA
Prior art keywords
mashup
mashup session
session
participant
services
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US13/888,064
Inventor
Vijay Dheap
Christopher Michael Gladd
Aaron Charles Lindsay
David Preston Sink
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to US12/651,072 priority Critical patent/US8458600B2/en
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Priority to US13/888,064 priority patent/US20130346880A1/en
Assigned to INTERNATIONAL BUSINESS MACHINES CORPORATION reassignment INTERNATIONAL BUSINESS MACHINES CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: LINDSAY, AARON CHARLES, GLADD, CHRISTOPHER MICHAEL, DHEAP, VIJAY, SINK, DAVID PRESTON
Publication of US20130346880A1 publication Critical patent/US20130346880A1/en
Application status is Abandoned legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00Digital computers in general; Data processing equipment in general
    • G06F15/16Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G06F15/163Interprocessor communication
    • G06F15/173Interprocessor communication using an interconnection network, e.g. matrix, shuffle, pyramid, star, snowflake
    • G06F15/17306Intercommunication techniques
    • G06F15/17325Synchronisation; Hardware support therefor
    • GPHYSICS
    • G08SIGNALLING
    • G08BSIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
    • G08B27/00Alarm systems in which the alarm condition is signalled from a central station to a plurality of substations
    • G08B27/001Signalling to an emergency team, e.g. firemen
    • GPHYSICS
    • G08SIGNALLING
    • G08BSIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
    • G08B27/00Alarm systems in which the alarm condition is signalled from a central station to a plurality of substations
    • G08B27/005Alarm systems in which the alarm condition is signalled from a central station to a plurality of substations with transmission via computer network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/14Network-specific arrangements or communication protocols supporting networked applications for session management
    • H04L67/141Network-specific arrangements or communication protocols supporting networked applications for session management provided for setup of an application session
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/14Network-specific arrangements or communication protocols supporting networked applications for session management
    • H04L67/142Network-specific arrangements or communication protocols supporting networked applications for session management provided for managing session state for stateless protocols; Signalling a session state; State transitions; Keeping-state mechanisms
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/14Network-specific arrangements or communication protocols supporting networked applications for session management
    • H04L67/146Markers provided for unambiguous identification of a particular session, e.g. session identifier, session cookie or URL-encoding

Abstract

A mashup session manager maintains state of the mashup session to ensure presentation consistency/uniformity across the execution environments. The mashup session manager also tracks the participating execution environments associated with a mashup session (e.g., usernames, device identifiers, network addresses, etc.), and transmits data for presentation consistency to the participating execution environments. In some cases, a view of the mashup session at a participating execution environment may not be current (“stale mashup session view”). The mashup session manager can detect if a view at a participating execution environment is of a past mashup session state, and provide data for the stale mashup session view to become current. In addition, the mashup session manager can propagate design modifications to the participants of the mashup session.

Description

    RELATED APPLICATIONS
  • This application is a continuation application that claims the benefit of U.S. patent application Ser. No. 12/651,072 filed Dec. 31, 2009.
  • BACKGROUND
  • Embodiments of the inventive subject matter generally relate to the field of mashup applications, and, more particularly, to a multi-user mashup session.
  • A mashup application (“mashup”) is constructed with reference to two or more distinct services. The services referenced by a mashup return data in response to a request that can indicate one or more parameters. A service may be a data service or a functional service. The references to the services are wired together to meet a situational or niche need contemplated by a designer of the mashup. The mashup itself can be implemented with logic to operate upon the data returned from one or more of the services. The mashup then presents an output resulting from the returned data.
  • SUMMARY
  • Embodiments include a method for presenting a multi-user mashup session across execution environments. The method generates a mashup session identifier for a mashup session based, at least in part on a mashup. A plurality of participant devices is associated with the mashup session identifier, and connections are established with the plurality of participant devices. The state data is maintained for the mashup session that correspond to a current view of the mashup session after a most recent action performed on the mashup during the mashup session at a first of the plurality of participant devices. An indication of the state data is communicated among the plurality of participant devices.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The present embodiments may be better understood, and numerous objects, features, and advantages made apparent to those skilled in the art by referencing the accompanying drawings.
  • FIGS. 1A and 1B depict conceptual diagrams of consistent views of a current state of a mashup session across multiple execution environments. FIG. 1A depicts a conceptual diagram of a mashup session manager managing a mashup session.
  • FIG. 1B depicts an example conceptual diagram of the mashup session manager maintaining consistent views across different execution environments of the participants of the mashup session.
  • FIG. 2 depicts a flowchart of example operations for creating a mashup session that can be shared across multiple execution environments.
  • FIG. 3 depicts a flowchart of example operations for updating mashup session state information based on data generated by a mashup application and delivering the data to multiple participant execution environments.
  • FIG. 4 depicts a flowchart of example operations for adding services to an existing mashup application.
  • FIG. 5 depicts a flowchart of example operations for adding participant execution environments to an existing mashup session.
  • FIG. 6 is an example conceptual diagram of a network for delivering data generated by mashup applications to participant execution environments.
  • FIG. 7 depicts a flowchart of example operations for dispatching an appropriate emergency responder using a distributed mashup.
  • FIG. 8 depicts an example computer system.
  • FIG. 9 depicts an example mashup session structure.
  • FIG. 10 depicts an example conceptual diagram of asynchronous collaboration with a mashup session shared across different execution environments.
  • DESCRIPTION OF EMBODIMENT(S)
  • The description that follows includes exemplary systems, methods, techniques, instruction sequences, and computer program products that embody techniques of the present inventive subject matter. However, it is understood that the described embodiments may be practiced without these specific details. For instance, although examples refer to Web Services Description Language (WDSL) and Representational State Transfer (REST) other feed techniques and service technologies can be used (e.g., RSS, ATOM, etc.). In other instances, well-known instruction instances, protocols, structures, and techniques have not been shown in detail in order not to obfuscate the description.
  • A mashup can be instantiated that runs across different execution environments and allows respective users of the different execution environments to collaboratively use and/or modify the mashup instance (“mashup session”). When any one of the multiple users submits a parameter to a view of the mashup session presented on their respective execution environment, the views of the mashup session at all of the execution environments can be updated in response, although individual configurations of the execution environments can lead to variances in the views of the mashup session (e.g., colors, alerts, fonts, etc.). A mashup session manager maintains state of the mashup session to ensure presentation consistency/uniformity across the execution environments. The mashup session manager also tracks the participating execution environments associated with a mashup session (e.g., usernames, device identifiers, network addresses, etc.), and transmits data for presentation consistency to the participating execution environments. In some cases, a view of the mashup session at a participating execution environment may not be current (“stale mashup session view”). The mashup session manager can detect if a view at a participating execution environment is of a past mashup session state, and provide data for the stale mashup session view to become current. In addition, the mashup session manager can propagate design modifications to the participants of the mashup session.
  • FIGS. 1A and 1B depict conceptual diagrams of consistent views of a current state of a mashup session across multiple execution environments. FIG. 1A depicts a conceptual diagram of a mashup session manager managing a mashup session. FIG. 1A depicts a mashup session manager 101 communication with devices 103, 105. The device 103 is a computer, and the device 105 is a smart phone in FIG. 1A.
  • At stage A, the device 103 selects a mashup application from a mashup catalog 109. The mashup catalog 109 can be stored locally or remotely with respect to the device 103. For instance, the device 103 retrieved one or more files for the selected mashup in response to the selection. Selection of the mashup may involve any one of adding functionality and/or data services to an existing mashup application, removing functionality and/or a data service from an existing mashup application, selecting multiple data services and assembling them into a mashup, etc.
  • At stage B, the device 103 indicates the selected mashup and one or more participants to the mashup session manager 101. The device 103 can indicate the selected mashup in accordance with a variety of techniques. For example, the device 103 can communicate any one or more of a mashup identifier, the mashup application itself, a database entry that corresponds to the mashup, etc. In addition, the device 103 can indicate participants for mashup session by device identifiers (MAC addresses, IP addresses, device serial numbers, etc.), by usernames, by telephone numbers, by e-mail addresses, etc. The device 103 may also select participants with a user interface and/or participant data associated with or accessible by the mashup session manager 101.
  • At stage C, the mashup session manager 101 instantiates and populates a mashup session structure 107 with indications of the mashup and the participants indicated by the device 103. The mashup session manager 101 uses the mashup session structure 107 to maintain state of the mashup session. Example data relevant to the state of the mashup session includes actions performed, requests submitted to services of the mashup, values of parameters submitted with requests, and results received in response to the actions performed. The mashup session manager c101 can use the mashup session structure to update a participant device that may have a stale view of mashup session (e.g., the participant device reconnects after losing connection, the participant device connects after the session begins, etc.).
  • FIG. 9 depicts an example mashup session structure. The depicted mashup session structure can be a standalone structure or an entry or part of another structure (e.g., entry in a hash table, element of a tree, etc.). The example mashup session structure includes a mashup session identifier field 901. The mashup session identifier field manager one indicates a value that identifies a corresponding mashup session. The mashup session manager or some other process can generate the mashup session identifier in accordance with a variety of techniques. For example, the mashup session manager can generate the mashup session and a log of a fire based upon a hash of an identifier of the owner and identifier of the corresponding mashup application.
  • The mashup session identifier field identifier references a substructure that includes a participants field 903, a mashup application identifier field 905, and a state data field 907. The mashup application identifier field 905 indicates a mashup application identifier. The state data field 907 indicates at least a most recent result for the mashup session. The state data field 907 can indicate a default of actions, a log of requests submitted to the services of the mashup, deltas of results, history of results, result history within a window of time, etc.
  • The participants field 903 references a substructure 909. The substructure 909 (e.g., an array, list, a tree, etc.) identifies an order of the mashup session and participants of the mashup session. The substructure 909 also identifies devices associated with the owner and participants.
  • The mashup session manager 101 can also edit an entry of an existing structure. For instance, a mashup session manager may be responsible for several ongoing mashup sessions, and manage them with one structure. The mashup session manager 101 could add an entry to this structure, overwrite an entry that already exists in this structure, etc. A mashup session manager may maintain a mashup session structure for all ongoing mashup sessions managed by the mashup session manager, a mashup session structure for each owner/creator, a mashup session structure for each individual session, etc.
  • After the mashup session structure 107 is instantiated and populated, the mashup session manager 101 communicates with the device 103 and the device 105. The communications can take place in any order and are represented by stages D1 and D2 in FIG. 1A. At stage D1, the mashup session manager 101 establishes a connection with the participant device 105 for the mashup session. The mashup session manager 101 indicates the mashup session to the participant device 105. The mashup session manager 101 establishes the connection with the device 105 using participant information previously indicated by the device 103 at stage B. Establishing the connection between the mashup session manager 101 and the device 105 may involve setting up a channel, setting up a communication session, authentication and verification operations, handshake operations, etc. Establishing the connection can also involve the mashup session manager 101 querying the device 105 for execution environment for the connection (e.g., formatting information, encoding information, software version information, etc.). The mashup session manager 101 may encapsulate, encode, and/or reformat data when communicating with the device 105. To indicate the mashup session to the device 105, the mashup session manager 101 can supply a reference or data fire of the mashup session structure 107. The device 105 can access the mashup session structure 107 to retrieve the mashup application. The mashup session manager 101 can also or alternatively supply the mashup to the device 105 as well as an identifier or reference to the mashup session structure 107. At stage D2, the mashup session manager 101 indicates the mashup session to the session owner that corresponds to the device 103. For example, the mashup session manager 101 transmits data that can comprise a memory address of the mashup session structure 107, an identifier of the mashup session structure 107, an identifier of the mashup session structure 107 and an index into the mashup session structure 107, etc.
  • At stage E, the device 103 performs an action in the mashup session and receives a corresponding result from the Internet 109.
  • At stage F, the device 103 updates a view 106 of the mashup session with the received result. FIG. 1A depicts the device 103 updating a map mashup. The view 106 illustrates a map with three restaurant locations and a public parking area nearest one of the restaurant locations that is near an intersection. As an example, the device 103 may have performed an action in the mashup session to map restaurants that are near the participants using the devices 103, 105 and that satisfy cuisine criteria indicated profiles of the participants.
  • At stage G, the device 103 indicates the received result and the performed action to the mashup session manager 101. For instance, device 103 indicates a request generated from the mashup that corresponds to the action performed at stage E to the mashup session manager 101 and the responsive data. Embodiments do not necessarily communicate indications of both the received result and the performed action. Embodiments can communicate one of the received result and the performed action to the mashup session manager 101.
  • At stage H, the mashup session manager 101 updates the mashup session structure 107 with indications of the result and the action, thus reflecting state of the mashup session in the mashup session structure 107. The mashup session manager 101 can maintain a history of actions performed during the mashup session in the mashup session structure 107. The history can be comprehensive or limited by a window of time. The mashup session manager 101 can indicate in the mashup session structure 107 each result of each performed action, a most current result, a last N results, a delta of a current result and a previous result, etc.
  • At stage I, the mashup session manager 101 indicates the result to the participant device 105. The mashup session manager 101 can also provide performed action to the participant device 105. The participant device 105 can automatically perform the performed action to obtain a current view of the mashup session. The participant device 105 can compare the results of device 105 receives from the Internet 109 against the result indicated from the mashup session manager 101. Any differences can be communicated back to the mashup session manager 101 for validation and/or propagation to other participants of the mashup session.
  • At stage J, the participant device 105 updates a view 111 of the mashup session with the result indicated by the mashup session manager 101. The views 106, 111 of the mashup session at the respective devices 103, 105 are consistent across the different execution environments of the participants.
  • FIG. 1B depicts an example conceptual diagram of the mashup session manager maintaining consistent views across different execution environments of the participants of the mashup session. At stage A, the participant device 105 performs an action in the mashup session and receives a corresponding result from the Internet 109. At stage B, the participant device 105 updates the view 111 of the mashup session with the received result. In FIG. 1B, the participant device 105 has updated the view 111 to depict a volleyball field at the intersection of roads, and to no longer depict one of the previously depicted restaurants. As an example, the participant device 105 may have performed an action in the mashup session that requested indication of recreational facilities near the restaurants already displayed, and an action in the mashup session that added a cost criterion. The eliminated restaurant exceeded, or perhaps fell below, the cost criterion indicated by the participant device 105.
  • At stage C, the participant device 105 indicates the result in the action to the mashup session manager 101.
  • At stage D, the mashup session manager 101 updates the mashup session structure 107 in accordance with the action and the result indicated by the participant device 105.
  • At stage E, the mashup session manager 101 indicates the result to the owner of the mashup session, which is the device 103. As stated earlier, the mashup session manager 101 can also indicate the result to the device 103.
  • At stage F, the device 103 updates the view 106 in accordance with the result indicated by the mashup session manager 101. Alternatively, the device 103 can obtain the result from the Internet 109 by performing the action indicated by the participant device 105. Although the example depicted by FIGS. 1A and 1B refer to obtaining results from the Internet, embodiments are not so limited. Embodiments can obtain results from any one or more of an intranet, virtual private network, and the Internet.
  • Although FIGS. 1A and 1B depict the mashup session manager 101 as being separate from the device 103 that initiated the mashup session, embodiments are not so limited. The mashup session manager 101 can be implemented at an intermediate device (e.g., a cloud, server, etc.), on the device 103, distribute across device 103 an intermediate device, etc. hence, communications that seemingly flow through the mashup session manager 101 may be direct communications between the device 103, which initiated the mashup session, and devices of participants of the mashup session. In addition, communications for the mashup session that flow directly between participant devices can be mirrored to an intermediate device or entity (e.g., cloud that supports the mashup session). Embodiments may also interject a mashup session manager between an initiating device and/or participant devices and the Internet. For example, actions performed at a participant device are submitted to the mashup session manager which generates the corresponding requests and submits or causes to be submitted the requests to the appropriate data service. Embodiments can direct mashup actions and responses to the mashup actions through a mashup session manager and/or processes spawned by or associated with the mashup session manager. Embodiments can instantiate/supply user interfaces to the participant devices that forward actions and corresponding parameter values indicated with the user interfaces to the mashup session manager. The mashup session manager can then submit the actions and corresponding parameter values to the mashup application. The mashup session manager can broadcast or multicast results of the submitted actions to all participants of the mashup session. In addition, the mashup session manger can perform operations to manage collisions among the execution environments. For example, embodiments can sequence and/or prioritize actions, which impact state of the mashup session, performed at the execution environments.
  • FIG. 2 depicts a flowchart of example operations for creating a mashup session that can be shared across multiple execution environments. A request to create a mashup application is received (201) from an execution environment. The request can indicate services to for the mashup application according to a need contemplated by a designer of the mashup application. The designer of the mashup application can be associated with the execution environment.
  • Services for the mashup application are determined (203). Services can be data sources, can provide functionality, or both. Examples of data source type services include weather databases, business directories, and restaurant review aggregators. Examples of functionally type services include database managers, map applications, and traffic reporting applications. Functionality can be implemented in servlets, applets, applications, etc. The services can be provided by a mashup session manager, a third-party, or a combination thereof. For example, a mashup session manager can determine the services based on the request. As another example, the mashup session manager can determine the services by querying the execution environment requesting creation of the mashup. The mashup session manager can provide an indication of the available services to the execution environment. The indication of available services can include descriptions of the services that help designers choose appropriate services for mashup applications the designers wish to create. In response, the execution environment can display the available services and can prompt the designer to select services for the mashup application.
  • The mashup application is created based on the services (204). The services can be wired together based on indications of the designer. For example, the purpose of the mashup application can be finding restaurants convenient to the locations of several individuals. The services selected for the mashup are a restaurant database and a map application. Both the restaurant database and the map application expect locations as inputs. Locations can be represented by global positioning system (GPS) coordinates, addresses, intersections, etc. The designer indicates that restaurants should be retrieved from the restaurant database based on locations that can be provided as inputs to the mashup application. Addresses of the restaurants output by the restaurant database and the provided locations should be input into the map application so that the map application can create a map of the provided locations and the restaurants.
  • Participant execution environments associated with the mashup application are determined (205). For example, the mashup session manager can determine the participant execution environments based on identifiers indicated in the request. As another example, the mashup session manager can determine the participant execution environments by querying the designer's execution environment. The mashup session manager can provide an indication of users known to the mashup session manager. The users may be known to the mashup session manager because the users registered the users' execution environments with the mashup session manager, the users' execution environments were previously associated with a mashup application, etc. In response, the designer' execution environment can display the known users and can prompt the designer to select participants to associate with the mashup application. The designer can select participants from the known users or can identify other users by providing contact information of the other users (e.g., an e-mail address, a phone number, an instant messaging username, etc). The designer's execution environment is automatically considered to be a participant execution environment.
  • A mashup session can be created based on the participant execution environments and the mashup application (207). Establishing the mashup session can comprise generating a mashup session identifier and populating a mashup session state structure with data that associates the mashup application with the mashup session identifier and the participant execution environments. The mashup session structure can be populated with the mashup session identifier, an indication of the mashup application, and indications of the participant execution environments. Examples of the indication of the mashup application include a name, a reference (e.g., a link to code, a memory address (i.e., pointer) to the code), code hash value, the mashup application itself, etc. Examples of indications of the participant execution environments include usernames, device identifiers (e.g., MAC addresses, phone numbers, etc.), network addresses, etc.
  • Data is retrieved from the mashup application based on parameters indicated by the participant execution environments (209). In the previous example of the convenient restaurant locator mashup, a mashup session manager determines the locations of each of the participant execution environments. The mashup session manager can determine the locations by querying the execution environments. The execution environments can automatically determine and return the parameters based on stored data (e.g., a GPS coordinate of a mobile phone). The devices can also prompt participants associated with the execution environments to enter the attributes. The mashup session manager can also determine parameters based on previously stored data accessible to the mashup session manager. For example, parameters can be stored by the mashup session manager when a user registers the users' execution environment with the mashup session manager. The mashup session manager can provide locations to the mashup as inputs. The mashup application can retrieve a list of restaurants from the restaurant database and utilize the map application to generate a map of the restaurants and the locations of the participant execution environments.
  • State information associated with the mashup session can be updated based on the data (block 211). The data can be stored in the state information associated with the mashup session identifier in the mashup session structure. The request can be stored with the data in the state information to maintain a history of requests and data generated by the mashup application in response to the requests.
  • The data is delivered to the participant execution environments (213). The data can be delivered in accordance with state information to ensure presentation consistency across the participant execution environments. Individual state information associated with each of the participant execution environments with respect to the mashup application can be maintained. The individual state information indicates a last state of the data that was viewed on a participant execution environment. The mashup session manager 101 can deliver data generated by the mashup application to the participant execution environment since the last state. The data can be delivered to the participants by a REST web service.
  • After a mashup session is established, requests made to a mashup application associated with the mashup session cause the mashup application to generate new data. FIG. 3 depicts a flowchart of example operations for updating mashup session state information based on data generated by a mashup application and delivering the data to multiple participant execution environments. A request to a mashup application is received from a participant execution environment (301). For example, a mashup session manager receives a request to add a new service to the mashup application. As another example, the mashup session manager receives a request to associate a new participant execution environment with the mashup application.
  • A mashup session associated with the participant execution environment is determined (303). The mashup session can be determined based on locating an identifier of the participant execution environment in a mashup session structure and determining a mashup session identifier associated with the participant execution environment identifier. A mashup application associated with the mashup session identifier can also be determined.
  • Data is retrieved from the mashup application based on the request (305). For example, the request comprises an indication of a new execution environment to participate in the mashup session. So, the mashup session manager determines a location of the new execution environment and provides the location as an input along with locations of other participant execution environments to a restaurant locator mashup application. The locations of other participant execution environments can be determined based on state data of a previous request submitted to the mashup application. The mashup application retrieves a new set of restaurants from a restaurant database based on the locations and utilizes a map application to create a new map of the locations and the restaurants.
  • State information of the mashup is updated based on the data and the request (307). State information can be stored in the mashup session structure based on the mashup session identifier. The state information can maintain a history of requests and data generated by the mashup application in response to the requests.
  • Other participant execution environments associated with the mashup session are determined (309). The other participant execution environments can be determined based on state information of the mashup session.
  • Data is delivered to the participant execution environments in accordance with the state information (311). Delivering the data to the participant execution environments can comprise determining that a state of a first participant execution environment corresponds to a past state of the mashup session and determining data generated by the mashup application since the past state of the mashup session based individual state information corresponding to the first participant execution environment in the mashup session structure. The data generated by the mashup application since the past state can be transmitted to the first participant execution environment to update a view of the mashup session associated with the first execution environment to the current state. For example, a Webpage representing the data is open in a browser of the first execution environment. A mashup session manager determines that the browser last loaded the Webpage prior to the latest request based on the individual state information. The mashup session manager can transmit an indication to the browser to cause the browser to refresh the Webpage.
  • After a mashup application is created, any of the participants associated with the mashup can add services to the mashup. In response to a mashup session manager adding the service to the mashup application, the mashup application can generate new data. The mashup session manager can automatically update state information to reflect the data and deliver the data to the participant execution environments associated with the mashup application. FIG. 4 depicts a flowchart of example operations for adding services to an existing mashup application. A request to add a service is received from a participant execution environment (401). For example, a mashup session manager receives a request indicating a new service to be added to an existing mashup application.
  • A mashup session associated with the participant execution environments is determined (403). The mashup session manager can determine the mashup application based on state information for a mashup session associated with the participant execution environment.
  • Existing services of the mashup application are determined (block 405). For example, a mashup session manager determines the existing services of the mashup based on metadata of the mashup application.
  • The mashup application is updated based on indicated connections among the new service and existing services (407). For example, a user may wish to add a restaurant review aggregator to the convenient restaurant locator mashup. The mashup session manager determines that a connection should be made between an output of the restaurant database to the restaurant review aggregator such that restaurant identifiers (e.g., restaurant names, addresses, phone numbers, etc.) can be input into the restaurant review aggregator to retrieve reviews.
  • Data is retrieved from the mashup application based on parameters indicated by the participant execution environments (409). For example, a calendar application may be added to a mashup application for scheduling business lunches. A query containing the locations and calendar identifiers of the participant execution environments can be submitted to the business lunch scheduler mashup application. In response, the mashup application can retrieve information about each participant's free time from the calendar application based on an identifier for each participant's calendar. In addition to retrieving data from the additional service, the mashup can retrieve data from the existing services if the attributes have changed. For example, a map of the restaurants may be updated if one or more of the participants' locations changed.
  • State information associated with the mashup session is updated based on the data and the request (411).
  • Other participant execution environments associated with the mashup are determined (413). The participant execution environments can be determined based on state information of the mashup session.
  • Data is delivered to the participant execution environments in accordance with the state information (415). For example, one of the participants opens a view of the data. Individual state information for the participant can indicate that the participant last viewed the data when a previous request was submitted to the mashup application. A mashup session manager can determine data that was generated by the mashup in response to the previous request and the current request and deliver the data to the participant through the participant execution environments.
  • After a mashup session is created, new execution environments can also be selected to participate in the mashup session. For example, a participant wishes to invite more colleagues to a lunch meeting. FIG. 5 depicts a flowchart of example operations for adding participant execution environments to an existing mashup session. It is determined that an execution environment has been selected to participate in an existing mashup session (501). For example, a mashup session manager receives a request identifying the execution environment to be added as a participant in the existing mashup session. The participant execution environment can be identified based on contact information of a user associated with the participant execution environment such as an e-mail address, a phone number, instant messaging username, etc. The request can include an identifier of the existing mashup session so the mashup session manager adds the participant execution environment to the appropriate mashup session.
  • The existing mashup session is determined (403). For example, the existing mashup session is determined based on an identifier in the request.
  • Data generated by the mashup is determined based on the state information (507). The execution device has never accessed a view of the data, so a mashup session manager can determine data that was generated by the mashup since the mashup was created.
  • The data is delivered to the execution environment (509).
  • FIG. 6 is an example conceptual diagram of a network for delivering data generated by mashup applications to participant execution environments. A mobile phone 605, a laptop computer 609, and a desktop computer 607 are connected to a mashup session manager 601 through a network 603. The mobile phone 605, the laptop computer 609, and the desktop computer 607 represent user devices registered with the mashup session manager 601. Although not shown, other user devices such as PDAs and portable music players can be connected to the mashup session manager 601 through the network 603.
  • The mashup session manager 601 is connected to various services 611 through the network 603. The services can comprise data sources and functionality. In this example, the services 611 comprise a restaurant locator 613, a weather service 615, a map application 617, and a traffic application 619. Other examples of services include business directories, movie listings, calendar applications, etc. In this example, the services 611 are hosted on third-party servers (not shown). In other examples, some (or all) of the services 611 can be hosted on the mashup session manager 601.
  • The mashup session manager 601 receives requests to create mashup applications from the mobile phone 605, the laptop computer 609, and the desktop computer 607, and creates the mashup applications based on selected services. The mashup session manager 601 associates participant execution environments and a mashup application with a mashup session. The mashup session manager retrieves data from the mashup application based on parameters indicated by the participant execution environments, updates state information of the mashup session to reflect the data, and distributes the data the participant execution environments in accordance with the state information. For example, the mashup session manager 601 can receive a request for creating a mashup application for responding to natural disasters from the desktop computer 607. The mashup session manager 601 can determine that the weather service 615, the map application 617, and the traffic application 619 constitute services specified for the mashup. The mashup session manager 601 can also determine that the laptop computer 609, the mobile phone 605, and the desktop computer 607 have been selected as participant execution devices associated with a mashup session. The mashup session manager 601 can retrieve weather information from the weather service 615. When a natural disaster hits, the mashup session manager 601 can utilize information reported by the weather service 615 to create a map, using the map application 617, of the natural disaster's location and impose the locations of the participants on the map. The mashup session manager can integrate traffic information from the traffic application 619 with the map to determine routes for each participant. The mashup session manager 601 compiles the data generated by the mashup application comprising the natural disaster information from the weather service 615, the map and traffic information and updates state information of the mashup session based on the data and distributes the data to the mobile phone 605, the laptop computer 609, and the desktop computer 607 so that the participants associated with the mobile phone 605, the laptop computer 609, and the desktop computer 607 can respond to the natural disaster.
  • Although examples refer to a stand-alone mashup session manager, embodiments are not so limited. For example, functionality of the mashup session manager can be implemented on a participant execution environment.
  • A distributed mashup can be created to dispatch appropriate emergency response personnel to an emergency. Services such as a map application, a traffic application, and an emergency database, can be added to the distributed mashup. Emergency responders can be selected participate in the mashup based on identification of the emergency responders' execution environments (e.g., laptop computer in response vehicles, mobile phones, navigation units in the response vehicles, etc.). FIG. 7 depicts a flowchart of example operations for dispatching an appropriate emergency responder using a distributed mashup. An emergency call is received (block 701). For example, an emergency is reported to a 911 dispatch center. A 911 operator can input information about the emergency (e.g., location, type, etc.) into an emergency database.
  • A mashup session manager can detect that a new emergency has been added to the emergency database and determine the location of the emergency and type of emergency (block 703) based on information in the emergency database.
  • Emergency responders to respond to the emergency are determined based on the type (block 705). For example, firefighters should respond to a fire emergency. As another example, police officers and emergency medical technicians should respond to a car accident.
  • Locations of the emergency responders are determined (block 707). For example, the mashup session manager queries the emergency responders' devices to determine GPS coordinates of the emergency responders.
  • A map application can be utilized to determine distances between the locations of the emergency responders and the location of the emergency (block 709).
  • A traffic application can be utilized to estimate travel times for the emergency responders and determine best routes (711). For example, traffic information can be imposed on the map so that the map application can determine the best routes.
  • An appropriate emergency responder is chosen based on the shortest distances and travel times (block 713). Availability of the emergency responders can also be used to determine the appropriate emergency responder. For example, an emergency responder who has already been dispatched to a previous emergency is not chosen as the appropriate emergency responder.
  • The output of the mashup is stored (block 715). In this example, the output comprises the type and location of the emergency and the best route.
  • The output is sent to the appropriate emergency responder (block 771) to dispatch the emergency responder. Although the output is sent to the appropriate emergency responder, the output can be distributed to other emergency responders because the appropriate emergency responder may need backup or may not be able to respond due to external factors (e.g., an increase in traffic along the best route).
  • Embodiments are not limited to the example flowcharts depicted in the above figures. Embodiments can perform additional operations, fewer operations, operations in parallel, etc. For instance, referring to FIG. 2, operations for creating a mashup based on the participant execution environments and retrieving data from the mashup application can be performed in parallel. Referring to FIG. 5, the operations for determining existing services of the mashup application and determining other participant execution environments can be performed in parallel.
  • As will be appreciated by one skilled in the art, aspects of the present inventive subject matter may be embodied as a system, method or computer program product. Accordingly, aspects of the present inventive subject matter may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present inventive subject matter may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
  • Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
  • A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
  • Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
  • Computer program code for carrying out operations for aspects of the present inventive subject matter may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
  • Aspects of the present inventive subject matter are described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the inventive subject matter. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
  • These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
  • The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
  • FIG. 8 depicts an example computer system. The computer system can act as a mashup session manager. A computer system includes a processor unit 801 (possibly including multiple processors, multiple cores, multiple nodes, and/or implementing multi-threading, etc.). The computer system includes memory 807. The memory 807 may be system memory (e.g., one or more of cache, SRAM, DRAM, zero capacitor RAM, Twin Transistor RAM, eDRAM, EDO RAM, DDR RAM, EEPROM, NRAM, RRAM, SONOS, PRAM, etc.) or any one or more of the above already described possible realizations of machine-readable media. The computer system also includes a bus 803 (e.g., PCI bus, ISA bus, PCI-Express bus, HyperTransport® bus, InfiniBand® bus, NuBus bus, etc.), a network interface 805 (e.g., an ATM interface, an Ethernet interface, a Frame Relay interface, SONET interface, wireless interface, etc.), and a storage device(s) 809 (e.g., optical storage, magnetic storage, etc.). The computer system also includes a mashup session manager 821. The mashup session manager 821 can determine participant execution environments associated with a mashup application and establish a mashup session based on the mashup application and the participant execution environments. The mashup session manger 821 can also create a mashup session structure to main state of the mashup session and ensure consistent, current views of the mashup session. The mashup session manager 821 can deliver data generated by the mashup application to the participant execution environments in accordance with the state information to ensure presentation consistency across the participant execution environments. Any one of these functionalities may be partially (or entirely) implemented in hardware and/or on the processing unit 801. For example, the functionality may be implemented with an application specific integrated circuit, in logic implemented in the processing unit 801, in a co-processor on a peripheral device or card, etc. Further, realizations may include fewer or additional components not illustrated in FIG. 8 (e.g., video cards, audio cards, additional network interfaces, peripheral devices, etc.). The processor unit 801, the storage device(s) 809, and the network interface 805 are coupled to the bus 803. Although illustrated as being coupled to the bus 803, the memory 807 may be coupled to the processor unit 801.
  • As stated earlier, participants of a mashup session can modify the mashup. Although a consistent view can be maintained across participant devices, participants may choose to modify the mashup for their own purposes without synchronizing the changes to the other participant devices. Hence, the various participants can asynchronously interact with the mashup in the mashup session. Although the interactions would be asynchronous and the views vary, the mashup session manager maintains a global perspective of the mashup session. Thus, participants can asynchronously collaborate with the mashup, and be aware of other participant's interactions with the mashup without necessarily being confined to a uniform, global view of the mashup session.
  • FIG. 10 depicts an example conceptual diagram of asynchronous collaboration with a mashup session shared across different execution environments. FIG. 10 illustrates a computer 1001, a smartphone 1005, and a mashup session manager 1003. For this illustration, the mashup session manager resides on an intermediate device, for example on a server.
  • The computer 1001 creates a mashup application 1007. As depicted in FIG. 10, creation of the mashup application can involve selecting from a catalog of mashup applications, and possibly modifying a selected mashup application. The mashup application 1007 can also be created with a tool that generates code based on services and functionality selected by a user. In FIG. 10, the computer 1001 creates the mashup 1007 to use a service A and a service B. The created mashup is indicated to the mashup session manager 1003, where mashup code 1009 is created. Embodiments can create the mashup code at the mashup session manager 1001 with data sent from the creating computer 1001 that indicates the services and functionality. Embodiments can also send the mashup code 1007 to the mashup session manager 1003. Embodiments can also create the mashup 1007 at the mashup session manager 1003, instead of at the computer 1001. For instance, the indications of services and functionality can be performed with a user interface at the computer 1001, while the generation of the mashup application code is done at the mashup session manager in response to the indications with the user interface. Embodiments can also generate different degrees of the mashup application code in the difference environments. For example, the mashup session manager can distribute mashup application code that comprises Perl script, DHTML code, and XSQL code. In another example, the mashup session manager can distribute mashup application code that indicates services (e.g., links, names of the data services, etc.), and how the services are wired together or how the services should be wired together. The execution environments can add additional code for presentation functionality (e.g., user interface components), additional code that operates upon data from the services, additional code that filters results from the services, additional code that manipulates input to be submitted to the services, additional code that implements the wiring, etc.
  • As discussed earlier, creating the mashup session involves adding participants. In accordance with information provided by the computer 1001, the mashup session manager 1003 establishes a connection with the smartphone 1005. Adding the smartphone 1005 as a participant device can comprise any one of sending the mashup code 1009 to the smartphone 1005, communicating a reference (e.g., network location) of the mashup code 1009 to the smartphone 1005, creating a connection for the computer 1001 to communicate the mashup code 1007 to the smartphone 1005, etc. After obtaining sufficient information, the mashup session manager 1003 instantiates the mashup session based upon the mashup code 1009.
  • After joining the mashup session, the smartphone 1005 modifies the mashup code 1009. The smartphone 1005 removes service B, and adds a service C and a service D, resulting in a mashup code 1011. The smartphone 1005 communicates the modification to the mashup session manager 1003. The mashup session manager 1003 updates the mashup session data accordingly. For instance, the mashup session manager can instantiate a mashup session structure or modify a data structure entry for the participant device 1005 that indicates the mashup code 1011, or at least the modifications. In FIG. 10, the mashup session manager 1003 modifies the mashup code 1009 to use services C, D, which were added by the smartphone 1005.
  • The mashup session manager 1003 then notifies the computer 1001 of the modifications made at the smartphone 1005. Although the computer's view can be synchronized with the view of the mashup session at the smartphone 1005, the computer 1001 opts to receive notifications of results and/or interactions of other participants (or a particular participant) instead of synchronizing the view of the mashup session. To illustrate, a first user creates a mashup to map restaurant locations within a threshold distance of all participants. So, the mashup utilizes a map service, a restaurant listing service, and global positioning services of the participants' devices. One of the participants may not care about the cuisine, but wants to find a ticket vendor near all participants. This participant modifies the mashup at his/her device to use a map service, the GPS services, and a ticket vendor directory. A third participant may not want to view the map, perhaps to conserve power, and only wishes to see reviews of restaurants returned to the query of the first participant. The mashup session manager can maintain data and code that provides results, or is aware of the results, that map restaurants for the first participant, and that map ticket vendors for the second participant. The mashup session manager can receive interact with the device of the third participant to retrieve restaurant reviews for the third participant for only those restaurants in the result provided to the first participant.
  • Although FIG. 10 depicts the mashup session manager modifying the mashup 1009 to reflect additions made by the participant device 1005, embodiments are not so limited. Embodiments can maintain each different mashup code for the different participant devices. For example, participant A uses services A and B; participant B uses services A, B, and C; and participants C and D use services A, B, and E. The mashup session manager can maintain separate mashup code for participants A, B, and a single mashup code for participants C and D. In addition to the separate mashup codes, the mashup session manager can also maintain a unifying mashup code that utilizes all of the services. The mashup session manager maintains data and code that allows views of the mashup session to be consistent across participant devices, if desired. And the mashup session manager can notify a first participants of results received/used by a second participant, without homogenizing the views of the mashup session. Embodiments can also allow a participant device to present at least a few if not all of the different views of the mashup session. Using the above illustration, a first participant device can display a first map of restaurants, a second map of ticket vendors, and a listing of the restaurant reviews of the mapped restaurants. Thus, the shared mashup session is flexible enough to allow collaboration of participants across devices in a mashup session with or without synchronization of views.
  • Furthermore, embodiments are not limited to services provided from websites on the Internet. As discussed above, a mashup can utilize a service of participant devices, such as the global positioning data provided by each device. Mashups can utilize services provided at the server hosting the mashup session manager, services provided by an intranet, etc.
  • While the embodiments are described with reference to various implementations and exploitations, it will be understood that these embodiments are illustrative and that the scope of the inventive subject matter is not limited to them. In general, techniques for distributing mashups across execution environments as described herein may be implemented with facilities consistent with any hardware system or hardware systems. Many variations, modifications, additions, and improvements are possible.
  • Plural instances may be provided for components, operations, or structures described herein as a single instance. Finally, boundaries between various components, operations and data stores are somewhat arbitrary, and particular operations are illustrated in the context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within the scope of the inventive subject matter. In general, structures and functionality presented as separate components in the exemplary configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements may fall within the scope of the inventive subject matter.

Claims (4)

What is claimed is:
1. A method comprising:
generating a mashup session identifier for a mashup session based, at least in part on a mashup that uses a first set of services to generate results in response to requests submitted to the mashup;
associating a plurality of participant devices with the mashup session identifier;
establishing connections with the plurality of participant devices;
determining that a first of the plurality of participant devices modifies the mashup either to add a service for the mashup to use in conjunction with the first set of services for generating results in response to requests submitted to the modified mashup or to remove one of the first set of services; and
maintaining state data for the mashup session that represent at least a first current result generated by the mashup from use of the first set of services and that represent at least a second current result generated by the mashup as modified.
2. The method of claim 1 further comprising at least one of synchronizing views of the mashup session across the plurality of devices to indicate the first current result and the second current result, notifying the first participant device of the at least first current result, presenting separate views of the mashup session that reflect the first current result and the second current result at a second participant device.
3. An apparatus for presenting a multi-user mashup session across execution environments, the apparatus comprising:
a processor; and
a computer readable storage medium having computer readable program code executable by the processor to cause the apparatus to,
generate a mashup session identifier for a mashup session based, at least in part on a mashup that uses a first set of services to generate results in response to requests submitted to the mashup;
associate a plurality of participant devices with the mashup session identifier;
establish connections with the plurality of participant devices;
determine that a first of the plurality of participant devices modifies the mashup either to add a service for the mashup to use in conjunction with the first set of services for generating results in response to requests submitted to the modified mashup or to remove one of the first set of services; and
maintain state data for the mashup session that represent at least a first current result generated by the mashup from use of the first set of services and that represent at least a second current result generated by the mashup as modified.
4. The apparatus of claim 3, wherein the computer readable storage medium further comprises computer usable program code executable by the processor to cause the apparatus to, at least one of, synchronize views of the mashup session across the plurality of devices to indicate the first current result and the second current result, notify the first participant device of the at least first current result, present separate views of the mashup session that reflect the first current result and the second current result at a second participant device.
US13/888,064 2009-12-31 2013-05-06 Distributed multi-user mashup Abandoned US20130346880A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US12/651,072 US8458600B2 (en) 2009-12-31 2009-12-31 Distributed multi-user mashup session
US13/888,064 US20130346880A1 (en) 2009-12-31 2013-05-06 Distributed multi-user mashup

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US13/888,064 US20130346880A1 (en) 2009-12-31 2013-05-06 Distributed multi-user mashup

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US12/651,072 Continuation US8458600B2 (en) 2009-12-31 2009-12-31 Distributed multi-user mashup session

Publications (1)

Publication Number Publication Date
US20130346880A1 true US20130346880A1 (en) 2013-12-26

Family

ID=44189004

Family Applications (2)

Application Number Title Priority Date Filing Date
US12/651,072 Expired - Fee Related US8458600B2 (en) 2009-12-31 2009-12-31 Distributed multi-user mashup session
US13/888,064 Abandoned US20130346880A1 (en) 2009-12-31 2013-05-06 Distributed multi-user mashup

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US12/651,072 Expired - Fee Related US8458600B2 (en) 2009-12-31 2009-12-31 Distributed multi-user mashup session

Country Status (1)

Country Link
US (2) US8458600B2 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140073321A1 (en) * 2012-09-11 2014-03-13 Nokia Corporation Method and apparatus for caching local mashup service parameters
US20140089901A1 (en) * 2012-09-24 2014-03-27 Ca, Inc. Embedding performance monitoring into mashup application development

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120128334A1 (en) * 2010-11-19 2012-05-24 Samsung Electronics Co. Ltd. Apparatus and method for mashup of multimedia content
EP2767066A2 (en) * 2011-10-14 2014-08-20 Open Text S.A. System and method for secure content sharing and synchronization
US9576046B2 (en) 2011-11-16 2017-02-21 Ptc Inc. Methods for integrating semantic search, query, and analysis across heterogeneous data types and devices thereof
US9098312B2 (en) 2011-11-16 2015-08-04 Ptc Inc. Methods for dynamically generating an application interface for a modeled entity and devices thereof
US8909641B2 (en) 2011-11-16 2014-12-09 Ptc Inc. Method for analyzing time series activity streams and devices thereof
US9798586B2 (en) * 2012-10-08 2017-10-24 Nokia Technologies Oy Method and apparatus for providing mashup service of component services
KR20140070689A (en) * 2012-11-12 2014-06-11 한국전자통신연구원 Apparatus for mash-up service generation based on voice command and method thereof
WO2014145084A1 (en) 2013-03-15 2014-09-18 Ptc Inc. Methods for managing applications using semantic modeling and tagging and devices thereof
JP5575999B1 (en) * 2014-02-13 2014-08-20 ソフトバンクモバイル株式会社 Map processing system
US10025942B2 (en) 2014-03-21 2018-07-17 Ptc Inc. System and method of establishing permission for multi-tenancy storage using organization matrices
US9467533B2 (en) 2014-03-21 2016-10-11 Ptc Inc. System and method for developing real-time web-service objects
US9350791B2 (en) 2014-03-21 2016-05-24 Ptc Inc. System and method of injecting states into message routing in a distributed computing environment
US9560170B2 (en) 2014-03-21 2017-01-31 Ptc Inc. System and method of abstracting communication protocol using self-describing messages
US9350812B2 (en) 2014-03-21 2016-05-24 Ptc Inc. System and method of message routing using name-based identifier in a distributed computing environment
US9961058B2 (en) 2014-03-21 2018-05-01 Ptc Inc. System and method of message routing via connection servers in a distributed computing environment
US9762637B2 (en) 2014-03-21 2017-09-12 Ptc Inc. System and method of using binary dynamic rest messages
US9462085B2 (en) 2014-03-21 2016-10-04 Ptc Inc. Chunk-based communication of binary dynamic rest messages
US9967707B2 (en) * 2014-04-16 2018-05-08 Honeywell International Inc. Weather data dissemination
US10151834B2 (en) 2016-07-26 2018-12-11 Honeywell International Inc. Weather data de-conflicting and correction system

Citations (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7188181B1 (en) * 1999-06-30 2007-03-06 Sun Microsystems, Inc. Universal session sharing
US7293034B2 (en) * 2004-02-23 2007-11-06 Microsoft Coporation Dynamically customizing a user interface for the aggregation of content
US20080268781A1 (en) * 2007-04-29 2008-10-30 Wong Man Chan Bluetooth fm transmitter with port detect
US20090063862A1 (en) * 2007-09-04 2009-03-05 Samsung Electronics Co., Ltd. Mashup service support method and apparatus
US20090193148A1 (en) * 2008-01-30 2009-07-30 Samsung Electronics Co., Ltd. Method of creating mashup application
US20090204594A1 (en) * 2008-02-07 2009-08-13 Rama Kalyani Akkiraju Recommendation System for Assisting Mashup Developers at Build-Time
US20090313601A1 (en) * 2008-06-12 2009-12-17 Kerstin Baird System For Dynamic Discovery, Configuration, And Development Of Process-Bound Widgets
US20090312033A1 (en) * 2008-06-16 2009-12-17 Microsoft Corporation Mashup application and service for wireless devices
US20100023259A1 (en) * 2008-07-22 2010-01-28 Microsoft Corporation Discovering points of interest from users map annotations
US20100037157A1 (en) * 2008-08-05 2010-02-11 International Business Machines Corp. Proactive machine-aided mashup construction with implicit and explicit input from user community
US20100036814A1 (en) * 2008-08-06 2010-02-11 Samsung Electronics Co., Ltd. Personal mashups
US20100064357A1 (en) * 2008-09-09 2010-03-11 Kerstin Baird Business Processing System Combining Human Workflow, Distributed Events, And Automated Processes
US20100064882A1 (en) * 2006-11-28 2010-03-18 Sony Corporation Mashup data file, mashup apparatus, and content creation method
US20100083287A1 (en) * 2008-09-30 2010-04-01 Maximilien E Michael Declarative Representation of Networked Applications
US20100107060A1 (en) * 2008-10-27 2010-04-29 Ricoh Company, Ltd. System, apparatus and method for generating schedule document
US20100118025A1 (en) * 2005-04-21 2010-05-13 Microsoft Corporation Mode information displayed in a mapping application
US20100211580A1 (en) * 2009-02-17 2010-08-19 International Business Machines Corporation Semantics-based data transformation over a wire in mashups
US20100268780A1 (en) * 2009-04-20 2010-10-21 International Business Machines Corporation Situational Application Creation Based on Observed User Behavior
US20110047246A1 (en) * 2009-08-21 2011-02-24 Avaya Inc. Telephony discovery mashup and presence
US20110106615A1 (en) * 2009-11-03 2011-05-05 Yahoo! Inc. Multimode online advertisements and online advertisement exchanges
US20110161409A1 (en) * 2008-06-02 2011-06-30 Azuki Systems, Inc. Media mashup system
US8261193B1 (en) * 2009-04-21 2012-09-04 Jackbe Corporation Method and system for capturing mashup data for collective intelligence and user-generated knowledge
US8312380B2 (en) * 2008-04-04 2012-11-13 Yahoo! Inc. Local map chat
US8370826B2 (en) * 2008-06-25 2013-02-05 International Business Machines Corporation Automatically managing versioning of mashup widgets
US8458596B1 (en) * 2009-04-21 2013-06-04 Jackbe Corporation Method and apparatus for a mashup dashboard
US8595186B1 (en) * 2007-06-06 2013-11-26 Plusmo LLC System and method for building and delivering mobile widgets
US20140032318A1 (en) * 2008-05-16 2014-01-30 Michael Hopwood Creating, sharing, and monetizing online digital content highlights
US9261193B2 (en) * 2008-11-13 2016-02-16 Applied Materials, Inc. Sealing apparatus for a process chamber

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020065912A1 (en) * 2000-11-30 2002-05-30 Catchpole Lawrence W. Web session collaboration
US8037506B2 (en) * 2006-03-03 2011-10-11 Verimatrix, Inc. Movie studio-based network distribution system and method
US20080109758A1 (en) * 2006-09-29 2008-05-08 Stambaugh Thomas M Spatial organization and display of event ticketing information
KR100700622B1 (en) * 2006-10-24 2007-03-28 주식회사 네오엠텔 Mash-up service system
KR20070009517A (en) 2006-12-29 2007-01-18 이종원 Mobile mashup system for user generate contents
US20080215675A1 (en) * 2007-02-01 2008-09-04 Worklight Ltd. Method and system for secured syndication of applications and applications' data
US20090024632A1 (en) * 2007-07-19 2009-01-22 Vijay Dheap Method of and System for Controlling Private Data in Web-Based Applications
US7899777B2 (en) * 2007-09-27 2011-03-01 Rockwell Automation Technologies, Inc. Web-based visualization mash-ups for industrial automation
US7945774B2 (en) * 2008-04-07 2011-05-17 Safemashups Inc. Efficient security for mashups
US8171415B2 (en) * 2008-06-11 2012-05-01 International Business Machines Corporation Outage management portal leveraging back-end resources to create a role and user tailored front-end interface for coordinating outage responses
US8156441B1 (en) * 2008-11-04 2012-04-10 Lockheed Martin Corporation Inter-gadget communication
US20100180330A1 (en) * 2009-01-09 2010-07-15 Microsoft Corporation Securing Communications for Web Mashups
US20100333037A1 (en) * 2009-06-29 2010-12-30 International Business Machines Corporation Dioramic user interface having a user customized experience

Patent Citations (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7188181B1 (en) * 1999-06-30 2007-03-06 Sun Microsystems, Inc. Universal session sharing
US7293034B2 (en) * 2004-02-23 2007-11-06 Microsoft Coporation Dynamically customizing a user interface for the aggregation of content
US20100118025A1 (en) * 2005-04-21 2010-05-13 Microsoft Corporation Mode information displayed in a mapping application
US20100064882A1 (en) * 2006-11-28 2010-03-18 Sony Corporation Mashup data file, mashup apparatus, and content creation method
US20080268781A1 (en) * 2007-04-29 2008-10-30 Wong Man Chan Bluetooth fm transmitter with port detect
US8595186B1 (en) * 2007-06-06 2013-11-26 Plusmo LLC System and method for building and delivering mobile widgets
US20090063862A1 (en) * 2007-09-04 2009-03-05 Samsung Electronics Co., Ltd. Mashup service support method and apparatus
US20090193148A1 (en) * 2008-01-30 2009-07-30 Samsung Electronics Co., Ltd. Method of creating mashup application
US20090204594A1 (en) * 2008-02-07 2009-08-13 Rama Kalyani Akkiraju Recommendation System for Assisting Mashup Developers at Build-Time
US8312380B2 (en) * 2008-04-04 2012-11-13 Yahoo! Inc. Local map chat
US20140032318A1 (en) * 2008-05-16 2014-01-30 Michael Hopwood Creating, sharing, and monetizing online digital content highlights
US20110161409A1 (en) * 2008-06-02 2011-06-30 Azuki Systems, Inc. Media mashup system
US20090313601A1 (en) * 2008-06-12 2009-12-17 Kerstin Baird System For Dynamic Discovery, Configuration, And Development Of Process-Bound Widgets
US20090312033A1 (en) * 2008-06-16 2009-12-17 Microsoft Corporation Mashup application and service for wireless devices
US8370826B2 (en) * 2008-06-25 2013-02-05 International Business Machines Corporation Automatically managing versioning of mashup widgets
US20100023259A1 (en) * 2008-07-22 2010-01-28 Microsoft Corporation Discovering points of interest from users map annotations
US20100037157A1 (en) * 2008-08-05 2010-02-11 International Business Machines Corp. Proactive machine-aided mashup construction with implicit and explicit input from user community
US20100036814A1 (en) * 2008-08-06 2010-02-11 Samsung Electronics Co., Ltd. Personal mashups
US8117180B2 (en) * 2008-08-06 2012-02-14 Samsung Electronics Co., Ltd. Personal mashups
US20100064357A1 (en) * 2008-09-09 2010-03-11 Kerstin Baird Business Processing System Combining Human Workflow, Distributed Events, And Automated Processes
US20100083287A1 (en) * 2008-09-30 2010-04-01 Maximilien E Michael Declarative Representation of Networked Applications
US20100107060A1 (en) * 2008-10-27 2010-04-29 Ricoh Company, Ltd. System, apparatus and method for generating schedule document
US9261193B2 (en) * 2008-11-13 2016-02-16 Applied Materials, Inc. Sealing apparatus for a process chamber
US20100211580A1 (en) * 2009-02-17 2010-08-19 International Business Machines Corporation Semantics-based data transformation over a wire in mashups
US20100268780A1 (en) * 2009-04-20 2010-10-21 International Business Machines Corporation Situational Application Creation Based on Observed User Behavior
US8458596B1 (en) * 2009-04-21 2013-06-04 Jackbe Corporation Method and apparatus for a mashup dashboard
US8261193B1 (en) * 2009-04-21 2012-09-04 Jackbe Corporation Method and system for capturing mashup data for collective intelligence and user-generated knowledge
US20110047246A1 (en) * 2009-08-21 2011-02-24 Avaya Inc. Telephony discovery mashup and presence
US20110106615A1 (en) * 2009-11-03 2011-05-05 Yahoo! Inc. Multimode online advertisements and online advertisement exchanges

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
An Execution Platform for Event Driven Mashups, December 16, 2009 *
As SARJAKOSKI, L.T. and A.M. NIVALA, 2005. Adaptation to Context A Way to Improve the Usability of Mobile Maps. A book chapter in Meng, L., Zipf, A. and T. Reichenbacher, (eds.), Map Based Mobile Services, Theories, Methods and Implementations, Springer, NY, pp. 107123. *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140073321A1 (en) * 2012-09-11 2014-03-13 Nokia Corporation Method and apparatus for caching local mashup service parameters
US9602623B2 (en) * 2012-09-11 2017-03-21 Nokia Corporation Method and apparatus for caching local mashup service parameters
US20140089901A1 (en) * 2012-09-24 2014-03-27 Ca, Inc. Embedding performance monitoring into mashup application development
US8972951B2 (en) * 2012-09-24 2015-03-03 Ca, Inc. Embedding performance monitoring into mashup application development

Also Published As

Publication number Publication date
US20110161833A1 (en) 2011-06-30
US8458600B2 (en) 2013-06-04

Similar Documents

Publication Publication Date Title
US8700540B1 (en) Social event recommendations
US20090254843A1 (en) Shared virtual area communication environment based apparatus and methods
US20060089792A1 (en) System and method for displaying location-specific images on a mobile device
US7512653B2 (en) System and method for dynamically grouping messaging buddies in an electronic network
US20100057743A1 (en) Web-based services for querying and matching likes and dislikes of individuals
US7606580B2 (en) Personalized location information for mobile devices
US20090100165A1 (en) Dynamically integrating disparate computer-aided dispatch systems
US20130238370A1 (en) Event planning and management system
US8601027B2 (en) Query-based user groups in social networks
US20130232194A1 (en) Event application
US20060190285A1 (en) Method and apparatus for storage and distribution of real estate related data
US20130217416A1 (en) Client check-in
US20090171979A1 (en) System and method for a web-based address book
US20080172372A1 (en) Expandable Homepage Modules
US20110196933A1 (en) Active e-mails
US20070136360A1 (en) Database for Use with a Wireless Information Device
US20070288164A1 (en) Interactive map application
US20070168446A1 (en) Dynamically mapping chat session invitation history
US8200247B1 (en) Confirming a venue of user location
US8370062B1 (en) Switching between location contexts
US8423392B2 (en) Trusted participants of social network providing answers to questions through on-line conversations
US20110167125A1 (en) Interpersonal Spacetime Interaction System
US20120209839A1 (en) Providing applications with personalized and contextually relevant content
US20120124176A1 (en) Automatic check-ins and status updates
US20100050237A1 (en) Generating user and avatar specific content in a virtual world

Legal Events

Date Code Title Description
AS Assignment

Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DHEAP, VIJAY;GLADD, CHRISTOPHER MICHAEL;LINDSAY, AARON CHARLES;AND OTHERS;SIGNING DATES FROM 20130424 TO 20130427;REEL/FRAME:030358/0078