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 .
This action is responsive to communication filed on 5/18/2026.
Claims 1-12 are subject to examination.
Applicant’s arguments have been fully considered and entered by the Examiner.
Claim Rejections - 35 USC § 103
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-12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sekharan et al. U.S. Patent Publication # 2018/0063252 (hereinafter Sekharan) in view of Venkatraman et al. U.S. Patent Publication # 2017/0357529 (hereinafter Venkatraman)
With respect to claim 1, Sekharan teaches a method of operating a service instance set node for a service of a communication network, the method comprising:
receiving an operation request for the service (i.e. receiving a HTTPS request that includes the session identifier and the service instance identifier)(Paragraph 26-27) from a service controller, wherein the request includes a context identifier (i.e. receiving a session identifier and service instance identifier) (Paragraph 27, 26).
responsive to receiving the operation request including the context identifier (i.e. session identifier) , transmitting a context data request to a service storage resource node (i.e. sessions storage), wherein the context data request includes the context identifier (i.e. session identifier)(Paragraph 37-38);
-after transmitting the context data request, receiving a context data response from the service storage resource node (i.e. collaboration sessions storage)(Fig.1 element 140) (i.e. retrieving from collaboration session storage the session identifier and the service instance identifier associated with the collaboration session based on the collaboration session identifier) (Paragraph 39-40), wherein the context data response includes context data corresponding to the context identifier (i.e. response includes session identifier and the service instance identifier associated with the collaboration session) (Paragraph 49-50) and
-transmitting an operation response to the service controller based on the operation request and based on the context data (i.e. service instance sends a response to the web browser application via load balancer that includes session identifier and the service instance identifier which when load balancer receives it, it forwards it to the web browser application (Paragraph 47, 49-50).
Although Sekharan teaches retrieving from the collaboration session storage the session identifier, Sekharan does not explicitly teach receiving a context data response from the service storage resource node.
Venkatraman teaches receiving a context data response (i.e. in response to receiving a context query) from the service storage resource node (i.e. local context database or remote context database) wherein the context data response includes context data corresponding to the context identifier (i.e. after context data is obtained, the context store can send the context information which includes device ID attribute-value mappings)(Paragraph 39)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement Venkatraman’s teaching in Sekharan’s teaching to come up with receiving a context data response from the service storage resource node. The motivation for doing so would be so the context client can use the context information to provide services and/or information to the user (paragraph 39).
With respect to claim 2, Sekharan and Venkatraman teaches the method of claim 1, but Sekharan further teaches further comprising: responsive to receiving the operation request including the context identifier, determining that the context data is not available locally at the service instance set (Paragraph 37); wherein transmitting the context data request comprises transmitting the context data request responsive to receiving the operation request and responsive to determining that the context data is not available locally at the service instance set (Paragraph 37-38).
With respect to claim 3, Sekharan and Venkatraman teaches the method of claim 1, but Sekharan further teaches further comprising: after receiving the context data response including the context data, modifying the context data based on the operation request to provide updated context data corresponding to the context identifier (i.e. request to update information) (Paragraph 38-40); transmitting the updated context data to the service storage resource node (Paragraph 39-40); receiving an updated context response from the service storage resource node, wherein the updated context response corresponds to the updated context data (Paragraph 37-40); wherein transmitting the operation response includes transmitting the updated context data responsive to receiving the updated context response (Paragraph 40)
With respect to claim 4, Sekharan and Venkatraman teaches the method of claim 1, but Sekharan further teaches wherein receiving the operation request from the service controller comprises receiving the operation request from the service controller through an access node (i.e. load balancer) (Paragraph 38-39), and wherein transmitting the operation response to the service control node comprises transmitting the operation response to the service controller through the access node (Paragraph 37-40)
With respect to claim 5, Sekharan and Venkatraman teaches the method of claim 1, but Sekharan further teaches wherein the context identifier is one of a plurality of context identifiers that correspond to the context data (Paragraph 50, 69)
With respect to claim 6, Sekharan teaches method of operating a service storage resource (SSR), the method comprising:
-receiving context data from a first service instance set (i.e. each service instance can handle requests from application to start collaboration session wherein a request includes collaboration session name, ID associated etc. and generated session identifier associated with the service)(Paragraph 36), wherein the first service instance set comprises a first plurality of instances of a service (Fig. 1 element service instance a-k) (Paragraph 35-36);
-receiving a context data request from a second service instance set, wherein the second service instance set comprises a second plurality of instances of the service (i.e. establishing through bidirectional communication session second data for the collaboration session from the service instance)(Paragraph 72, 10-12); and
transmitting a context data response to the second service instance set responsive to receiving the context data request, wherein the context data response includes at least a portion of the context data (i.e. service instance sends a response to the web browser application via load balancer that includes session identifier and the service instance identifier which when load balancer receives it, it forwards it to the web browser application) (Paragraph 10-12, 47, 49-50).
Although Sekharan teaches retrieving from the collaboration session storage the session identifier, Sekharan does not explicitly teach transmitting a context data response.
Venkatraman teaches transmitting context data response (i.e. in response to receiving a context query) to the second service instance set (i.e. local context database or remote context database) responsive to receiving the context data set request, wherein the context data response includes at least a portion of context data (i.e. after context data is obtained, the context store can send the context information which includes device ID attribute-value mappings)(Paragraph 39)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement Venkatraman’s teaching in Sekharan’s teaching to come up with transmitting a context data response from the service storage resource node. The motivation for doing so would be so the context client can use the context information to provide services and/or information to the user (paragraph 39).
With respect to claim 7, Sekharan and Venkatraman teaches the method of claim 6, but Sekharan further teaches wherein receiving the context data comprises receiving the context data with a context identifier, wherein the context data request includes the context identifier, and wherein the context data response includes the context identifier. (i.e. response includes session identifier and the service instance identifier associated with the collaboration session) (Paragraph 49-50) and
With respect to claim 8, Sekharan and Venkatraman teaches the method of claim 6, but Sekharan further teaches wherein the context data comprises original context data and wherein the context identifier is a first context identifier, the method further comprising: receiving an update context request from the second service instance set after transmitting the context data response (i.e. request to update information) (Paragraph 38-40) updating the original context data responsive to receiving the update context request to provide updated context data (Paragraph 38-40) and transmitting an update context response to the second service instance set responsive to receiving the update context request (Paragraph 38-40)
With respect to claim 9, Sekharan and Venkatraman teaches the method of claim 6, but Sekharan further teaches wherein the context identifier is a first context identifier and wherein the update context request includes a second context identifier different than the first context identifier (i.e. session identifier and service instance identifier)(Paragraph 27)
With respect to claim 10, Sekharan and Venkatraman teaches the method of claim 6, but Sekharan further teaches wherein the first service instance set comprises a first plurality of instances of the service (Fig. 1 element 135a) , and wherein the second service instance set (Fig. 1 element 135b) comprises a second plurality of instances of the service (Fig. 1 element 135 a-k) (Paragraph 35-36)
With respect to claim 11, it teaches same limitation as claim 1, therefore rejected under same basis.
With respect to claim 12, it teaches same limitation as claim 6, therefore rejected under same basis.
Response to Arguments
Applicant's arguments filed 5/18/2016 have been fully considered but they are not persuasive.
A). Applicant states Sekharan does not teach “receiving an operation request for the service from a service controller”.
With respect to remark A, Examiner respectfully disagrees with the applicant because Sekharan teaches in Paragraphs 26-27, Sekharan teaches receiving an operation request for the service (i.e. receiving a HTTPS request that includes the session identifier and the service instance identifier)(Paragraph 26-27) from a service controller, wherein the request includes a context identifier (i.e. receiving a session identifier and service instance identifier) (Paragraph 27, 26).
First, Examiner would like to point out that the claim language does not define service controller. Based on the specification of the current application, in Paragraph 39, it state service controller is a node or control service node which can be a node, server, entity, function etc.
Therefore, in Paragraph 26-27, Sekharan teaches client device is the service controller wherein, the client device (i.e. service controller) sends a collaboration request to start a collaboration session (i.e. operation request for the service) with one or more users of the other client devices. The HTTP/HTTPS request includes the session identifier and the service instance identifier (i.e. request includes a context identifier).
Sekharan also teaches after transmitting the context data request, receiving a context data response from the service storage resource node (i.e. collaboration sessions storage)(Fig.1 element 140) (i.e. retrieving from collaboration session storage the session identifier and the service instance identifier associated with the collaboration session based on the collaboration session identifier) (Paragraph 39-40), wherein the context data response includes context data corresponding to the context identifier (i.e. response includes session identifier and the service instance identifier associated with the collaboration session) (Paragraph 49-50). Examiner would like to point out that service storage resource node of the claim language is functionally equivalent to Sekharan’s collaboration session storage. Therefore, Sekharan teaches the claimed limitations.
Although Sekharan teaches retrieving from the collaboration session storage the session identifier, Sekharan does not explicitly teach receiving a context data response from the service storage resource node.
Venkatraman teaches receiving a context data response (i.e. in response to receiving a context query) from the service storage resource node (i.e. local context database or remote context database) wherein the context data response includes context data corresponding to the context identifier (i.e. after context data is obtained, the context store can send the context information which includes device ID attribute-value mappings)(Paragraph 39).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement Venkatraman’s teaching in Sekharan’s teaching to come up with receiving a context data response from the service storage resource node. The motivation for doing so would be so the context client can use the context information to provide services and/or information to the user (paragraph 39).
B). Applicant states combination of Sekharan and Venkatraman does not make sense in the context of Sekharan’s system and techniques and that motivation to combine the references makes no sense.
First, Examiner would like to point out that claim language does not define or provide an explicitly definition of “context data”. Hence, using the specification of the current application and broadest reasonable interpretation, context data of Venkatraman is functionally equivalent to context data of the claim language. If applicant wants to provide particular definition of the context data, Examiner suggests to amend the claim language to recite such definition.
Furthermore, in response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement Venkatraman’s teaching in Sekharan’s teaching to come up with receiving a context data response from the service storage resource node. The motivation for doing so would be so the context client can use the context information to provide services and/or information to the user (paragraph 39).
C). Applicant states Sekharan does not teach both “a first and second service instance set, each one comprising a plurality of instance of the service”.
With respect to remark C, First, Examiner would like to point out that Sekharan clearly teaches plurality of instances of the service, in Paragraph 11, Sekharan clearly teaches having first service instance and second service instance in the plurality of service instances.
Furthermore, Examiner respectfully disagrees with the applicant because in Paragraphs 35-36, Sekharan teaches receiving context data from a first service instance set (i.e. each service instance can handle requests from application to start collaboration session wherein a request includes collaboration session name, ID associated etc. and generated session identifier associated with the service)(Paragraph 36), wherein the first service instance set comprises a first plurality of instances of a service (Fig. 1 element service instance a-k) (Paragraph 35-36);
In Paragraphs 72, 10-12, Sekharan teaches receiving a context data request from a second service instance set, wherein the second service instance set comprises a second plurality of instances of the service (i.e. establishing through bidirectional communication session second data for the collaboration session from the service instance)(Paragraph 72, 10-12). Furthermore, in Paragraph 11, Sekharan clearly teaches having first service instance and second service instance in the plurality of service instances.
In Paragraphs 10-12, 47, 49-50, Sekharan teaches transmitting a context data response to the second service instance set responsive to receiving the context data request, wherein the context data response includes at least a portion of the context data (i.e. service instance sends a response to the web browser application via load balancer that includes session identifier and the service instance identifier which when load balancer receives it, it forwards it to the web browser application) (Paragraph 10-12, 47, 49-50).
Although Sekharan teaches retrieving from the collaboration session storage the session identifier, Sekharan does not explicitly teach transmitting a context data response.
Venkatraman teaches transmitting context data response (i.e. in response to receiving a context query) to the second service instance set (i.e. local context database or remote context database) responsive to receiving the context data set request, wherein the context data response includes at least a portion of context data (i.e. after context data is obtained, the context store can send the context information which includes device ID attribute-value mappings)(Paragraph 39)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement Venkatraman’s teaching in Sekharan’s teaching to come up with transmitting a context data response from the service storage resource node. The motivation for doing so would be so the context client can use the context information to provide services and/or information to the user (paragraph 39).
Furthermore, in response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement Venkatraman’s teaching in Sekharan’s teaching to come up with transmitting a context data response from the service storage resource node. The motivation for doing so would be so the context client can use the context information to provide services and/or information to the user (paragraph 39).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
A). Dao et al. U.S. Patent Publication # 2019/0261260 which teaches about UE context and PDU session context management for the UE which can be mitigated.
B). Kuchibhotla et al. U.S. Patent Publication # 2018/0084081 which teaches about cloud operation reservation system for defining a set of time windows that are available to perform one or more cloud operations on cloud targets.
C). Zwisler et al. U.S. Patent Publication # 2010/0153613
D). Trossen et al. U.S. Patent Publication # 2021/0211510
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 DHAIRYA A PATEL whose telephone number is (571)272-5809. The examiner can normally be reached M-F 7:30am-4:00pm.
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, Kamal B Divecha can be reached at 571-272-5863. 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.
DHAIRYA A. PATEL
Primary Examiner
Art Unit 2453
/DHAIRYA A PATEL/ Primary Examiner, Art Unit 2453
Prosecution Insights