IP Library Granted Patent US 8,407,354
Granted Patent B2
US 8,407,354 · App. 12/727,743 · Granted Mar 26, 2013

System and method for determining trust for SIP messages

Inventors: Jan Hendrik Lucas Bakker (Keller, TX); Adrian Buckley (Tracy, CA); Andrew Allen (Mundelein, IL)
Assignee: Research In Motion Limited
View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 8,407,354
App. No.
12/727,743
Granted
Mar 26, 2013
Kind
B2
Abstract

A method for performing registration is provided. The method includes receiving a server timeout message, the server timeout message including at least a field set to a value equal to a value received during a first registration. The method further includes initiating restoration procedures by performing a second registration in response to receiving the server timeout message.

Claims (90)

1. A method for determining if a message received from a node in an IP (Internet Protocol) Multimedia Subsystem (IMS) network can cause one or more actions to be performed, comprising:

a user agent (UA) receiving from the node a message containing a trust indicator;

the UA determining whether the trust indicator matches trust information stored in the UA;

when the trust indicator matches trust information stored in the UA, the UA performing all actions typically associated with receipt of the message; and

when the trust indicator does not match trust information stored in the UA, the UA refraining from performing at least one action typically associated with receipt of the message.

2. The method of claim 1 , wherein the trust indicator is a Uniform Resource Identifier (URI) of the node that sent the message.

3. The method of claim 2 , wherein the trust information is a plurality of URIs of trusted nodes that are provided to and stored in the UA.

4. The method of claim 3 , wherein the plurality of URIs are associated with the trusted nodes by a URI parameter in a Session Initiation Protocol (SIP) message.

5. The method of claim 3 , wherein the UA associates the plurality of URIs with the trusted nodes by querying a data repository containing a plurality of URIs of trusted nodes.

6. The method of claim 1 , wherein the trust indicator is conveyed to the UA in one of:

a SIP Config Framework;

a SIP Policy Framework;

an EAP based policy retrieval mechanism;

an XCAP/HTTP based server; and

an Open Mobile Alliance (OMA) device management (DM) object.

7. The method of claim 1 , wherein the trust indicator is conveyed to the UA as a value representative of the sender of the message, and wherein the UA knows the value could be provided only by a trusted sender.

8. The method of claim 1 , wherein the trust information is provided to the UA in a message sent to the UA in response to a registration request made by the UA.

9. The method of claim 1 , wherein the location of the trust information is provided to the UA in a message sent to the UA in response to a registration request made by the UA, and wherein the UA retrieves the trust information from the location.

10. The method of claim 1 , wherein the location of the trust information is provided to the UA in a message sent to the UA in response to a subscription request made by the UA, and wherein the UA retrieves the trust information from the location.

11. The method of claim 1 , wherein the trust information is provided to the UA as information related to a route over which a registration request made by the UA was routed.

12. The method of claim 11 , wherein the information related to the route is included in at least one field in at least one of:

a SIP Path header;

a SIP Service-Route header; and

a new SIP header defined for including the information.

13. The method of claim 1 , wherein refraining from performing at least one action typically associated with receipt of the message includes at least one of:

denying the message;

discarding the message;

terminating the message;

returning an error message related to the message; and

not performing undesirable actions associated with the message and performing other associated with the message.

14. A user agent (UA), comprising:

a processor configured to receive, from a node outside a trust domain in an IP (Internet Protocol) Multimedia Subsystem (IMS) network, a message containing a trust indicator, further configured to determine whether the trust indicator matches trust information stored in the UA, when the trust indicator matches trust information stored in the UA, to perform all actions typically associated with receipt of the message, and further configured, when the trust indicator does not match trust information stored in the UA, to refrain from performing at least one action typically associated with receipt of the message.

15. The UA of claim 14 , wherein the trust indicator is a Uniform Resource Identifier (URI) of the node that sent the message.

16. The UA of claim 15 , wherein the trust information is a plurality of URIs of trusted nodes that are provided to and stored in the UA.

17. The UA of claim 16 , wherein the plurality of URIs are associated with the trusted nodes by a URI parameter in a Session Initiation Protocol (SIP) message.

18. The UA of claim 16 , wherein the UA associates the plurality of URIs with the trusted nodes by querying a data repository containing a plurality of URIs of trusted nodes.

19. The UA of claim 14 , wherein the trust indicator is conveyed to the UA in one of:

a SIP Config Framework;

a SIP Policy Framework;

an EAP based policy retrieval mechanism;

an XCAP/HTTP based server; and

an Open Mobile Alliance (OMA) device management (DM) object.

