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 .
Priority
Examiner acknowledges the following data:
Applicant has no priority data on file.
Status of the Application
This Non-final office action is in response to Applicant’s amendment received by the Office on 14 December 2023. Claims 1-40 have been presented in the application, of which, claims 21-40 are cancelled and claims 1-20 are original. Accordingly, pending claims 1-20 are addressed herein.
Information Disclosure statements
The information disclosure statements (IDS) were submitted and filed on 12/14/2023. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Claim Interpretations - 35 USC § 112(f)
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
Claim limitations “communications hardware” (claims 16-19) have been interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because it uses/they use a generic placeholder “configured to” coupled with functional language “receive a service entity request” (claims 16-19) without reciting sufficient structure to achieve the function. Furthermore, the generic placeholder is not preceded by a structural modifier.
Since the claim limitations invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, claims 16-19 have been interpreted to cover the corresponding structure described in the specification that achieves the claimed function, and equivalents thereof.
A review of the specification shows that the following appears to be the corresponding structure described in the specification, referenced by the PGPUB, for the 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph limitation:
• “communications hardware” – Specification [56] – it appears that the corresponding structure is a device or circuitry.
If applicant wishes to provide further explanation or dispute the examiner’s interpretation of the corresponding structure, applicant must identify the corresponding structure with reference to the specification by page and line number, and to the drawing, if any, by reference characters in response to this Office action.
If applicant does not intend to have the claim limitation(s) treated under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112 , sixth paragraph, applicant may amend the claim(s) so that it/they will clearly not invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, or present a sufficient showing that the claim recites/recite sufficient structure, material, or acts for performing the claimed function to preclude application of 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
For more information, see MPEP § 2173 et seq. and Supplementary Examination Guidelines for Determining Compliance With 35 U.S.C. 112 and for Treatment of Related Issues in Patent Applications, 76 FR 7162, 7167 (Feb. 9, 2011).
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.
Claims 1-8 and 10-20 are rejected under 35 U.S.C. 103 as being unpatentable over Ng et al (US 2021/0035055) in view of Khullar et al (US 2024/0095239).
Regarding claim 1, Ng et al discloses method for facilitating operations for a user with a service entity, the method comprising (entity may provide temporary access to POS functionality to enable users to utilize their personal user devices to facilitate transactions between customers and the entity, [0020], lines 3-4):
receiving, by communications hardware (fig. 1A item 104, Entity device), a service entity request pertaining to the user within a proximity interaction region (entity device 104 may determine a presence of user device(s) 108 based on the user device(s) 108 expressly indicating presence at the location of the entity 106 (e.g., via check-in(s), request(s) for access to functionality associated with an service entity, etc., [0027], 9-11), wherein the service entity request comprises (a) an indication of a service entity identity that corresponds to a service entity of interest to the user ((e.g., via check-in(s), request(s) for access to functionality ((a) indication of a service entity identity) associated with an entity, etc.), [0027], 9-11), (b) a user identifier for the user ((e.g., via check-in(s) ((b) a user identifier for the user), request(s) for access to functionality associated with an entity, etc.), [0027], 9-11), and (c) a user credential ((e.g., via check-in(s) ((c) a user credential), request(s) for access to functionality associated with an entity, etc.), [0027], 9-11);
determining, by operations management circuitry, a service entity configuration set for the service entity, wherein the service entity configuration set is indicative of a service entity device that is associated with the service entity (Entity 106 may initiate a settling-up (configuration set) process to provide payment to the user 110A. Additionally, in some examples, the entity 106 may rate the user 110A based on his or her performance, efficiency, accuracy, etc, [0038], lines 3-5);
initiating, by communications hardware (fig. 1A item 104, Entity device), a session with the service entity device using a session establishment request, wherein the session establishment request comprises the user identifier and the user credential (Based at least in part on receiving input indicating that the entity 106 desires (request) to temporarily provide access to the service functionality to user device 108A (corresponding to user 110A), the entity device 104 may provide access data 116 to the user device 108A. In some examples, the access data 116 may be associated with a password, code, key, or other unique identifier associated with the entity 106, [0029], lines 1-4);
receiving, by the communications hardware (fig. 1A item 104, Entity device), a session establishment response from the service entity device, wherein in an instance in which the service entity device successfully authenticated the user, the service establishment response comprises (a) a session token and (b) user account data pertaining to a user account managed by the service entity and that corresponds to the user (The entity device 104 may provide (response) access data 116 to the user device 108A. In some examples, the access data 116 may be associated with a password, code ((b) user account data), key ((a) a session token), or other unique identifier associated with the entity 106, [0029], lines 2-4);
generating, by interface circuitry and based on the service entity configuration set and the user account data, service entity user interface data (Password, code, key, or other unique identifier may be input via a web interface to enable the user device 108A to temporarily access the inventory management application via the web interface, [0029], lines 7-9); and
Ng et al does not specifically disclose concept of providing, by the communications hardware, the service entity user interface data.
However, Khullar et al specifically teaches concept of providing, by the communications hardware, the service entity user interface data (At S210, a framework may provide a user with a graphical view of existing services (and entity and field-level mapping) across multiple layers and the User Interface (“UI”) with an example data model, [0039], lines 1-3).
At the time the invention was filed, it would have been obvious for one of ordinary skill in the art to have modified system of Ng et al with concept of providing, by the communications hardware, the service entity user interface data of Khullar et al. One of ordinary skill in the art would have been motivated to make this modification in order to improve application to perform business function, (Khullar et al, [0001], line 1)
Regarding claim 2, Ng et al discloses method, further comprising (FIG. 3 depicts a non-limiting flow diagram illustrating a method, [0009], line 1);
receiving, by the communications hardware (fig. 1A item 104, Entity device), an operation request pertaining to the user, wherein the operation request comprises a service request type and one or more service request parameters (entity device 104 may determine a presence of user device(s) 108 based on the user device(s) 108 expressly indicating presence at the location of the entity 106 (e.g., via check-in(s), request(s) for access to functionality associated with an entity, etc., [0027], 9-11);
generating, by the operations management circuitry, a service entity operation request, wherein service entity operation request comprises (a) the session token and (b) the service request type and the one or more service request parameters ((e.g., via check-in(s), request(s) for access to functionality ((a) indication of a service entity identity) associated with an entity, etc.), [0027], 9-11); and
providing, by the communications hardware (fig. 1A item 104, Entity device), the service entity operation request to the service entity device (Based at least in part on receiving input indicating that the entity 106 desires (request) to temporarily provide access to the service functionality to user device 108A (corresponding to user 110A), the entity device 104 may provide access data 116 to the user device 108A. In some examples, the access data 116 may be associated with a password, code, key, or other unique identifier associated with the entity 106, [0029], lines 1-4).
Regarding claim 3, Ng et al discloses method, further comprising (FIG. 3 depicts a non-limiting flow diagram illustrating a method, [0009], line 1):
receiving, by the communications hardware (fig. 1A item 104, Entity device), a service entity operation response from the service entity device, wherein (a) the service entity operation response is indicative that an operational flow corresponding to the service request type was successfully performed and (b) the service entity operation response comprises updated user account data (Based at least in part on receiving input indicating that the entity 106 desires (request) to temporarily provide access to the service functionality to user device 108A (corresponding to user 110A), the entity device 104 may provide access data 116 to the user device 108A. In some examples, the access data 116 may be associated with a password, code, key, or other unique identifier associated with the entity 106, [0029], lines 1-4);
generating, by the interface circuitry and based on the service entity configuration set and the service entity operation response, updated service entity user interface data; and providing, by the communications hardware (fig. 1A item 104, Entity device), the updated service entity user interface data (Password, code, key, or other unique identifier may be input via a web interface to enable the user device 108A to temporarily access the inventory management application via the web interface, [0029], lines 7-9).
Regarding claim 4, Ng et al discloses method, further comprising (FIG. 3 depicts a non-limiting flow diagram illustrating a method, [0009], line 1):
receiving, by the communications hardware (fig. 1A item 104, Entity device), a service entity instruction message from the service entity device, wherein the service entity instruction message comprises instructions to perform an interaction with the user (Based at least in part on receiving input indicating that the entity 106 desires (request) to temporarily provide access to the service functionality to user device 108A (corresponding to user 110A), the entity device 104 may provide access data 116 to the user device 108A. In some examples, the access data 116 may be associated with a password, code, key, or other unique identifier associated with the entity 106, [0029], lines 1-4); and
providing, by the communications hardware (fig. 1A item 104, Entity device), an instruction message to an agent device, wherein the instruction message comprises instructions to perform the interaction with the user (user interface 114 may graphically represent each of the user devices 108 present at the physical store of the entity 106. The entity 106 (or an agent acting on behalf of the entity 106) may interact with the user interface 114 to select one or more users 110 for provisioning temporary access to the service functionality, [0028], lines 4-7).
Regarding claim 5, Ng et al discloses method (FIG. 3 depicts a non-limiting flow diagram illustrating a method, [0009], line 1), wherein the interaction with the user comprises at least one of (a) providing the user with a currency amount, (b) receiving a currency amount from the user, (c) providing the user with a document corresponding to a document type, or (d) receiving a document corresponding to a document type from the user (entity profile 222 may store data associated with an entity 106 including, but not limited to, data including information about the entity 106 (e.g., name of the entity, geographic location of the entity, types of goods or services offered by the entity, operating hours of the entity, an entity identifier, an entity category classification, etc.), information about events associated with the entity 106 (e.g., past and upcoming events, dates of events, locations of events, etc.), accounting information associated with the entity 106 (e.g., bank(s) that the entity banks with, etc.), contractual information associated with the entity 106 (e.g., terms of a contract between the entity and the payment service provider), [0061], lines 1-6).
Regarding claim 6, Ng et al discloses method, further comprising (FIG. 3 depicts a non-limiting flow diagram illustrating a method, [0009], line 1):
receiving, by the communications hardware (fig. 1A item 104, Entity device), an escalation request from the user, wherein the escalation request comprises a request to connect to a representative associated with the service entity (The system enables user devices to interact with the service functionality; users may request additional help or support via the application. While the main focus is inventory/POS, the UI and system modules allow for user-initiated requests, including escalation for assistance, [0030], lines 1-9, [0049], lines 1-14);
providing, by the communications hardware (fig. 1A item 104, Entity device), a live user session request to the service entity device, wherein the live user session requests comprises the session token and a request to connect the user to an available representative (The system transmits user requests and session information between user devices, entity devices, and service provider servers. When a user needs further support, the system can send a request (with session context) to the service entity device. The system is capable of transmitting a user’s escalation request, along with session information (e.g., access credential/session token), to the service entity device to facilitate further support, [0031], lines 1-4, [0033], lines 1-13, [0047], lines 1-4, [0049], lines 1-14 and [0058], lines 1-5);
receiving, by the communications hardware (fig. 1A item 104, Entity device), a live user session response from the service entity device, wherein the live user session response comprises a session link to establish a live session between the user and a representative (The system enables two-way communication between user devices and service provider systems, including the ability to receive instructions, data, or links for further actions (such as joining a live session or support chat). The system can receive, via communications hardware, a response from the service entity device containing a link or instructions to establish a live session with a representative, [0040], lines 1-5, [0058], lines 1-5 and [0074], lines 1-8); and
providing, by the communications hardware (fig. 1A item 104, Entity device), the live user session response (The response (e.g., session link or instructions) is provided to the user device for action (e.g., joining a live support session). The system provides the session response (e.g., a live session link) to the user, enabling the connection to a representative., [0040], lines 1-5, [0058], lines 1-5 and [0074], lines 1-8).
Regarding claim 7, Ng et al discloses method, further comprising (FIG. 3 depicts a non-limiting flow diagram illustrating a method, [0009], line 1):
determining, by the operations management circuitry, a session termination event (The system monitors for events such as expiration of a time interval, the user device leaving a geo-fence, or completion of a task/activity—all of which trigger session termination. (“The event may correspond to the expiration of a time period, a determination that the user device … is outside of a particular geo-fence, a determination that the user device engaged in particular user activity, etc.”, [0030]; thus is seen as the entity device (operations management) detects when a session should end, based on predefined events (time, location, activity). [0039], lines 1-6, [0050], lines 1-10, [0087], lines 1-12);
in response to determining the session termination event, terminating, by the communications hardware (fig. 1A item 104, Entity device), the session with the service entity device Upon detecting the event, the system sends instructions to terminate access/session. (“…the access provisioning module 214 may terminate the access to the service functionality. In such examples, the access provisioning module 214 may send instructions to the user device… to terminate future access…”); Thus is seen as the system (via communications hardware) terminates the session with the user device and/or service entity device when the event occurs, [0030], lines 1-9, [0039], lines 1-6, [0088], lines 1-4); and
clearing, by the operations management circuitry, the session token from an associated memory (After termination, access credentials or tokens are invalidated and access is revoked. (“…terminate the user device’s access to the service functionality.”) While the term “session token” is not always explicit, the access data (password, code, key) serves this function and is revoked/invalidated; thus is seen as upon session termination, the system clears or invalidates the session credentials (token) from memory, ensuring no further access, 0039], lines 1-6, [0088], lines 1-4).
Regarding claim 8, Ng et al discloses method, further comprising (FIG. 3 depicts a non-limiting flow diagram illustrating a method, [0009], line 1):
determining, by operations management circuitry, a user inquiry from the user (entity device 104 may determine a presence of user device(s) 108 based on the user device(s) 108 expressly indicating presence at the location of the entity 106 (e.g., via check-in(s), request(s) for access to functionality associated with an entity, etc., [0027], 9-11);
generating, by the operations management circuitry and based on the service entity configuration set, an agent script, wherein the agent script comprises dialogue for an agent to answer the user inquiry (user interface 114 may graphically represent each of the user devices 108 present at the physical store of the entity 106. The entity 106 (or an agent acting on behalf of the entity 106) may interact with the user interface 114 to select one or more users 110 for provisioning temporary access to the service functionality, [0028], lines 4-7); and
providing, by the communications hardware (fig. 1A item 104, Entity device), the agent script to an agent device (customer may acquire an item by purchasing the item, renting the item, leasing the item, etc. In at least one example, the entity 106 may be associated with one or more agents, such as sales associates, employees, independent contractors, etc., which may interact with entity device 104 on behalf of the entity, [0044], lines 2-4).
Regarding claim 10, Ng et al discloses method, further comprising (FIG. 3 depicts a non-limiting flow diagram illustrating a method, [0009], line 1):
generating, by the operations management circuitry and based on the service entity configuration set, a virtual agent script, wherein the virtual agent script comprises dialogue to interact with the user (user interface 114 may graphically represent each of the user devices 108 present at the physical store of the entity 106. The entity 106 (or an agent acting on behalf of the entity 106) may interact with the user interface 114 to select one or more users 110 for provisioning temporary access to the service functionality, [0028], lines 4-7); and
providing, by the communications hardware (fig. 1A item 104, Entity device), the virtual agent script (customer may acquire an item by purchasing the item, renting the item, leasing the item, etc. In at least one example, the entity 106 may be associated with one or more agents, such as sales associates, employees, independent contractors, etc., which may interact with entity device 104 on behalf of the entity, [0044], lines 2-4).
Regarding claim 11, Ng et al discloses method, further comprising encrypting, by cryptographic circuitry and based on the service entity configuration set, the session establishment request using a cryptographic key associated with the service entity device (Based at least in part on receiving input indicating that the entity 106 desires (request) to temporarily provide access to the service functionality to user device 108A (corresponding to user 110A), the entity device 104 may provide access data 116 to the user device 108A. In some examples, the access data 116 may be associated with a password, code, key, or other unique identifier associated with the entity 106, [0029], lines 1-4).
Regarding claim 12, Ng et al discloses method (FIG. 3 depicts a non-limiting flow diagram illustrating a method, [0009], line 1), further comprising decrypting, by cryptographic circuitry and based on the service entity configuration set, the session establishment response using a cryptographic key (Based at least in part on receiving input indicating that the entity 106 desires (request) to temporarily provide access to the service functionality to user device 108A (corresponding to user 110A), the entity device 104 may provide access data 116 to the user device 108A. In some examples, the access data 116 may be associated with a password, code, key, or other unique identifier associated with the entity 106, [0029], lines 1-4).
Regarding claim 13, Ng et al discloses method, further comprising (FIG. 3 depicts a non-limiting flow diagram illustrating a method, [0009], line 1):
receiving, by communications hardware (fig. 1A item 104, Entity device), a second service entity request pertaining to the user, wherein the second service entity request comprises (a) an indication of a service entity identity that corresponds to a second service entity of interest to the user, (b) a second user identifier for the user, and (c) a second user credential ((e.g., via check-in(s), request(s) for access to functionality ((a) indication of a service entity identity) associated with an entity, etc.), [0027], 9-11);
determining, by operations management circuitry (processing unit(s) 206 may include a central processing unit (CPU), [0045], line 4),
a service entity configuration set for the second service entity, wherein the second service entity configuration set is indicative of a second service entity device that is associated with the second service entity (The entity device 104 may provide (response) access data 116 to the user device 108A. In some examples, the access data 116 may be associated with a password, code ((b) user account data), key ((a) a session token), or other unique identifier associated with the entity 106, [0029], lines 2-4);
Preliminary Amendment initiating, by communications hardware (fig. 1A item 104, Entity device), a session with the second service entity device using a second session establishment request, wherein the second session establishment request comprises the second user identifier and the second user credential (Based at least in part on receiving input indicating that the entity 106 desires (request) to temporarily provide access to the service functionality to user device 108A (corresponding to user 110A), the entity device 104 may provide access data 116 to the user device 108A. In some examples, the access data 116 may be associated with a password, code, key, or other unique identifier associated with the entity 106, [0029], lines 1-4).;
receiving, by the communications hardware (fig. 1A item 104, Entity device), a second session establishment response from the second service entity, wherein in an instance in which the second service entity device successfully authenticated the user, the second service establishment response comprises (a) a second session token and (b) second user account data pertaining to a user account for the user managed by the second service entity (access provisioning module 214 may send data associated with a password, code, key, or other unique identifier associated with the entity 106 to a user device 108A. In at least one example, the user device 108A may store an inventory management application, which is associated with the service functionality. The password, code, key, or other unique identifier may be provided to the inventory management application stored on the user device 108A, and may accordingly enable access to service functionality for the entity 106, [0048], lines 1-5);
generating, by interface circuitry and based on the second service entity configuration set and the user account data, second service entity user interface data (Password, code, key, or other unique identifier may be input via a web interface to enable the user device 108A to temporarily access the inventory management application via the web interface, [0029], lines 7-9); and
providing, by the communications hardware (fig. 1A item 104, Entity device), the second service entity user interface data (customer may acquire an item by purchasing the item, renting the item, leasing the item, etc. In at least one example, the entity 106 may be associated with one or more agents, such as sales associates, employees, independent contractors, etc., which may interact with entity device 104 on behalf of the entity, [0044], lines 2-4).
Regarding claim 14, Ng et al discloses method, further comprising (FIG. 3 depicts a non-limiting flow diagram illustrating a method, [0009], line 1):
in response to receiving the second service entity request, determining, by the operations management circuitry, a session termination event ((e.g., via check-in(s), request(s) for access to functionality ((a) indication of a service entity identity) associated with an entity, etc.), [0027], 9-11);
in response to determining the session termination event, terminating, by the communications hardware (fig. 1A item 104, Entity device), the session with the service entity device (item may be a good or a service. A customer may acquire an item by purchasing the item, renting the item, leasing the item, etc. In at least one example, the entity 106 may be associated with one or more agents, such as sales associates, employees, independent contractors, etc., which may interact with entity device 104 on behalf of the entity. The entity (i.e., an agent of the entity) may interact with the entity device 104 to process transactions and/or manage other aspects of the entity's business via tools available by the payment processing service 138, [0044], lines 2-6); and
clearing, by the operations management circuitry, the session token from an associated memory (at least one example, the access data 116 may be associated with data indicating a user activity level, the achievement of which causes the termination of the temporary access to the service functionality, [0030], lines 5-7).
Regarding claim 15, Ng et al discloses method, further comprising (FIG. 3 depicts a non-limiting flow diagram illustrating a method, [0009], line 1):
receiving, by the communications hardware (fig. 1A item 104, Entity device), temporal population data (user devices may be devices that are personal to the user and are not owned and operated by the entity. In at least one example, a device operated by an entity may provide temporary access to the service functionality to a user device. The temporary access may be limited by location, time, user activity, etc, [0017], lines 6-8);
determining, by location determination circuitry based on the temporal population data, a location of interest; assigning, by the location determination circuitry, the location of interest as a future operation location (entity may provide temporary access to POS functionality to enable users to utilize their personal user devices to facilitate transactions between customers and the entity. Such temporary provisioning may be useful during the holiday season or for other special events. Additionally and/or alternatively, an entity may provide temporary access to information about the layout of a physical store to enable users to utilize their personal user devices to organize and/or arrange items in the physical store, [0020], lines 3-7); and
providing, by the communications hardware (fig. 1A item 104, Entity device), the future operation location and operating hours (access provisioning module 214 may send instructions to the user device 110 instructing the application associated with the service functionality to terminate future access to the service functionality, [0088], lines 3-4).
Regarding claim 16, Ng et al discloses apparatus for facilitating operations for a user with a service entity, the apparatus comprising (entity may provide temporary access to POS functionality to enable users to utilize their personal user devices to facilitate transactions between customers and the entity, [0020], lines 3-4):
communications hardware (fig. 1A item 104, Entity device) configured to:
receive a service entity request pertaining to the user within a proximity interaction region (entity device 104 may determine a presence of user device(s) 108 based on the user device(s) 108 expressly indicating presence at the location of the entity 106 (e.g., via check-in(s), request(s) for access to functionality (indication of a service entity identity) associated with an entity, etc., [0027], 9-11), wherein the service entity request comprises (a) an indication of a service entity identity that corresponds to a service entity of interest to the user ((e.g., via check-in(s), request(s) for access to functionality ((a) indication of a service entity identity) associated with an entity, etc.), [0027], 9-11), (b) a user identifier for the user ((e.g., via check-in(s) ((b) a user identifier for the user), request(s) for access to functionality associated with an entity, etc.), [0027], 9-11), and (c) a user credential ((e.g., via check-in(s) ((c) a user credential), request(s) for access to functionality associated with an entity, etc.), [0027], 9-11), and (c) a user credential ((e.g., via check-in(s) ((c) a user credential), request(s) for access to functionality associated with an entity, etc.), [0027], 9-11);
operations management circuitry configured to (processing unit(s) 206 may include a central processing unit (CPU), [0045], line 4):
determine a service entity configuration set for the service entity, wherein the service entity configuration set is indicative of a service entity device that is associated with the service entity (Entity 106 may initiate a settling-up (configuration set) process to provide payment to the user 110A. Additionally, in some examples, the entity 106 may rate the user 110A based on his or her performance, efficiency, accuracy, etc, [0038], lines 3-5);
wherein the communications hardware (fig. 1A item 104, Entity device) is further configured to:
initiate a session with the service entity device using a session establishment request, wherein the session establishment request comprises the user identifier and the user credential (Based at least in part on receiving input indicating that the entity 106 desires (request) to temporarily provide access to the service functionality to user device 108A (corresponding to user 110A), the entity device 104 may provide access data 116 to the user device 108A. In some examples, the access data 116 may be associated with a password, code, key, or other unique identifier associated with the entity 106, [0029], lines 1-4), and
receive a session establishment response from the service entity device, wherein in an instance in which the service entity device successfully authenticated the user, the service establishment response comprises (a) a session token and (b) user account data pertaining to a user account managed by the service entity and that corresponds to the user (The entity device 104 may provide (response) access data 116 to the user device 108A. In some examples, the access data 116 may be associated with a password, code ((b) user account data), key ((a) a session token), or other unique identifier associated with the entity 106, [0029], lines 2-4); and
interface circuitry configured to: generate, based on the service entity configuration set and the user account data, service entity user interface data (Password, code, key, or other unique identifier may be input via a web interface to enable the user device 108A to temporarily access the inventory management application via the web interface, [0029], lines 7-9); and
Ng et al does not specifically disclose concept of wherein the communications hardware is further configured to provide the service entity user interface data.
However, Khullar et al specifically teaches concept of wherein the communications hardware is further configured to provide the service entity user interface data (At S210, a framework may provide a user with a graphical view of existing services (and entity and field-level mapping) across multiple layers and the User Interface (“UI”) with an example data model, [0039], lines 1-3).
At the time the invention was filed, it would have been obvious for one of ordinary skill in the art to have modified system of Ng et al with concept of wherein the communications hardware is further configured to provide the service entity user interface data of Khullar et al. One of ordinary skill in the art would have been motivated to make this modification in order to improve application to perform business function, (Khullar et al, [0001], line 1).
Regarding claim 17, Ng et al discloses apparatus (fig. 1A item 104, Entity device), wherein the communications hardware (fig. 1A item 104, Entity device) is further configured to receive an operation request pertaining to the user, wherein the operation request comprises a service request type and one or more service request parameters ((e.g., via check-in(s), request(s) for access to functionality ((a) indication of a service entity identity) associated with an entity, etc.), [0027], 9-11);
wherein the operations management circuitry is further configured to generate a service entity operation request, wherein service entity operation request comprises (a) the session token and (b) the service request type and the one or more service request parameters ((e.g., via check-in(s), request(s) for access to functionality ((a) indication of a service entity identity) associated with an entity, etc.), [0027], 9-11); and
wherein the communications hardware (fig. 1A item 104, Entity device) is further configured to provide the service entity operation request to the service entity device (Based at least in part on receiving input indicating that the entity 106 desires (request) to temporarily provide access to the service functionality to user device 108A (corresponding to user 110A), the entity device 104 may provide access data 116 to the user device 108A. In some examples, the access data 116 may be associated with a password, code, key, or other unique identifier associated with the entity 106, [0029], lines 1-4).
Regarding claim 18, Ng et al discloses apparatus (fig. 1A item 104, Entity device), wherein the communications hardware (fig. 1A item 104, Entity device) is further configured to receive a service entity operation response from the service entity device, wherein (a) the service entity operation response is indicative that an operational flow corresponding to the service request type was successfully performed and (b) the service entity operation response comprises updated user account data (Based at least in part on receiving input indicating that the entity 106 desires (request) to temporarily provide access to the service functionality to user device 108A (corresponding to user 110A), the entity device 104 may provide access data 116 to the user device 108A. In some examples, the access data 116 may be associated with a password, code, key, or other unique identifier associated with the entity 106, [0029], lines 1-4);
wherein the interface circuitry is further configured to generate, based on the service entity configuration set and the service entity operation response, updated service entity user interface data ((e.g., via check-in(s), request(s) for access to functionality ((a) indication of a service entity identity) associated with an entity, etc.), [0027], 9-11); and
wherein the communications hardware (fig. 1A item 104, Entity device) is further configured to provide the updated service entity user interface data (Password, code, key, or other unique identifier may be input via a web interface to enable the user device 108A to temporarily access the inventory management application via the web interface, [0029], lines 7-9).
Regarding claim 19, Ng et al discloses apparatus (fig. 1A item 104, Entity device), wherein the communications hardware (fig. 1A item 104, Entity device) is further configured to:
receive a service entity instruction message from the service entity device, wherein the service entity instruction message comprises instructions to perform an interaction with the user (Based at least in part on receiving input indicating that the entity 106 desires (request) to temporarily provide access to the service functionality to user device 108A (corresponding to user 110A), the entity device 104 may provide access data 116 to the user device 108A. In some examples, the access data 116 may be associated with a password, code, key, or other unique identifier associated with the entity 106, [0029], lines 1-4); and
provide an instruction message to an agent device, wherein the instruction message comprises instructions to perform the interaction with the user (customer may acquire an item by purchasing the item, renting the item, leasing the item, etc. In at least one example, the entity 106 may be associated with one or more agents, such as sales associates, employees, independent contractors, etc., which may interact with entity device 104 on behalf of the entity, [0044], lines 2-4).
Regarding claim 20, Ng et al discloses computer program product for facilitating operations for a user with a service entity, the computer program product comprising at least one non-transitory computer-readable storage medium storing software instructions that, when executed, cause an apparatus to (“module” refers broadly to software stored on non-transitory storage medium (e.g., volatile or non-volatile memory for a computing device), hardware, or firmware (or any combination thereof) modules, [0064], lines 4-5):
receive a service entity request pertaining to the user within a proximity interaction region (entity device 104 may determine a presence of user device(s) 108 based on the user device(s) 108 expressly indicating presence at the location of the entity 106 (e.g., via check-in(s), request(s) for access to functionality (indication of a service entity identity) associated with an entity, etc., [0027], 9-11), wherein the service entity request comprises (a) an indication of a service entity identity that corresponds to a service entity of interest to the user ((e.g., via check-in(s), request(s) for access to functionality ((a) indication of a service entity identity) associated with an entity, etc.), [0027], 9-11), (b) a user identifier for the user ((e.g., via check-in(s) ((b) a user identifier for the user), request(s) for access to functionality associated with an entity, etc.), [0027], 9-11), and (c) a user credential ((e.g., via check-in(s) ((c) a user credential), request(s) for access to functionality associated with an entity, etc.), [0027], 9-11);
determine a service entity configuration set for the service entity, wherein the service entity configuration set is indicative of a service entity device that is associated with the service entity (Entity 106 may initiate a settling-up (configuration set) process to provide payment to the user 110A. Additionally, in some examples, the entity 106 may rate the user 110A based on his or her performance, efficiency, accuracy, etc, [0038], lines 3-5);
initiate a session with the service entity device using a session establishment request, wherein the session establishment request comprises the user identifier and the user credential (Based at least in part on receiving input indicating that the entity 106 desires (request) to temporarily provide access to the service functionality to user device 108A (corresponding to user 110A), the entity device 104 may provide access data 116 to the user device 108A. In some examples, the access data 116 may be associated with a password, code, key, or other unique identifier associated with the entity 106, [0029], lines 1-4);
receive a session establishment response from the service entity device, wherein in an instance in which the service entity device successfully authenticated the user, the service establishment response comprises (a) a session token and (b) user account data pertaining to a user account managed by the service entity and that corresponds to the user (The entity device 104 may provide (response) access data 116 to the user device 108A. In some examples, the access data 116 may be associated with a password, code ((b) user account data), key ((a) a session token), or other unique identifier associated with the entity 106, [0029], lines 2-4);
generate, based on the service entity configuration set and the user account data, service entity user interface data (Password, code, key, or other unique identifier may be input via a web interface to enable the user device 108A to temporarily access the inventory management application via the web interface, [0029], lines 7-9); and
Ng et al does not specifically disclose concept of provide the service entity user interface data.
However, Khullar et al specifically teaches concept of provide the service entity user interface data (At S210, a framework may provide a user with a graphical view of existing services (and entity and field-level mapping) across multiple layers and the User Interface (“UI”) with an example data model, [0039], lines 1-3).
At the time the invention was filed, it would have been obvious for one of ordinary skill in the art to have modified system of Ng et al with concept of provide the service entity user interface data of Khullar et al. One of ordinary skill in the art would have been motivated to make this modification in order to improve application to perform business function, (Khullar et al, [0001], line 1).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Ng et al (US 2021/0035055) in view of Khullar et al (US 2024/0095239) and further in view of Nathan et al (US 2015/0143487)
Regarding claim 9, Ng et al discloses method, further comprising (FIG. 3 depicts a non-limiting flow diagram illustrating a method, [0009], line 1):
Ng et al and Khullar et al do not specifically disclose concept of generating, by operations management circuitry, a virtual agent object comprising a default virtual avatar;
providing, by the communications hardware, the virtual agent object; and
in response to determining a service entity configuration set associated with the service entity, replacing, by the operations management circuitry, the default virtual avatar with a service entity virtual avatar described by the service entity configuration set.
However, Nathan et al specifically teaches concept of generating, by operations management circuitry, a virtual agent object comprising a default virtual avatar (generate the "physical embodiments" of Avatar 221a may render as 3D with facial expression in one Virtual Environment 211b, but may need to be rendered as a 2D image for use as Avatar 221a in another of Virtual Environments 211a to 215n, [0071], lines 17-19);
providing, by the communications hardware, the virtual agent object (Author Tools 332a to 332p provides user management of the Persistent Avatar 221a. In some embodiments, each Customer 130 may own or use multiple Persistent Avatars 221a to 221t, [0069], lines 4-6); and
in response to determining a service entity configuration set associated with the service entity, replacing, by the operations management circuitry, the default virtual avatar with a service entity virtual avatar described by the service entity configuration set (At step 711 the Enabler 510 decodes the data and logs the Avatar 221a into the Virtual Environment 211b. The Avatar 221a incurs experiences within the Virtual Environment 211b which may result in changes made to the Avatar 221a. At step 712 the experiences within Virtual Environment 211b modify Avatar 221a data. In step 713 the enabler encodes the Avatar 221a data, including the modifications, for storage on the Server 121. In step 714 the Virtual Environment sends the Avatar 221a to 215n data over the WAN 101 to the Server 121. The Server 121 then stores the Avatar 221a data, thereby incorporating changes made to the Avatar 221a within the Virtual Environment 211b, [0086], lines 1-6).
At the time the invention was filed, it would have been obvious for one of ordinary skill in the art to have modified system of Ng et al with concept of providing, by the communications hardware, the service entity user interface data of Khullar et al and concept of generating, by operations management circuitry, a virtual agent object comprising a default virtual avatar; providing, by the communications hardware, the virtual agent object; and in response to determining a service entity configuration set associated with the service entity, replacing, by the operations management circuitry, the default virtual avatar with a service entity virtual avatar described by the service entity configuration set of Nathan et al. One of ordinary skill in the art would have been motivated to make this modification in order to improve authenticating an avatar with reputation information from a centralized identity provider, (Nathan et al, [0002], line 2)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FRANTZ BATAILLE whose telephone number is (571)270-7286. The examiner can normally be reached Monday-Friday 9:00 AM-5:00 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, Akwasi Sarpong can be reached on 571-270-3438. 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.
/FRANTZ BATAILLE/ Primary Examiner, Art Unit 2681