DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application is being examined under the pre-AIA first to invent provisions.
Information Disclosure Statement
The information disclosure statement submitted on 12/21/2023 has been considered by the Examiner and made of record in the application file.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper time wise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Long, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Onium, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Torrington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based terminal Disclaimer may be filled out completely online using web-screens. An terminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about terminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-20 are rejected on the ground of nonstatutory anticipation double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 11,856,033 respectfully. Although the claims at issue are not identical, they are not patentably distinct from each other because, by comparing the claims, all the limitations of claims 1 and 10 of the current application are anticipated and included in claims 1 and 10 of U.S. Patent No. 11,856,033 respectfully with some obvious wording or terminology variations.
Therefore, the current claims 1 and 10 encompass the claimed invention of U.S. Patent No. 11,856,033 and differ only in terminology. To the extent that the instant independent claims are generic to the claimed invention of claims 1 and 10 of U.S. Patent No. 11,856,033. Claims 1 and 10 of the instant application are broader in each and every aspect than claims 1 and 10 of the US patent 11,856,033, and thus the claims are anticipated, in re Goodman 29 USPQ 2d 2010 CAFC 1993, states that a generic claim cannot be issued without a terminal disclaimer, if a species claim has been previously been claimed in a patent or co-pending application.
Claims 1 and 10 of the Instant Application
Claims 1 and 10 of US Patent 11,856,033
1. A method for indicating an application server (AS) capability, the method comprising:
generating, at the AS, a Session Initiation Protocol (SIP) request including a SIP header comprising a token that identifies at least one service supported by the AS that is included in the signaling route and the SIP request further including an address of the AS;
transmitting, by the AS, the SIP request; and
transmitting, by the AS, a SIP response including the token.
10. A network component comprising a processor configured to:
generate, at the network component, a Session Initiation Protocol (SIP) request including a SIP header comprising a token that identifies at least one service supported by the network component, the SIP request further including an address of the network component;
transmit by the network component, the SIP request; and
transmit, by the network component, a SIP response including the token.
1. A method for indicating an application server (AS) capability, the method comprising:
generating, at the AS, a Session Initiation Protocol (SIP) request including a SIP header comprising a token that identifies at least one service supported by the AS that is included in the signaling route and the SIP request further including a uniform resource identifier (URI) comprising an address of the AS;
transmitting, by the AS, the SIP request via the communication network towards a first user agent (UA); and
transmitting, by the AS, a SIP response via the communication network to a second user agent (UA), the SIP response including the token.
10. A network component comprising a processor configured to:
generate, at the network component, a Session Initiation Protocol (SIP) request including a SIP header comprising a token that identifies at least one service supported by the network component, the SIP request further including a uniform resource identifier (URI) comprising an address of the network component;
transmit by the network component, the SIP request via the communication network towards a first user agent (UA); and
transmit, by the network component, a SIP response via the communication network to a second user agent (UA) different than the first UA, the SIP response including the token.
Claim 1 of instant application includes all of the limitations of claim 1 of the parent Patent No. US 11,856,033 B2 except “…a uniform resource identifier (URI) comprising …”, “…via the communication network towards a first user agent (UA)…”, and “…via the communication network to a second user agent (UA), the SIP response…”, (emphasis added).
Nonetheless, the removal of said limitations from claim 1 of the instant application made the claim 1 of instant application a broader version of claim 1 of the parent Patent No. US 11,856,033 B2. Therefore, claim 1 is not patentably distinct from claim 1 of the parent Patent No. US 11,856,033 B2.
Claim 2 of the instant application, is rejected because the limitations of claim 2 is included in claim 2 of U.S. Patent No. 11,856,033.
Claim 3 of the instant application, is rejected because the limitations of claim 3 is included in claim 3 of U.S. Patent No. 11,856,033 respectfully.
Claim 4 of the instant application, is rejected because the limitations of claim 4 is included in claim 4 of U.S. Patent No. 11,856,033.
Claim 5 of the instant application, is rejected because the limitations of claim 5 is included in claim 5 of U.S. Patent No. 11,856,033 respectfully.
Claim 6 of the instant application, are rejected because the limitations of claim 6 is included in claim 6 of U.S. Patent No. 11,856,033.
Claim 7 of the instant application, is rejected because the limitations of claim 7 is included in claim 7 of U.S. Patent No. 11,856,033.
Claim 8 of the instant application, is rejected because the limitations of claim 8 is included in claim 8 of U.S. Patent No. 11,856,033.
Claim 9 of the instant application, is rejected because the limitations of claim 9 is included in claim 9 of U.S. Patent No. 11,856,033.
This is a nonstatutory anticipation double patenting rejection.
Independent claim 10 of the instant application includes all of the limitations of claim 10 of the parent Patent No. US 11,856,033 B2 except “…a uniform resource identifier (URI) comprising…”, “…via the communication network towards a first user agent (UA)…”, and “…via the communication network to a second user agent (UA) different than the first UA, the SIP response…”, (emphasis added).
Nonetheless, the removal of said limitations from claim 10 of the instant application made the claim 10 of instant application a broader version of claim 10 of the parent Patent No. US 11,856,033 B2. Therefore, claim 10 is not patentably distinct from claim 10 of the parent Patent No. US 11,856,033 B2.
Claim 11 of the instant application, is rejected because the limitations of claim 11 is included in claims 11 U.S. Patent No. 11,856,033.
Claim 12 of the instant application, is rejected because the limitations of claim 12 is included in claim 12 of U.S. Patent No. 11,856,033 respectfully.
Claim 13 of the instant application, is rejected because the limitations of claim 13 is included in claim 13 of U.S. Patent No. 11,856,033.
Claim 14 of the instant application, is rejected because the limitations of claim 14 is included in claim 14 of U.S. Patent No. 11,856,033 respectfully.
Claim 15 of the instant application, are rejected because the limitations of claim 15 is included in claim 15 of U.S. Patent No. 11,856,033.
Claim 16 of the instant application, is rejected because the limitations of claim 16 is included in claim 16 of U.S. Patent No. 11,856,033.
Claim 17 of the instant application, is rejected because the limitations of claim 17 is included in claim 17 of U.S. Patent No. 11,856,033.
Claim 18 of the instant application, is rejected because the limitations of claim 18 is included in claim 18 of U.S. Patent No. 11,856,033.
Claim 19 of the instant application, is rejected because the limitations of claim 19 is included in claim 20 of U.S. Patent No. 11,856,033.
Claim 20 of the instant application, is rejected because the limitations of claim 20 is included in claim 19 of U.S. Patent No. 11,856,033.
This is a nonstatutory anticipation double patenting rejection.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 7, 10 and 16 are rejected under 35 U.S.C. 103(a) as being unpatentable over Postmus (US 2006/0047840 Al, hereinafter Postmus), in view of Partanen et al. (US 6,888,828 B1 Al, hereinafter Partanen).
Regarding claim 1, Postmus disclose, a method for indicating an application server (AS) capability (see e.g., “a method and system for exchanging end-point capabilities information using the Session Initiation Protocol (SIP)”, [0002]), the method comprising:
generating, at the AS (see e.g., Fig. 2, Application Server 200) a Session Initiation Protocol (SIP) request including a SIP header comprising a token that identifies at least one service supported by the AS that is included in the signaling route (see e.g., “the functionality of a Session Initiation Protocol (SIP) engine included in a SIP application server, also called herein a SIP container, is extended with service logic that automatically interprets SIP end-point capabilities, such as for example the SIP option tags and feature tags, and in turn automatically adds the correct end-point capabilities information in the appropriate SIP message headers of the requests/responses send out from the server”, [0040] and/or “the SIP request comprises a Uniform Resource Identifier (URI) 222 that identifies the receiving end-point of the request 220”, [0051]) and the SIP request further including an address of the AS;
transmitting, by the AS, the SIP request (see e.g., “When the SIP service sends a request…the SIP container adds the correct headers and values to the request/response. For the inclusion of option tags in a SIP message, the SIP container can add or change any of the following headers if required…supported…unsupported”, [0043]-[0045]); and
transmitting, by the AS, a SIP response including the token (see e.g., “information in the appropriate SIP message headers of the requests/responses send out from the server”, [0040] and/or “When the SIP service sends a…response, the SIP container adds the correct headers and values to the request/response. For the inclusion of option tags in a SIP message, the SIP container can add or change any of the following headers if required…supported…unsupported”, [0043]-[0045] and/or “FIG. 1.b…that shows a preliminary list 150 of various SIP feature tags 152, along with their short descriptions 154. Each such feature tag may be included in a "Contact" header of a SIP message. For example, a SIP end-point may include in a "Contact" header of a SIP message the following feature tag…Feature_tag value="sip.audio" which indicates to the receiving SIP end-point that the sender's device supports audio as a streaming media. It is also possible for other types of feature tags, such as for example proprietary feature tags, to be also included in a SIP message header”, [0017]-[0018]).
Postmus fails to explicitly disclose, the SIP request further including an address of the AS.
In the same field of endeavor, Partanen discloses, the SIP request further including an address of the AS (see e.g., “the last service providing server 38 (FIGS. 2 and 6) or the controlling entity 36 (FIG. 9) adds its address to the standard SIP Via header”, column 11, lines 41-43 and/or “application servers 17 including a session initiation protocol (SIP) application server 20”, Fig. 1, column 1, lines 26-28);
Therefore, at the time invention was filed, it would have been obvious to one of ordinary skilled in the art, to modify teachings of Postmus with Partanen, in order to obtain a response, by adding its address to the standard SIP via header (See Partanen, Column 11, lines 40-43).
Regarding claim 7, Postmus and Partanen combined disclose, wherein a uniform resource identifier (URI) is sent in the SIP request (see Postmus e.g., ““the SIP request comprises a Uniform Resource Identifier (URI) 222 that identifies the receiving end-point of the request 220”, [0051]), and wherein the URI is included in one of: a Record-Route header; a Record header; a Via header (see Postmus e.g., “…the SIP option tags and feature tags, and in turn automatically adds the correct end-point capabilities information in the appropriate SIP message headers of the requests/responses send out from the server”, [0040]).
Regarding claim 10, Postmus disclose, a network component comprising a processor (see e.g., Fig. 2, Application Server 200 with Sip Container 202 also called SIP engine with inherent processor) configured to:
generate, at the network component (see e.g., Fig. 2, Application Server 200) a Session Initiation Protocol (SIP) request including a SIP header comprising a token that identifies at least one service supported by the network component (see e.g., “the functionality of a Session Initiation Protocol (SIP) engine included in a SIP application server, also called herein a SIP container, is extended with service logic that automatically interprets SIP end-point capabilities, such as for example the SIP option tags and feature tags, and in turn automatically adds the correct end-point capabilities information in the appropriate SIP message headers of the requests/responses send out from the server”, [0040] and/or “the SIP request comprises a Uniform Resource Identifier (URI) 222 that identifies the receiving end-point of the request 220”, [0051]), the SIP request further including an address of the network component;
transmitting, by the network component, the SIP request (see e.g., “When the SIP service sends a request…the SIP container adds the correct headers and values to the request/response. For the inclusion of option tags in a SIP message, the SIP container can add or change any of the following headers if required…supported…unsupported”, [0043]-[0045]); and
transmitting, by the network component, a SIP response including the token (see e.g., “information in the appropriate SIP message headers of the requests/responses send out from the server”, [0040] and/or “When the SIP service sends a…response, the SIP container adds the correct headers and values to the request/response. For the inclusion of option tags in a SIP message, the SIP container can add or change any of the following headers if required…supported…unsupported”, [0043]-[0045] and/or “FIG. 1.b…that shows a preliminary list 150 of various SIP feature tags 152, along with their short descriptions 154. Each such feature tag may be included in a "Contact" header of a SIP message. For example, a SIP end-point may include in a "Contact" header of a SIP message the following feature tag…Feature_tag value="sip.audio" which indicates to the receiving SIP end-point that the sender's device supports audio as a streaming media. It is also possible for other types of feature tags, such as for example proprietary feature tags, to be also included in a SIP message header”, [0017]-[0018]).
Postmus fails to explicitly disclose, the SIP request further including an address of the network component.
In the same field of endeavor, Partanen discloses, the SIP request further including an address of the network component (see e.g., “the last service providing server 38 (FIGS. 2 and 6) or the controlling entity 36 (FIG. 9) adds its address to the standard SIP Via header”, column 11, lines 41-43 and/or “application servers 17 including a session initiation protocol (SIP) application server 20”, Fig. 1, column 1, lines 26-28);
Therefore, at the time invention was filed, it would have been obvious to one of ordinary skilled in the art, to modify teachings of Postmus with Partanen, in order to obtain a response, by adding its address to the standard SIP via header (See Partanen, Column 11, lines 40-43).
Regarding claim 16, Postmus and Partanen combined disclose, wherein a uniform resource identifier (URI) is sent in the SIP request (see Postmus e.g., ““the SIP request comprises a Uniform Resource Identifier (URI) 222 that identifies the receiving end-point of the request 220”, [0051]), and wherein the URI is included in one of: a Record-Route header; a Record header; a Via header (see Postmus e.g., “…the SIP option tags and feature tags, and in turn automatically adds the correct end-point capabilities information in the appropriate SIP message headers of the requests/responses send out from the server”, [0040]).
Claims 2-3, 8, 11-12, 17-18 and 20 are rejected under 35 U.S.C. 103(a) as being unpatentable over Postmus, in view of Partanen, and further in view of Applicant submitted IDS reference JOHNSTON, A., et al. ("Session Initiation Protocol Service Examples", July, 16, 2007, hereinafter Johnston).
Regarding claim 2, Postmus and Partanen combined fails to explicitly disclose, wherein the SIP request further includes a uniform resource identifier (URI) that is a Globally Routable UA URI (GRUU).
In the same field of endeavor, Johnston discloses, wherein the SIP request further includes a uniform resource identifier (URI) that is a Globally Routable UA URI (GRUU) (see e.g., “The presence of the gr URI parameter in the Contact URI in message Fl0 indicates that the Contact URI is a GRUU [16] and will be globally routable outside of the dialog”, page 57, lines 3-4).
Therefore, at the time invention was made, it would have been obvious to one of ordinary skilled in the art, to modify teachings of Postmus and Partanen with Johnston, in order to help further the goal of standard implementation of RFC 3261 for SIP implementers and designer (See Johnston, page 3, lines 17-20).
Regarding claim 3, Postmus and Partanen combined fails to explicitly disclose, wherein the token indicates whether the at least one service is provided by the AS as an originating AS or a terminating AS.
In the same field of endeavor, Johnston discloses, wherein the token indicates whether the at least one service is provided by the AS as an originating AS (see e.g., “From: sips:music@server.example.com >; tag=0111”, page 42, line 18; Examiner’s note: “From;…musiv@server…” corresponds to originating AS) or a terminating AS (see e.g., “To: <sips: a8342043f@atlanta.example.com;gr>”, page 42, line 19; Examiner’s note: “To: <sips: a8342043f@atlanta.example...” corresponds to terminating AS).
Therefore, at the time invention was made, it would have been obvious to one of ordinary skilled in the art, to modify teachings of Postmus and Partanen with Johnston, in order to help further the goal of standard implementation of RFC 3261 for SIP implementers and designer (See Johnston, page 3, lines 17-20).
Regarding claim 8, Postmus and Partanen combined fails to explicitly disclose, wherein the first SIP request that the AS receives from the first UA is a SIP INVITE message.
In the same field of endeavor, Johnston discloses, wherein the first SIP request that the AS receives from the first UA is a SIP INVITE message (see e.g., “F1 INVITE Alice -> Proxy 1, INVITE sips:bob@biloxi.example.com SIP/2.0, Via: SIP/2.0/TLS client.atlanta.example.com:5061…From: Alice <sips :alice@atlanta.example.com>;tag=1234567’ To: Bob <sips : bob@biloxi.example.com>...CSeq: 1 INVITE…”, Scenario Alice calls Bob, page 6, lines 12-20).
Therefore, at the time invention was made, it would have been obvious to one of ordinary skilled in the art, to modify teachings of Postmus and Partanen with Johnston, in order to help further the goal of standard implementation of RFC 3261 for SIP implementers and designer (See Johnston, page 3, lines 17-20).
Regarding claim 11, Postmus and Partanen combined fails to explicitly disclose, wherein the SIP request further includes a uniform resource identifier (URI) that is a Globally Routable UA URI (GRUU).
In the same field of endeavor, Johnston discloses, wherein the SIP request further includes a uniform resource identifier (URI) that is a Globally Routable UA URI (GRUU) (see e.g., “The presence of the gr URI parameter in the Contact URI in message Fl0 indicates that the Contact URI is a GRUU [16] and will be globally routable outside of the dialog”, page 57, lines 3-4).
Therefore, at the time invention was made, it would have been obvious to one of ordinary skilled in the art, to modify teachings of Postmus and Partanen with Johnston, in order to help further the goal of standard implementation of RFC 3261 for SIP implementers and designer (See Johnston, page 3, lines 17-20).
Regarding claim 12, Postmus, Partanen and Johnston combined discloses, wherein the URI contains a 'gr' parameter (see Johnston e.g., “Contact: <sips: 39itp34klkd@chicago.example.com; gr>”, page 61, line 15 and/or “The presence of the gr URI parameter in the Contact URI in message Fl0 indicates that the Contact URI is a GRUU [16] and will be globally routable outside of the dialog”, page 57, lines 3-4).
Therefore, at the time invention was made, it would have been obvious to one of ordinary skilled in the art, to modify teachings of Postmus and Partanen with Johnston, in order to help further the goal of standard implementation of RFC 3261 for SIP implementers and designer (See Johnston, page 3, lines 17-20).
Regarding claim 17, Postmus and Partanen combined fails to explicitly disclose, receiving, by the network component, a SIP invite from the second UA before the network component generates the SIP request.
In the same field of endeavor, Johnston discloses, receiving, by the network component, a SIP invite from the second UA before the network component generates the SIP request (see e.g., “F10 INVITE Bob -> Proxy 1, INVITE sips:alice@client.atlanta.example.com SIP/2.0, Via: SIP/2.0/TLS client.biloxi.example.com:5061…From: Bob <sips :bob@biloxi.example.com>;tag=314159’ To: Alice <sips : alice@atlanta.example.com>...CSeq: 1 INVITE…”, page 10, lines 14-21).
Therefore, at the time invention was made, it would have been obvious to one of ordinary skilled in the art, to modify teachings of Postmus and Partanen with Johnston, in order to help further the goal of standard implementation of RFC 3261 for SIP implementers and designer (See Johnston, page 3, lines 17-20).
Regarding claim 18, Postmus and Partanen and Johnston combined discloses, wherein a user portion of the URI identifies at least one of: a user agent that originated the SIP INVITE message (see Johnston e.g., “F1 INVITE Alice -> Proxy 1, INVITE sips:bob@biloxi.example.com SIP/2.0, Via: SIP/2.0/TLS client.atlanta.example.com:5061…From: Alice <sips :alice@atlanta.example.com>;tag=1234567’ To: Bob <sips : bob@biloxi.example.com>...CSeq: 1 INVITE…”, Scenario Alice calls Bob, page 6, lines 12-20 and/or “F10 INVITE Bob -> Proxy 1, INVITE sips:alice@client.atlanta.example.com SIP/2.0, Via: SIP/2.0/TLS client.biloxi.example.com:5061…From: Bob <sips :bob@biloxi.example.com>;tag=314159’ To: Alice <sips : alice@atlanta.example.com>...CSeq: 1 INVITE…”, page 10, lines 14-21).
Therefore, at the time invention was made, it would have been obvious to one of ordinary skilled in the art, to modify teachings of Postmus and Partanen with Johnston, in order to help further the goal of standard implementation of RFC 3261 for SIP implementers and designer (See Johnston, page 3, lines 17-20).
Regarding claim 20, Postmus, Partanen and Johnston combined disclose, wherein the AS is a telephony application server (see Postmus e.g., “The servlets implement telephone service logic, such as call forwarding, call screening and mobility service and may be resident on a SIP proxy server.”, [0019] and/or “through the so-called SIP feature tags related to SIP caller/callee preferences and capabilities. Caller preferences are used, for example, to route a SIP request to the proper terminal of a given recipient (in SIP a terminal is called User Equipment, i.e. UE)…”, [0014]).
Claims 4-6 and 13-15 are rejected under 35 U.S.C. 103(a) as being unpatentable over Postmus, in view of Partanen, and further in view of Astrom et al. (US 2008/0189414 A1, hereinafter Astrom).
Regrading Claim 4, Postmus and Partanen combined fails to explicitly disclose, wherein the token is an IP (Internet Protocol) Multimedia Subsystem (IMS) Communication Service Identifier (ICSI).
In the same field of endeavor, Astrom discloses, wherein the token indicates whether the at least one service is provided by the AS as an originating AS (see e.g., Feature Tags express capabilities of registered contacts, i.e., capabilities of a registered terminal. Examples of FTs are audio, video, SIP methods--defined in RFC 2840/3841 and referred to as base feature tags. Other feature tags may be defined to express other capabilities than the ones that exist as base feature tags. Examples are +g.+g.oma.poc.talkburst for Push-to-talk, +g.oma.sip-im, +g.3gpp.app_ref=3gpp-service.ims.icsi.mmtel, etc.”, [0042]; Examiner’s note: “…ref=3gpp-service.ims.icsi.mmtel…” corresponds to token as IP IMS ICSI).
Therefore, at the time invention was made, it would have been obvious to one of ordinary skilled in the art, to modify teachings of Postmus and Partanen with Astrom, in order to identifying particular communication service when other data of said service, such as media being used is not sufficient to do so (See Astrom, para. [0042]).
Regarding claim 5, Postmus, Partanen and Astrom combined disclose, wherein a URI parameter in the URI is set equal to an ICSI value for a particular service provided by the AS (see Astrom e.g., “to identify a terminal to be registered is a Globally Routable User Agent URI (Uniform Resource Identifier) (GRUU). The IMS architecture supports the possibility for multiple UEs (User Equipment/User Entity) to register with the same Public User Identity... Many IMS based enablers, such as Voice Call Continuity, Presence, Conferencing or Push To Talk, need to be able to identify the origin of SIP signaling and route that SIP signaling to a specific UE instance even when multiple UEs use the same Public User Identity”, [0043] and/or “service identifiers, and/or other items to identify the terminal to be registered) are associated with the user, e.g., terminal, and stored in the S-CSCF...Examples are +g.+g.oma.poc.talkburst for Push-to-talk, +g.oma.sip-im, +g.3gpp.app_ref=3gpp-service.ims.icsi.mmtel, etc.,… feature Tags are used for service identification,”, [0042]; Examiner’s note: using ICSI value for a URI sent in a SIP messaging for a specific services such a s voice call continuity…push to talk corresponds to ICSI value for specific service).
Therefore, it would have been obvious to one of ordinary skilled in the art before the effective filing date of the claimed invention to combine teachings of Postmus, Partanen with Astrom, in order to identifying particular communication service when other data of said service, such as media being used is not sufficient to do so (See Astrom, para. [0042]).
Regarding claim 6, Postmus, Partanen and Astrom combined disclose, wherein the URI parameter is a g.3gpp.app_ref tag (see Astrom e.g., “service identifiers, and/or other items to identify the terminal to be registered) are associated with the user, e.g., terminal, and stored in the S-CSCF... Other feature tags may be defined to express other capabilities than the ones that exist as base feature tags. Examples are +g.+g.oma.poc.talkburst for Push-to-talk, +g.oma.sip-im, +g.3gpp.app_ref=3gpp-service.ims.icsi.mmtel…feature Tags are used for service identification,”, [0042]).
Therefore, it would have been obvious to one of ordinary skilled in the art before the effective filing date of the claimed invention to combine teachings of Postmus and Partanen with Astrom, in order to identifying particular communication service when other data of said service, such as media being used is not sufficient to do so (See Astrom, para. [0042]).
Regrading Claim 13, Postmus and Partanen combined fails to explicitly disclose, wherein the token is an IP (Internet Protocol) Multimedia Subsystem (IMS) Communication Service Identifier (ICSI).
In the same field of endeavor, Astrom discloses, wherein the token indicates whether the at least one service is provided by the AS as an originating AS (see e.g., Feature Tags express capabilities of registered contacts, i.e., capabilities of a registered terminal. Examples of FTs are audio, video, SIP methods--defined in RFC 2840/3841 and referred to as base feature tags. Other feature tags may be defined to express other capabilities than the ones that exist as base feature tags. Examples are +g.+g.oma.poc.talkburst for Push-to-talk, +g.oma.sip-im, +g.3gpp.app_ref=3gpp-service.ims.icsi.mmtel, etc.”, [0042]; Examiner’s note: “…ref=3gpp-service.ims.icsi.mmtel…” corresponds to token as IP IMS ICSI).
Therefore, at the time invention was made, it would have been obvious to one of ordinary skilled in the art, to modify teachings of Postmus and Partanen with Astrom, in order to identifying particular communication service when other data of said service, such as media being used is not sufficient to do so (See Astrom, para. [0042]).
Regarding claim 14, Postmus, Partanen and Astrom combined disclose, wherein a uniform resource identifier (URI) is sent in the SIIP request and includes a URI parameter in the URI is set equal to the ICSI (see Astrom e.g., “to identify a terminal to be registered is a Globally Routable User Agent URI (Uniform Resource Identifier) (GRUU). The IMS architecture supports the possibility for multiple UEs (User Equipment/User Entity) to register with the same Public User Identity... Many IMS based enablers, such as Voice Call Continuity, Presence, Conferencing or Push To Talk, need to be able to identify the origin of SIP signaling and route that SIP signaling to a specific UE instance even when multiple UEs use the same Public User Identity”, [0043] and/or “service identifiers, and/or other items to identify the terminal to be registered) are associated with the user, e.g., terminal, and stored in the S-CSCF...Examples are +g.+g.oma.poc.talkburst for Push-to-talk, +g.oma.sip-im, +g.3gpp.app_ref=3gpp-service.ims.icsi.mmtel, etc.,… feature Tags are used for service identification,”, [0042]; Examiner’s note: using ICSI value for a URI sent in a SIP messaging for a specific services such a s voice call continuity…push to talk corresponds to ICSI value for specific service).
Therefore, it would have been obvious to one of ordinary skilled in the art before the effective filing date of the claimed invention to combine teachings of Postmus, Partanen with Astrom, in order to identifying particular communication service when other data of said service, such as media being used is not sufficient to do so (See Astrom, para. [0042]).
Regarding claim 15, Postmus, Partanen and Astrom combined disclose, wherein the URI parameter is a g.3gpp.app_ref tag (see Astrom e.g., “service identifiers, and/or other items to identify the terminal to be registered) are associated with the user, e.g., terminal, and stored in the S-CSCF... Other feature tags may be defined to express other capabilities than the ones that exist as base feature tags. Examples are +g.+g.oma.poc.talkburst for Push-to-talk, +g.oma.sip-im, +g.3gpp.app_ref=3gpp-service.ims.icsi.mmtel…feature Tags are used for service identification,”, [0042]).
Therefore, it would have been obvious to one of ordinary skilled in the art before the effective filing date of the claimed invention to combine teachings of Postmus and Partanen with Astrom, in order to identifying particular communication service when other data of said service, such as media being used is not sufficient to do so (See Astrom, para. [0042]).
Claims 9 and 19 are rejected under 35 U.S.C. 103(a) as being unpatentable over Postmus, in view of Partanen, and further in view of George et al. (US 2008/0244709 A1, hereinafter George).
Regarding claim 9, Postmus and Partanen combined fails to explicitly disclose, wherein the token is associated with the at least one service by one of: a hard coding of the association; and execution of an algorithm that performs the association.
In the same field of endeavor, George discloses wherein the token is associated with the at least one service by one of: a hard coding of the association ( see e.g., “the SIP application configuration information for each SIP application that the SIP server hosts is hard coded into the SIP server”, [0104]).
Therefore, it would have been obvious to one of ordinary skilled in the art before the effective filing date of the claimed invention to combine teachings of Postmus and Partanen with George, in order to standardize way that a particular SIP endpoint supporting multiple applications have subset of applications enabled and an individual application to have a subset of features enabled (see George, para. [0007]).
Regarding claim 19, Postmus and Partanen combined fails to explicitly disclose, wherein the token is associated with the at least one service by one of: a hard coding of the association; and execution of an algorithm that performs the association.
In the same field of endeavor, George discloses wherein the token is associated with the at least one service by one of: a hard coding of the association ( see e.g., “the SIP application configuration information for each SIP application that the SIP server hosts is hard coded into the SIP server”, [0104]).
Therefore, it would have been obvious to one of ordinary skilled in the art before the effective filing date of the claimed invention to combine teachings of Postmus and Partanen with George, in order to standardize way that a particular SIP endpoint supporting multiple applications have subset of applications enabled and an individual application to have a subset of features enabled (see George, para. [0007]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FARID SEYEDVOSOGHI whose telephone number is (571)272-9679. The examiner can normally be reached Mon - Fri 8:00-5:00.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Anthony S. Addy can be reached on 5712727795. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/FARID SEYEDVOSOGHI/Examiner, Art Unit 2645