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 .
DETAILED ACTION
Status of Claims
Claims 1, 3-8, 10, 12-15 are subject to examination. Claims 2, 9, 11 are cancelled.
The title dated 8/1/25 is acknowledged.
Election/Restrictions
Applicant’s response dated 12/9/25 is persuasive, the restriction requirement as set forth in the Office action mailed on 9/10/25 is hereby withdrawn, and hence 1, 3-8, 10, 12-15 are hereby rejoined and fully examined for patentability under 37 CFR 1.104.
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 of this title, 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, 4, 5, 8, 12, 15, is/are rejected under 35 U.S.C. 103 as being unpatentable over PREZET et al., FR 3098943 A1 in view of Mathur et al., 20210152643.
Referring to claim(s) 1, 8, 15, PREZET substantially discloses A data exchange system, the system comprising: at least one content provider; at least one content receiver; and a communication platform for connecting the at least one content provider to the at least one content receiver, the communication platform configured to: characterised in that the communication platform is configured for transmitting data between a content provider and a content receiver, A method of exchanging data via a virtual channel, wherein the method is executed at a communication platform for connecting at least one content provider to at least one content receiver, the method comprising: A non-transitory computer readable medium storing computer- readable instructions executable by a computer for connecting at least one content provider to at least one content receiver, wherein execution of the instructions by the computer configure the computer to:
To differentially respond to data requests, a request manager server stores a set of predefined response definitions, each response definition having a distinct assigned virtual requestor identifier; and for each virtual requestor identifier, a selection criterion. The server receives a data request associated with one of a plurality of requesters, the data request including request parameters and a set of requestor attributes. The server compares all the attributes of the requester with the selection criteria; based on the comparison, assigns a selected identifier of the virtual requestor identifiers to the data request; retrieves one of the active response definitions corresponding to the selected virtual requestor identifier; obtains response data based on query parameters and the active response definition; and transmits, in response to the data request, the response data, abstract
maintain predefined authentication conditions associated with the content provider; receive a request from a first content receiver; determine whether an attribute distinct from an identifier of the first content receiver satisfies the predefined authentication conditions; and when an attribute satisfies the predefined authentication conditions, transmitting data between a content provider and the first content receiver (
a plurality of Global Distribution Systems (GDSs), e.g. each implemented by servers or more typically a network of servers, receive data requests from the requesters 108. Each GDS also obtains, either directly from suppliers (e.g. airlines) or more typically from third party publishers, fare and scheduling information (i.e. at least a portion of the source data in the repositories 116 and 124). Such information defines rules specifying which requesters 108 have access to which flights and/or fares. For example, some requesters 108 may have negotiated pricing agreements with one or more suppliers. Such agreements may grant the requester access to discounted pricing, 3rd para, page 5
Each GDS typically assigns authentication and/or connection credentials to each requester 108 that the GDS serves. Upon receiving a request from a requester 108, a given GDS processes the above-mentioned rules according to the identity of the requester 108 to generate a response. The GDS therefore also responds differentially to data requests from the requesters 108 that it serves. That is, two requesters 108 requesting flights on the same dates between the same endpoints may receive different offers based on the above agreements, as implemented at the GDS server via the fare and scheduling data, 4th para, page 5
the server provide fare and scheduling information to a set of GDSs or third-party publishers. The server as contemplated by the New Distribution Capability (NDC) standard, is directly responsible for receiving data requests and generating responses to the requests. Shifting responsibility for response generation to the supplier, 5rd para, page 5,
The server 104 to receive a data request, such as a request for travel product offers The server 104 to compare a requester attribute set of the request to the selection criteria 132, and based on the comparison, to assign one of the virtual requester identifiers to the request. Further, the server 104 is to retrieve an active response definition from the response definition set 128, and to generate a response to the request according to the active response definition. The response definitions may themselves require the execution of additional applications, such as example response component generator applications 216 and 220 shown in FIG. 2. The applications 216 and 220 may be responsible for a wide variety of response generation actions, such as ancillary service selection, pricing selection, and the like. Such applications may also reside outside the server 104, for example at the auxiliary server 120.
The server 104 compares the requester attribute set of the request received at block 305 with the selection criteria 132. The selection criteria 132, in general, define one or more conditions for each virtual requester identifier employed by the server 104. When the requester attributes of the request satisfy the conditions corresponding to a virtual requester identifier, that virtual requester identifier is assigned to the request, last para, page 5
selection criteria are shown for two virtual requester identifiers 500-1 and 500-2. When the requester type is “TMC”, the virtual requester identifier 500-1 is assigned to the request. When the requester type is “META”, on the other hand (e.g. for metasearch requesters, such as the requester 108-1 shown in FIG. 1), the virtual requester identifier 500-2 is assigned to the request. The virtual requester identifiers 500 can take a variety of forms. In the present example, the virtual requester identifiers are pseudo-city-codes (PCCs), which may also be referred to as OfficeIDs, employed by various travel product suppliers to identify entities such as travel agents, 2nd para, page 8
PREZET does not disclose, which Mathur discloses create a virtual channel (
[0006] The devices establish one or more virtual channels for wireless communications over a physical wireless channel (e.g., a frequency channel), by which pairs of these processors, each of the processors belonging to a separate one of the devices, may exchange application data. As such, each virtual channel enables point-to-point communication between individual processors located on different devices of the AR system. Virtual channels may be implemented using different sets of features, such as different encryption policies, security key-pairs, qualities of service, etc. The devices execute a virtual channel protocol that uses header information for wirelessly transmitted fragments to specify which features to apply and to identify a destination processor. Accordingly, each virtual channel may be independently encrypted/decrypted to provide secure communications between pairs of processors with reduced—and in some cases, minimal—copying of packetized data within each device of the AR system.
[0053] In some examples, each of the devices of the AR system 10 may include a supervisory processor (e.g., supervisory processor 224 and supervisory processor 226) in addition to the various processors that generate and/or consume application data. HMD 112 includes supervisory processor 224 to manage components of HMD 112, such as processors of SoCs of HMD 112. Peripheral device 136 includes supervisory processor 226 to manage components of peripheral device 136, such as processors of SoCs of peripheral device 136. Supervisory processor 224 and supervisory processor 226 may establish virtual channels for processors of HMD 112 to exchange data with processors of peripheral device 136. Supervisory processor 224 may utilize an encryption/decryption processor to establish a secure virtual channel between HMD 112 and peripheral device 136.
[0054] One operation of supervisory processor 224 and/or supervisory processor 226 is to manage wireless communications with another device of the AR system, for instance, by establishing a virtual channel to enable point-to-point wireless communications between devices within the AR system. It is appreciated that virtual channels can be implemented using different sets of features where each set of features includes an encryption policy, a security key-pair, a quality of service, etc. In one example, a source processor of one device requests a virtual channel from the supervisory processor..
[0037] virtual channels for wireless communications between multiple devices, such as peripheral device 136 operating as a co-processing AR device when operationally paired with one or more HMDs, e.g., HMD 112. Although the techniques described herein are described with respect to virtual channels for wireless communications between a peripheral device 136 and one or more HMDs, the techniques may apply to any devices that may be paired in AR system 10.
[0038] When peripheral device 136 and HMD 112 engage in wireless communications, components within peripheral device 136 and HMD 112 may provide virtual channels to provide wireless communications between pairs of processors executing in multiple devices. Each processor within each of peripheral device 136 and HMD 112 may require that each other of the processors be identified by a supervisory processor.
[0132] The wireless handler processes a wireless communication comprising a fragment of an application payload (1000). The wireless communication may be in the form of a data unit, such as a network packet, transmitted via a physical wireless link between a first device and a second device of artificial reality system 500. The data unit may partitioned into a header portion and a data portion in which the fragment is encapsulated. The header portion is arranged to store attributes describing the fragment of the application payload. The attributes in the header portion, which may also be known as header information, include (but not limited to) a source identifier, a destination identifier, a stream identifier, a (fragment) sequence number, etc. [0082] Both wireless handler 350A and wireless handler 350B implement a virtual channel communication protocol permitting the exchange of application data between the above-mentioned pairs of processors.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by PREZET to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing the creating of a virtual channel.
One of ordinary skilled in the art would readily know what a virtual channel is.
A virtual channel is a logical communication pathway between two or more network devices or system components that allows data to be transmitted over a shared physical link. It is often used in connection-oriented networks, such as those using TCP, to provide reliable, ordered delivery of data. Hence, the created virtual channel would enable reliable delivery of the data, para 6.
Referring to claim 4, Mathur discloses wherein the communication platform comprises a plurality of rules, wherein the rules activate which authentication conditions are used to create the virtual channel (
[0006] The devices establish one or more virtual channels for wireless communications over a physical wireless channel (e.g., a frequency channel), by which pairs of these processors, each of the processors belonging to a separate one of the devices, may exchange application data. As such, each virtual channel enables point-to-point communication between individual processors located on different devices of the AR system. Virtual channels may be implemented using different sets of features, such as different encryption policies, security key-pairs, qualities of service, etc. The devices execute a virtual channel protocol that uses header information for wirelessly transmitted fragments to specify which features to apply and to identify a destination processor. Accordingly, each virtual channel may be independently encrypted/decrypted to provide secure communications between pairs of processors with reduced—and in some cases, minimal—copying of packetized data within each device of the AR system.
Referring to claim 5, 12, Mathur discloses wherein the authentication conditions comprise a combination of a content receiver connectivity identification with a content receiver identification
[0054] One operation of supervisory processor 224 and/or supervisory processor 226 is to manage wireless communications with another device of the AR system, for instance, by establishing a virtual channel to enable point-to-point wireless communications between devices within the AR system. It is appreciated that virtual channels can be implemented using different sets of features where each set of features includes an encryption policy, a security key-pair, a quality of service, etc. In one example, a source processor of one device requests a virtual channel from the supervisory processor, which (in turn) exchanges a stream identifier for the virtual channel with a supervisory processor of a destination processor of the other device. To manage wireless communications of the application data between the source processor and the destination processor, one or both supervisory processors may allocate a portion of shared memory within their respective device.
[0006] In some examples, each of the devices of the AR system may include one or more processors that generate and consume application data. The devices establish one or more virtual channels for wireless communications over a physical wireless channel (e.g., a frequency channel), by which pairs of these processors, each of the processors belonging to a separate one of the devices, may exchange application data. As such, each virtual channel enables point-to-point communication between individual processors located on different devices of the AR system. Virtual channels may be implemented using different sets of features, such as different encryption policies, security key-pairs, qualities of service, etc. The devices execute a virtual channel protocol that uses header information for wirelessly transmitted fragments to specify which features to apply and to identify a destination processor. Accordingly, each virtual channel may be independently encrypted/decrypted to provide secure communications between pairs of processors with reduced—and in some cases, minimal—copying of packetized data within each device of the AR system.
Claim(s) 3, 10, is/are rejected under 35 U.S.C. 103 as being unpatentable over Marthur in view of PREZET and Stoyanov et al., 20070244966.
Referring to claim 3, 10, Marthur and PREZET does not disclose, which Stoyanov discloses wherein the virtual channel is closed after transmitting the data
[0070] For example, OnClose can then transfer the intention to close the dynamic virtual channel to client component 353 (act 310). Similarly, it may that client component 353 receives a channel close command for the dynamic virtual channel (act 311). OnClose can then transfer the intention to close the dynamic virtual channel to server component 351
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Marthur to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing the closing of the channel. The closing would enable free us resources associated with the virtual channel for dynamic implementation, para 70.
Claim(s) 6, 13, is/are rejected under 35 U.S.C. 103 as being unpatentable over Marthur in view of PREZET and CHO, KR 102007995 B1 2019.
Referring to claim 6, 13, Marthur and PREZET does not disclose, which Cho discloses flight information and wherein the virtual channel specifies fares for the flight information to transmit (
a plurality of virtual multis for a ticket reservation request message of which a seat reservation probability 700 of the seats to be reserved by the ticket reservation request message included in the first priority exceeds a threshold value. By setting up a channel, multiple ticket reservation request messages can be delivered more quickly at the same time. The virtual multi-channel may be a channel for simultaneously processing a plurality of ticket reservation request messages through a plurality of virtual PCC value assignments by the ticket service server. The number of virtual multi-channels may be continuously changed according to the number of ticket reservation request messages whose seat reservation probability 700 exceeds a threshold. In this virtual multi-channel, when performing a search request, the ticket service server may be predetermined by collecting information on the remaining seats of the searched aircraft. That is, the number of ticket reservation request messages to be determined as the first priority during the threshold time is predicted in advance, and the number of the virtual multi-channels determined during the threshold time according to the prediction may be maintained. The determined number of virtual multi-channels may be the maximum value of the number of ticket reservation request messages to be determined as the first priority, 3rd last para, page 8,
The integrated flight reservation management server may search for a ticket meeting a condition based on the search request ticket search information included in the ticket search request message and the PCC information of the travel agency A. In this case, the integrated flight reservation management server may search flight schedules and search flight schedules based on flight schedules, baseline fare for each flight schedule, and travel agency A's rate calculation information (for example, A travel agency discount information and A travel agency fee information). The search fee information can be determined, last fifth para, page 3,
The integrated flight reservation management server may transmit a ticket search result message including the search flight schedule and the search fare information to the ticket service server (step S230). The ticket service server may transmit the flight schedule and the search fare information to the user device of the travel agency A customer (step S240), 4th last para, page 3,
The user device of the travel agency A customer may receive a ticket search result message, select a desired ticket, and send a ticket reservation request message including information on the selected flight schedule and the selected fare to the ticket service server to request a ticket reservation ( Step S250), 3th last para, page 3,
The integrated flight reservation management server and the plurality of travel agency-specific pricing information may be linked to each other, so that a plurality of travel agency-specific airfares may be delivered to customers of each of the plurality of travel agencies. For example, if a customer of travel agency A sends a ticket search request message that includes travel agency identification information such as pseudo city code (PCC) information, the integrated airline reservation management server identifies travel agency A based on travel agency A's PCC. Then, the search fare information according to the search flight schedule and the search flight schedule may be determined based on the fare calculation information of the travel agency A (for example, A travel agency discount information and A travel agency fee information) (step S330), last para, page 3,
In more detail, the customer 400 of the travel agency A may be provided with information about an departure schedule / return schedule, a time required, a stopover, flight information, a fare rule, a total fare, a detailed fare, etc. for each airline through the user device, 6th para, page 5.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Marthur to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing the virtual channel with fares for the flight information. The virtual channel would enable communicating the flight information among devices for making the flight ticket reservation for travel, which include the schedule, fare rules, total fare and discount, 3rd last para, page 8.
Claim(s) 7, 14, 15, is/are rejected under 35 U.S.C. 103 as being unpatentable over Marthur in view of PREZET, CHO amd DONOGHUE et al., 20190014368.
Referring to claims 7, 14, Marthur, PREZET and CHO does not disclose, which DONOGHUE discloses a rule engine and wherein the rule engine generates keywords as authentication conditions (
[0330] Another rule implemented by the rules engine may comprise providing a virtual channel (a VPMC) of recommended content only to certain classes of subscribers (e.g., those at a premium level of service, or subscribers who have “opted-in” to receiving the channel), those in a particular geographic or network service area, those requesting at a particular time of day or day of the week, etc.
[0327] In another aspect of the invention, the aforementioned recommendation engine 601 (rendered as one or more computer programs disposed on e.g., the server 700 and/or the CPE 106) includes a so-called “rules” engine. These rules may be fully integrated within various entities associated with the present invention, or may be associated with the recommendation engine 601 itself, and controlled via e.g., the aforementioned interfaces 470. In effect, the rules engine comprises a supervisory entity which monitors and selectively controls the content recommendation functions at a higher level, so as to implement desired operational or business rules. The rules engine can be considered an overlay of sorts to the recommendation and playlist/EPG population algorithms. For example, the recommendation engine 601 may make certain recommendations or playlist collections based on the user profile(s) of interest and the metadata associated with particular content elements. However, these recommendations may not always be compatible with higher-level business or operational goals, such as maximizing profit/revenue, best use of network resources, or system reliability. Hence, when imposed, the business/operational rules can be used to dynamically and transparently (or manually) control the operation of the recommendation engine 601. The rules may be, e.g., operational or business-oriented in nature, or related to preservation of security, and may also be applied selectively in terms of time of day, duration, specific local areas, or even at the individual premises or user level.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Marthur to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing rule engine for creating conditions. The conditions would enable verifying data associated with authentication. This would enable deciding whether the user is an authorized user or not for secure access to the content, para 327.
Claim(s) 1, 4, 5, 8, 12, 15, is/are rejected under 35 U.S.C. 103 as being unpatentable over PREZET et al., FR 3098943 A1 in view of WU et al., CN 108924059 A.
Referring to claim(s) 1, 8, 15, PREZET substantially discloses A data exchange system, the system comprising: at least one content provider; at least one content receiver; and a communication platform for connecting the at least one content provider to the at least one content receiver, the communication platform configured to: characterised in that the communication platform is configured for transmitting data between a content provider and a content receiver, A method of exchanging data via a virtual channel, wherein the method is executed at a communication platform for connecting at least one content provider to at least one content receiver, the method comprising: A non-transitory computer readable medium storing computer- readable instructions executable by a computer for connecting at least one content provider to at least one content receiver, wherein execution of the instructions by the computer configure the computer to:
To differentially respond to data requests, a request manager server stores a set of predefined response definitions, each response definition having a distinct assigned virtual requestor identifier; and for each virtual requestor identifier, a selection criterion. The server receives a data request associated with one of a plurality of requesters, the data request including request parameters and a set of requestor attributes. The server compares all the attributes of the requester with the selection criteria; based on the comparison, assigns a selected identifier of the virtual requestor identifiers to the data request; retrieves one of the active response definitions corresponding to the selected virtual requestor identifier; obtains response data based on query parameters and the active response definition; and transmits, in response to the data request, the response data, abstract
maintain predefined authentication conditions associated with the content provider; receive a request from a first content receiver; determine whether an attribute distinct from an identifier of the first content receiver satisfies the predefined authentication conditions; and when an attribute satisfies the predefined authentication conditions, transmitting data between a content provider and the first content receiver (
a plurality of Global Distribution Systems (GDSs), e.g. each implemented by servers or more typically a network of servers, receive data requests from the requesters 108. Each GDS also obtains, either directly from suppliers (e.g. airlines) or more typically from third party publishers, fare and scheduling information (i.e. at least a portion of the source data in the repositories 116 and 124). Such information defines rules specifying which requesters 108 have access to which flights and/or fares. For example, some requesters 108 may have negotiated pricing agreements with one or more suppliers. Such agreements may grant the requester access to discounted pricing, 3rd para, page 5
Each GDS typically assigns authentication and/or connection credentials to each requester 108 that the GDS serves. Upon receiving a request from a requester 108, a given GDS processes the above-mentioned rules according to the identity of the requester 108 to generate a response. The GDS therefore also responds differentially to data requests from the requesters 108 that it serves. That is, two requesters 108 requesting flights on the same dates between the same endpoints may receive different offers based on the above agreements, as implemented at the GDS server via the fare and scheduling data, 4th para, page 5
the server provide fare and scheduling information to a set of GDSs or third-party publishers. The server as contemplated by the New Distribution Capability (NDC) standard, is directly responsible for receiving data requests and generating responses to the requests. Shifting responsibility for response generation to the supplier, 5rd para, page 5,
The server 104 to receive a data request, such as a request for travel product offers The server 104 to compare a requester attribute set of the request to the selection criteria 132, and based on the comparison, to assign one of the virtual requester identifiers to the request. Further, the server 104 is to retrieve an active response definition from the response definition set 128, and to generate a response to the request according to the active response definition. The response definitions may themselves require the execution of additional applications, such as example response component generator applications 216 and 220 shown in FIG. 2. The applications 216 and 220 may be responsible for a wide variety of response generation actions, such as ancillary service selection, pricing selection, and the like. Such applications may also reside outside the server 104, for example at the auxiliary server 120.
The server 104 compares the requester attribute set of the request received at block 305 with the selection criteria 132. The selection criteria 132, in general, define one or more conditions for each virtual requester identifier employed by the server 104. When the requester attributes of the request satisfy the conditions corresponding to a virtual requester identifier, that virtual requester identifier is assigned to the request, last para, page 5
selection criteria are shown for two virtual requester identifiers 500-1 and 500-2. When the requester type is “TMC”, the virtual requester identifier 500-1 is assigned to the request. When the requester type is “META”, on the other hand (e.g. for metasearch requesters, such as the requester 108-1 shown in FIG. 1), the virtual requester identifier 500-2 is assigned to the request. The virtual requester identifiers 500 can take a variety of forms. In the present example, the virtual requester identifiers are pseudo-city-codes (PCCs), which may also be referred to as OfficeIDs, employed by various travel product suppliers to identify entities such as travel agents, 2nd para, page 8
PREZET does not disclose, which WU discloses create a virtual channel (1st para, page 3).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by PREZET to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing the creating of a virtual channel.
One of ordinary skilled in the art would readily know what a virtual channel is.
A virtual channel is a logical communication pathway between two or more network devices or system components that allows data to be transmitted over a shared physical link. It is often used in connection-oriented networks, such as those using TCP, to provide reliable, ordered delivery of data. Hence, the created virtual channel would enable reliable delivery of the data, 1st para, page 3.
Response to Arguments
Applicant’s remarks/arguments dated 12/9/25 with respect to amended claim(s) dated 8/1/25 have been considered. It is noted that the Applicant has amended the claims in response to the prior office action. Accordingly, the above rejections in this office action (over prior rejections) are applied in order to address the claim amendments, and also the arguments that are made in view of the amended claims. Please refer to the updated rejections for the amended limitations.
PREZET substantially discloses A data exchange system, the system comprising: at least one content provider; at least one content receiver; and a communication platform for connecting the at least one content provider to the at least one content receiver, the communication platform configured to: characterised in that the communication platform is configured for transmitting data between a content provider and a content receiver, A method of exchanging data via a virtual channel, wherein the method is executed at a communication platform for connecting at least one content provider to at least one content receiver, the method comprising: A non-transitory computer readable medium storing computer- readable instructions executable by a computer for connecting at least one content provider to at least one content receiver, wherein execution of the instructions by the computer configure the computer to:
To differentially respond to data requests, a request manager server stores a set of predefined response definitions, each response definition having a distinct assigned virtual requestor identifier; and for each virtual requestor identifier, a selection criterion. The server receives a data request associated with one of a plurality of requesters, the data request including request parameters and a set of requestor attributes. The server compares all the attributes of the requester with the selection criteria; based on the comparison, assigns a selected identifier of the virtual requestor identifiers to the data request; retrieves one of the active response definitions corresponding to the selected virtual requestor identifier; obtains response data based on query parameters and the active response definition; and transmits, in response to the data request, the response data, abstract
maintain predefined authentication conditions associated with the content provider; receive a request from a first content receiver; determine whether an attribute distinct from an identifier of the first content receiver satisfies the predefined authentication conditions; and when an attribute satisfies the predefined authentication conditions, transmitting data between a content provider and the first content receiver (
a plurality of Global Distribution Systems (GDSs), e.g. each implemented by servers or more typically a network of servers, receive data requests from the requesters 108. Each GDS also obtains, either directly from suppliers (e.g. airlines) or more typically from third party publishers, fare and scheduling information (i.e. at least a portion of the source data in the repositories 116 and 124). Such information defines rules specifying which requesters 108 have access to which flights and/or fares. For example, some requesters 108 may have negotiated pricing agreements with one or more suppliers. Such agreements may grant the requester access to discounted pricing, 3rd para, page 5
Each GDS typically assigns authentication and/or connection credentials to each requester 108 that the GDS serves. Upon receiving a request from a requester 108, a given GDS processes the above-mentioned rules according to the identity of the requester 108 to generate a response. The GDS therefore also responds differentially to data requests from the requesters 108 that it serves. That is, two requesters 108 requesting flights on the same dates between the same endpoints may receive different offers based on the above agreements, as implemented at the GDS server via the fare and scheduling data, 4th para, page 5
the server provide fare and scheduling information to a set of GDSs or third-party publishers. The server as contemplated by the New Distribution Capability (NDC) standard, is directly responsible for receiving data requests and generating responses to the requests. Shifting responsibility for response generation to the supplier, 5rd para, page 5,
The server 104 to receive a data request, such as a request for travel product offers The server 104 to compare a requester attribute set of the request to the selection criteria 132, and based on the comparison, to assign one of the virtual requester identifiers to the request. Further, the server 104 is to retrieve an active response definition from the response definition set 128, and to generate a response to the request according to the active response definition. The response definitions may themselves require the execution of additional applications, such as example response component generator applications 216 and 220 shown in FIG. 2. The applications 216 and 220 may be responsible for a wide variety of response generation actions, such as ancillary service selection, pricing selection, and the like. Such applications may also reside outside the server 104, for example at the auxiliary server 120.
The server 104 compares the requester attribute set of the request received at block 305 with the selection criteria 132. The selection criteria 132, in general, define one or more conditions for each virtual requester identifier employed by the server 104. When the requester attributes of the request satisfy the conditions corresponding to a virtual requester identifier, that virtual requester identifier is assigned to the request, last para, page 5
selection criteria are shown for two virtual requester identifiers 500-1 and 500-2. When the requester type is “TMC”, the virtual requester identifier 500-1 is assigned to the request. When the requester type is “META”, on the other hand (e.g. for metasearch requesters, such as the requester 108-1 shown in FIG. 1), the virtual requester identifier 500-2 is assigned to the request. The virtual requester identifiers 500 can take a variety of forms. In the present example, the virtual requester identifiers are pseudo-city-codes (PCCs), which may also be referred to as OfficeIDs, employed by various travel product suppliers to identify entities such as travel agents, 2nd para, page 8
PREZET does not disclose, which Mathur discloses create a virtual channel (
[0006] The devices establish one or more virtual channels for wireless communications over a physical wireless channel (e.g., a frequency channel), by which pairs of these processors, each of the processors belonging to a separate one of the devices, may exchange application data. As such, each virtual channel enables point-to-point communication between individual processors located on different devices of the AR system. Virtual channels may be implemented using different sets of features, such as different encryption policies, security key-pairs, qualities of service, etc. The devices execute a virtual channel protocol that uses header information for wirelessly transmitted fragments to specify which features to apply and to identify a destination processor. Accordingly, each virtual channel may be independently encrypted/decrypted to provide secure communications between pairs of processors with reduced—and in some cases, minimal—copying of packetized data within each device of the AR system.
[0053] In some examples, each of the devices of the AR system 10 may include a supervisory processor (e.g., supervisory processor 224 and supervisory processor 226) in addition to the various processors that generate and/or consume application data. HMD 112 includes supervisory processor 224 to manage components of HMD 112, such as processors of SoCs of HMD 112. Peripheral device 136 includes supervisory processor 226 to manage components of peripheral device 136, such as processors of SoCs of peripheral device 136. Supervisory processor 224 and supervisory processor 226 may establish virtual channels for processors of HMD 112 to exchange data with processors of peripheral device 136. Supervisory processor 224 may utilize an encryption/decryption processor to establish a secure virtual channel between HMD 112 and peripheral device 136.
[0054] One operation of supervisory processor 224 and/or supervisory processor 226 is to manage wireless communications with another device of the AR system, for instance, by establishing a virtual channel to enable point-to-point wireless communications between devices within the AR system. It is appreciated that virtual channels can be implemented using different sets of features where each set of features includes an encryption policy, a security key-pair, a quality of service, etc. In one example, a source processor of one device requests a virtual channel from the supervisory processor..
[0037] virtual channels for wireless communications between multiple devices, such as peripheral device 136 operating as a co-processing AR device when operationally paired with one or more HMDs, e.g., HMD 112. Although the techniques described herein are described with respect to virtual channels for wireless communications between a peripheral device 136 and one or more HMDs, the techniques may apply to any devices that may be paired in AR system 10.
[0038] When peripheral device 136 and HMD 112 engage in wireless communications, components within peripheral device 136 and HMD 112 may provide virtual channels to provide wireless communications between pairs of processors executing in multiple devices. Each processor within each of peripheral device 136 and HMD 112 may require that each other of the processors be identified by a supervisory processor.
[0132] The wireless handler processes a wireless communication comprising a fragment of an application payload (1000). The wireless communication may be in the form of a data unit, such as a network packet, transmitted via a physical wireless link between a first device and a second device of artificial reality system 500. The data unit may partitioned into a header portion and a data portion in which the fragment is encapsulated. The header portion is arranged to store attributes describing the fragment of the application payload. The attributes in the header portion, which may also be known as header information, include (but not limited to) a source identifier, a destination identifier, a stream identifier, a (fragment) sequence number, etc. [0082] Both wireless handler 350A and wireless handler 350B implement a virtual channel communication protocol permitting the exchange of application data between the above-mentioned pairs of processors.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by PREZET to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing the creating of a virtual channel.
One of ordinary skilled in the art would readily know what a virtual channel is.
A virtual channel is a logical communication pathway between two or more network devices or system components that allows data to be transmitted over a shared physical link. It is often used in connection-oriented networks, such as those using TCP, to provide reliable, ordered delivery of data. Hence, the created virtual channel would enable reliable delivery of the data, para 6.
Conclusion
Applicant's amendment (dated 8/1/25 in response to the non final office action dated 4/3/25, necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 HARESH PATEL whose telephone number is (571)272-3973. The examiner can normally be reached on M-F 9-5:30.
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, Jorge L. Ortiz-Criado, can be reached at (571) 272-7624. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HARESH N PATEL/Primary Examiner, Art Unit 2496
Prosecution Insights