DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The Information Disclosure Statement submitted on 10/10/2023 has been considered by the examiner (see attached PTO-1449 form).
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-8, 11-14, 17-25 and 27-28 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Allen (US 20110040836).
Regarding claim 1 and 17, Allen teaches a method for handling an ongoing communication session with a remote party in a communication network, a user being associated with a set of User Equipments, UEs, in a single user subscription, which set of UEs comprises at least a first UE and a second UE, the ongoing communication session with the remote party involving the first UE ([0046] Using the present system a network serving a user with multiple UEs, each sharing a common identification, may receive an invitation to participate in a session that includes various media types.), the method comprising:
for each respective UE out of the set of UEs, obtaining information related to the respective UE's name recognizable by the user (nickname),
communication capabilities (supported media types), and
communication session status (notifications that describe the ongoing sessions on a particular UE or all the UEs associated with the user) (“[0098] During operation of the present system, a network node distributes a list of URIs or identities of IUT UEs (i.e. a set of URIs or identities of UEs which can request IUT transfer or be transferred, or a set of URIs of controller and controllee UEs belonging to the same IUT set) .. The list of URIs or identities of IUT UEs may include information such as device nickname, supported media types per URI or identity of each IUT UEs”; [0103] “The list of URIs or identities of IUT UEs may be updated periodically or not periodically by re-broadcasting, sending, or communicating the list, broadcasting updates only as the list is changed and updated, or by each controller UE requesting an updated list” [0158] During operation of the present system, an IUT controller UE may subscribe to receive notifications that describe the ongoing sessions on a particular UE or all the UEs associated with the user. The notifications may identify various ongoing sessions and their associated controllee and/or controller UEs. In one example, a user A has initiated two sessions; one with user C and user D, and another with user B. With reference to the session with users C and D, user A has three sessions for his IUT controller UE set (i.e. devices 1, 2 and 3). For the conversation with user B, user A has two sessions on his IUT UE set (i.e. devices 2 and 3)”;
obtaining a user indication based on the received information, which indication indicates to transfer the ongoing communication session with the remote party ([0074] “As shown in FIG. 1, the multimedia session includes two media components (Media-A and Media-B) and UE-1 wants to transfer the collaborative session control and one of the media components (media-A) to UE-2 via an IUT... by communicating or sending a transfer request to the SCC AS. The transfer request indicates that the collaborative session control and media type (Media-A) are to be transferred to UE-2.” [0077] “In step 104, a session carrying media-A between UE-2 and the SCC AS is established. At this point, the system may optionally update the remote leg between the SCC AS and the remote party in accordance with the establishment of the new session with UE-2.”); and
according to the indication (a transfer request), requesting a network node (SCC) to transfer the ongoing communication session from the first UE to the second UE ([0074], Fig. 1, "As shown in FIG. 1, the multimedia session includes two media components (Media-A and Media-B) and UE-1 wants to transfer the collaborative session control and one of the media components (media-A) to UE-2 via an IUT. As illustrated, in step 101, UE-1 initiates the process of transferring the collaborative session control and media type (media-A) to UE-2 by communicating or sending a transfer request to the SCC AS. The transfer request indicates that the collaborative session control and media type (Media-A) are to be transferred to UE-2 ... The UE-2 may be identified by, but not limited, to GRUU .. UE-2's GRUU is stored in the SCC AS (valid REGISTRATION exists) and stored against that GRUU are media feature tags that match those that have been received in the request from UE-1", [0077], Fig. 1, "In step 104, a session carrying media-A between UE-2 and the SCC AS is established. At this point, the system may optionally update the remote leg between the SCC AS and the remote party in accordance with the establishment of the new session with UE-2").
Regarding claim 11 and 25, Allen teaches a method performed by a network node, for handling an ongoing communication session with a remote party in a communication network, a user being associated with a set of User Equipments (a user with multiple UEs), UEs, in a single user subscription, which set of UEs comprises at least a first UE and a second UE, the ongoing communication session with the remote party involving the first UE ([0046] Using the present system a network serving a user with multiple UEs, each sharing a common identification; [0076] “the collaborative session includes a logical set of one or more IP Multimedia Subsystem (IMS) sessions, possibly on two or more UEs sharing the same IMS subscription”), the method comprising:
for each respective UE out of the set of UEs, obtaining information related to the respective UE's name recognizable by the user (nickname),
communication capabilities (supported media types), and
communication session status, which information is transmitted to at least one UE out of the set of UEs (notifications that describe the ongoing sessions on a particular UE or all the UEs associated with the user) (“[0098] During operation of the present system, a network node distributes a list of URIs or identities of IUT UEs (i.e. a set of URIs or identities of UEs which can request IUT transfer or be transferred, or a set of URIs of controller and controllee UEs belonging to the same IUT set) .. The list of URIs or identities of IUT UEs may include information such as device nickname, supported media types per URI or identity of each IUT UEs”; [0103] “The list of URIs or identities of IUT UEs may be updated periodically or not periodically by re-broadcasting, sending, or communicating the list, broadcasting updates only as the list is changed and updated, or by each controller UE requesting an updated list” [0158] During operation of the present system, an IUT controller UE may subscribe to receive notifications that describe the ongoing sessions on a particular UE or all the UEs associated with the user. The notifications may identify various ongoing sessions and their associated controllee and/or controller UEs. In one example, a user A has initiated two sessions; one with user C and user D, and another with user B. With reference to the session with users C and D, user A has three sessions for his IUT controller UE set (i.e. devices 1, 2 and 3). For the conversation with user B, user A has two sessions on his IUT UE set (i.e. devices 2 and 3)”;
receiving a request from the at least one UE, requesting to transfer the ongoing communication session from the first UE to the second UE; ([0074], Fig. 1, "As shown in FIG. 1, the multimedia session includes two media components (Media-A and Media-B) and UE-1 wants to transfer the collaborative session control and one of the media components (media-A) to UE-2 via an IUT. As illustrated, in step 101, UE-1 initiates the process of transferring the collaborative session control and media type (media-A) to UE-2 by communicating or sending a transfer request to the SCC AS. The transfer request indicates that the collaborative session control and media type (Media-A) are to be transferred to UE-2 ... The UE-2 may be identified by, but not limited, to GRUU ... UE-2's GRUU is stored in the SCC AS (valid REGISTRATION exists) and stored against that GRUU are media feature tags that match those that have been received in the request from UE-1"); and
based on the request, transferring the ongoing communication session from the first UE to the second UE ([0077], Fig. 1, "In step 104, a session carrying media-A between UE-2 and the SCC AS is established. At this point, the system may optionally update the remote leg between the SCC AS and the remote party in accordance with the establishment of the new session with UE-2")
Regarding claim 2, 14 and 18 and 28, Allen teaches the method according to claim 1, further comprising: when the ongoing communication session has been transferred, for each respective UE out of the set of UEs, obtaining updated information related to the respective UE's name recognizable by the user, communication capabilities, and communication session status ([0077] “In step 104, a session carrying media-A between UE-2 and the SCC AS is established. At this point, the system may optionally update the remote leg between the SCC AS and the remote party in accordance with the establishment of the new session with UE-2… After successful establishment of the collaborative session control and transfer of media-A to UE-2 .. UE-1 becomes a controllee UE (a UE that receives and/or transmits media flow (media-B) as part of the collaborative session, while being subordinate to the controller UE for session control) and UE-2 assumes the role of controller UE. Media type (Media-A) is communicated between UE-2 and the remote party and media type (Media-B) continues to be communicated between UE-1 and the remote party“; [0116] an IUT controller UE sends SIP OPTIONS to the UEs identified in the list to determine the capabilities of the other IUT UEs (for example, by using the received IUT controller feature tag in the 200 OK response) and to discover which are currently available, IUT capable and which can have the IUT controller function transferred to them. The IUT Controllee UEs can obtain the capabilities of the other UEs including the media feature tag that indicates support for IUT controller/controllee functionality via a message such as the 200 (OK) response returned in response to a message such as a SIP OPTIONS request.”; [0098] “During operation of the present system, a network node distributes a list of URIs or identities of IUT UEs (i.e. a set of URIs or identities of UEs which can request IUT transfer or be transferred, or a set of URIs of controller and controllee UEs belonging to the same IUT set) to the controller UEs or a set of IUT UEs allowing the identification of which UEs are controller or controllee, which UEs support IUT controller function and to which UE an IUT controller function can be transferred. The list of URIs or identities of IUT UEs may include information such as device nickname, supported media types per URI or identity of each IUT UEs”; [0103] “The list of URIs or identities of IUT UEs may be updated periodically or not periodically by re-broadcasting, sending, or communicating the list.. Updating the list of URIs or identities of IUT UEs may be important as UEs may be constantly added (or registered) or removed (or de-registered) to/from the serving network entities such as HSS, S-CSCF, SCC AS in the serving network such as S-CSCF, HSS, or SCC AS. Updates may include the deletion, addition, or modification of entries as described above. The network node such as the SCC AS, DM Server provides the list of URIs or identities of IUT UEs”).
Regarding claim 3 and 19, Allen teaches the method according to claim 1, wherein the communication session status comprises any one or more out of: whether being involved in the ongoing session ([0158] During operation of the present system, an IUT controller UE may subscribe to receive notifications that describe the ongoing sessions on a particular UE or all the UEs associated with the user. The notifications may identify various ongoing sessions and their associated controllee and/or controller UEs); whether not being involved in the ongoing session; and a current status of another session than the ongoing session. [0098] “During operation of the present system, a network node distributes a list of URIs or identities of IUT UEs (i.e. a set of URIs or identities of UEs which can request IUT transfer or be transferred, or a set of URIs of controller and controllee UEs belonging to the same IUT set) to the controller UEs or a set of IUT UEs allowing the identification of which UEs are controller or controllee, which UEs support IUT controller function and to which UE an IUT controller function can be transferred. The list of URIs or identities of IUT UEs may include information such as device nickname, supported media types per URI or identity of each IUT UEs”; [0103] “The list of URIs or identities of IUT UEs may be updated periodically or not periodically by re-broadcasting, sending, or communicating the list... Updating the list of URIs or identities of IUT UEs may be important as UEs may be constantly added (or registered) or removed (or de-registered) to/from the serving network entities such as HSS, S-CSCF, SCC AS in the serving network such as S-CSCF, HSS, or SCC AS. Updates may include the deletion, addition, or modification of entries as described above. The network node such as the SCC AS, DM Server provides the list of URIs or identities of IUT UEs”).
Regarding claim 4 and 20, Allen teaches the method according to claim 1, wherein the name recognizable by the user is any one out of: a descriptive name set by a user; a descriptive name set by an operator; and a descriptive name automatically generated ([0098] “During operation of the present system, a network node distributes a list of URIs or identities of IUT UEs (i.e. a set of URIs or identities of UEs which can request IUT transfer or be transferred, or a set of URIs of controller and controllee UEs belonging to the same IUT set) to the controller UEs or a set of IUT UEs allowing the identification of which UEs are controller or controllee, which UEs support IUT controller function and to which UE an IUT controller function can be transferred. The list of URIs or identities of IUT UEs may include information such as device nickname, supported media types per URI or identity of each IUT UEs”);
Regarding claim 5 and 21, Allen teaches the method according to claim 1, wherein the information related to the respective UE's name recognizable by the user, communication capabilities, and communication session status, further comprises device information, wherein the device information comprising any one or more out of: a tag indicating the UE supports one or more types of media ([0098] “During operation of the present system, a network node distributes a list of URIs or identities of IUT UEs (i.e. a set of URIs or identities of UEs which can request IUT transfer or be transferred, or a set of URIs of controller and controllee UEs belonging to the same IUT set) to the controller UEs or a set of IUT UEs allowing the identification of which UEs are controller or controllee, which UEs support IUT controller function and to which UE an IUT controller function can be transferred. The list of URIs or identities of IUT UEs may include information such as device nickname, supported media types per URI or identity of each IUT UEs”); a tag indicating the UE supports one or more types of communication; and a tag indicating the UE have registered one or more capabilities associated with the UE.
Regarding claim 6, 12 and 22, Allen teaches the method according to claim 1, wherein the method is performed by any one out of the first UE or the second UE ([0074], Fig. 1, "As shown in FIG. 1, the multimedia session includes two media components (Media-A and Media-B) and UE-1 wants to transfer the collaborative session control and one of the media components (media-A) to UE-2 via an IUT. As illustrated, in step 101, UE-1 initiates the process of transferring the collaborative session control and media type (media-A) to UE-2 by communicating or sending a transfer request to the SCC AS. The transfer request indicates that the collaborative session control and media type (Media-A) are to be transferred to UE-2 ... The UE-2 may be identified by, but not limited, to GRUU ... UE-2's GRUU is stored in the SCC AS (valid REGISTRATION exists) and stored against that GRUU are media feature tags that match those that have been received in the request from UE-1");
Regarding claim 7, 13, 23 and 27, Allen teaches the method according to claim 1, wherein obtaining comprises retrieving the information from a device performing the method, or receiving the information from the network node (“[0098] During operation of the present system, a network node distributes a list of URIs or identities of IUT UEs (i.e. a set of URIs or identities of UEs which can request IUT transfer or be transferred, or a set of URIs of controller and controllee UEs belonging to the same IUT set) .. The list of URIs or identities of IUT UEs may include information such as device nickname, supported media types per URI or identity of each IUT UEs”; [0103] “The list of URIs or identities of IUT UEs may be updated periodically or not periodically by re-broadcasting, sending, or communicating the list, broadcasting updates only as the list is changed and updated, or by each controller UE requesting an updated list” [0158] During operation of the present system, an IUT controller UE may subscribe to receive notifications that describe the ongoing sessions on a particular UE or all the UEs associated with the user. The notifications may identify various ongoing sessions and their associated controllee and/or controller UEs. In one example, a user A has initiated two sessions; one with user C and user D, and another with user B. With reference to the session with users C and D, user A has three sessions for his IUT controller UE set (i.e. devices 1, 2 and 3). For the conversation with user B, user A has two sessions on his IUT UE set (i.e. devices 2 and 3).
Regarding claim 8 and 24, Allen teaches the method according to claim 1, wherein the received information is presented by the first UE or the second UE to be recognized by the user ([0196] “The UE 1700 includes a display 702” [0198] “the UE 1700 has access to information on various servers, such as a server 1706. The server 1706 may provide content that may be shown on the display 702”).
Response to Arguments
Applicant's arguments filed 7/7/2026 have been fully considered but they are not persuasive.
Applicant argues that,
“A. The Cited Reference Does Not Disclose Applicant's Obtaining Communication Capabilities Associated With Each Respective UE Independent Claims 1, 11, 17 and 25”.
The examine respectfully disagrees. When examining a claim, the examiner must give the broadest reason interpretation of the claim (MPEP 2111). Thus “Communication Capabilities” is interpreted as a capability/feature that the UE can use to communicate. Clearly, a “communication capability” is very broad term and can read on any capability is related to communication. Thus, a supported media types (which are the types of media that are compatible for the UE to use to communicate) would meet the limitation “Communication Capabilities”.
(see Allen, “[0098] During operation of the present system, a network node distributes a list of URIs or identities of IUT UEs (i.e. a set of URIs or identities of UEs which can request IUT transfer or be transferred, or a set of URIs of controller and controllee UEs belonging to the same IUT set) .. The list of URIs or identities of IUT UEs may include information such as device nickname, supported media types per URI or identity of each IUT UEs”)”
Applicant argues that,
“Allen's disclosure of supported media types and basic identifying information merely identifies whether a device may support particular forms of media, such as audio, video, or messaging. This is not the same as Applicant's communication capabilities, which include at least "circuit switch capability" or "packet switched capability" (Applicant PCT Application: pg. 3, Ins. 20-32). In other words, Applicant's communication capabilities refer to signal communication protocol information, communication technologies, services or network features of the UE, as opposed to the UE identifying information and supported media types disclosed by Allen.”
The examiner respectfully disagrees. Applicant admits that Allen discloses “a device may support particular forms of media, such as audio, video, or messaging”. These are indeed the type of communication capability a device can have. Messaging is a type of communication capability. Audio or videos are also different types of communication capability as well. The only difference here is that these capabilities are not the same as what applicant intended. However, the intended capability are not being claimed. Applicant is invited to amend the claim the specific intended capability.
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “communication protocol information, communication technologies, services or network features of the UE”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Applicant argues that,
“The identifying information and supported media types as described in Allen is not reasonably equated to Applicant's claimed communication capabilities. Put another way, Applicant's communication capabilities, as clearly set out in Applicant's specification refer to capabilities of a UE to communicate with the network itself, such as having a "circuit switch capability" or "packet switched capability".
The examiner respectfully disagrees. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., circuit switch capability" or "packet switched capability") are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Applicant argues that,
“B. The Cited Reference Does Not Disclose Applicant's Obtaining
Communication Session Status Information For Each Respective UE.”
The examiner respectfully disagrees. When examining a claim, the examiner must give the broadest reasonable interpretation of the claim. Thus “Communication Session Status” can be interpreted as any status or condition that is related the communication. An “ongoing session” means there is “a session going on” or “a session is active”. Therefore, the examiner submits that the condition of “session is going on” meets the broad limitation of a “Communication Session Status” (See Allen, “[0158] During operation of the present system, an IUT controller UE may subscribe to receive notifications that describe the ongoing sessions on a particular UE or all the UEs associated with the user. The notifications may identify various ongoing sessions and their associated controllee and/or controller UEs. In one example, a user A has initiated two sessions; one with user C and user D, and another with user B. With reference to the session with users C and D, user A has three sessions for his IUT controller UE set (i.e. devices 1, 2 and 3). For the conversation with user B, user A has two sessions on his IUT UE set (i.e. devices 2 and 3)”;
Applicant argues that,
“The Office Action asserts that Allen allegedly discloses obtaining communication session status information for each respective UE. The Office Action relies on Allen's discussion of ongoing sessions and session transfer protocols. (Allen Specification[0074], [0077], [0116] and [0158]). However, these portions merely indicate that a communication session exists and may be transferred between devices, not the actual current status of the communication session.
The examiner respectfully disagrees. The existence of a session is indeed a communication session status because it means the session “is going on”. One of ordinary skill can interpret an “ongoing session” as “a session exists” or “a session is active” which would definitely meet the limitation of “a communication status”.
Applicant argues that,
“As described, Allen discloses only the listing of other connected devices by name or device nickname. This is not the same as Applicant's obtaining communication session status information. A communication session status identifies a present operating condition of a respective UE relative to a communication session, such as whether the UE is, for example, "idle", "busy", "active", participating in a session, or otherwise capable of receiving a transferred communication session. (Applicant's PCT Application pg. 19, Ins. 7-23).”
The examiner respectfully disagrees. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., "idle", "busy", "active") are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
For a more positive result, the examiner invites the applicant to amend the claim to include the specific intended communication capability and communication status rather than the broad generic terms: capability and status.
Citation of Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Wilcock (US20020073150) teaches transfer between two identified participants—the second identified participant is invited into the session and if this participant accepts to join, then the first participant is removed from the session. Successful transfer results in a “Transferred” event being generated ([0055]).
The service instance associated with a communication session instance has access to the data held by the session instance, including the participant data and session transport data ([0057] ).
Allen (US20150312295) teaches Figure 10, an example flow for transferring media-A and controller function from UE-1 to UE-2, where the incoming session request includes a controller function identifier and is delivered over the I1 reference point and the media-A is transmitted via a CS network ([0022])
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DUNG L LAM whose telephone number is (571)272-6497. The examiner can normally be reached Monday -Thursday 9-5pm.
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, Jeanette Parker can be reached at 571-270-3647. 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.
/DUNG L LAM/Examiner, Art Unit 2646
/JEANETTE J PARKER/Supervisory Patent Examiner, Art Unit 2646
Prosecution Insights