Patent Grant
9934519
The invention generally relates to a system and method for computer systems and, more particularly, the invention relates to a system and method of implementing charging models for subscriber driven media agnostic content delivery across same or different networks.
In recent years, the digital media marketplace has been ever expanding. For example, more and more content is migrating from traditional mechanisms to be digitally generated, electronically distributed and rendered in a variety of mechanisms. With this known, there are many trends in the market place today.
For example, while most Tier 1 content is generated by content creators such as movie studios and record labels, more and more content is generated by individuals. For this reason, better tooling and content creation environments are increasingly becoming commoditized, putting these creation capabilities in the hands of individuals. But, while Tier 1 content creators have worked hard to spend significant money on infrastructure to traditionally and digitally distribute the content, the Internet is, itself, now permitting individuals to play a more significant role in the distribution of content. In fact, peer to peer content sharing mechanisms have become commonplace, becoming the single biggest consumer of Internet bandwidth globally.
While the Tier 1 content creators, aggregators, and distributors and device manufacturers all want to restrict where and how the content is rendered (so that they can then work towards maximizing their portion of the revenue), individuals want control over where and how they view the content of their choice. For this reason, individuals are creating their own content and using peer to peer content sharing mechanisms to distribute such content. However, the sharing of content becomes very difficult, if not impossible, with competing and incompatible communication protocols, media formats, different standards for media conversion and content delivery mechanisms.
Accordingly, there exists a need in the art to overcome the deficiencies and limitations described hereinabove.
In a first aspect of the invention, a method comprises receiving content of a first media type over a network from a sending client. The method further includes sending the content or a reference to the content to a receiving client in a preferred media type and to a preferred device in accordance with at least one preference of the receiving client. The method further includes generating a billing record based on the content and user preferences of a sending client and/or a receiving client.
In another aspect of the invention, a method is provided for charging a subscriber for sending subscriber driven media agnostic content delivery across different networks. The method comprises providing a computer infrastructure operable to generate a billing report based on at least one of a type of content to be delivered and one or more charging preferences of a sending client and/or receiving client.
In yet another aspect of the invention, a computer program product is provided for charging subscriber driven media agnostic content delivery across networks. The computer program product comprises: a computer readable media; first program instructions to send the content or a reference to the content to a receiving client in a preferred media type and to a preferred device in accordance with at least one preference of the receiving client; and second program instructions to generate a billing report based on at least one of a type of content to be delivered to the receiving client and one or more charging preferences of a sending client and/or the receiving client. The first and second program instructions are stored on the computer readable media.
The present invention is described in the detailed description which follows, in reference to the noted plurality of drawings by way of non-limiting examples of exemplary embodiments of the present invention.
The invention generally relates to a system and method for computer systems and, more particularly, the invention relates to a system and method of implementing charging models for subscriber driven media agnostic content delivery across same or different networks. The system and method of the invention provide a unique mechanism and infrastructure focused on peer to peer distribution and delivery of content. For example, the system and method of the present invention are structured and configured to use existing telecommunications networks, i.e., primarily non-IMS (IP Multimedia Subsystem) based networks, as well as IMS based core networks, to deliver content of different types to different compatible and incompatible devices, and to provide charging models for such services. As should be known to those of skill in the art, IMS is an architectural framework for delivering internet protocol (IP) multimedia to mobile users.) As such, the system and method of the present invention can be supported on a completely wireless broadband based architecture where the focus has shifted from an access based provider to one that is primarily content driven over “fat pipes.”
Accordingly, in implementation, service providers can support end to end points implementing the system and method of the present invention, even through an extended migratory period from non-IMS enabled networks to IBM enabled networks. The service providers can also support end to end points, regardless of the devices and media type. Also, the system and method of the invention provides a flexible means of media management, while also providing different charging schemes for the services rendered in accordance with the invention.
In embodiments, the service provider can be a Solution Integrator, content provider, telecommunications company, or other third party offering to perform the processes described herein. In this case, the service provider can create, maintain, deploy, support, etc., the computer infrastructure 12 that performs the process steps of the invention for one or more customers, e.g., a sending client 40 and/or a receiving client 60. In return, the service provider can receive payment from the customer(s) under a subscription and/or fee agreement.
The sending client 40, service provider 50 and/or receiving client 60 can provide preferences to the Agent 30, via a Messaging Gateway Framework 65. The Messaging Gateway Framework 65 may also be provided to send notifications and messages (including content of different types using different protocols) to the sending client 40 and the receiving client 60, using a host of protocols (as discussed herein) and regardless of the device of the sending or receiving client. The preferences can be stored in a storage system (e.g., highly scalable database) 22B. The storage system can be, for example, a Home Subscriber Service (HSS) Profile Manager, in the case of IMS content.
By defining the preferences, the present invention provides a flexible means of media management, which media can be manipulated. That is, by defining the preferences the Agent 30 can efficiently enable the distribution of content, from a subscriber to another subscriber or set of subscribers, using a set of subscriber defined preferences, for both IMS and non IMS domains. The subscribers can be, for example, the sending client 40, service provider 50 and/or receiving client 60. The preferences can include, for example:
As one preference is a desired media type, the present invention contemplates whether transcoding of the content is necessary in order for the receiving client 60 to view the content, amongst other features. In the case of transcoding, the Agent 30 can allow content and metadata transformation as part of the workflow processing to satisfy all requests. A determination as to the type of content and whether the content needs to be transformed can be made by the Agent 30, for example, by parsing header information of the content. Also, in implementation, the present invention factors in location based delivery via integration to a network housed location platform 75, using protocols such as Open LS or Parlay X.
In further implementations, the Agent 30 supports a variety of notification and delivery channels. For example, it is contemplated that the Agent 30 can support XMPP (Extensible Messaging and Presence Protocol), MMSC (Multimedia Messaging Switching Center), WAP (Wireless Application Protocol), SMS (Short Message Service) and SMTP (Simple Mail Transfer Protocol) (including out of band notifications), IMS Handsets via a SIP (Session Initiation Protocol) client, Web Services (SOAP and REST) and STB. The Web Services allow application and automated process integration where required. In the case of an IMS network, the Agent 30 can incorporate SIP based session control (or provide instructions for such session control) while ensuring that the actual digital media is referenced as an external object that can then be referenced in the media stream via a media server. In this way, the system can support a plethora of handsets (e.g., 2G, 3G and possibly 4G handsets), each of which have different rendering capabilities, browser based applications, portable media players, gaming consoles, non standard devices such as Set Top Boxes and applications which are endpoints by means of using REST or SOAP style invocations and providing end point implementations. The Agent 30 can also provide for or set-up necessary edge based caching so as to optimize delivery of the content, and provide for integration into both an IMS and non-IMS accounting and charging platforms.
In addition, a charging platform 85 is provided in order to provide charging models to charge for services rendered. The charging platform 85 may be maintained, deployed, created and/or serviced by the service provider 50. The charging platform 85 is designed to generate a charging record for services rendered to a subscriber, e.g., the receiving client and/or the sending client (originator) will be charged for the services rendered (sending or receiving of content) based on the charging model implemented by the system and method of the invention. In embodiments, the service provider 50 and/or Agent 30 can calculate an amount to be charged, based on many different considerations and generate the charging record to be sent to the charging platform 85. In turn, the charging platform can generate an invoice and/or deduct a usage charge from an account of the subscriber.
The charging model(s) may be applicable to either or both of the sending client 40 and the receiving client 60. Also, as discussed in more detail herein, the sending client 40 and/or the receiving client 60 may select one or more of the charging models during set-up (see,
The charging model will be used by the Agent 30 and/or service provider 50 to create and maintain a charging record of the services provided in accordance with the invention. More specifically, in embodiments, the system and method of the invention will use the charging preferences in order to validate the charging methodology. Any created charging record can then be provided to the sending client 40 and/or receiving client 60, for submission of payment.
Many different considerations may be taken into account to determine how much is charged for the services rendered in accordance with the present invention. In one example, a different charging model may be devised for different scenarios in a peer to peer media distribution system in accordance with the invention. By way of illustration, a different charging model may be used to support multiple subscriber endpoints such as, for example, a plethora of Handsets each of which have different rendering capabilities (e.g., 2G, 3G and possibly 4G handsets), browser based applications, portable media players, gaming consoles, non-standard devices such as Set Top Boxes and applications which are endpoints by means of using REST or SOAP style invocations and providing end point implementations. Also, a premium charge may be applied based on a particular subscriber endpoint. So, for example, a premium charge may be provided for a non-compatible device with the network, e.g., a non-IMS compatible device.
Additionally, a charging model may be based on different complexities required during the transcoding and delivery of media. For example, a MPEG2 to MPEG4 conversion may require a different amount of processing cycles than a HD-DVD to MPEG2 conversion and, as such, may be billed at a higher rate (premium rate). Also, time sensitivity could make content more valuable depending on when it is shared and used (viewed) temporally. So, for example, a piece of content (e.g., a boxing match) may have greater value if immediately shared, and less when it is shared a day after the event, less a week later and so on. Accordingly, more time sensitive content may be billed at a higher rate (premium rate) than less time sensitive content which is not immediately sent to the receiving client (even though it is time sensitive material).
Charging models may be based on a number of other variables, including, for example, the number of times a shared piece of content is viewed. In this example, the charging model may be based on each time content is viewed or sent to different recipients.
Other variables that can affect the charging model include, for example, a specific window of time within which a piece of content may be used, the location that the content is sent from or to, the number of destination devices (for example, it is possible to send the same piece of content to multiple destinations for the same time from two perspectives), the number of subscribers with a single device or a single subscriber with multiple devices and any combination of the above. In these examples, the charging model may include an increase in cost (premium charge) for sending content to multiple destinations (multiple receiving clients or multiple devices from a single receiving client or a combination thereof) or receiving content at multiple destinations or a certain location.
It is further contemplated that other considerations may be taken into account for charging of the services rendered in accordance with the invention. For example, the subscriber may be a prepaid consumer (in which case the service provider (or charging platform) can deduct a charge from a balance in order to support media distribution transactions which the subscriber has initiated). As a prepaid consumer, the consumer may be provided with a discount for services rendered. A premium charge may be applied to subscribers that are post paid customers (billed after the transaction) or subscribers that are ad hoc customers (pay as they go).
It is also contemplated by the present invention that charges may not apply to subscribers that do not view the content. So, for example, there would be no charge for content sent to Subscriber “A”, which is not viewed (because subscriber “A” deleted the content, was not available to receive the content, etc.).
It is further contemplated by the present invention that content can be provided on a “no charge” or reduced fee basis if the recipient is willing to view an advertisement prior to the content. In embodiments, it is contemplated that the recipient will receive a reduced fee or no charge once the recipient has actually viewed the advertisement, which can before or after viewing the content. In this scenario, the Agent 30 can monitor whether the recipient has viewed the advertisement by the use of known monitoring technologies (e.g., an agent residing on the device of the receiving client) in order to provide the discount.
In one implementation, at any time, any of the subscribers can opt out of such premium (or other) based services. For example, by opting out, the receiving client would not receive any content that would be charged at a premium rate.
In any of the above charging models, for example, the service provider 50 and/or Agent 30 can provide notification to the subscriber that a charge (including a premium charge) may be applied for certain types of services. For example, the service provider 50 and/or Agent 30 would provide notification to the subscriber that a premium charge may be applied for time sensitive material or extensive use of processing cycles (computer resources), a route that the content must take in order to be viewed by the receiving client, an amount of data (e.g., content) that is either sent by the sending client or viewed by the receiving client, etc.
The computing device 14 includes a processor 20, a memory 22A, an input/output (I/O) interface 24, and a bus 26. The memory 22A can include local memory employed during actual execution of program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution. Further, the computing device 14 is in communication with an external I/O device/resource 28 and the storage system 22B. As should be understood, in certain implementation such as non-IMS enabled networks, the storage system 22B may be internal to the Agent 30.
The I/O device 28 can comprise any device that enables an individual to interact with the computing device 14 or any device that enables the computing device 14 to communicate with one or more other computing devices using any type of communications link. For example, the external I/O device/resource 28 may be keyboards, displays, pointing devices, etc.
In general, the processor 20 executes the program code, which is stored in memory 22A and/or the storage system 22B and/or the Agent 30. While executing the program code, the processor 20 can read and/or write data to/from the memory 22A, storage system 22B, I/O interface 24, and/or Agent 30. The bus 26 provides a communications link between each of the components in the computing device 14.
The computing device 14 can comprise any general purpose computing article of manufacture capable of executing computer program code installed thereon (e.g., a personal computer, server, handheld device, etc.). However, it is understood that the computing device 14 is only representative of various possible equivalent computing devices that may perform the processes described herein. To this extent, in embodiments, the functionality provided by the computing device 14 can be implemented by a computing article of manufacture that includes any combination of general and/or specific purpose hardware and/or computer program code. In each embodiment, the program code and hardware can be created using standard programming and engineering techniques, respectively.
Similarly, the computer infrastructure 12 is only illustrative of various types of computer infrastructures for implementing the invention. For example, in embodiments, the computer infrastructure 12 comprises two or more computing devices (e.g., a server cluster) that communicate over any type of communications link, such as a network, a shared memory, or the like, to perform the process described herein. Further, while performing the processes described herein, one or more computing devices in the computer infrastructure 12 can communicate with one or more other computing devices external to the computer infrastructure 12 using any type of communications link (e.g., location platform, gateway, etc.). The communications link can comprise any combination of wired and/or wireless links; any combination of one or more types of networks (e.g., the Internet, a wide area network, a local area network, a virtual private network, etc.); and/or utilize any combination of transmission techniques and protocols.
Generally, the invention includes a set-up flow and a content distribution processing flow. By way of example,
Although
The invention can take the form of an entirely hardware embodiment or an embodiment containing both hardware and software elements (any of which is referred generally as “file management program”). The hardware and software elements include a computer infrastructure configured to implement the functionality of the present invention, as shown in
Referring to
In the implementation of
At step S260, the Subscriber Endpoint Client logs in and configures delivery and receipt of the preferences via the Subscriber Preference Manager. For example, in step S260, the Subscriber Endpoint Client can provide its preferences to the Subscriber Preference Manager via an HTTP. In embodiments, these preferences can include the preferred charging methodologies (which can later be validated). The Subscriber Preference Manager, in turn, updates the HSS/Profile Manager and, if necessary, the Agent (depending on the network (IMS vs. non-IMS enabled networks), at step S270. At step S280, if necessary, the HSS/Profile Manager sends notifications (via the Diameter protocol) to the Agent, so as to remain synchronized. Although a certain order is shown, the processes of the present invention may be provided in a different order, e.g., step S280 may be performed directly after or at any time after step S250.
It is to be noted that during call flow, HSS lookups do not have to be performed to aid in the overall performance of the system. Also, any information received via the Diameter protocol as part of the provisioning process (e.g., set-up process) can be cached within the Agent platform (e.g., storage system 22B). Moreover, it is contemplated by the present invention that the set-up information can be periodically updated and, as such, provisions are provided to update the database so to add new devices and/or other preferences, when requested by the Subscriber Endpoint Client (sending client or receiving client), to the solution mix.
At step S305, if necessary, the Agent can perform value added processing such as, for example, transcoding, as well as make a determination of the actual delivery channels. It is also contemplated that the transcoding, to save overhead, can be performed by the sending client or other participant, if resources (e.g., hardware and software) are available on the particular devices.
At step S310, the content can be delivered to an edge content location for future retrieval by the preferred device of the receiving client (e.g., STB). The content can be delivered directly from the sending client or, in other embodiments, via the Agent.
At step S315, if necessary, the Agent contacts the location platform to determine the location of the receiving client. (In embodiments, the location platform may be part of the Agent.) This can be done in any conventional manner such as, for example, via a GPS transceiver or other known messaging. At step S320, the location platform determines the location of the receiving client and provides this location information to the Agent. As such, the location, geographic separation and preferences of both the receiver and the sender may be used as factors implementing one or more rules within the system and method of the invention. The communication with the location platform may be performed via an Open LS Request and Response, for example. It should be recognized, though, that other communication protocols are also contemplated by the invention, as discussed herein.
At step S325, the Agent notifies the preferred device of the receiving client that content is ready for delivery. In embodiments, depending on the content and delivery preferences, the notification can be provided to a STB (Set Top Box) or other user-defined device. For example, after determining that the receiving client is at or near his/her residence and based on the preferences of the receiving client, the Agent can send a notification of content to the STB in the receiving client's residence. The notification can be a reference to the content which resides, for example, on the edge network distribution (e.g., a server at the edge of the network, geographically nearer to the target client). The content can be retrieved by the STB or other preferred device, for example, from the server on the network, via the reference.
At step S330, a notification can be provided to the cellular telephone or other device of the receiving client, again depending on the preferences. This notification will notify the receiving client that content is ready to be downloaded on a preferred device. In the case of a cellular telephone, for example, the notification can be sent to the Messaging Gateway Framework (65) via a short message peer-to-peer protocol (SMPP) notification and then to the target client via an SMS notification. Similarly, at step S335, a notification can also be provided to the cellular telephone or other device of the sending client, again depending on the preferences. Again, in the case of a cellular telephone, for example, the notification can be sent to the Messaging Gateway Framework via a SMPP notification and then to the sending client via an SMS notification. This notification can indicate, amongst other notices, that the receiving client has received a notification of the content and/or has downloaded the content.
At step S340, the preferred device of the receiving client (in this example the STB), requests the content from the server. In this example, the STB (or other preferred device) asynchronously requests the content and downloads it locally. At step S345, the content is sent to the preferred device. In embodiments, as discussed above, the Agent can send a notification to the sending client that the content has been delivered to the receiving client. At step S350, the receiving client can view the content on the preferred device.
At step S355, the Agent generates a charging record that is sent to the charging platform. In embodiments, prior to the generation of a charging record, the Agent will make a determination of the charging methodology selected by either or both of the receiving client and/or the sending client. This can be performed by using the preferences selected by the receiving client and/or the sending client. Also, a determination may be made by the Agent to determine the type and amount of content sent from the sending client to the receiving client, in order to generate the billing record. For example, the client may be charged a premium for: (i) the use of a certain handset with certain capabilities, (ii) computer resources (e.g., converting MPEG2 to MPEG4), (iii) the number of times a shared piece of content is viewed, (iv) the time window within which a piece of content needs to be used, (v) the location that the content is sent from or to, (vi) the number of destination devices, (vii) the number of subscribers, with a single device or a single subscriber with multiple devices and any combination of the above, (viii) a route required to send the content to a receiving client, etc. At step S360, the charging record is sent to either or both the sending client and the receiving client, as appropriate. The clients may receive a notification of a billing event prior to the sending of the charging record.
Also, it should be recognized that to simplify the call flow for illustrative purposes, the interaction from the Agent and the SIP aware MMSC (Multimedia Messaging Switching Center) is not depicted as flowing through an S-CSCF node(s). Also, as discussed above, as the media objects can be large, indirect notification via a reference is assumed, which is a specification supported case. Also,
Referring now specifically to
At step S410, the Agent opens communication with the location platform, if necessary, to determine the location of the receiving client. At step S415, the location platform determines the location of the receiving client and provides this location information to the Agent. As noted above, the location, geographic separation and preferences of both the receiver and the sender may be used as factors implementing one or more rules within the system and method of the invention. The communication with the location platform may be performed via an Open LS Request and Response, for example. It should be recognized, though, that other communication protocols are also contemplated by the invention, as discussed herein.
At step S420, after the Agent determines that there is an SIP end point, the content is transcoded and sent to the edge caching tier for temporary transient storage. At step S425, the Agent sends a SIP message request (notification of content) to the IMS Compliant MMSC, which then contacts and notifies the SIP U/A, on the receiving client, that content is available for viewing. The IMS Compliant MMSC may be a Media Gateway Framework (MGF), which includes the set of delivery channels identified in
At step S430, the receiving client sends a SIP message response to the IMS compliant MMSC, which makes it back to the Agent (via the MMSC). At step S435, the receiving client (SIP U/A) requests the message contents by sending an indirect message request to the MMSC. At step S440, the MMSC responds with a Message Response SIP message with the indirect reference to the content's logical location in the edge distribution network.
At step S445, the receiving client (SIP U/A) requests the content via an MM1_Retrieve.REQ request. It should be understood by those of skill in the art that the request could have also been sent directly to the MMSC. At step S450, the receiving client receives an MM1_Retrieve.RES in response to the request. At step S455, the SIP U/A generates a delivery acknowledgement via the MM1_Acknowledgement REQ SIP message sent to the MMSC. At step S460, the MMSC notifies the Agent with the same MM1_Acknowledgment REQ message. At step S465, the Agent generates an SMPP message to be delivered to the originating (sending client) handset via the Messaging Gateway Framework, which will generate an OTA SMS message. This SMS message will confirm delivery receipt of the content to the receiving client.
At step S470, the Agent generates a charging record that is sent to the charging platform. In embodiments, prior to the generation of a charging record, the Agent will make a determination of the charging methodology selected by either or both of the receiving client and/or the sending client. This can be performed by using the preferences selected by the receiving client and/or the sending client. Also, a determination may be made by the Agent to determine the type and amount of content sent from the sending client to the receiving client, in order to generate the billing record. For example, the client may be charged a premium for: (i) the use of a certain handset with certain capabilities, (ii) computer resources (e.g., converting MPEG2 to MPEG4), (iii) the number of times a shared piece of content is viewed, (iv) the time window within which a piece of content needs to be used, (v) the location that the content is sent from or to, (vi) the number of destination devices, (vii) the number of subscribers, with a single device or a single subscriber with multiple devices and any combination of the above, (viii) a route required to send the content to a receiving client, etc. At step S475, the charging record is sent to either or both the sending client and the receiving client, as is appropriate. The clients may receive a notification of a billing event prior to the sending of the charging record.
The Access Tier primarily depicts the transport network which may include the Internet, Wireless Network or edge Cache, amongst other channels of delivery. These channels of delivery will deliver the content and any required notifications via the respective protocols. As discussed above, the content and notifications can be delivered on different channels, depending on the preferences and type of content.
The Services Tier primary contains the Messaging Gateway Framework 65 and the Agent 30 with all the protocol support required to connect to the underlying telecommunications infrastructure platform as well as to the Messaging Gateway Framework via the various protocols that are required for delivery of the content. For example, the Messaging Gateway Framework supports: XMPP (Extensible Messaging and Presence Protocol) Gateway, SMSC (SMPP), MMSC (MM7), WAP Gateway, Web Services Gateway (W/S), and/or SIP Gateway. All of these protocols can be supported by the system and method of the invention, unlike in known technologies.
The Agent is shown as a Media Distribution Platform. The Platform includes a transcoder, as well as a rules engine, mediation, routing and protocol conversion engine. In embodiments, as the sender of content may have no visibility into the receiver's rendering capabilities, the rules engine will be used to parse the preferences of the sender and the receiver in order to coordinate the delivery of the content by the Agent. The mediation can be an Enterprise Service Bus which is configured to apply the rules (preferences). The protocol conversion engine is a core function which converts the content from one protocol to another protocol, again depending on the content and preferences. For example, the protocol conversion engine can convert data transmission from asynchronous to synchronous, TCP/IP to another protocol, etc.
The Control Tier primarily comprises elements of the IMS control (e.g., S-CSCF, a charging platform and an HSS). The Control Tier also includes elements of the non IMS tier networks. For example, a device profile component may be included in the Control Tier, which is a database (e.g., Storage System 22B) storing the preferences of the end points (sending client and receiving client). The Agent can communicate with the device profile via W/S. The Client Tier also includes the location platform which is in communication with the Agent via Open LS or Parlay X.
The present invention also implements a Media Baseline which allows the system and method to generate one baseline representation of media and send each user the corresponding media to their respective and desired device. For example, a baseline XML for Multiple Notifications can be written as follows:
With the subject as follows:
With the body as follows:
Additionally, a representative set of exemplary call flows are described below. These call flows describe some of the services and capabilities that are implemented using the system and method of the invention, based on user preferences.
View Content
A subscriber views some content on his/her browser and wants to notify his/her friends about the content. He/She requests the system to deliver the content to the friend. As a case in point, one of the subscribers has requested that the content be sent to a Set Top Box at home. When that subscriber gets home (location platform dip), and turns on the television, he/she is notified about the content and views the content, which has been downloaded to his Personal Storage Device at his residence. The agent and/or charging platform generates the billing record, depending on the typed of delivered content, amount of content, user preferences, etc. as discussed herein.
Create Content
A subscriber creates content on his/her device and wants to notify his/her friends about the content. He/She requests the system to deliver the content to the friend. As a case in point, one of the subscribers has requested that his content be sent to his Set Top Box at home. When that subscriber gets home (location platform dip), and turns on his TV, he/she is notified about the content and views the content, which has been downloaded to his Personal Storage Device at his residence. The agent and/or charging platform generates the billing record, depending on the typed of delivered content, amount of content, user preferences, etc. as discussed herein.
Notification Scenarios
A subscriber gets an SMS notification about some content sent to his/her media player on his home personal computer. He/She logs into his/her personal computer at home and views the content.
A subscriber gets an SMS notification about some content sent to his/her media player on his home Entertainment System or personal computer. He/She may retrieve a proxy or synopsis of that content on the mobile device.
A subscriber gets a WAP based notification sent to his device, transcoded to the format that his/her device can support and views the content immediately.
While the invention has been described in terms of embodiments, those skilled in the art will recognize that the invention can be practiced with modifications and in the spirit and scope of the appended claims.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5621727 | Vaudreuil | Apr 1997 | A |
| 6157945 | Balma et al. | Dec 2000 | A |
| 6725303 | Hoguta et al. | Apr 2004 | B1 |
| 6751673 | Shaw | Jun 2004 | B2 |
| 6854007 | Hammond | Feb 2005 | B1 |
| 6965917 | Aloni et al. | Nov 2005 | B1 |
| 6996393 | Pyhälammi et al. | Feb 2006 | B2 |
| 6999566 | Eason et al. | Feb 2006 | B1 |
| 7030730 | Zondervan | Apr 2006 | B1 |
| 7035653 | Simon et al. | Apr 2006 | B2 |
| 7653001 | Agrawal et al. | Jan 2010 | B2 |
| 7668765 | Tanaka | Feb 2010 | B2 |
| 20020123934 | Tanaka et al. | Sep 2002 | A1 |
| 20020129371 | Emura et al. | Sep 2002 | A1 |
| 20020143972 | Christopoulos et al. | Oct 2002 | A1 |
| 20020147778 | Dutta | Oct 2002 | A1 |
| 20030037110 | Yamamoto | Feb 2003 | A1 |
| 20040193648 | Lai et al. | Sep 2004 | A1 |
| 20050009541 | Ye | Jan 2005 | A1 |
| 20050114784 | Spring et al. | May 2005 | A1 |
| 20050136895 | Thenthiruperai et al. | Jun 2005 | A1 |
| 20050210498 | Scott, III | Sep 2005 | A1 |
| 20050283533 | Schluter | Dec 2005 | A1 |
| 20060015649 | Zutaut et al. | Jan 2006 | A1 |
| 20060031369 | Caron | Feb 2006 | A1 |
| 20060184431 | Rosenberg | Aug 2006 | A1 |
| 20060272028 | Maes | Nov 2006 | A1 |
| 20070055783 | Gourraud | Mar 2007 | A1 |
| 20070067424 | Raciborski et al. | Mar 2007 | A1 |
| 20070143775 | Savoor et al. | Jun 2007 | A1 |
| 20070162228 | Mitchell | Jul 2007 | A1 |
| 20080082649 | Gazier et al. | Apr 2008 | A1 |
| 20080101455 | Scheelke | May 2008 | A1 |
| 20080207182 | Maharajh | Aug 2008 | A1 |
| 20080292074 | Boni et al. | Nov 2008 | A1 |
| Entry |
|---|
| Lemlouma, Tayeb et al. “Adapted Content Delivery for Different Contexts”, IEEE Computer Society, Proceedings of the 2003 Symposium on Applications and the Internet. |
| Wan, Andrew et al., “Profile Based Routing and Billing Multimedia Content Delivery Network”, IEEE Computer Society, Proceedings of the International Conference on Networking, International Conference on Systems and International Conference on Mobile Communications and Learning Technologies, 2006. |
| “MMS MM1 Stage 3, Using SIP”, 3rd Generation Partnership Project 2 “3GPP2”. |
| Pospischil, Günther et al., “A Location-based Push Architecture using SIP”. |
| Camarillo, C. et al, “RFC 4117—Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc)”, URL: http://www.packetizer.com/rfc/rfc4117, Jun. 2005. |
| Non-Final Office Action dated Jun. 15, 2010, for related U.S. Appl. No. 11/969,550. |
| Badii, et al., “Profiling Management . . . ”, Proceedings of the Second International Conference on Automated Production of Cross Media Conent . . . , 2006, 8 pages. |
| Notice of Allowance dated Mar. 26, 2012 in U.S. Appl. No. 11/969,550. |
| Office Action dated Oct. 6, 2011 in U.S. Appl. No. 11/969,550. |
| Office Action dated Nov. 17, 2015, in related U.S. Appl. No. 13/480,686, 20 pp. |
| Notice of Allowance in related U.S. Appl. No. 13/480,686 dated Apr. 12, 2017, 18 pages. |
| Final Office Action in related U.S. Appl. No. 13/480,686 dated Apr. 28, 2016, 25 pages. |
| Office Action in related U.S. Appl. No. 13/480,686 dated Dec. 27, 2016, 20 pages. |
| Final Office Action dated Nov. 29, 2010 for related U.S. Appl. No. 11/969,550. |
| 3rd Generation Partnership Project 2 “3GPP2”, “MMS MM1 Stage 3, Using SIP”, Jun. 2004, 42 pages. |
| Pospischil, Gunther et al., “A Location-based Push Architecture using SIP”, 2001, 7 pages. |
| Number | Date | Country | |
|---|---|---|---|
| 20090177536 A1 | Jul 2009 | US |