20. The UA of claim 14 , wherein the trust indicator is conveyed to the UA as a value representative of the sender of the message, and wherein the UA knows the value could be provided only by a trusted sender.

21. The UA of claim 14 , wherein the trust information is provided to the UA in a message sent to the UA in response to a registration request made by the UA.

22. The UA of claim 14 , wherein the location of the trust information is provided to the UA in a message sent to the UA in response to a registration request made by the UA, and wherein the UA retrieves the trust information from the location.

23. The UA of claim 14 , wherein the location of the trust information is provided to the UA in a message sent to the UA in response to a subscription request made by the UA, and wherein the UA retrieves the trust information from the location.

24. The UA of claim 14 , wherein the trust information is provided to the UA as information related to a route over which a registration request made by the UA was routed.

25. The UA of claim 24 , wherein the information related to the route is included in at least one field in at least one of:

a SIP Path header; and

a SIP Service-Route header; and

a new SIP header defined for including the information.

26. The UA of claim 14 , wherein refraining from performing at least one action typically associated with receipt of the message includes at least one of:

denying the message;

discarding the message;

terminating the message;

returning an error message related to the message; and

not performing undesirable actions associated with the message and performing other associated with the message.

27. A method for determining if a node outside a trust domain in an IP (Internet Protocol) Multimedia Subsystem (IMS) network can be trusted, comprising:

a user agent (UA) receiving a message from the node;

the UA determining whether a trust indicator is present in the message;

when the trust indicator is present in the message, the UA performing all actions typically associated with receipt of the message; and

when the trust indicator is not present in the message, the UA refraining from performing at least one action typically associated with receipt of the message.

28. The method of claim 27 , wherein the trust indicator is conveyed to the UA in one of:

a SIP Config Framework;

a SIP Policy Framework;

an EAP based policy retrieval mechanism;

an XCAP/HTTP based server; and

an Open Mobile Alliance (OMA) device management (DM) object.

29. The method of claim 27 , wherein the trust indicator is conveyed to the UA as a value representative of the sender of the message, and wherein the UA knows the value could be provided only by a trusted sender.

30. The method of claim 27 , wherein refraining from performing at least one action typically associated with receipt of the message includes at least one of:

denying the message;

discarding the message;

terminating the message;

returning an error message related to the message; and

not performing undesirable actions associated with the message and performing other associated with the message.

31. A user agent (UA), comprising:

a processor configured to receive a message from a node outside a trust domain in an IP (Internet Protocol) Multimedia Subsystem (IMS) network, further configured to determine whether a trust indicator is present in the message, further configured, when the trust indicator is present in the message, to perform all actions typically associated with receipt of the message, and further configured, when the trust indicator is not present in the message, to refrain from performing at least one action typically associated with receipt of the message.

32. The UA of claim 31 , wherein the trust indicator is conveyed to the UA in one of:

a SIP Config Framework;

a SIP Policy Framework;

an EAP based policy retrieval mechanism;

an XCAP/HTTP based server; and

an Open Mobile Alliance (OMA) device management (DM) object.

33. The UA of claim 31 , wherein the trust indicator is conveyed to the UA as a value representative of the sender of the message, and wherein the UA knows the value could be provided only by a trusted sender.

34. The UA of claim 31 , wherein refraining from performing at least one action typically associated with receipt of the message includes at least one of:

denying the message;

discarding the message;

terminating the message;

returning an error message related to the message; and

not performing undesirable actions associated with the message and performing other associated with the message.

Assignments (4)
CHANGE OF NAME Recorded Oct 2, 2013
From: RESEARCH IN MOTION LIMITED
To: BLACKBERRY LIMITED
Reel/Frame 031329/0587 →
CORRECTIVE ASSIGNMENT TO CORRECT THE ASSIGNOR AND ASSIGNEE WHICH ARE REVERSED. CORPORATION SHOULD HAVE BEEN ASSIGNOR AND LIMITED THE ASSIGNEE PREVIOUSLY RECORDED ON REEL 024275 FRAME 0584. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT. Recorded Nov 24, 2010
From: RESEARCH IN MOTION CORPORATION
To: RESEARCH IN MOTION LIMITED
Reel/Frame 025412/0951 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Oct 21, 2010
From: RESEARCH IN MOTION LIMITED
To: RESEARCH IN MOTION CORPORATION
Reel/Frame 025172/0904 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Apr 22, 2010
From: BAKKER, JAN HENDRIK LUCAS; BUCKLEY, ADRIAN; ALLEN, ANDREW
To: RESEARCH IN MOTION CORPORATION
Reel/Frame 024275/0584 →
Continuity (2)
Provisional Application 61168798 · Apr 13, 2009
Related Publication 20100262704A1 · Oct 14, 2010