DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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 timewise 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 Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); /n re Thorington, 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 § 2146 et seq. 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 filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual 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 eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 4, 6, 7, 11, 13, 14, 15, 18, 20, 21, 22 and 23 of U.S. Patent No. 12, 127, 149 B2. Although the claims at issue are not identical, they are not patentably distinct from each other because the claimed limitations recited in the present application are found in the U.S. Patent No. 12, 127, 149 B2 with obvious wording variations as described in Tables I-II. All limitations are mapped in detail with respect to primary reference in the complete office action.
Table I
Current Application No. 18894129
U.S. Patent No. 12,127,149 B2
Claims 1, 9, 17:
A method comprising: receiving, by a gateway and from a first messaging hub, an application programming interface (API) call, wherein the API call is based on the first messaging hub receiving a request to execute rich communication services (RCS) messaging from a first mobile device (receiving a request from a mobile device of a first service provider or hub of a first service provider, where the API call is associated with RCS messaging. Hub of a first service provider is mapped through figures in primary reference);
triggering, based on the receiving of the API call, a modification of a service order code, resulting in a modified service order code, wherein the modified service order code indicates whether the first mobile device is registered to use a single registration or a dual registration (triggering a modification of a service order code is same in scope as receiving by the core an indication to modify the service code wherein the modified code indicates single or dual registration);
and routing, by one or more core devices, a plurality of RCS messages from the first mobile device to a second mobile device based on the modified service order code (Claim is broader in scope. Core device routes the messages from the first mobile device in accordance with the service order code. See also claims 4, 11, 18 and 21 of the patented application ).
Claims 1, 8, 15:
A method comprising: receiving a message, wherein the message is an application programming interface (API) call initiated by a mobile device of a first service provider (receiving a message which is an API call);
based on the receiving of the message, detecting an indication to modify a service order code associated with rich communication services (RCS) messaging...; and sending the indication to modify the service order code to a core device, wherein the service order code indicates single registration for RCS messaging or dual registration for RCS messaging...
wherein the core device routes the message and at least a second message from the mobile device based on at least one virtual device and at least one physical device of the core device in accordance with the modified service order code...
Claims 4, 11, 18:
The computer readable storage medium of claim 15, the operations further comprising sending routing instructions based on the service order code.
Claims 21,
The computer readable storage medium of claim 15, wherein the API call is initiated by the mobile device based on the mobile device attempting to RCS message a second mobile device.
Table II
Current Application No. 18894129
U.S. Patent No. 12,127,149 B2
Claims 2, 10:
The method of claim 1, wherein the first mobile device is on a first wireless provider network, and the second mobile device is on the first wireless provider network (same network),
and wherein the modified service order code indicates use of the single registration.
Claim 22:
and wherein the mobile device and the second mobile device are on a same wireless provider network
Claim 1:
...wherein the service order code indicates single registration...
Claims 3, 11:
The method of claim 1, wherein the first mobile device is on a first wireless provider network, and the second mobile device is on a second wireless provider network that is different from the first wireless provider network (different providers),
and wherein the modified service order code indicates use of the dual registration.
Claim 23:
The computer readable storage medium of claim 21, wherein the mobile device and the second mobile device communicate through different wireless service providers.
Claim 1:
... wherein the service order code indicates single registration or dual registration
Claims 4, 12:
The method of claim 3, wherein the routing of the plurality of RCS messages comprises routing the plurality of RCS messages to a second messaging hub associated with the second wireless provider network (RCS messaging from one mobile to other on different networks).
Claim 1:
wherein the core device routes the message and at least a second message from the mobile device (routing plurality of RCS messaging from a first mobile).
Claims 21:
The computer readable storage medium of claim 15, wherein the API call is initiated by the mobile device based on the mobile device attempting to RCS message a second mobile device.
Claim 23:
The computer readable storage medium of claim 21, wherein the mobile device and the second mobile device communicate through different wireless service providers.
Claims 5, 13:
The method of claim 1, further comprising sending routing instructions based on the service order code.
Claims 4, 11, 18:
...sending routing instructions based on the service order code.
Claims 6, 14:
The method of claim 1, wherein based on the triggering the one or more core devices modify the service order code, resulting in the modified service order code (triggering a modification of a service order code is same in scope as receiving an indication to modify the service code wherein the modified code indicates single or dual registration and routing per the modified code).
Claims 1, 8, 15:
... sending the indication to modify the service order code to a core device, wherein the service order code indicates single registration for RCS messaging or dual registration for RCS messaging, the core device modifying an application server index to a fully qualified domain name ..., and the core device modifying the application server index to a presence application server ... wherein the core device routes the message and at least a second message from the mobile device ...in accordance with the modified service order code...
Claims 7, 15:
The method of claim 6, wherein the one or more core devices comprise a virtual network function.
Claims 6, 13, 20:
The method of claim 1, wherein the core device comprises a virtual network function.
Claims 8, 16:
The method of claim 6, wherein the one or more core devices comprise a home subscriber server.
Claims 7, 14:
The method of claim 1, wherein the core device comprises a home subscriber server.
Claim 18:
The computer readable storage medium of claim 17, wherein the at least one RCS message comprises a plurality of RCS messages.
Claim 1:
wherein the core device routes the message and at least a second message from the mobile device (plurality of messages).
Claims 21:
The computer readable storage medium of claim 15, wherein the API call is initiated by the mobile device based on the mobile device attempting to RCS message a second mobile device (plurality of RCS messages from the mobile device).
Claim 19:
The computer readable storage medium of claim 17, wherein the routing is facilitated via a core device, and wherein when the triggering indicates that the first device is being registered to use the dual registration the core device modifies an application server index to a fully qualified domain name.
Claims 1, 8, 15:
...and sending the indication to modify the service order code to a core device, wherein the service order code indicates single registration for RCS messaging or dual registration for RCS messaging, the core device modifying an application server index to a fully qualified domain name when the mobile device is switching from the single registration to the dual registration...
Claim 20:
The computer readable storage medium of claim 19, wherein when the triggering indicates that the first device is being registered to use the single registration the core device modifies the application server index to a presence application server.
Claims 1, 8, 15:
and the core device modifying the application server index to a presence application server when the mobile device is switching from the dual registration to the single registration in accordance with the indication...
Claim Rejections - 35 USC § 103
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 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-18 are rejected under 35 U.S.C. 103 as being unpatentable over US 20180295157 A1 (Marappa) in view of US 20210281614 Al (Ahmad et al.) (hereinafter Ahmad) in view of US 20210219131 A1 (BYADGI et al.) (hereinafter BYADGI) and in further view of US 20050286531 A1 (Tuohino et al.) (hereinafter Tuohino).
In re claims 1, 9 and 17, Marappa discloses a method (Fig. 2, [0045], “FIG. 2 illustrates an example method 200 of processing an IMS service request or other service-related communication from a communication device”), an apparatus (Fig. 1, [0046], “An action 204 comprises receiving, at a computing device associated with the IMS of a communications carrier...”) comprising: a processor (Fig. 3:304, [0053], “The network device 300 may further comprise processor(s) 304”); and memory coupled with the processor (Fig. 3:302, [0053], “The network device 300 may further comprise processor(s) 304, a removable storage 306, a non-removable storage 308, transceivers 310, output device(s) 312, and input device(s) 314, any or all of which can be communicatively connected via a communications bus”), and a computer readable storage medium (Fig. 3: 306, 308, [0055]) storing computer executable instructions ([0053], “The network device 300 may have system memory 302 that stores various executable components and data for implementing the method 200 of FIG. 2”) that when executed by a computing device ([0052], “FIG. 3 illustrates a component level view of a telecommunication network device 300...”) cause said computing device to effectuate operations comprising:
receiving, by a gateway and from a first messaging hub, an application programming interface (API) call ([0010], “An initial request from a UE is received by an IMS Call Session Control Function (CSCF). The request specifies a particular type of service”. [0046], “The request may specify a particular type of service to which the communication corresponds, such as voice, conferencing, video, messaging, etc. The request may be received from any of multiple communication devices, some of which may be subscribers of the wireless communications carrier and some of which may be subscribers of entities other than the wireless communications carrier, such as the third parties 118 of FIG. 1”), wherein the API call is based on the first messaging hub receiving a request (Fig. 2: 204, [0028], “To establish a communication session, a requesting one of the UEs 106 sends an initial request to the CSCF 110 of the IMS core 104”) to execute rich communication services (RCS) messaging from a first mobile device ([0015], “FIG. 1 illustrates an example wireless telecommunication system 100, which may be provided and/or supported by a wireless communications carrier 102 or other service provider. The system 100 includes an Internet Protocol (IP) Multimedia Subsystem (IMS) core 104 that provides services for multiple user equipment (UE) devices 106”. [0022], “The carrier application servers 112 may also include an IP short message gateway (IP-SM-GW)...between UEs. The carrier application servers 112 may include a Rich Communication Suite (RCS)”);
triggering, based on the receiving of the API call, a modification of a service order code, resulting in a modified service order code, wherein the modified service order code indicates whether the first mobile device is registered to use a single registration or a dual registration ([0049], “for example, the action 210 may comprise parsing the received request to determine which of multiple services are specified by the request, and routing the request to an application server of the carrier that provides the specified service”. [0051]. “For example, a carrier-supported application server 112 may provide a service at a first QoS for subscribers of the carrier, and a third party-supported application server 116 may provide the service at a second, different QoS for subscribers of the third party”);
and routing, by one or more core devices, a plurality of RCS messages from the first mobile device to a second mobile device based on the modified service order code ([0049], “If the requesting device is a subscriber of the wireless communication carrier, an action 210 is performed of routing the request to an appropriate IMS application server of the wireless communications carrier”. [0050], “If the device is a subscriber of a third-party business entity other than the wireless communications carrier, an action 212 is performed of routing the request to an IMS application server of the business entity. For example, the action 210 may comprise parsing the received request to determine which of multiple services are specified by the request and routing the request to a corresponding application server that is provided by or on behalf of the entity of which the requesting device is a subscriber” (routing by the core, based on subscription)).
Marappa does not explicitly disclose triggering, based on the receiving of the API call, a modification of a service order code, resulting in a modified service order code.
Ahmad discloses triggering, based on the receiving of the API call, a modification of a service order code, resulting in a modified service order code (Fig. 2:211, [0034], “...the sender device UE 102 may be an application running on one or more processors that generate a call or a message on behalf of a business. This may be useful, for example, in communicating with customers via a software-based telephony program running on a computer associated with the business...The business data server 160 may insert additional enriched data to the message, such as a business logo, business photo, urgency indicator, subject matter, a vcard, a Uniform Resource Locator (URL), or a map. Such enriched data may then be sent by the business data server 160 to be routed to the receiver UE 104 when initiating the call”. [0021], “In some embodiments, the RCS capabilities of senders or recipients may be indicated within the UE contact phonebook. Alternatively, the service provider may utilize a subscription-based or account-based approach...to obtain subscription-level or account-level information pertaining to enriched call elements for voice or video calls”. [0034], “In some embodiments, the UE 102 may insert a custom SIP HEADER in the RCS messages that distinguishes the message from unwanted robo-calls and from those of individual subscribers and indicates the sender is a business having previously configured account settings to send enriched data identifying the business to the recipient of the call. Upon receiving this message containing the custom SIP HEADER, a network element, such as an IMS core network element of the operating company may take special action, such as routing the call to business data server 160” (triggering, based on the API call, a modification to the service order code)).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Marappa with Ahmad to provide a telecommunications infrastructure that is based in part on an IP Multimedia Subsystem (IMS) where users could be subscribed to both to avail rich communication services such as group chat, content sharing, voice calling, video calling, social presence etc., and wherein an indication is provided to distinguish an incoming call as an API call. The advantage of doing so is to enable differentiated routing by the core network for users with different subscriptions and profiles to the application server that supports the service.
Marappa and Ahmad do not disclose wherein the modified service order code indicates whether the first mobile device is registered to use a single registration or a dual registration; and routing, by one or more core devices, a plurality of RCS messages from the first mobile device to a second mobile device based on the modified service order code.
BYADGI discloses the modified service order code indicates whether the first mobile device is registered to use a single registration or a dual registration ([0092], “In an embodiment, In-Call capability features of a device may be discovered based on a device registration type, where the device is the MO 100 or the MT 200. The type of device registration can be a single registration or a dual registration”. [0094], “In an embodiment, when the MO 100 and the MT 200 have the single registration, then the In-Call capability features may negotiate in the contact header of the SIP INVITE message”. [0095], “In an embodiment, the MO 100 may generate the SIP private extension header for identifying the In-Call capability features in the dual registration. The MO 100 may add the SIP private extension header in the SIP INVITE message to convey the MT 200 that the MO 100 is RCS registered and supports in the In-Call capability features” (service code indicates single or dual registration)).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Marappa, Ahmad and BYADGI to provide a method to differentiate the calls based on device registration type by replacing the original header of the SIP message with a modified header associated with the traffic type. The advantage of doing so is to be able to differentiate between such subscribers with dual subscriptions and routing traffic accordingly to help improve network latency, load balancing and improve quality of service.
Marappa, Ahmad and BYADGI do not explicitly disclose routing, by one or more core devices, a plurality of RCS messages from the first mobile device to a second mobile device based on the modified service order code.
Tuohino discloses routing, by one or more core devices, a plurality of RCS messages from the first mobile device to a second mobile device based on the modified service order code (Fig. 12, [0032], “FIG. 12 shows embodiments for explaining routing examples for routing messages and/or message sets and/or sessions such as calls from one to another equipment” (from one mobile device to other). [0035], “FIG. 15 illustrates another embodiment of the present invention which provides a solution "Route the message and/or message set and/or session according to the media and/or QoS and/or other requirements". [0081], “The local ENUM-DNS database 6 may include also IMS E.164 identities of the trusted operators. This part of the database may contain delegations to appropriate ENUM-DNS databases of respective operators following standard DNS principles. The database 7 includes an ENUM-DNS database containing information to find FQDN (FQDN=Fully Qualified Domain Name) of foreign I-CSCFs (i.e., FQDN of other operators/networks is searched for dual registration”. [0109], “This database 23 is used by BGCF 11 of the network 10, for finding IMS identities or FQDNs used for routing to parties/terminals/networks/NEs (Network Elements) being identified by the E.164 numbers, in the message and/or session request message of step 6a”. [0240], “The HSS 89 returns the FQDN, e.g., scscf12.ims.sonera.fi, of S-CSCF 90 where the B-subscriber is registered” (using FQDN for dual registration routing). [0297], “In the latter case if the subscriber has dual subscription (i.e., both IMS and non-IMS e.g., CS) and a dual terminal, those IMS messages and/or message sets and/or sessions can be routed through non-IMS e.g., CS network where the media and/or QoS and/or other requirements can be fulfilled with the capabilities offered by the non-IMS e.g., CS network”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Marappa, Ahmad, BYADGI with that of Tuohino to provide a method of routing traffic via an IMS system where the service routing information comprises single or dual registration. The advantage of doing so is efficient routing of traffic with secondary subscriptions to improve network latency, load balancing and quality of service.
In re claims 2 and 10, the combination discloses the method of claim 1 and the apparatus of claim 9, wherein Marappa discloses wherein the first mobile device is on a first wireless provider network and the second mobile device is on the first wireless provider network ([0046], “An action 204 comprises receiving, at a computing device associated with the IMS of a communications carrier or other service provider, a request 202 or other communication from a communication device. The request may specify a particular type of service to which the communication corresponds, such as voice, conferencing, video, messaging, etc. The request may be received from any of the multiple communication devices, some of which may be subscribers of the wireless communications carrier (same wireless provider network) and some of which may be subscribers of entities other than the wireless communications carrier, such as the third parties 118 of FIG. 1”), and wherein BYADGI discloses wherein the modified service order code indicates use of the single registration ([0093], “In an embodiment, in the single registration, the VOLTE and the RCS may be registered on a single PDN for a same International Mobile Subscriber Identity (IMSI) or Mobile Subscriber Integrated Services Digital Network (MSISDN)” (discloses use of a single registration)).
In re claims 3 and 11, the combination discloses the method of claim 1 and the apparatus of claim 9, wherein Marappa discloses wherein the first mobile device is on a first wireless provider network and the second mobile device is on a second wireless provider network that is different from the first wireless provider network ([0046], “The request may be received from any of multiple communication devices, some of which may be subscribers of the wireless communications carrier and some of which may be subscribers of entities other than the wireless communications carrier, such as the third parties 118 of FIG. 1” (different service providers), and wherein BYADGI discloses wherein the modified service order code indicates use of the dual registration ([0093], “In the dual registration, the VOLTE and the RCS may be registered on a different PDN for the same IMSI or MSISDN”. [0094], “In an embodiment, when the MO 100 and the MT 200 have the dual registration, then the SIP INVITE message may include the SIP private extension header with the In-Call capability features” (discloses use of dual registration)).
In re claims 4 and 12, the combination discloses the method of claim 3 and the apparatus of claim 11, wherein Marappa discloses wherein the routing of the plurality of RCS messages comprises routing the plurality of RCS messages to a second messaging hub associated with the second wireless provider network ([0011], “As one example, members of the emergency services community have noted the need for a dedicated network to be used by emergency service personnel (from one mobile to another attempting to RCS message). Such a network would be associated with particular service level agreements regarding reliability, speed, security, availability, etc. As another example, a third party may want to provide specialized video conferencing capabilities for its employees (one mobile to other video messaging or RCS). As yet another example, a third party may be what is referred to as a “mobile virtual network operator” or MVNO, and may want to offer general voice, text, and data services under its own brand, using its own QoS parameters and billing schemes”. [0046], “An action 204 comprises receiving, at a computing device associated with the IMS of a communications carrier or other service provider, a request 202 or other communication from a communication device. The request may specify a particular type of service to which the communication corresponds, such as voice, conferencing, video, messaging, etc. The request may be received from any of multiple communication devices, some of which may be subscribers of the wireless communications carrier and some of which may be subscribers of entities other than the wireless communications carrier, such as the third parties 118 of FIG. 1” (See also “In re claims 3 and 11”. Mobile devices can be on different service providers and different service providers will have different messaging hubs)).
In re claims 5 and 13, the combination discloses the method of claim 1 and the apparatus of claim 9, wherein BYADGI discloses sending routing instructions based on the service order code (Fig. 4, [0096], “The SIP private extension header may be defined as P-Associated-Features. Consider the device may be registered to the RCS & In-Call capability features. While initiating the call, the MO 100 may send the SIP INVITE message to the MT 200 by adding the SIP private extension header “P-Associated-Features” with all the supported “In-Call capability features”. [0100], “Route: sip: [2405:200:370:1581::33]:5067; lr” (routing instructions based on headers or codes)).
In re claims 6 and 14, the combination discloses the method of claim 1 and the apparatus of claim 9, wherein Tuohino discloses wherein the one or more core devices modify the service order code, resulting in the modified service order code (Fig. 8, [0038], “ENUM-DNS database to find FQDN of the own MGCFs and foreign BGCFs (i.e. BGCFs of other operators/networks”. [0081], “The database 7 includes an ENUM-DNS database containing information to find FQDN (FQDN=Fully Qualified Domain Name) of foreign I-CSCFs (i.e. I-CSCFs of other operators/networks). Instead of the database 6 other means may be used to help translating E.164 to corresponding routing address”. [0109], “The database 23 is provided for network 10 and includes the own IMS E.164 identities as well as the FQDNs of the own MGCFs, e.g. MGCF 16, and foreign BGCFs, e.g. BGCF 9. This database 23 is used by BGCF 11 of the network 10, for finding IMS identities or FQDNs used for routing to parties/terminals/networks/NEs (Network Elements) being identified by the E.164 numbers, in the message and/or session request message of step 6a”. [0240], “The HSS 89 returns the FQDN, e.g., scscf12.ims.sonera.fi, of S-CSCF 90 where the B-subscriber is registered” (modifying FQDN for routing)).
In re claims 7 and 15, the combination discloses the method of claim 6 and the apparatus of claim 14, wherein Marappa discloses wherein the one or more core devices comprise a virtual network function (Fig. 1, [0011], “As yet another example, a third party may be what is referred to as a “mobile virtual network operator” or MVNO”. [0052], “The network device 300 may, as an example, comprise a physical or virtual computer server” (IMS core consists of various application servers including for third party and can operate as a virtual network function)).
In re claims 8 and 16, the combination discloses the method of claim 6 and the apparatus of claim 14, wherein Marappa discloses wherein the one or more core devices comprise a home subscriber server ([0021], “The IMS core 104 may have a Home Subscriber Server (HSS) 114, which is a database that stores a service profile for each subscriber. Among other things, a service profile specifies one or more Initial Filter Criteria (IFCs). Each IFC specifies a rule for handling requests received from the subscriber”)).
In re claim 18, the combination discloses the computer readable storage medium of claim 17, wherein Marappa discloses wherein the at least one RCS message comprises a plurality of RCS messages ([0022], “The carrier application servers 112 may include a Rich Communication Suite (RCS). RCS is a platform that supports various types of media communications, including one-to-one chat, group chat, file transfer, content sharing, voice calling, video calling, social presence, video calling, geolocation exchange, service identification, notifications, and others”. [0031], “Examples of services that may be provided by the carrier application servers 112 and/or the third-party application servers 116 include, without limitation”. [0032], “instant messaging”. [0033], “voice”. [0034], “video”. [0035], “audio”. [0036], “presence”. [0037], “streaming”. [0038], “charging”. [0039], “conferencing” ... [0042], “push-to-talk voice” ... [0044], “earthquake and tsunami warning” (messages can be a plurality of RCS messages such as push notification of a Tsunami warning, conferencing to multiple users, voice and video streaming etc.)).
Claim(s) 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US 20180295157 A1 (Marappa) in view of US 20210281614 Al (Ahmad et al.) (hereinafter Ahmad) in view of US 20210219131 A1 (BYADGI et al.) (hereinafter BYADGI) and in further view of US 20050286531 A1 (Tuohino et al.) (hereinafter Tuohino) and in further view of US 20130013796 A1 (Kim et al.) (hereinafter Kim).
In re claim 19, the combination discloses the computer readable storage medium of claim 17, wherein Tuohino discloses wherein the routing is facilitated via a core device, and wherein when the triggering indicates that the first device is being registered to use the dual registration, the core device modifies an application server index to a fully qualified domain name (Fig. 4, [0081], “The local ENUM-DNS database 6 may include also IMS E.164 identities of the trusted operators. This part of the database may contain delegations to appropriate ENUM-DNS databases of respective operators following standard DNS principles. The database 7 includes an ENUM-DNS database containing information to find FQDN (FQDN=Fully Qualified Domain Name) of foreign I-CSCFs (i.e., FQDN of other operators/networks is searched for dual registration)”. [0106], “The embodiment of FIG. 4 provides three databases 21, 22, 23, for checking and finding IMS identities and FQDNs” (provided in the application server index). [0109], “This database 23 is used by BGCF 11 of the network 10, for finding IMS identities or FQDNs used for routing to parties/terminals/networks/NEs (Network Elements) being identified by the E.164 numbers, in the message and/or session request message of step 6a”. [0240], “The HSS 89 returns the FQDN, e.g., scscf12.ims.sonera.fi, of S-CSCF 90 where the B-subscriber is registered” (using FQDN for dual registration). [0297], “In the latter case if the subscriber has dual subscription (i.e., both IMS and non-IMS e.g., CS) and a dual terminal, those IMS messages and/or message sets and/or sessions can be routed through non-IMS e.g., CS network where the media and/or QoS and/or other requirements can be fulfilled with the capabilities offered by the non-IMS e.g., CS network”).
Marappa, Ahmad, BYADGI and Tuohino do not explicitly disclose modifying an application server index.
Kim discloses modifying an application server index (Fig. 2, [0050], “the setting is performed at the time of registration, whereby the tokens communicated in the SIP REGISTRATION message are passed to the application server 28 via a third party registration and subscription... in order to determine the capabilities of the devices and their corresponding addresses, e.g., GRUUs, SIP URIs, SIPS URI or Telephone Numbers (TEL URIs). The server is then able to route the invitation or communication message based upon the media types in the invitation to the devices that indicated support for those media types/capabilities in the registration event package”. [0047], “When an incoming Invitation or communication message arrives at the application server 28, the server compares the media types identified in the invitation or communication message and routes the Invitation communication message to the addresses, e.g., the GRUU, SIP URIs, SIPS URI or Telephone Numbers (TEL URIs) that correspond to the media type or types listed in a User Preference mapping...The user preferences are indexed together with media types in the listing 112, and the user preferences are indexed together with device capabilities in the listing 114” (modifying application server index)).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Marappa, Ahmad, BYADGI and Tuohino with Kim to provide a method for setting preferences for the routing of RCS messages wherein the address information is obtained through the application server index to identify single or dual registration. The advantage of differentiating such secondary subscriptions and routing traffic accordingly can help improve network latency, load balancing and meet the necessity of everyday life.
In re claim 20, the combination discloses the computer readable storage medium of claim 19, wherein Kim discloses wherein when the triggering indicates that the first device is being registered to use the single registration the core device modifies the application server index to a presence application server ([0053], “Here, when the UE registers in the SIP REGISTER, a P-Network-Access-Info header is provided. This information is communicated to the application server 28 so that the application server can adapt its routing tables. Alternately, the application server subscribes to a presence function or a domain selection function to determine the RAT in which the UE is registered”).
Contact
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SWATI JAIN whose telephone number is (571)270-0699. The examiner can normally be reached Mon - Fri (830 am - 530 pm).
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, Pan Yuwen can be reached on 5712727855. 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.
/SWATI JAIN/Examiner, Art Unit 2649
Prosecution Insights